Your Training Partner
Techniques Toolbox
Gradient title card carrying the text: The seven review types.

Reviews

A review is the evaluation of the content of a work product by one or more people other than or alongside its author, to remove defects, confirm that it is complete and correct, build consensus, resolve a question or familiarise reviewers with the content. It always bears on the product, never on the skills or actions of the people. BABOK describes each review through three dimensions, the objective pursued, the participants gathered and the technique used, and gathers under this name seven types that answer different combinations of those three settings. The seven types share one common core, and the right type reads off once the three dimensions are fixed.

Objective

A review tells you whether a work product holds up before others build on it. It puts one or more sets of eyes on the content that are not the author's, and the gap between what the author meant to write and what is actually written is a defect. BABOK sets the boundary at the outset: a review evaluates the content of the work product and not the skills or actions of the participants (§10.37.2). That boundary is the condition under which a team agrees to submit its work: a review that drifts towards judging people dries up its own material.

The product under review may be a complete package, a deliverable, part of a deliverable or work still in process, and its state already steers the intent. On a finished product the intent is most often to remove defects or to inform reviewers; on work in process it is to resolve a question or settle a point. The business analyst is always a participant in a review, as the author of a submitted deliverable or as the reviewer of someone else's.

What the family leaves behind is a reviewed product and a record of the findings, more or less formal according to the type chosen. The value of a review lies in what the record then allows: reopening a point, proving that a read happened, tracking a correction through to its verification.

A project management method can make that record mandatory. HERMES, the Swiss Confederation's method, separates checking, which covers the content and the form of documents and compliance with the agreed processes, from testing, which covers the running system; its task 5.4.3.38 Perform quality assurance covers checking only. It cites "consultations, reviews, audits" as possible procedures without prescribing any. The review plan (Prüfplan), a chapter of the Project management plan, names in advance the outcomes to be checked, their review procedure and the role that carries it out, according to whether the project follows the traditional or the agile approach. The findings and the decision on the status of the outcome are recorded in outcome 4.4.1.40 Review report.

Usage

When to use it

  • A work product others will depend on: requirements, specification, architecture, a model the rest will build on.
  • Defects to remove early: a defect found at reading costs far less than the same defect found in production.
  • Consensus or shared understanding to establish: several parties must agree on a deliverable before it moves on.
  • Conformance to a standard or specification to demonstrate: a quality gate requires a documented read.
  • An open question or technical point to settle: work in process is stuck on a choice that a focused read can unblock.
  • Bringing a team up to speed: having peers read a product makes them familiar with the content they will have to maintain.

When not to use it

  • A decision to make between options already known: a review evaluates content, it does not choose; move to decision analysis.
  • Executable behaviour to test: a review reads a static product and runs nothing; reach for the testing techniques and test-case design.
  • A defect already known and located: there is nothing left to find, only to correct and verify; open the rework directly and carry the point into item tracking.

The three dimensions of a review

BABOK presents the seven types as the product of three choices (§10.37.2). Each dimension is set independently of the other two, and it is their combination that names the type.

The objective

The objective is announced before the review and communicated to all participants (§10.37.3.1). BABOK names seven possible ones: remove defects, verify conformance to a specification or standard, establish that the product is complete and correct, build consensus on an approach or solution, answer a question or explore alternatives, familiarise reviewers with the product, measure its quality. The dominant objective weighs heaviest in the choice of type: measuring the quality of a critical component does not call for the same review as quick feedback on a draft.

The participants

Four roles are available (Table 10.37.1). The author answers questions, listens and incorporates the changes after the review. The reviewer, a peer or stakeholder, examines the product against the announced objectives; in a defect-detection review, they examine it before the session and keep the list of their findings. The facilitator, a neutral participant, runs the session, keeps it on its objective and checks that the reviewers have prepared; BABOK notes that they should not be the author, lest the review be compromised. The scribe, also a neutral participant, records defects, comments, points and open questions. The number of reviewers is the decisive setting of this dimension: one alone, and you are on the side of the desk check and the ad hoc review; a team, and you are on the side of inspection, the formal walkthrough and the pass around. The facilitator and the scribe do not appear in every type. The facilitator runs the most formal reviews, inspection and the formal walkthrough, and may lend a hand to the single issue review. The scribe records in inspection, in the formal walkthrough and in the informal walkthrough.

The technique and the formality

BABOK orders the seven types from most to least formal and calls the first three formal techniques, the next four informal (§10.37.3.2). Two binary questions set this dimension. Is the session planned, with roles assigned? Do reviewers examine the product each on their own before talking about it? Two yeses place the review among the formal types, costly and rigorous; two noes place it among the informal types, light and quick. It is also along this dimension that assurance and cost rise together.

From the three settings to the type

Once the three dimensions are set, the review type is all but determined. Measure the quality of a finished specification, with a team available and a planned session: that is an inspection. Build consensus and educate, with peers and stakeholders in session: a formal walkthrough. Settle a single point or conformance to a standard, with a few experts on the subject: a single issue review. Gather quick feedback on a draft, with peers who have prepared little: an informal walkthrough. A single outside reviewer, at their convenience: a desk check. Several reviewers, each on their own, with no meeting: a pass around. The occasional help of a peer on work in process: an ad hoc review.

Formal
Informal
Inspection
Formal Walkthrough
Single Issue Review
Informal Walkthrough
Desk Check
Pass Around
Ad Hoc Review
BABOK §10.37.3.2
BABOK's seven review types, ordered from most to least formal (§10.37.3.2). Rigour and cost rise with formality, and so does the assurance gained. The choice moves down the ladder to the first type that does the job.
Review typeDominant objectiveParticipantsFormality
InspectionRemove defects and measure the quality of a critical product.A team of trained peers, facilitator and scribe.Formal, planned session, prior individual reading.
Formal walkthroughBuild consensus and educate, while removing defects.Peers and stakeholders, facilitator and scribe.Formal, less rigorous than inspection.
Single issue reviewSettle a single point or conformance to a standard.A few experts on the point in focus.Formal, session focused on the matter at hand.
Informal walkthroughGather quick feedback and familiarise.A few peers, minimal preparation.Informal, light session, the author walks through.
Desk checkGet the opinion of an outside eye.A single reviewer, outside the making of it.Informal, no session, at their convenience.
Pass aroundGather feedback from several, at lower cost.Several reviewers, each on their own.Informal, no session, shared or circulated copy.
Ad hoc reviewGet the occasional help of a peer.One peer asked.Informal, no session, on work in process.
The three right-hand columns are the three dimensions. A review type is a profile across all three; conversely, three given settings point to the type that matches them.

The three dimensions are not entirely free of one another, and that is what makes the decision workable. Measuring the quality of a product means counting, hence a formal technique and a team: that objective pulls the other two dimensions towards the formal end of the family. Conversely, a single reviewer cannot build consensus, so the desk check and the ad hoc review serve the objectives of feedback and help. A finding that must survive the review, whatever the type, leaves the technique and enters item tracking, where it is given an owner, a due date and a status.

Strengths and limitations of the family

The strengths hold for the whole family (§10.37.4.1). Reviews catch defects early in the work product's life cycle, where they cost least to remove. They make reviewers engaged in the outcome: whoever has read a product feels vested in its quality. And the informal types with one or several asynchronous reviewers bend to the reviewer's own schedule, with no meeting to convene.

The limitations follow the same dimensions. A review set high on all three axes costs time and effort, so only the most critical products warrant it. A review set low, with one or two reviewers, is cheap but gives less assurance that all significant defects have been removed. On a desk check or a pass around, it is hard for the author to verify that an independent read actually happened. And feedback exchanged by e-mail produces many messages that are hard to reconcile. Setting the three dimensions is also choosing which of these limitations you accept.

AI considerations

The help bears on the material of the product under review. A model reads a product against a checklist and flags the mechanical gaps, a requirement with no acceptance criterion, a term used before it is defined, a reference that does not resolve: a first pass that lightens the technique dimension of the formal types. It groups and shapes the scattered feedback of a pass around, which addresses the e-mail-thread limitation directly. It drafts a record from the scribe's notes.

The limit falls on the setting of the three dimensions, which is judgement. Fixing the objective means knowing what the product commits to and what evidence the organisation will have to show; fixing the participants means knowing their availability and expertise; fixing the formality means weighing the assurance sought against the time available. A model knows none of these three. The consensus and education objectives further run through a conversation between people that no automatic summary replaces, and a finding produced by a model is plausible by construction, so it enters the review as a hypothesis that a reviewer confirms or discards. As the products under review are often sensitive, internal requirements, client data, passing them through an external tool assumes the legal basis and the authorisation that data protection requires.

Sources

  • IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.37 Reviews: the definition of a review, the boundary limiting a review to the content, the three dimensions (objectives, techniques, participants), the four roles, the ordering of the seven types by formality and the strengths and limitations of the family.
  • IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits: standards.ieee.org/ieee/1028. The standardised taxonomy of reviews and audits and the formal/informal distinction.
  • Karl E. Wiegers, Peer Reviews in Software: A Practical Guide, Addison-Wesley: processimpact.com, chapter 3. The formality continuum of peer reviews and the trade-off between rigour, cost and assurance.
  • Swiss Confederation, Federal Chancellery, HERMES 2022, Project Management Reference Manual, task 5.4.3.38 Perform quality assurance, outcome 4.4.1.40 Review report, review plan (chapter of outcome 4.4.1.34 Project management plan): the separation of checking from testing, the review cited as one of the possible checking procedures without its form being prescribed, the review plan that fixes the outcome, the procedure and the role in advance, as well as the review report that records the findings and the decision on the status of the outcome.
Return on Investment (ROI)
All techniques
Risk Analysis and Management