Requirements That Outlive The Sign-Off Meeting That Wrote It

Originally published at badna.pinnacletechsolutions.co.uk. This is a shortened version.

Every business analyst has watched the same thing happen. A requirement gets agreed in a workshop, written up, signed off by a stakeholder who nods at the summary slide, and handed to a delivery team as a line in a backlog. Three sprints later a developer asks what "the system shall support bulk upload" actually means, and nobody in the room was at the workshop.

Why sign-off prose decays

A requirement written for sign-off is optimised for one reader at one moment: the stakeholder deciding whether to approve it. It compresses a lot of context into a short sentence because everyone in that room shares the context. Delivery teams read the sentence months later, out of the room, without the shared assumptions that made it clear.

The shape that survives

What survives is a requirement written as a testable condition rather than an intent statement. The rewrite is mechanical once you know to look for it: replace a verb that describes a wish ("shall support", "shall enable", "shall allow") with a verb that describes an observable outcome, and attach the specific inputs and outputs that make the outcome checkable.

Take "the system shall support bulk upload." Rewritten as acceptance criteria:

Given a CSV file of up to 5,000 rows in the agreed column format
When a user uploads the file through the import screen
Then every valid row is created as a new record within two minutes
And every invalid row is reported by row number and reason, without stopping the valid rows

A developer reading this eight months later can build against it without a single follow-up question, because "bulk" and "support" are gone, replaced by a row count, a time bound and an explicit statement of what happens to the rows that fail.

The rewrite happens once, and it happens before sign-off, not after. A stakeholder who signs off on the acceptance-criteria version has actually agreed to the two-minute bound and the row-by-row error reporting, not to a vague promise a developer will later have to interpret alone.

The full article also covers where the rewrite sits in the process, and the stakeholder-management half that keeps it honest rather than merely more precise.

Read the full article at badna.pinnacletechsolutions.co.uk/blog/requirements-that-survive-delivery/.