Requirements that survive contact with delivery

The requirement was clear. Everyone agreed it was clear. It got built, and the thing that arrived wasn’t the thing anyone had in mind.

If you’ve worked in delivery you’ve seen this often enough that "write clearer requirements" has stopped sounding like advice. The document wasn’t unclear — it was silent on the one question that came up, and somebody had to answer it without you.

That’s the actual failure, and it points at a different fix.

What the cost-of-change data really says

One detour first, because the number you’ll hear most often in defence of requirements work is misused.

You have heard that a defect costs a hundred times more to fix after delivery than during requirements. The source is real. Barry Boehm and Victor Basili published the Software Defect Reduction Top 10 List in IEEE Computer in January 2001, and the first item states that finding and fixing a software problem after delivery is often about a hundred times more expensive than finding and fixing it during requirements and design.

Two things get dropped when you hear it quoted.

The same paper notes that for smaller and less critical systems the escalation is closer to five to one. The hundred-times figure is a large-system finding rather than a universal constant, and the original 1981 data came from large defence and enterprise projects at TRW, corroborated by IBM, GTE and the Safeguard programme.

And the tidy per-phase table people draw — one, then ten, then a hundred — isn’t in any of that work at the level of precision it implies. Later research has questioned whether the escalation is even reliably exponential or monotonic. Willis and colleagues, looking at effort to fix more than 66,000 defects across multiple projects, produced tables suggesting it need not be either.

So the direction is well supported and the multipliers are folklore. Use the direction. If you build a business case on the exact hundred-times figure for a small internal tool, you’ve quoted a large-systems finding at a context it was never measured in.

So I don’t defend requirements work on defect economics. I defend it like this: ambiguity gets resolved by whoever hits it first. That person is alone, under time pressure, with no context. And they are not going to call you.

What actually breaks

The requirement described an outcome instead of a rule. "Users should be able to easily find their invoices" isn’t a requirement, it’s a hope. One engineer builds search. Another builds a filter. Neither is wrong, because you never said. State the rule: which invoices, ordered how, visible to whom.

The awkward cases were left out. This is the analyst’s job done properly, and where it most often isn’t. Every requirement has a boring middle and three edges. Empty state, partial data, the record that was migrated badly in 2019, the user with two accounts. Delivery hits the edges on day two. If your document is silent, someone guesses. They won’t flag it, because they don’t know they’re guessing.

It wasn’t falsifiable. If you can’t demonstrate the requirement has been met or missed, it gets marked done. Anything that can’t be shown to be wrong will be reported as right.

It described the interface instead of the need. Over-specify and you feel precise while taking away your engineer’s ability to solve it better. Under-specify and you leave the decision unmade. The line sits at whether the detail carries a business consequence: the sort order does, the button colour doesn’t.

It rested on an assumption nobody wrote down. The legacy system will return this field. The team has capacity. This data is complete. When one turns out false, the requirement was never wrong exactly — it was conditional and nobody said so.

What I write instead

The decision rule, in a sentence someone can apply without me. Not what should happen, but how to tell which thing should happen.

The awkward cases, explicitly, including the ones I don’t know the answer to. Writing "unclear what happens when a user has two active contracts — needs a decision from finance" is more useful than silence and more honest than a guess. It converts an unknown unknown into a tracked question.

How this is demonstrated. If I cannot describe what a person would do to check it, I haven’t finished writing it. This is where acceptance criteria come from, and they’re far more useful written by the person who understands the need than reverse-engineered by the person who built it.

The assumptions, as a visible list. The same list I described in discovery on a committed roadmap. Conditions the requirement depends on, stated so that if one breaks, the conversation is about the condition rather than about the requirement being wrong.

What is deliberately out of scope. The exclusions prevent more rework than the inclusions, because the expensive misunderstandings are almost always about something nobody thought to mention.

On the level of detail

How detailed should you go? It’s the question I get most, and detail is the wrong axis.

A requirement can be long and useless. It can be short and complete. What decides it: can the person making a call at 4pm on a Thursday, with you in a meeting, find the answer? Write for that moment.

So the test isn’t whether your document is thorough. It’s whether the questions delivery brings you are the ones you couldn’t have anticipated, rather than the ones you didn’t bother to.

The thing generative tooling changed, and the thing it didn’t

Producing a plausible requirements document is now inexpensive. That has genuinely removed a chunk of drudgery and I wouldn’t go back.

What it hasn’t changed is the part that mattered. A generated document is fluent about the middle and silent about the edges, because your edges live in your organisation’s history rather than in any training data. Your 2019 migration isn’t in the model.

So the work moved. Less time drafting, more time on the four questions that were always the job: what’s the rule, what happens at the edges, how would we know, and what is this resting on.

Common questions

Does it really cost 100 times more to fix a defect after delivery?

For large systems, that figure has a real source: Boehm and Basili's Software Defect Reduction Top 10 List in IEEE Computer, January 2001. The same paper notes the escalation is closer to five to one for smaller, less critical systems. The often drawn per-phase table of 1x, 10x, 100x is not supported at that precision, and later research on tens of thousands of defects has questioned whether the escalation is reliably exponential at all. Treat the direction as sound and the multipliers as folklore.

What makes a requirement good?

It states a decision rule someone can apply without asking you, covers the awkward cases explicitly, can be demonstrated as met or missed, and names the assumptions it depends on. Length isn't the measure. A short complete requirement beats a long vague one.

What is the difference between a requirement and acceptance criteria?

The requirement states what must be true and why. The acceptance criteria state how you would demonstrate it. If you can't describe what someone would do to check it, the requirement is unfinished, and criteria written by the person who understands the need are more useful than criteria reverse-engineered by the person who built the thing.

How detailed should requirements be?

Detail is the wrong axis. The test is whether someone facing a decision late in the day, with nobody available to ask, can find the answer. Specify anything that carries a business consequence, such as sort order or eligibility rules, and leave implementation choices to the people implementing.

Why do requirements change during development?

Often they do not change so much as get completed. Delivery reaches an edge case the document was silent on, someone decides, and the decision surfaces later as a change. Writing the awkward cases in advance, including the ones with no answer yet, converts most of that churn into questions tracked before build.

Does AI change how requirements are written?

It makes drafting inexpensive without changing the hard part. Generated documents are fluent about the common path and silent about the edges, because the edges live in an organisation's own history rather than in training data. The remaining work is the rule, the edges, the demonstration and the assumptions.

Should requirements describe the solution or the problem?

The need, plus any detail with a business consequence. Over-specifying the interface removes the engineer's ability to find a better solution; under-specifying leaves a decision unmade that someone will make alone. The dividing line is consequence rather than granularity.