Requirements Validation & Reviews

Requirements Validation & Reviews

Writing requirements is only half the job. Before a single line of code is written, someone must confirm that every requirement is correct, complete, consistent, and feasible. That confirmation process — requirements validation and the structured reviews that support it — is what separates professional analysis from wishful thinking. Defects found during a requirements review cost roughly 10 to 100 times less to fix than the same defects discovered during system testing or after deployment. This lesson walks through the full toolkit: walkthroughs, inspections, and the formal sign-off process.

Why Validate Requirements at All?

Consider a logistics company building a parcel-tracking portal. The analyst documents: "The system shall display the current location of a parcel." This sounds reasonable until a developer asks: "Does 'current location' mean the last depot scan, the GPS coordinate of the delivery vehicle, or the destination city?" If that ambiguity reaches development, one team builds GPS tracking, another builds depot history — and neither delivers what operations actually needed. A structured review would have surfaced the question in 30 minutes at negligible cost.

Requirements validation catches four categories of defects:

• Errors of commission — requirements that are wrong, contradict each other, or contradict business rules.
• Errors of omission — missing requirements that no one articulated but everyone assumed.
• Errors of ambiguity — wording that two readers can interpret differently.
• Errors of infeasibility — requirements that cannot be delivered within the agreed time, budget, or technology constraints.

Technique 1 — The Informal Walkthrough

A walkthrough is a peer-led review where the author of a requirements document presents it to a small group of colleagues, walking them through section by section. It is informal, collaborative, and focused on mutual understanding rather than formal defect logging.

Typical format: 3–6 participants, 60–90 minutes, a shared screen or printed draft. The author narrates each requirement; participants raise questions, note confusions, and suggest improvements in real time.

Clinic booking example. An analyst walks through a draft SRS section covering appointment cancellation. A developer immediately asks: "Requirement 3.4 says patients can cancel up to 2 hours before the appointment, but Requirement 3.7 says a confirmation email is sent on cancellation — what happens if the cancellation occurs 90 minutes before and the email fails to send? Is the cancellation still valid?" That cross-requirement question — never asked by the original author — is exactly what walkthroughs surface.

Walkthroughs are fast and low-overhead. Their weakness is that the author's presence can inhibit candid criticism — reviewers may soften feedback to avoid conflict.

Technique 2 — The Formal Inspection (Fagan Inspection)

An inspection is a rigorous, role-based defect-detection process. Originally defined by Michael Fagan at IBM in 1976, it remains the gold standard for high-stakes requirements. The key difference from a walkthrough: the author does not present the material. Instead, a designated reader paraphrases each requirement in their own words, forcing active interpretation rather than passive listening.

Defined roles:

• Moderator — a trained facilitator who keeps the meeting focused, enforces time limits, and has no personal stake in the document.
• Reader — reads and paraphrases each requirement aloud; not the author.
• Author — present to answer factual questions but does not defend the document.
• Reviewers (2–4) — domain expert, developer, tester, and/or end-user representative. Each prepares independently before the meeting.
• Scribe — logs every raised defect using a standard issue taxonomy.

Five-phase lifecycle: Planning → Overview → Individual Preparation → Inspection Meeting → Rework/Follow-up. Inspections consistently find 60–80% of all requirements defects. An online store might run an inspection on the checkout-flow requirements, where a tester's preparation uncovers that three requirements implicitly assume a single-currency environment — a critical gap for a platform planning EU expansion.

Walkthrough vs. Inspection — Choosing the Right Tool

Neither technique is universally superior. The right choice depends on risk, maturity, and available time.

Defect Classification During Reviews

Every defect raised in a review should be classified, not just noted. A standard taxonomy keeps follow-up manageable:

• Major — the requirement is wrong, missing, or contradictory. Must be resolved before baselining.
• Minor — grammar, formatting, or clarity issue that does not change meaning. Can be fixed without re-inspection.
• Query — a question that needs a stakeholder answer before the requirement can be confirmed. Assigned to a named owner with a due date.

Prototyping and Scenario Walk-Throughs as Validation

Formal meetings are not the only validation technique. Showing stakeholders a UI prototype and walking through realistic scenarios is often the fastest way to uncover missing or misunderstood requirements. When a logistics operations manager sees a prototype screen for the first time and says: "Where is the bulk re-routing button? We do that 40 times a day" — that is a requirements omission discovered through validation, not development.

Similarly, running a stakeholder through a use-case scenario — "Imagine it is Monday morning and a driver calls in sick. Walk me through what you would do in the system" — surfaces implicit requirements that no amount of document review would find.

Getting Sign-Off: The Baseline

Baselining is the formal act of freezing a version of the requirements document after validation is complete. It is not a bureaucratic ritual — it is the moment that transforms a draft into a contract. After baseline:

• All approved requirements are placed under change control. No changes without a formal Change Request (CR).
• The project team can begin design and estimation against a stable foundation.
• Stakeholders acknowledge — ideally in writing — that the requirements reflect their agreed needs.

Who must sign off? This depends on the organisation, but typically: the primary business owner, a representative end-user, the lead developer (confirming technical feasibility), and the QA lead (confirming testability). For a clinic booking system, that means the clinic administrator, a receptionist or doctor who will use the system daily, the development lead, and the test manager.

What Happens After Sign-Off?

After baselining, the requirements document becomes the reference for design, development, and testing. Any proposed change must go through a defined Change Control Board (CCB) or equivalent process — assessing impact on scope, cost, and schedule before approval. This feeds directly into requirements traceability, which is covered in the next lesson.

A Practical Validation Checklist

Before declaring a requirements set ready for sign-off, work through these questions for each requirement:

1. Correct? Does this accurately reflect what the stakeholder actually needs?
2. Unambiguous? Can it be interpreted in only one way?
3. Complete? Does it define all conditions, including error paths?
4. Consistent? Does it contradict any other requirement?
5. Verifiable? Can a tester write a test case that confirms whether it has been met?
6. Feasible? Can the team build it within the agreed constraints?
7. Traceable? Can it be linked to a business objective or a stakeholder source?

Any "No" answer is a defect. No requirement passes validation with an outstanding "No."