Business Analyst Technique: Reviews - Definition, Types, Objectives
What Is the Reviews Technique in Business Analysis?
Reviews are a business analysis technique used to communicate, verify, and validate work products. Rather than relying on a single author's judgment, a review brings other stakeholders into the process to examine a work product — such as a requirements document, design artifact, or process model — before it moves forward.
Reviews can be formal or informal, ranging from a rigorous, role-based inspection process to a quick, informal check with a peer. Regardless of the format, business analysts should communicate the review's objectives to participants in advance, so everyone understands exactly what they're evaluating the work product for.
Quick Answer: What Are the Objectives of a Review?
Typical review objectives include:
- Removing defects
- Checking conformity to specifications or standards
- Checking completeness
- Measuring quality
- Reaching consensus on an approach or solution
- Resolving issues
- Exploring alternatives
- Educating reviewers on the work product or domain
Setting the objective clearly upfront ensures reviewers know whether they're hunting for defects, confirming standards compliance, or simply building shared understanding — each requires a different mindset from participants.
Formal Review Techniques
Formal reviews follow a defined, structured process and are generally used when the work product is high-risk or when defect removal is critical.
Inspection
The most stringent formal review process. Inspection is designed to remove defects and create a high-quality product. It mandates a prior self-review by the author before the session, and it assigns distinct roles to participants (such as moderator, reader, and recorder), making it the most rigorous and resource-intensive review type.
Formal Walkthrough / Team Review
This technique combines individual reviews with team consolidation — reviewers first examine the work product independently, then come together as a team to consolidate their feedback into a single, agreed-upon set of comments.
Single Issue / Technical Review
This review technique focuses on either one specific issue or a particular standard, rather than evaluating the entire work product broadly. It's useful when a narrow, well-defined concern needs focused expert attention.
Informal Review Techniques
Informal reviews trade some rigor for speed and practicality, making them well suited to early drafts or lower-risk work products.
Informal Walkthrough
Used for getting feedback on a draft work product, typically in a relaxed setting without the formal roles or structure of an inspection.
Desk Check
Independent reviewers provide feedback at their own desks, reviewing the work product on their own time without a joint session.
Pass Around
Multiple reviewers provide feedback on the same work product as it circulates among them, often sequentially.
Ad Hoc
An informal review or assistance from a peer, typically requested spontaneously rather than as part of a planned review cycle.
Strengths of the Reviews Technique
- Promotes stakeholder discussions and involvement, which supports higher-quality output by incorporating multiple perspectives.
- Identifies defects early, before they become more expensive to fix later in the project lifecycle.
- Desk checks and pass-around reviews are convenient, since they don't require coordinating a joint meeting time for all participants.
Limitations of the Reviews Technique
- Rigorous team reviews can be time-consuming, particularly formal inspections with their structured roles and mandatory self-review steps.
- Informal reviews are more practical but may not ensure removal of significant defects, since they lack the structure and rigor of formal techniques.
- It's difficult to validate whether a prior independent review actually took place in desk check and pass-around reviews, since these happen outside a shared, observable session.
- Repeated revisions can result if changes aren't carefully managed and tracked across review cycles.
- Sharing and discussing review comments over email can elongate the approval process, especially compared to a live, synchronous review session.
Choosing the Right Review Technique
With so many review types available, the right choice depends on a few key factors:
- Risk and criticality of the work product. High-risk artifacts — such as requirements for a safety-critical or compliance-driven system — generally warrant formal techniques like inspection.
- Time and resource availability. Informal techniques like desk checks or pass-around reviews are faster but offer less assurance; formal reviews take longer but provide stronger defect removal.
- Maturity of the work product. Early drafts are often better suited to informal walkthroughs, while near-final documents may benefit from a formal walkthrough or inspection before sign-off.
- Number and diversity of stakeholders involved. When broad consensus is the goal, a formal team review may be more effective than scattered individual feedback.
Best Practices for Running Effective Reviews
- State the objective clearly before the review begins — defect removal, standards conformity, completeness, or consensus-building each calls for a different reviewer mindset.
- Match the review technique to the stakes involved, rather than defaulting to the same format for every work product regardless of risk.
- Consolidate feedback carefully to avoid conflicting comments triggering repeated, unmanaged revision cycles.
- Prefer live discussion over email threads where possible, to keep the approval process moving efficiently.
- Track review completion, especially for desk checks and pass-around reviews, so it's clear which reviewers have actually completed their independent review.
Roles in review
|
Role |
Mandatory? |
Played by |
Responsibility |
Applicable to ____ techniques |
|
Author |
Yes |
Typically, business analysis |
Answers questions, listens to suggestions. Incorporates changes after review session. |
All |
|
Reviewer |
Yes |
A peer or stakeholder |
Reviews requirements document prior to review. Asks questions, comments, suggests changes and discusses them with group. |
All |
|
Facilitator |
Yes |
*Must be neutral and independent* |
Keeps participants focused. Verifies all participants have reviewed document prior. Ensures participation by all. |
|
|
Scribe |
No |
*Neutral participant with strong communication skills* |
Documents comments, suggestions, issues, concerns, outstanding questions. |
|
Frequently Asked Questions
What is the reviews technique in business analysis? Reviews are a technique used to communicate, verify, and validate work products by having other stakeholders examine them, either through a formal structured process or an informal, lightweight check.
What is the difference between formal and informal reviews? Formal reviews — such as inspection, formal walkthroughs, and single-issue/technical reviews — follow a structured process with defined roles and steps. Informal reviews — such as informal walkthroughs, desk checks, pass-around reviews, and ad hoc reviews — are faster and less structured, but provide less assurance around defect removal.
What is the most rigorous type of formal review? Inspection is the most stringent formal review technique. It's designed to remove defects and produce a high-quality product, and it requires a prior self-review by the author along with distinct roles for participants.
What are common objectives for conducting a review? Common objectives include removing defects, checking conformity to specifications or standards, checking completeness, measuring quality, reaching consensus, resolving issues, exploring alternatives, and educating reviewers.
What are the main drawbacks of using reviews? Formal reviews can be time-consuming, informal reviews may miss significant defects, independent review completion can be hard to verify in desk checks and pass-around reviews, and email-based feedback can slow down approvals.
Key Takeaway
Reviews give business analysts a structured way to bring other perspectives into the validation of a work product, whether through a rigorous formal inspection or a quick informal desk check. The technique's value depends heavily on matching the right review type to the stakes of the work product and being explicit about the objective from the outset. Done well, reviews catch defects early, build stakeholder consensus, and produce higher-quality outputs — done carelessly, they can drag out approval timelines without meaningfully improving quality.
Worked Out Example
Governance, Risk and Compliance (GRC) management system is developed for the IT and ITES domain. The primary objective of GRC management system is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, one of which is to plan and track projects and programs using standards such as CMMI, ISO 9001, ISO 27001 etc.
Requirements verification
|
Date of review |
14-Dec-20 |
Reviewed by |
LN Mishra |
|
Overview |
Yes/No/NA |
Remarks |
|
|
Check if prototyping requirements, if any, are documented |
Yes |
|
|
|
Check requirements for completeness |
Yes |
|
|
|
All stated requirements together ,when implemented, will achieve the systems' stated objective |
Yes |
|
|
|
Check for consistency |
Yes |
|
|
|
Standards and methods are all consistent across all modules of the system |
Yes |
|
|
|
Check whether requirements are testable |
Yes |
|
|
|
Requirements are stated in such a way that they can be tested |
Yes |
|
|
|
Requirements are stated such that acceptance criteria can be derived out of them |
Yes |
|
|
|
The process descriptions in the SRS are correct? |
Yes |
|
|
|
All requested functionality is described in the SRS? |
Yes |
|
|
|
The proposed screen layouts, screen flows are correct, no items are missing? |
Yes |
|
|
|
All field validations are correct? |
No |
Field validations to be reviewed again - Calendar controls mentioned as List box. |
|
|
All reports, documents, policy schedules, etc. are correct? |
No |
Report layouts not provided. |
|
|
All screen text and document text are correct? |
Yes |
|
|
|
SRS is shared with finance? |
Yes |
|
|
|
All topics of change log are correctly included in the SRS? |
Yes |
|
|
|
All the Minutes of Meetings are approved? |
Yes |
|
|
|
All business analysts use cases represent the correct functionality as stated in the SRS? |
Yes |
|
|
IIBA® Certification Prep
Everything you need to pass on the first attempt — with our Success and Moneyback Guarantees.
- ✔ 45+ hours of Live Learning
- ✔ 2000+ Mock Questions questions
- ✔ Live Fort-nightly Q&A with instructors
- ✔ 97% first-pass rate
You May Also Like
These Related Stories

Management Reporting: Cut KPI Noise, Set Priorities in Tech

Demystifying BABoK V3 terms and understanding them practically

.webp?width=389&height=60&name=2026%20Jan%20Adaptive%20Logo%20(350%20X%2054).webp)
.webp?width=350&height=54&name=2026%20Jan%20Adaptive%20Logo%20(350%20X%2054).webp)
No Comments Yet
Let us know what you think