Study guide
6.2 Verify Requirements
CBAP Certified Business Analysis Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & BACCM Framework
1.1 CBAP Exam Structure, Eligibility & Study Plan 1.2 The Business Analysis Core Concept Model (BACCM) 1.3 Key Concepts, Terms & Requirements Classification 1.4 Business Analysis Governance & Stakeholder Engagement Principles
2 Chapter 2: Business Analysis Planning and Monitoring
2.1 Plan Business Analysis Approach 2.2 Plan Stakeholder Engagement 2.3 Plan Business Analysis Governance 2.4 Plan Business Analysis Information Management 2.5 Identify Business Analysis Performance Improvements
3 Chapter 3: Elicitation and Collaboration
3.1 Prepare for Elicitation 3.2 Conduct Elicitation 3.3 Confirm Elicitation Results 3.4 Communicate Business Analysis Information 3.5 Manage Stakeholder Collaboration
4 Chapter 4: Requirements Life Cycle Management
4.1 Trace Requirements 4.2 Maintain Requirements 4.3 Prioritize Requirements 4.4 Assess Requirements Changes 4.5 Approve Requirements
5 Chapter 5: Strategy Analysis
5.1 Analyze Current State 5.2 Define Future State 5.3 Assess Risks 5.4 Define Change Strategy 5.5 Business Case Development & Financial Analysis
6 Chapter 6: Requirements Analysis and Design Definition
6.1 Specify and Model Requirements 6.2 Verify Requirements 6.3 Validate Requirements 6.4 Define Requirements Architecture 6.5 Define Design Options 6.6 Analyze Potential Value and Recommend Solution 6.7 Data Modeling & Process Modeling Techniques 6.8 Use Cases, User Stories & Acceptance Criteria Definition 6.9 Non-Functional Requirements & Solution Constraints
7 Chapter 7: Solution Evaluation
7.1 Measure Solution Performance 7.2 Analyze Performance Measures 7.3 Assess Solution Limitations 7.4 Assess Enterprise Limitations 7.5 Recommend Actions to Increase Solution Value
8 Chapter 8: Underlying Competencies, Techniques & Perspectives
8.1 Analytical Thinking, Problem Solving & Business Knowledge 8.2 Behavioral Characteristics & Interaction Skills 8.3 Core BABOK Techniques Master Review 8.4 Business Analysis Perspectives
6.2 Verify Requirements
Key Takeaways Explain This Topic AI
Task 21 (Verify Requirements) ensures that requirements and design artifacts meet strict quality standards before downstream consumption.
BABOK Guide v3 defines nine quality characteristics: Atomic, Complete, Consistent, Concise, Feasible, Unambiguous, Testable, Prioritized, and Understandable.
Verification focuses on structural quality and compliance with documentation standards, whereas Validation focuses on business value alignment.
Key verification techniques include Requirements Checklists, Peer Reviews, Structured Walkthroughs, and Inspection reviews.
Conducting rigorous verification early prevents costly downstream defect propagation during software development and testing phases.
Last updated: August 2026
- 6.2 Verify Requirements
- Purpose of Task 21
The primary objective of Task 21: Verify Requirements is to ensure that set requirements and design specifications are fit for purpose, technically well-formed, and compliant with organizational documentation standards. Verification is a quality assurance activity performed by the business analyst to confirm that requirements artifacts are written clearly, accurately, and without internal contradictions before they are reviewed by business sponsors or handed over to development and testing teams.
While stakeholders often confuse verification with validation, BABOK® Guide v3 maintains a strict distinction:
Verification ("Built Right"): Focuses on internal quality, clarity, completeness, consistency, and adherence to modeling standards. It asks: Is the requirements specification well-constructed and free of technical defects?
Validation ("Built the Right Thing"): Focuses on external alignment with business goals, expected ROI, and customer value. It asks: Does this requirement deliver the business value necessary to solve the enterprise problem?
Core Requirements Quality Characteristics
For a requirement or design specification to be considered verified, it must satisfy nine core quality criteria defined in BABOK Guide v3. A defect in any of these characteristics degrades requirement quality and increases project rework risk.
Quality Characteristic Definition & Verification Standard Common Defect / Anti-Pattern
Atomic Contains a single, discrete requirement that cannot be broken down further without losing clarity. Combining user authentication, password resets, and session timeouts into one compound requirement statement.
Complete Contains all necessary details, background context, business rules, and acceptance criteria required for implementation. Stating "The system shall generate reports" without specifying trigger frequency, report fields, or output formats.
Consistent Free of conflicting statements, conflicting terminology, or mutually exclusive business logic across specifications. One section specifying 30-day payment terms while another section specifies 45-day payment terms for the same vendor tier.
Concise Stated clearly and succinctly without unnecessary background chatter, fluff, or redundant wording. Multi-paragraph narratives explaining legacy history instead of stating the crisp functional rule.
Feasible Technically, operationally, and economically achievable within known solution constraints, technology, and budget. Requiring real-time sub-millisecond database sync across global regions over high-latency public networks.
Prioritized Ranked, grouped, or negotiated in terms of relative importance and value against every other requirement. Handing a 400-item specification to developers with no priority ranking, forcing them to guess what must ship first.
Testable Stated in measurable, objective terms such that a QA engineer can design binary pass/fail test scripts. Writing vague statements such as "The system must be user-friendly and load pages extremely fast."
Unambiguous Expressed in precise language that yields only one single interpretation by all technical and business readers. Using subjective adverbs like "approximately", "as necessary", "flexible", or "user-friendly".
Understandable Written in clear language suited to the target audience using common business vocabulary and defined glossary terms. Using obscure technical jargon when presenting business rules to non-technical operations teams.
Verification Techniques and Inspection Workflows
Business analysts employ structured techniques to audit requirement quality systematically: REQUIREMENTS VERIFICATION WORKFLOW
- ┌────────────────────────┐ ┌────────────────────────┐ ┌────────────────────────┐
- │ 1. BA Self-Checklist │───>│ 2. Peer Review │───>│ 3. Structured │
- │ Audit │ │ Inspection │ │ Walkthrough │
- ├────────────────────────┤ ├────────────────────────┤ ├────────────────────────┤
- │ Verify format standards│ │ Peer BAs audit logic, │ │ Technical lead, QA, │
- │ & quality criteria. │ │ syntax, & consistency. │ │ & BA review testability│
- └────────────────────────┘ └────────────────────────┘ └────────────────────────┘
- 1. Requirements Checklist
Checklists are standardized audit sheets customized to an organization's methodology. A BA evaluates each requirement against a pre-defined set of quality criteria (e.g., "Does every requirement possess a unique ID?", "Are all acronyms defined in the project dictionary?", "Are non-functional thresholds quantified?").
2. Peer Reviews and Inspections
Peer reviews involve secondary business analysts inspecting requirements specifications. Peers bring fresh eyes to detect hidden assumptions, ambiguous phrasing, missing edge cases, or broken cross-references that the primary BA may have overlooked.
3. Structured Walkthroughs
A walkthrough is an interactive review session led by the BA with solution architects, software developers, and quality assurance leads. The goal is to review requirement syntax and testability line-by-line, confirming that technical teams interpret the specifications identically.
Economic Impact of Early Requirement Defect Prevention
Requirement defects discovered late in the system development lifecycle (SDLC) are exponentially more expensive to remediate than those corrected during verification.
SDLC Phase Defect Identified Relative Cost to Remediate Operational Impact & Rework Scope
Requirements Phase (Task 21) 1x (Baseline) Correcting prose, updating models, re-running checklist. Takes minutes.
Design Architecture Phase 3x - 5x Modifying database schemas, adjusting architectural components.
Software Coding Phase 10x - 15x Refactoring code, re-compiling builds, adjusting API contracts.
Integration / System Testing 25x - 50x Re-writing test scripts, re-executing regression suites, delaying sprints.
Post-Production Deployment 100x+ Emergency hotfixes, potential regulatory fines, lost customer trust, system downtime.
CBAP Exam Tips & Real-World Pitfalls
Distinguish Verification from Validation: If an exam scenario describes checking for proper capitalization, unique IDs, absence of subjective adverbs, or adherence to corporate templates, the answer is Task 21 Verify Requirements . If it describes confirming alignment with executive business goals, expected cost savings, or customer satisfaction metrics, the answer is Task 22 Validate Requirements .
Beware of Subjective Words: Exam questions frequently test testability by presenting non-testable statements (e.g., "The application should respond rapidly under normal loads"). A verified requirement must specify exact metrics: "The application shall process responses within 500ms under a load of 1,000 concurrent users."
Role of the BA in Verification: The BA is accountable for performing requirements verification prior to asking business sponsors for formal sign-off (Validation).