6.2 Verify Requirements
Key Takeaways
- 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.
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).
A business analyst is auditing a draft requirements specification and identifies the following statement: 'The loan processing system must process user applications quickly and handle high volume during peak hours without crashing.' How should the BA modify this statement to ensure it satisfies BABOK v3 verification standards?
During a requirements inspection review, a software architect notes that Requirement 4.2 states that customer addresses must be stored using a 5-digit ZIP code format, whereas Requirement 8.7 states that international address formats including alphanumeric postal codes must be supported for all accounts. Which quality characteristic has been violated?
A lead business analyst conducts a quality review on a newly drafted Business Requirements Document (BRD) using a standardized audit checklist before presenting the document to executive stakeholders. What task is the BA performing?
Why is verifying requirements early in the project lifecycle considered one of the most cost-effective risk mitigation strategies in business analysis?