How to Conduct a Requirements Review That Actually Finds Problems
A requirements review that finds fifty typos and three passive-voice constructions has done almost nothing for your program. A requirements review that finds five requirements that cannot be tested — or two that directly contradict each other — may have saved you a year of rework. These are not the same activity, even if they both produce a marked-up document.
Most reviews fail because they are not designed to find real problems. Reviewers show up without clear roles, without a shared vocabulary for what a defect looks like, and without an understanding of which defect types are most dangerous. They read sequentially and react to whatever catches their eye. The result is review feedback dominated by style preferences and formatting corrections while fundamental problems — unmeasurable performance claims, requirements that make integration physically impossible, test criteria that will never be satisfied — sail through unchallenged.
This guide explains how to design and run a review that finds the problems that matter.
The Six Categories of Requirements Defects
Before a reviewer can find problems, they need a taxonomy. These six categories cover the vast majority of requirements defects that cause downstream program damage.
Ambiguity. A requirement is ambiguous when two qualified engineers reading it independently would reach different conclusions about what the system must do. Words like “adequate,” “robust,” “user-friendly,” “fast,” and “sufficient” are the most common offenders. Ambiguity is dangerous not because it is confusing at the requirements stage but because it is invisible — both engineers believe they understand the requirement and do not discover the disagreement until integration. The review question to ask: “If I gave this to two different design teams, would they build the same thing?”
Unmeasurability. A requirement is unmeasurable when there is no credible way to assign a number to it. “The system shall provide high reliability” is unmeasurable. “The system shall achieve a Mean Time Between Failures of no less than 5,000 hours under rated operating conditions” is measurable. Unmeasurable requirements are not requirements — they are aspirations. They generate paperwork that closes without accountability. The review question: “How would I put a number on this? If I cannot, can the author?”
Incompleteness. A requirement is incomplete when it specifies some but not all of the conditions, constraints, or behaviors the system must satisfy. This includes requirements that omit operating range conditions, that specify nominal behavior but not fault behavior, or that define a function without specifying the environment in which it must operate. Incompleteness is particularly common at interfaces. The review question: “What conditions or states is this requirement silent about that the system will still encounter?”
Conflicts. Two requirements conflict when satisfying one makes satisfying the other impossible or significantly more difficult. Conflicts can be direct (two power budgets that sum to more than the source can provide) or indirect (a thermal requirement that demands active cooling and a vibration requirement that forbids moving parts). Conflicts are rarely found by reading requirements sequentially — they require reviewers to hold multiple requirements in mind simultaneously or to have access to a model that represents their relationships. The review question: “Is there anything else in this document that this requirement fights with?”
Gold-plating. A requirement is gold-plated when it specifies performance, precision, or capability significantly beyond what the mission actually requires. Gold-plating is not a style problem — it is a cost and schedule problem. A pointing accuracy requirement tighter than the system’s mission geometry actually demands will drive sensor selection, structural stiffness, control bandwidth, and test equipment in ways that add real cost. The review question: “What is the actual consequence to the mission if this number is 20% less demanding? Does anyone know?”
Untestability. A requirement is untestable when there is no feasible test, analysis, inspection, or demonstration that can produce objective evidence of compliance. Untestable requirements survive reviews regularly because they sound reasonable and often encode genuine intent. But a requirement that cannot be verified is not a contractual commitment — it is a statement of hope. The review question: “Write down the test procedure for this requirement right now. If you cannot do it, the requirement is not ready.”
Structured Inspection vs. Informal Walkthrough
The dominant mode of requirements review in most organizations is the informal walkthrough: someone circulates a document, reviewers mark it up individually or in a meeting, comments are collected, and the author disposes of them at their discretion. This produces the typo-heavy, style-dominated feedback described above.
Structured inspection — originally formalized by Michael Fagan at IBM in the 1970s and since validated across hundreds of software and systems programs — consistently outperforms walkthrough review on defect detection rate. The structural differences that account for this are not mysterious.
Entry criteria. Before inspection begins, the document must meet defined quality thresholds. Reviewers should not be discovering formatting problems and broken cross-references during inspection — that is what entry criteria prevent. A document that fails entry is returned to the author before review resources are spent on it. This alone shifts what reviewers focus on during the session itself.
Assigned roles. Each participant in a structured inspection has a defined role: moderator, author, reviewer, and recorder. These roles are not interchangeable. Reviewers are assigned specific defect categories to look for — one reviewer focuses on conflicts and interfaces, another on testability, another on ambiguity. This prevents the natural tendency for everyone to look for the same surface-level problems.
Individual preparation. Reviewers prepare individually before the inspection meeting, using their assigned checklists. The meeting itself is not a reading session — it is a defect logging session. Reviewers bring prepared findings. The meeting surfaces disagreements, confirms findings, and adds defects that emerge from group discussion.
Logging, not disposition. During the inspection, findings are logged, not resolved. The author does not defend requirements in the meeting. The moderator’s job is to keep the meeting moving through the document, not to debate whether a finding is valid. Disposition — deciding what to do with each finding — happens afterward.
The Moderator’s Role
The moderator is the most underappreciated function in a requirements inspection. Most organizations assign moderation to the most senior technical person in the room, which is exactly wrong. The most senior technical person in the room has the most technical opinions and the most authority to impose them — both of which undermine the inspection process.
The moderator’s job is to manage the process, not to contribute content. Specifically:
- Enforce entry criteria before the session begins. If the document is not ready, the moderator sends it back.
- Keep the session on pace. Most inspections cover between five and twenty requirements pages per hour, depending on complexity. The moderator tracks this and moves the group forward.
- Prevent author defensiveness from blocking defect logging. “We will log this and discuss it in disposition” is the moderator’s most important phrase.
- Distinguish between defects (something wrong with the requirement as written) and issues (questions or concerns that need follow-up) and log them separately.
- Close the session with a clear disposition: accepted, accepted with minor rework, or re-inspection required.
The moderator should receive specific training for this role. Reading the Fagan inspection literature is a minimum. Organizations that treat moderation as a clerical function consistently produce inspection sessions that degrade into technical debates, fail to work through the full document, and produce finding lists that the author dismisses as opinion.
Assigning and Tracking Review Actions
A finding without an owner is not a finding. This is where most reviews — even well-run ones — fail to close the loop.
Every finding that survives initial disposition should have: a unique identifier, an assigned owner (usually the requirement author or their lead), a required action (revise, clarify, delete, escalate to a system-level decision), and a due date. These should live in a tracked register, not in email threads or comment annotations on a shared document.
Findings should be categorized by severity. Major defects — ambiguities that affect design decisions, untestable requirements, confirmed conflicts — require verification of resolution before the requirement baseline is closed. Minor defects — editorial issues, formatting, style — can be resolved at the author’s discretion.
The moderator or a designated review lead should verify closure of major findings. “Author says it’s fixed” is not verification. Verification means the revised requirement was checked against the original defect description by someone other than the author.
Organizations that close review actions informally — by confirming the author addressed all comments — produce baselines full of requirements that were revised in response to feedback but still contain the original defect in a different form. Rewriting an ambiguous requirement without resolving the ambiguity is the most common example.
How Modern Tools Support — and Enable — Better Reviews
A persistent problem in manual reviews is that human reviewers spend cognitive effort on problems that are straightforwardly mechanical: inconsistent use of defined terms, requirements that reference system elements that do not exist in the architecture, statements that lack verifiable acceptance criteria by structure, traceability links that point to deleted parent requirements. These are real defects, but they do not require judgment — they require pattern-matching.
When human reviewers spend a two-hour session catching these, they have less capacity for the defects that actually require reasoning: the conflict hidden across two subsystem specifications, the requirement whose test procedure is technically conceivable but requires equipment that does not exist, the performance number that drives the whole propulsion trade study in an unexamined direction.
Flow Engineering addresses this directly. Before review begins, the platform runs automated quality checks across the requirements set — flagging structural issues, broken traces, missing verification methods, and requirements that fail basic completeness heuristics. These findings are surfaced before human review sessions are scheduled, so reviewers arrive at a document that has already been cleared of mechanical defects. The inspection session is then genuinely focused on the categories that require human judgment: conflicts, gold-plating, domain-specific ambiguity, and testability in the context of the actual test environment.
The graph-based model that Flow Engineering uses to represent requirements and their relationships also makes conflict detection more tractable. When requirements are connected to the system architecture, interfaces, and verification methods in a live model rather than stored as paragraphs in a document, reviewers can traverse relationships — following a performance requirement up to the mission need that drives it and down to the test that would satisfy it — rather than holding all of this in memory while reading sequentially.
Practical Starting Points
If your current process is informal walkthrough review, the highest-leverage change is not a new tool — it is adopting the six defect categories as a shared vocabulary and using them to build reviewer checklists. Give each reviewer one or two categories to own. Require individual preparation before the review session. Log findings without disposition during the session.
If you have a structured inspection process but reviews are still producing mostly editorial feedback, audit your entry criteria. The most common cause of inspection sessions dominated by formatting and cross-reference problems is that the document was allowed into inspection before basic quality checks were complete.
If your organization has enough review volume that reviewer time is the binding constraint — which is true of any program managing more than a few hundred requirements under active revision — invest in automated pre-review quality checks. The goal is not to automate the review; it is to make the human review session worth the time it costs.
Honest Summary
The difference between a review that finds fifty typos and one that finds five requirements that will drive an impossible test is not skill level or effort — it is design. Reviews that find real problems are structured to find them: reviewers know what defect categories exist, each reviewer is responsible for specific categories, the process has entry criteria, findings are logged and tracked to verified closure, and mechanical checks are handled before humans sit down.
A requirements baseline that has been through a well-run inspection is a different artifact than one that has been through an informal walkthrough. That difference shows up in integration, in test, and in the cost and schedule of the programs that depend on it.