Writing Requirements That Survive

A requirements document assembled from vendor feature lists selects for the vendor whose list you copied. The useful version describes your situation, not their capabilities.

Start from the work, not the features

Who records time, how many of them, and in what circumstances? Desk workers, field workers, shift workers and contractors have almost nothing in common as users.

When do they record it? In the moment, daily, or at the end of a week.

What must the record feed? Payroll, invoices, project costing, statutory records — name the actual systems.

What rules apply? Overtime thresholds, break handling, rounding, rest periods, by jurisdiction.

What must never happen? The negative requirements are the ones that get forgotten and the ones that matter in a dispute.

Separate must from want

Must: the deployment fails without it. Usually fewer than ten items.

Want: improves things, does not decide the purchase.

Will not: explicitly excluded. Screen capture, activity scoring, automatic idle deduction belong here if you have decided against them, and writing them down stops them arriving enabled.

A document where everything is a must is a document that has not been thought about, and vendors recognise it immediately.

The requirements people forget

Consistently, across implementations.

Worker access to their own record, which in several jurisdictions is part of the legal standard rather than a feature.

An audit trail on edits: who changed what, when, and why.

Offline operation, for anyone not at a desk.

Bulk correction, because a misconfigured rule will need unwinding across a period.

Export of everything, including the audit trail, in a format something else can read.

Retention configurable per data category, not one global setting.

Support for the rules in every jurisdiction you employ in, which is where multi-country deployments come apart.

Write the hard cases down

The specific situations that will break a generic product.

Someone working across two projects in one hour. A shift that crosses midnight. A break that was interrupted. A contractor invoicing in a different currency. A correction after payroll has run.

Give these to vendors as scenarios and ask them to demonstrate each, rather than asking whether the feature exists. The answer to "can it handle split shifts" is always yes; the demonstration is where you find out what that means.

Size it honestly

Number of people recording, now and in three years.

Number of entries per person per week, which drives the licence cost far more than headcount in some pricing models.

Number of jurisdictions, projects and rate structures.

Volume of history to migrate.

These four numbers change which products are viable, and giving them to a vendor early saves everyone a month.

Hard cases as scenarios

The format that makes a requirements document testable.

Write each awkward situation as a scenario rather than as a feature.

Not "must support split shifts" but: a person works 22:00 to 02:00, then 06:00 to 10:00 the next morning, in a jurisdiction with an eleven-hour rest minimum. Show me the record, the rest calculation and the payroll export.

Hand the scenarios to vendors and require a demonstration.

The answer to a feature question is always yes. The demonstration is where you find out what yes meant.

Keep it short enough to be read

A specification nobody reads selects nothing.

Ten mandatory requirements, not eighty.

Each one testable: a vendor can demonstrate it or cannot.

Scenarios rather than feature names for anything involving rules.

The exclusions on the same page, not in an appendix.

A document a vendor can respond to properly in a week gets better answers than one that takes a month and is answered by a template.

Write integration requirements as outcomes

Instead of asking for a named connector, describe the record that must arrive. This example can be converted into inputs, outputs and failure criteria.