Requirements quality and defect prevention

The finding everyone quotes, and the three next to it

Boehm and Basili's Software Defect Reduction Top 10 List (IEEE Computer, January 2001) is best known for one line: finding and fixing a software problem after delivery is often about 100 times more expensive than finding and fixing it during requirements and design. On small, non-critical projects the ratio is closer to 5:1 — a caveat that gets dropped almost every time the figure is repeated.

The three findings alongside it are more useful and almost never cited.

Current software projects spend about 40 to 50 percent of their effort on avoidable rework. Not cost — effort. Half of a development organization's capacity, spent redoing work that did not need redoing.

About 80 percent of avoidable rework comes from 20 percent of the defects. Rework is not evenly distributed. A small number of defects generate most of the cost, which means the return on catching the right defect early is far higher than the average suggests.

Two major sources of avoidable rework are hastily specified requirements and nominal-case design. Boehm and Basili name the mechanism directly: when off-nominal requirements are accommodated late, the result is major architecture, design, and code breakage.

Read together, these say something more specific than "defects are cheaper to fix early." They say that a minority of defects, originating largely in requirements, consume most of the rework budget.

Why this got worse, not better

The 2001 paper describes a world where humans wrote the code. Ambiguity in a requirement met a developer who noticed it, and the question surfaced.

Coding agents do not stop to ask. Given a requirement that is silent on what happens when a broker's license has expired, an agent produces working code for the case it was given and nothing for the case it was not. The output compiles, passes review, and ships. Nobody experiences the ambiguity as an ambiguity, because the gap was filled silently.

That is what makes specification quality a different problem now than it was. The volume of code produced from a given requirement has gone up sharply, and the number of moments where a human notices something is missing has gone down. The rework does not disappear. It arrives later, in larger units, exactly as the paper's third finding predicts.

What a requirement has to contain before it is safe to hand over

Most requirements are written to be understood by someone who already shares the writer's context. That is fine for a conversation and insufficient for a specification. Five things determine whether a requirement can survive being handed to an agent, or to a tester who has never seen the product.

Off-nominal cases, stated explicitly

This is Boehm and Basili's named source of rework, and it is still the most common gap. A requirement describing what happens when the operation succeeds, with nothing about failure, timeout, permission denial, or invalid input, is a requirement that will be completed by whoever implements it — and their assumptions will not be written down anywhere.

Acceptance criteria that can fail

"The page should load quickly" cannot fail, because nothing determines whether it did. Criteria have to be stated so that a specific observation would falsify them.

Terminology bound to a definition

Domain vocabulary carries meaning that is obvious internally and invisible externally. If "active account" means something particular in your business, the requirement has to say what, or every implementation will encode a slightly different version of it.

Dependencies made visible

Requirements that assume a state established elsewhere — a user already provisioned, a rate table already loaded — produce code that works in isolation and fails in sequence.

Traceability to a test

If nothing downstream references the requirement, no one can tell whether it was implemented. This is the link that makes the rest checkable rather than aspirational.

Where Spec2TestAI acts

Requirements Intelligence analyzes each story and its acceptance criteria across 32 quality measures, detecting ambiguity and enhancing the requirement for clarity, completeness, and testability before code exists. The same specification then generates the tests that prove it, which is what makes the traceability real rather than a document reference — the requirement and the test are two views of one artifact.

At a major financial regulator, this approach was associated with approximately 90% fewer requirements-phase defects. We report that as an engagement result rather than a general claim; outcomes vary with existing requirements maturity and release cadence.

The argument for acting here is not that requirements work is virtuous. It is the arithmetic in the 2001 paper: if 40 to 50 percent of effort goes to avoidable rework, and 80 percent of that rework traces to 20 percent of defects, and a major share of those originate in hastily specified requirements — then requirements quality is not a documentation exercise. It is the largest available lever on delivery capacity.

What this does not solve

A clean specification does not remove the need to test. It changes what testing is for: confirming that what was built matches what was specified, rather than discovering what was meant in the first place. Teams that improve requirements quality and then reduce testing tend to find the second decision expensive.

Nor does specification quality address defects introduced by implementation — genuine coding faults, integration failures, environment differences. Boehm and Basili's own list covers those separately. The claim here is narrower: the requirements-origin share of rework is large, measurable, and preventable, and it is the share that coding agents make larger.

Sources

• Boehm, B. & Basili, V., “Software Defect Reduction Top 10 List”, IEEE Computer 34(1), January 2001 — ~100× post-delivery fix cost versus requirements and design, closer to 5:1 on small non-critical projects; 40–50% of project effort spent on avoidable rework; ~80% of avoidable rework from 20% of defects; hastily specified requirements and nominal-case design named as major sources.
• Regulator outcome: AgileAI Labs engagement result, not an industry figure.