A Requirement Is a Contract, Not a Wish List
Ask an engineer what a requirements document is for and they will usually say "documentation". That is the least important thing it does. A requirements document is a contract — and its real value is not what it records, but what it prevents.
Treat requirements as documentation and you get a file nobody reads. Treat them as a contract and you get alignment, de-risking, and a reference point that settles arguments before they become expensive.
If it is not written and agreed, it does not exist
A requirement that lives only in someone’s head is not a requirement; it is a hope. Two people can sit in the same meeting and leave with two different memories of what was decided. Six months later, both of them will be certain — and both will be wrong.
The written, agreed requirement is the only version of the decision that survives contact with time and turnover. It is the thing everyone can point to when the memory fades.
What a contract does for a project
- It makes disagreements explicit while they are still cheap — better to argue about a sentence than about a shipped system.
- It defines "done" — the spec is the finish line everyone is running toward.
- It prevents scope creep — new work is a change to the contract, and changes are visible, not absorbed silently.
- It protects against turnover — the next person inherits the agreement, not the memory of it.
- It is the neutral referee — when stakeholders disagree, the written spec says what was actually agreed.
The social function nobody talks about
A contract’s most valuable effect is social, not technical. Writing a requirement forces the customer, the builder, and the buyer to face their disagreement at the moment it is cheapest. The customer who has to sign a sentence like "the system shall support 500 concurrent users" either agrees, negotiates, or admits the number was never thought through — and all three outcomes are better than finding out after launch.
The spec is not just a list of features. It is the artifact that turns a collection of individuals with different goals into a team with a shared one.
Signing it changes behaviour
There is a measurable difference between a spec that people nodded at and one they signed. The act of agreeing in writing changes how people behave: they read more carefully, push back earlier, and feel bound afterward. Ambiguity that survives a signature becomes a shared commitment — and a shared commitment is what a project actually runs on.
That is why the approval step matters as much as the writing step. A requirement nobody agreed to is not yet a requirement.