Business Analysis 101: Requirements Analysis and Design Definition Verifying and Validating Requirements

Study Guide – Verifying and Validating Requirements
(Designed for ECBA, CCBA, and CBAP candidates – and for anyone who needs to apply the practice on the job.)

What This Is

Verifying and validating requirements are the quality‑control activities that ensure the documented needs are complete, consistent, feasible, and truly reflect what the stakeholders want. In the BABOK® they belong to the Requirements Life Cycle Management (RLCM) knowledge area and are the “check‑points” before a solution is built or changed.

Real‑world example: A financial services firm is rolling out a new CRM system. After the BA has captured functional and non‑functional requirements, the team runs a verification review to confirm each requirement is clear, testable, and traceable. Then they hold a validation workshop with sales, support, and compliance stakeholders to confirm the requirements actually solve the problem of fragmented customer data.

Key Terms & Techniques

• Verification – The process of checking that each requirement is well‑formed (clear, complete, consistent, feasible, and testable). (RLCM – Output: Verified Requirements)
• Validation – The activity of confirming that the documented requirements meet the true business need and will deliver the intended value. (RLCM – Output: Validated Requirements)
• Traceability Matrix – A table linking requirements to sources, design elements, test cases, and business objectives. (RLCM – Deliverable: Traceability Matrix)
• Peer Review / Inspection – A structured, formal review where a small group of subject‑matter experts examines requirements for defects. (RLCM – Technique)
• Walk‑through – An informal, collaborative session where the BA walks stakeholders through the requirement statements to gain agreement. (Elicitation & Collaboration – Technique)
• Acceptance Criteria – Specific conditions that must be satisfied for a requirement (or user story) to be accepted by the customer. (RLCM – Output)
• Change Control Board (CCB) – A governance body that reviews, approves, or rejects changes to verified/validated requirements. (RLCM – Input/Output)
• Prototyping – Building a lightweight mock‑up or simulation to help stakeholders validate that the requirement will solve the problem. (Solution Evaluation – Technique)
• Requirements Baseline – The set of verified and validated requirements that have been formally approved and frozen for a given phase. (RLCM – Output)
• Non‑Functional Requirement (NFR) Checklist – A predefined list (e.g., performance, security, usability) used to verify that NFRs are captured and testable. (RLCM – Technique)
• MoSCoW Prioritization – Classifying requirements as Must, Should, Could, Won’t to aid validation when resources are limited. (Elicitation & Collaboration – Technique)
• Root‑Cause Analysis (5 Whys / Fishbone) – Used during validation to ensure the requirement addresses the underlying business problem, not just symptoms. (Solution Evaluation – Technique)

Step‑by‑Step / Process Flow

1. Prepare Verification Artifacts – Gather the draft requirements, the traceability matrix, and the NFR checklist.
2. Conduct a Peer Review – Invite SMEs, architects, and test leads; use a checklist (e.g., “Is the requirement atomic?”) to log defects.
3. Update & Re‑Verify – Incorporate review comments, resolve ambiguities, and re‑run the verification checklist until the set is verified (no open defects).
4. Facilitate a Validation Workshop – Walk stakeholders through the verified requirements, use prototypes or mock‑ups, and capture acceptance criteria.
5. Obtain Formal Sign‑Off & Baseline – Present the validated requirements to the Change Control Board (or project sponsor) for approval; record the baseline version.

(In an Agile context, steps 2‑5 are repeated each sprint for the backlog items that are “ready”.)

Common Mistakes

• Mistake: Treating verification as “testing” the solution.
  Correction: Verification is done before any solution is built; it checks the quality of the requirement statements, not the product.

• Mistake: Skipping stakeholder validation because the requirements look “obviously correct”.
  Correction: Validation must involve the actual business owners; otherwise you risk delivering a solution that solves the wrong problem (BABOK RLCM).

• Mistake: Using a single reviewer for verification, leading to missed defects.
  Correction: Apply a peer review with at least three diverse perspectives (technical, business, testing) to catch different defect types.

• Mistake: Baselineing requirements before they are fully validated.
  Correction: Only after the CCB signs off on the validation outcomes should the requirements be baselined.

• Mistake: Forgetting to link each requirement to a business objective in the traceability matrix.
  Correction: The matrix must show source → requirement → design → test case → objective to satisfy RLCM traceability rules.

Certification Exam Tips

1. “What is the next activity after a requirements review?” – The BABOK sequence is Verification → Validation → Baseline. Choose the answer that mentions “validation with stakeholders” rather than “implementation”.
2. Watch for “Elicitation vs. Verification” traps – Remember: Elicitation produces information, while Verification produces checked requirements.
3. Know the knowledge‑area boundaries – Validation belongs to RLCM, not to Solution Evaluation (which starts after the solution is built).
4. Remember the “four‑C” of a good requirement (Clear, Concise, Complete, Consistent). If a question lists these, it’s pointing to verification.

Quick Check Questions

1. Scenario: After a requirements workshop, the sales team says the new CRM must capture “customer sentiment”. Which technique should the BA use to validate this need?
   Answer: Prototyping – building a quick mock‑up of the sentiment capture field lets the sales team see and confirm the solution meets their intent.

2. Scenario: The draft requirements contain ambiguous wording (“system shall respond quickly”). Which verification activity will most directly address this?
   Answer: Non‑Functional Requirement Checklist – it forces the BA to replace “quickly” with a measurable metric (e.g., “response time ≤ 2 seconds”).

3. Scenario: A requirement has been reviewed, corrected, and approved by the CCB. What is the correct BABOK term for its status?
   Answer: Requirements Baseline – the set of verified and validated requirements that are now frozen for the current phase.

Last‑Minute Cram Sheet (10 One‑Liners)

1. ⚠️ Verification ≠ Validation – verification checks requirements; validation checks solution fit.
2. RLCM is the BABOK knowledge area that houses verification, validation, traceability, and baselining.
3. Traceability Matrix links Source → Requirement → Design → Test → Business Objective.
4. Peer Review = formal, defect‑focused inspection; Walk‑through = informal, agreement‑focused session.
5. Acceptance Criteria must be testable and are part of the validated requirement set.
6. Change Control Board (CCB) signs off on the Requirements Baseline after validation.
7. NFR Checklist ensures non‑functional requirements are measurable (performance, security, etc.).
8. MoSCoW is a prioritization tool used during validation when resources are constrained.
9. Prototyping is a Solution Evaluation technique that also supports validation of requirements.
10. Four‑C Rule (Clear, Concise, Complete, Consistent) = core verification checklist.

Good luck – you’ve got the concepts, the language, and the exam tricks you need to ace the verification and validation portion of the BABOK!