6.2 Verify Requirements (Task 7.2)
Key Takeaways
- Task 7.2 ensures requirements and designs meet internal quality standards, follow modeling conventions, and are ready to guide implementation.
- BABOK v3 defines nine essential Quality Characteristics of verified requirements: Atomic, Complete, Consistent, Concise, Feasible, Unambiguous, Testable/Verifiable, Prioritized, and Understandable.
- Verification focuses on structural quality and syntax ('Are we building the artifact right?'), distinct from validation which focuses on value ('Are we building the right thing?').
- Key verification activities include Formal Inspections (moderator-led), Structured Walkthroughs (author-led), Peer Reviews, Desk Checks, and Quality Checklists.
- Syntactic correctness validates conformance to modeling notations and grammar; semantic correctness validates internal logic and consistency of meaning.
6.2 Verify Requirements (Task 7.2)
Quick Summary: BABOK® Guide v3 Task 7.2 (Verify Requirements) is the rigorous quality assurance gate for business analysis work products. It ensures that specified requirements and designs meet defined quality standards, adhere to modeling conventions, are internally consistent, and provide sufficient clarity to support downstream design, development, and testing activities.
Purpose and Definition of Task 7.2
The purpose of Verify Requirements is to ensure that a set of requirements or designs has been developed with sufficient detail and quality to be used by stakeholders for subsequent work. Verification acts as an editorial and structural filter—it does not ask whether a requirement delivers high financial ROI (which is the domain of Validation in Task 7.3), but rather whether the requirement is well-formed, cohesive, unambiguous, and mathematically testable.
Requirements that bypass verification introduce severe downstream project failures:
- Development Rework: Engineers build incorrect features based on conflicting or vague statements.
- Unverifiable Acceptance Criteria: Quality assurance testers cannot construct pass/fail test cases for subjective requirements like "the interface must be fast and intuitive."
- Scope Creep: Poorly bounded, compound requirements disguise massive hidden architectural work.
+-----------------------------------------------------------------------------------+
| BABOK Task 7.2 Structure |
+-----------------------------------------------------------------------------------+
| INPUTS: |
| * Requirements (Specified and Modeled - from Task 7.1) |
| * Designs (Specified and Modeled - from Task 7.1) |
| |
| ELEMENTS: |
| 1. Characteristics of Requirements and Designs Quality |
| 2. Verification Activities |
| 3. Checklists |
| |
| OUTPUTS: |
| * Requirements (Verified) |
| * Designs (Verified) |
+-----------------------------------------------------------------------------------+
The Nine Quality Characteristics of Verified Requirements
BABOK v3 defines nine foundational quality characteristics that every verified requirement and design artifact must exhibit. CCBA candidates must know these definitions and be capable of diagnosing violations in scenario questions:
| Quality Characteristic | BABOK v3 Definition | Flawed / Unverified Example | Verified / Corrected Example |
|---|---|---|---|
| 1. Atomic | Self-contained; describes a single capability or constraint that cannot be divided without loss of meaning. | "The system shall allow users to upload PDF invoices, extract line items, and email payment receipts to vendors." | Divided into three separate atomic requirements: (1) upload PDF, (2) extract line items, (3) email receipts. |
| 2. Complete | Contains all information necessary for developers to build and testers to verify without unstated assumptions. | "The system shall calculate sales tax on orders." | "The system shall calculate state and municipal sales tax based on the customer's verified delivery zip code using Tax Table Rev-2026." |
| 3. Consistent | Does not contradict or conflict with any other requirement, enterprise policy, or standard. | Requirement A states "Passwords expire in 30 days", while Requirement B states "Passwords never expire for SSO users." | Harmonized requirement specifying explicit conditions under which standard vs. SSO password policies apply. |
| 4. Concise | Free of extraneous narrative, fluff, redundancy, or unnecessary technical jargon. | "In order to make sure our great customers feel truly appreciated, the UI will display a nice friendly welcome banner." | "The home screen shall display the user's first name in a greeting banner upon successful login." |
| 5. Feasible | Capable of being implemented within known constraints of budget, technical architecture, timeline, and legal boundaries. | "The mobile app must process encrypted video streams with zero millisecond latency over 3G cellular connections." | "The mobile app shall buffer video streams to achieve uninterrupted playback with <= 1.5 second initial latency over 4G/5G connections." |
| 6. Unambiguous | Worded so clearly that all readers reach exactly one single, identical interpretation. | "The system shall generate reports in a reasonable timeframe." | "The system shall generate standard monthly reconciliation reports within <= 3.0 seconds under peak load." |
| 7. Testable / Verifiable | Phrased so that an objective test, demonstration, inspection, or analysis can conclusively prove compliance. | "The user interface shall be highly user-friendly and modern." | "90% of first-time users shall complete an order checkout without errors in <= 2 minutes during usability testing." |
| 8. Prioritized | Ranked or categorized according to urgency, business value, technical risk, or implementation dependencies. | A flat list of 400 requirements where every item is marked "Critical Priority." | Requirements prioritized using MoSCoW (Must, Should, Could, Won't) or numerical ranking aligned with release releases. |
| 9. Understandable | Written in clear, grammatically sound language using domain-appropriate terminology familiar to stakeholders. | Heavy use of obscure developer shorthand and conflicting internal acronyms without definitions. | Written in clear business domain language with all technical terms defined in the project glossary. |
Verification Activities and Techniques
Verification is executed through structured evaluation activities, ranging from lightweight peer checks to rigorous formal inspections:
┌─────────────────────────────────────────────────────────────────────────────┐
│ INFORMAL / LOW CEREMONY │
│ * Desk Check: The author self-reviews artifacts against standard checklists.│
│ * Peer Review: A fellow business analyst inspects models for syntax/grammar.│
├─────────────────────────────────────────────────────────────────────────────┤
│ MODERATE CEREMONY │
│ * Structured Walkthrough: The BA author leads stakeholders through the │
│ deliverables step-by-step to explain logic and gather direct feedback. │
├─────────────────────────────────────────────────────────────────────────────┤
│ FORMAL / HIGH CEREMONY │
│ * Formal Inspection (Fagan Style): A formal, role-based review chaired by a │
│ neutral Moderator (not the author), with dedicated Inspectors and Scribe. │
│ Defects are logged, categorized by severity, and tracked to closure. │
└─────────────────────────────────────────────────────────────────────────────┘
Syntactic vs. Semantic Correctness
- Syntactic Correctness: Validates that the artifact adheres to formal notation rules, grammatical syntax, and structural conventions (e.g., ensuring every BPMN gateway has both incoming and outgoing sequence flows, or that every user story follows the As a / I want / So that template).
- Semantic Correctness: Validates that the artifact expresses true, logically consistent meaning within the business domain without contradictions, circular dependencies, or logical paradoxes.
The Role of Quality Checklists
Checklists establish standardized verification criteria across an enterprise business analysis practice. Checklists typically evaluate:
- Are all standard requirement attributes (author, version, priority, status, source) documented?
- Do all non-functional requirements contain quantifiable metrics and measurement conditions?
- Are all domain terms linked to entries in the project glossary?
- Have all exception paths and alternate scenarios been documented for each use case?
Enterprise Scenario: Quality Audit of a Clinical Prescription System
A health-tech enterprise is developing a cloud-based Electronic Prescription (e-Rx) solution for hospital networks. During Task 7.2, the lead BA conducts a formal verification inspection of the requirement specifications:
- Ambiguity Detected: Requirement 4.2 states: "The system should warn doctors when prescribing potentially dangerous drug interactions."
- Verification Finding: Fails Unambiguous and Testable criteria (what is "potentially dangerous"? what type of "warning"?).
- Correction: "The system shall display a modal blocking alert whenever a prescribed medication has a Level 1 (Severe/Contraindicated) interaction in the National Drug Database with the patient's active medication list."
- Non-Atomicity Detected: Requirement 6.1 states: "The system shall authenticate the physician via two-factor authentication, query the state prescription monitoring program database, and log the audit transaction."
- Verification Finding: Fails Atomic criteria (bundles authentication, external API integration, and audit logging into a single requirement).
- Correction: Decomposed into three distinct, individually traceable requirements.
- Inconsistency Detected: Functional Spec lists patient weight in kilograms, while the dosage calculation algorithm assumes pounds.
- Verification Finding: Fails Consistent criteria.
- Correction: Standardized the entire data model on metric units (kg) with explicit conversion functions.
Key BABOK v3 Techniques for Task 7.2
- Acceptance and Evaluation Criteria: Ensures requirements are written with objective, measurable pass/fail thresholds.
- Checklists: Provides standardized quality rubrics to ensure no verification dimensions are overlooked.
- Item Tracking: Logs, tracks, and manages defects, questions, and action items discovered during verification reviews through resolution.
- Metrics and Key Performance Indicators (KPIs): Measures requirement defect density (e.g., number of defects found per requirement block during inspections).
- Reviews (Walkthroughs and Inspections): Engages peers, architects, and SMEs in structured evaluations to identify errors, ambiguities, and omissions.
[!TIP] CCBA Exam Tip: Remember the key distinction between a Structured Walkthrough and a Formal Inspection. In a Walkthrough, the author leads the presentation and guides attendees through the document. In a Formal Inspection, a neutral Moderator leads the meeting, participants arrive having performed pre-meeting reviews, and the primary objective is defect identification, not solutioning.
[!WARNING] CCBA Exam Trap: Questions often present a requirement that sounds very desirable and strategically aligned (e.g., "The new portal must be completely secure, highly reliable, and provide a world-class user experience") and ask whether it is ready for development. The answer is NO—it fails Verification because it is ambiguous, subjective, untestable, and non-atomic.
A business analyst reviews a software requirement specification document containing the following statement: 'The new customer portal must be extremely responsive, user-friendly, and capable of exporting financial account statements in CSV format while automatically sending text notifications to account managers.' When evaluated against the BABOK v3 quality characteristics of verified requirements, which combination of defects does this requirement exhibit?
An enterprise business analysis team is preparing for a high-stakes quality evaluation of a core banking platform requirements package. The review session is chaired by an independent, trained Moderator who guides the team through pre-distributed artifacts. Participants have pre-read the specifications and bring logged defect lists. A dedicated Scribe records all identified defects, while the author does not lead the meeting. What type of verification activity is being conducted?
During a requirements verification review of a newly modeled business process, a senior business analyst notes that while all BPMN gateways adhere perfectly to notation syntax (valid branching symbols and labeled outgoing sequence flows), a parallel split gateway leads to two mutually exclusive tasks that can never execute simultaneously in business operations. How is this quality distinction classified in BABOK v3 verification?