Requirements Verification Methods That Catch Defects Early

In this article:

Share the раgе:

Most teams verify requirements once, at sign-off, by reading them. Reading catches typos. It does not catch the requirement that contradicts another one forty pages away, the state a record can enter and never leave, or the sentence three people understood three ways. Five methods work before a line of code exists: structured review against a checklist, traceability in both directions, model-based checks against a data or state model, prototype walk-throughs with the people who will use the system, and deriving the acceptance tests from the requirement before build. Each catches a different class of defect and misses another, which is why the answer is a sequence rather than a choice. Capers Jones' long-running industry data puts the removal efficiency for requirements defects at 77%, the lowest of any defect origin, because the class of defect that enters earliest is the one teams check least. This guide covers the five methods, what each finds, and how to run them inside a normal requirements phase.

Introduction

The requirements were signed. Forty-one pages, reviewed by six stakeholders, approved by the sponsor. Four months later a tester asked what "the system shall support concurrent edits" meant when two users saved the same record within a second of each other, and the room discovered that the finance lead had assumed the second save would be rejected, the operations lead had assumed it would merge, and the developer had built last-write-wins because nobody had said otherwise.

The requirement had been read by six people. It had not been verified by any of them, because reading and verifying are different activities and the review meeting only does the first.

What is requirements verification, and why does reading fail?

Requirements verification is the work of checking that a requirement is correct, complete, unambiguous, consistent with every other requirement, and testable, before anything is built from it. It is distinct from validation, which checks that the requirements describe the right system for the business. Verification asks whether the requirement is a good requirement. Validation asks whether it is the right one.

Reading fails at verification for a structural reason. A reader checks each requirement against their own understanding, and their understanding is one of several in the room. The requirement that is ambiguous between two readings passes review with both readers satisfied, because each saw the reading they expected. The contradiction between requirement 12 and requirement 87 passes because nobody holds both in mind at once. The missing exception path passes because the reader was checking what was written, not what was absent.

The cost of that gap is well documented. In Capers Jones' industry data across thousands of projects, requirements defects have a removal efficiency of 77%, lower than design defects at 85% and coding defects at 95%. The defects that enter earliest are the ones least likely to be removed before delivery, and the reason is that the methods applied to requirements are weaker than the methods applied to code. Code gets static analysis, unit tests, and inspection. Requirements get a meeting.

Key Takeaway: Reading checks a requirement against one person's understanding. Verification checks it against the other requirements, the models, the users, and the tests. Those are five different checks.

Signing off a requirements set that has only been read? Our Analysis & Design practice runs the verification pass before approval. Book a free consultation.

What are the five requirements verification methods?

Five, each catching a class of defect the others miss. The table gives the shape; the sections after it give the practice.

Method	What it catches	What it misses	Cost
Structured review against a checklist	Ambiguous words, compound requirements, missing exception paths, unstated assumptions	A requirement that is clear, single, and wrong	Hours
Traceability, both directions	Requirements with no business objective behind them, objectives with no requirement, requirements no test can reach	A requirement that traces perfectly and contradicts another	A day, then ongoing
Model-based checks	Contradictions between requirements, states with no exit, fields with no owner, rules that conflict	Whether the operation described is the one people can run	Days
Prototype walk-through with users	Requirements that are consistent, testable, and describe the wrong behaviour	Non-functional and data requirements the prototype does not exercise	Days
Test-case derivation before build	Every requirement from which no test can be written, which is the definition of untestable	Nothing about correctness; it forces precision, not truth	Hours per requirement, recovered at test time

Read the third column as a chain. The checklist misses the clear wrong requirement, which the prototype catches. The prototype misses the non-functional requirement, which the model catches. The model misses the operational fit, which the walk-through catches. No single method covers the column, and the projects that verify with one method have chosen which class of defect to ship.

The concurrent-edit requirement from the introduction would have failed three of the five. The checklist would have flagged "support" as an undefined verb. The state model would have shown two saves reaching one record with no rule for the second. The test-case derivation would have stalled at "expected result," because nobody could write one. It passed the review meeting because the review meeting was none of these.

Most requirements sets are signed after one review and never see the other four methods, because the project plan has one line for "requirements review" and the reviewers are stakeholders rather than analysts. ID Business Analysis Canada runs all five as a verification pass inside every Requirements Engagement, with a business analyst producing the checklist findings, the two-way traceability matrix, the data and state models with the conflicts they expose, the walk-through record with the users' corrections, and the derived acceptance test for every requirement, before the set goes to the sponsor for signature.

Key Takeaway: Five methods, five classes of defect. A requirements set verified by one method has chosen which four classes to build.

How do you run the three cheapest methods?

Checklist, traceability, and test-case derivation together cost a few days on a typical set and catch most of the defects that make it into build.

Five requirements verification methods in sequence, each with the class of defect it catches and its cost.

Structured review against a checklist. Not "read and comment." Each requirement is checked against a fixed list of questions, and the answer to each is recorded. Does it contain one requirement or several? Does it use a word with more than one reading: support, handle, appropriate, timely, user-friendly? Does it state what happens when the input is wrong, missing, or late? Does it name the actor, or say "the system" for something a person does? Does it depend on something not yet defined? A requirement fails if any answer is wrong, and the failure is a defect with an ID, not a comment in a margin.

Traceability in both directions. Every requirement links backward to the business objective or business rule it serves and forward to the test that will prove it. Build the matrix, then read it for gaps. A requirement with nothing behind it is scope creep that got written down. An objective with nothing in front of it is a gap the sponsor will discover at UAT. A requirement with no test in front of it is untestable, and it either gets rewritten or it comes out.

Test-case derivation before build. For each requirement, write the acceptance test: the setup, the action, the expected result, in terms a tester who missed every workshop could execute. If the expected result cannot be written, the requirement is not finished. This is the method most often deferred to the test phase, and deferring it is the single most expensive decision in the requirements process, because it moves the discovery of every untestable requirement from a day in analysis to a week in test.

The three run in that order because each one narrows the set the next one has to cover. The checklist removes the ambiguous rows, traceability removes the orphan rows, and test derivation is applied to what survives.

Key Takeaway: Checklist, traceability, then tests, in that order. A few days on a typical set, and the untestable requirements are found in analysis rather than in test.

When are models and prototypes worth the cost?

When the requirements describe data, states, or rules that interact, and when the people who will use the system were not the people who wrote the requirements.

Model-based checks. Draw the data model, the state model for any record that has a life cycle, and a decision table for any rule with more than two conditions. Then check the requirements against the models, not the other way round. A requirement that references a field the data model does not hold is a defect. A state the model shows a record entering with no requirement that gets it out is a defect. Two requirements that give a decision table row different outcomes are a contradiction, and the model is the only method that finds it, because the two requirements are on different pages and no reader holds both.

Models earn their cost on any system with a workflow, a record life cycle, or business rules that finance and operations both own. On a content site or a reporting dashboard they are usually overhead.

Prototype walk-through with users. Take a clickable mock-up or a paper flow to the people who will operate the system and walk one scenario end to end, with the requirements open beside it. The finding this produces is the one no other method can: the requirement is clear, single, traceable, testable, consistent with the model, and describes something the operators will not do. The ConOps post on this site covers the operational scenarios that feed this walk-through. When those scenarios exist, the walk-through is a day. When they do not, it is the day the scenarios get discovered.

Both methods sit closer to validation than the first three. Verification asks whether the requirements are good; validation asks whether they are right. The walk-through is where the two meet, and it is the method most often skipped on projects whose sponsors assume they know the operation.

Key Takeaway: Models when data, states, or rules interact. Walk-throughs when the operators were not in the room. Both find defects the other three methods cannot.

How does this fit inside a normal requirements phase?

As a stage between drafting and sign-off, with its own exit criteria, on the plan as a line with a duration.

The sequence for a typical requirements set of moderate size:

Draft complete. All requirements written, numbered, and in one place.
Checklist pass. Every requirement checked, every failure logged as a defect with an ID. Usually one to two days for a set of a hundred to two hundred requirements.
Traceability build. Matrix populated both ways, gaps logged. One day.
Model check. Data, state, and decision models drawn where warranted, requirements checked against them, conflicts logged. Two to four days depending on the system.
Walk-through. One or two scenarios with real users, corrections logged. One day plus preparation.
Test derivation. Acceptance test written for every surviving requirement. Two to three days, most of it recovered later in the test phase.
Defects closed. Every logged defect either fixed in the requirement or accepted with a reason. Then sign-off.

That is roughly two weeks added between draft and signature on a set that would otherwise take a week to review. The two weeks are the difference between a set that six people have read and a set that has been verified, and they are recovered several times over at the point where the tester asks what "support" means.

Key Takeaway: A stage with exit criteria, roughly two weeks for a typical set. Every logged defect fixed or accepted before signature.

Frequently Asked Questions

What is the difference between requirements verification and requirements validation?Verification checks that each requirement is well-formed: correct, complete, unambiguous, consistent with the others, and testable. Validation checks that the set of requirements describes the right system for the business need. A requirement can pass verification and fail validation, which is the clear, testable requirement for behaviour the operators will not accept. Checklists, traceability, models, and test derivation are verification methods. The walk-through with users is where verification ends and validation begins.

How do we start verifying requirements on a set that is already signed?Run the checklist and the test derivation on the signed set first, because both are fast and both produce a defect count that tells you how much trust the signature deserves. A signed set where a third of the requirements fail the checklist or cannot produce a test has not been verified, whatever the signature page says. ID Business Analysis Canada does this as a scoped verification pass inside a Requirements Engagement, with a business analyst running all five methods on the existing set and returning the defect log, the traceability gaps, the model conflicts, and the derived tests, so the build team starts against a set that has been checked rather than read. On a signed set it typically takes two weeks and typically changes the set.

Can requirements verification be done on an agile project?Yes, and the unit changes from the document to the story. The checklist runs at refinement, on each story before it is accepted into a sprint. Traceability runs from epic to story to acceptance test. Test derivation is the acceptance criteria, written before the story is estimated rather than after it is built. Models are kept as living artifacts the stories are checked against. The walk-through is the sprint review with real users in the room. The methods are the same; the batch size is smaller.

Who should perform requirements verification?The analyst who did not write the requirement, using the methods above, with the author present to answer questions. Self-verification catches typos and little else, because the author reads what they meant. Stakeholder review catches whether the requirement matches the stakeholder's expectation, which is validation. The verification pass is analysis work, and on small teams it is worth swapping analysts across workstreams for a week to get it done by someone with fresh eyes.

Conclusion

Six people read the requirement and each one saw the reading they expected. The defect did not enter at build. It entered at sign-off, with six signatures on it, and it was found by the first person who tried to write a test.

If your requirements sets go from draft to signature through a review meeting and nothing else, ID Business Analysis Canada's Analysis & Design practice runs the five-method verification pass inside a Requirements Engagement and returns a defect log, a two-way traceability matrix, the model conflicts, and a derived acceptance test for every requirement before the set is signed. Book a free consultation and bring the last set that surprised a tester.

Get in touch

Prove It Early: Requirements Verification Methods That Catch Defects Before Build