Techniques BABOK Guide v3, 10.37
Reviews
In short A review is a structured look at a work product, such as a requirements set, a model, or a plan, by people other than its author, to find defects and confirm it is fit for purpose. Choosing the right type of review for the risk involved catches misunderstandings while they are still cheap to fix.
Based on: IIBA, BABOK® Guide v3, technique 10.37 “Reviews”; Watermark Learning, BABOK v3 Study Tables, section 10.37; K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 17; D. Leffingwell, D. Widrig, Managing Software Requirements, ch. 29 and 33; Yu. A. Maglinets, Analysis of Requirements for Information Systems, lecture 6.
On this page
What it is#
Reviews evaluate the content of a work product: a single deliverable, part of a set, or work in progress. The BABOK Guide says reviews should be tailored to the organization’s needs and that business analysts take part in every one. Its elements are the review’s objectives, the technique used, and the participants.
Review types, from most to least formal:
- Inspection — a formal, checklist-driven search for defects, led by a trained moderator.
- Formal walkthrough (team review) — the author leads a group through the product; findings are recorded.
- Single-issue review (technical review) — focuses on one aspect, such as compliance with a standard.
- Informal walkthrough — the author walks a few peers through a draft for quick feedback.
- Desk check — one reviewer examines the product alone.
- Pass-around — the product goes to several reviewers, who send comments back.
- Ad hoc — an informal request for a second pair of eyes.
Verification and validation. Wiegers and Beatty separate two questions. Verification asks whether the requirements are written correctly: complete, unambiguous, consistent, testable. Validation asks whether they are the right requirements: whether they serve the business objectives and real customer needs. The BABOK Guide splits these into tasks 7.2 Verify Requirements and 7.3 Validate Requirements, and reviews support both.
Formal inspection. Maglinets traces inspections to Michael Fagan’s work at IBM and to the IEEE 1028 standard for software reviews. Key rules: managers do not inspect their own team’s work, an independent trained moderator leads, and the author always takes part. A recorder logs findings, and inspectors prepare individually with a checklist before the meeting. An inspection ends in one of three ways: accept as is or with minor edits, accept once the rework has been checked, or re-inspect.
When to use it#
The study tables link reviews to planning tasks 3.1, 3.3, and 3.5, to 4.3 Confirm Elicitation Results, 4.4 Communicate Business Analysis Information, 5.5 Approve Requirements, and 7.2–7.3. Review anything others will build from, sign off, or rely on.
How much review is enough? Leffingwell and Widrig scale the effort by asking what the social or economic consequences of a failure would be, and how much checking it takes to prevent them. They separate depth (how thoroughly an item is checked) from coverage (how many items are checked). Low-risk items can get lighter methods or be sampled, but the skipped items and the reasons must be recorded. Anything affecting human safety is always checked fully.
Strengths, per the study tables: defects are found early; reviewers become invested in the result; desk checks and pass-arounds fit around people’s schedules. Limits: inspections and formal walkthroughs take a lot of time; informal reviews carry a higher risk of missed defects; it is hard to confirm that a desk check or pass-around really happened; and comments sent by email are hard to consolidate.
How to do it#
- Set objectives. Find defects, confirm alignment with goals, or prepare for approval? State what is out of scope, such as formatting.
- Choose the type by risk and consequences: inspection for critical rules, walkthroughs for complex logic, pass-around for low-risk content.
- Pick reviewers who will use the product: developers, testers, and the business stakeholders who own the need. Add a moderator and a recorder for formal reviews.
- Prepare a package: a small chunk of the product, the objectives, a checklist, reference material, and a deadline.
- Prepare individually. Reviewers read and note issues before any meeting.
- Find, don’t fix. In the meeting, log each finding; solve problems afterwards.
- Draft test ideas. Wiegers and Beatty recommend planning tests while you review: trying to write a test exposes ambiguity and gaps. Maglinets suggests a matrix of requirements against test scenarios, so every requirement has at least one scenario and every scenario is supported by requirements.
- Decide the outcome, do the rework, and verify it.
- Improve the checklist with the defect types you keep finding.
Example#
The Workshop, a fictional chain of 12 bike-repair workshops, holds a formal walkthrough of its notification requirements. One reads: “The system shall notify the customer when the repair is delayed.”
Each reviewer reads it differently. Front-desk staff ask, “Delayed compared with what?” A mechanic asks, “Who decides it is delayed?” The development lead asks, “By SMS or email, and how soon?” Wiegers and Beatty describe a similar case: a requirement that looked complete split into conflicting interpretations once reviewers discussed it.
Rewritten: “When a mechanic changes the estimated completion date to a later date, the system sends the customer an SMS with the new date within 5 minutes.” The tester immediately drafts a test for it. Help-page texts get a pass-around; the privacy rules get an inspection.
The economic case, as Wiegers and Beatty report it from a study by Kelly, Sherif, and Hops (1992): a defect found during requirements took about 30 minutes to fix, while the same kind of defect found in system testing took 5 to 17 hours.
Common mistakes#
- Reviewing too much at once → send small chunks.
- No individual preparation → require reading before the meeting.
- Fixing in the meeting → log findings; rework afterwards.
- Managers inspecting their team’s work → people defend instead of finding.
- Comments scattered in email → keep one findings log.
- Verifying only → also validate with the business stakeholders who own the need.
- Assuming a desk check happened → ask for findings or a sign-off.
Checklist#
For each requirement under review:
- Has a unique ID and states one thing
- Has only one reasonable interpretation
- Can be tested; a test idea exists
- Traces to a business objective or stakeholder need
- Is feasible within known constraints
- Does not conflict with other requirements
- Describes a need, not a design
- Any open points are marked and logged
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.37 “Reviews”.
- Watermark Learning. BABOK v3 Study Tables. 2016. (study aid for the BABOK Guide). Section 10.37.
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Ch. 17 (validating requirements).
- D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Ch. 29, 33 (verification and validation; scaling the effort).
- Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007. Lecture 6 (inspections after M. Fagan; IEEE 1028; test scenarios).