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.
Typical review objectives include:
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 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 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.
With so many review types available, the right choice depends on a few key factors:
|
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. |
|
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.
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.
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.
|
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 |
|
|