Study guide
1.3 Requirements Classification Schema & Architecture
CCBA Certification of Capability in Business Analysis Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & CCBA Exam Foundation
1.1 CCBA Exam Structure, Eligibility & IIBA Framework 1.2 The Business Analysis Core Concept Model (BACCM™) 1.3 Requirements Classification Schema & Architecture 1.4 CCBA Competency & Proficiency Levels (Level 2 — Skilled)
2 Chapter 2: Business Analysis Planning and Monitoring
2.1 Plan Business Analysis Approach (Task 3.1) 2.2 Plan Stakeholder Engagement (Task 3.2) 2.3 Plan Business Analysis Governance (Task 3.3) 2.4 Plan Business Analysis Information Management (Task 3.4) 2.5 Identify BA Performance Improvements (Task 3.5)
3 Chapter 3: Elicitation and Collaboration
3.1 Prepare for Elicitation (Task 4.1) 3.2 Conduct Elicitation (Task 4.2) 3.3 Confirm Elicitation Results (Task 4.3) 3.4 Communicate Business Analysis Information (Task 4.4) 3.5 Manage Stakeholder Collaboration (Task 4.5)
4 Chapter 4: Requirements Life Cycle Management
4.1 Trace Requirements (Task 5.1) 4.2 Maintain Requirements (Task 5.2) 4.3 Prioritize Requirements (Task 5.3) 4.4 Assess Requirements Changes (Task 5.4) 4.5 Approve Requirements (Task 5.5)
5 Chapter 5: Strategy Analysis
5.1 Analyze Current State (Task 6.1) 5.2 Define Future State (Task 6.2) 5.3 Assess Risks (Task 6.3) 5.4 Define Change Strategy (Task 6.4)
6 Chapter 6: Requirements Analysis and Design Definition — Modeling & Architecture
6.1 Specify and Model Requirements (Task 7.1) 6.2 Verify Requirements (Task 7.2) 6.3 Validate Requirements (Task 7.3) 6.4 Define Requirements Architecture (Task 7.4)
7 Chapter 7: Requirements Analysis and Design Definition — Design & Value
7.1 Define Design Options (Task 7.5) 7.2 Analyze Potential Value and Recommend Solution (Task 7.6) 7.3 Estimation Techniques & Solution Trade-Offs 7.4 Acceptance and Evaluation Criteria Definition
8 Chapter 8: Solution Evaluation
8.1 Measure Solution Performance (Task 8.1) 8.2 Analyze Performance Measures (Task 8.2) 8.3 Assess Solution Limitations (Task 8.3) 8.4 Assess Enterprise Limitations (Task 8.4) 8.5 Recommend Actions to Increase Solution Value (Task 8.5)
9 Chapter 9: Essential BABOK Techniques
9.1 Core Elicitation & Analysis Techniques 9.2 Process, Data & Non-Functional Requirements Modeling 9.3 Financial Analysis & Business Case Techniques 9.4 Prioritization & Scope Techniques 9.5 Root Cause & Decision Analysis Techniques
10 Chapter 10: Underlying Competencies & Perspectives
10.1 Analytical Thinking, Problem Solving & Systems Thinking 10.2 Behavioral Characteristics, Communication & Interaction Skills 10.3 Business Acumen, Solution Knowledge & BA Tooling 10.4 The Five BABOK Perspectives in Practice
11 Chapter 11: CCBA Exam Mastery & Scenario Strategy
11.1 Deconstructing CCBA Scenario Questions & BABOK Logic 11.2 Common Traps, Distractors & Subtle BABOK Distinctions 11.3 Comprehensive 8-Week Study Plan & Exam Day Strategy
1.3 Requirements Classification Schema & Architecture
Key Takeaways Explain This Topic AI
The BABOK v3 Requirements Classification Schema defines four structured tiers: Business Requirements, Stakeholder Requirements, Solution Requirements, and Transition Requirements.
Solution Requirements are divided into Functional Requirements (capabilities, behaviors, and actions) and Non-Functional / Quality of Service Requirements (environmental conditions, performance, security, reliability, scalability).
Transition Requirements are temporary capabilities, data migrations, and training activities necessary to move from the current state to the future state, and become obsolete once the transition is complete.
Requirements and Designs exist along a continuous spectrum where requirements represent 'what' is needed to deliver value and designs represent 'how' that need is realized.
Traceability establishes bidirectional lineage from high-level strategic business requirements down to granular functional, non-functional, and transition requirements.
Last updated: August 2026
1.3 Requirements Classification Schema & Architecture
A central responsibility of the business analyst is structuring, organizing, and categorizing business analysis information. In the BABOK® Guide v3 , this is formalized through the Requirements Classification Schema .
Requirements do not exist in isolation; they form a hierarchical architecture that traces high-level executive strategy down to granular system behaviors and temporary migration steps. Understanding this classification is essential for the CCBA exam, as many scenario questions require candidates to identify the specific class of requirement described or determine whether an artifact represents a requirement or a design.
- 1. The BABOK® v3 Requirements Classification Schema
- The BABOK® Guide v3 defines four distinct categories of requirements: ┌────────────────────────┐
- │ BUSINESS REQUIREMENTS │
- │ High-level goals, ob- │
- │ jectives, & enterprise │
- │ rationale │
- └───────────┬────────────┘
- │ (Derives)
- ▼
- ┌────────────────────────┐
- │STAKEHOLDER REQUIREMENTS│
- │ Needs of specific stake-│
- │ holders / user groups │
- └───────────┬────────────┘
- │ (Derives)
- ▼
- ┌────────────────────────┐
- │ SOLUTION REQUIREMENTS │
- │ Capabilities & qualities│
- │ of the future system │
- └───────────┬────────────┘
- │
- ┌───────────────────────┴───────────────────────┐
- ▼ ▼
- ┌────────────────────────┐ ┌────────────────────────┐
- │ FUNCTIONAL │ │ NON-FUNCTIONAL │
- │ System capabilities, │ │ Quality of service, │
- │ behaviors, actions, │ │ performance, security, │
- │ & data processing │ │ reliability, usability │
- └────────────────────────┘ └────────────────────────┘
- ▲
- │ (Supported by)
- ┌───────────┴────────────┐
- │TRANSITION REQUIREMENTS │
- │ Temporary capabilities │
- │ for cutover & migration│
- └────────────────────────┘
- 2. Detailed Breakdown of the Four Requirement Categories
- 1. Business Requirements
Definition: High-level statements of the goals, objectives, and outcomes of the enterprise. They describe why an initiative has been started and define the measurable success metrics.
Scope: Broad, enterprise-wide, or business-unit focused. They do not describe system features or user workflows.
Examples:
- "Increase digital insurance policy renewals by 25% within 12 months of launch."
- "Reduce customer onboarding processing costs from $85 per applicant to under $20 per applicant by Q3."
- "Achieve compliance with federal Anti-Money Laundering (AML) audit reporting standards by December 31."
- 2. Stakeholder Requirements
Definition: Statements of the needs of particular stakeholders or stakeholder classes that must be met in order to achieve the overarching business requirements. They describe how stakeholders will interact with the future state.
Scope: Bridge between strategic business requirements and granular solution capabilities. Often expressed from user, manager, customer, or partner viewpoints.
Examples:
"Underwriting managers must be able to review applicant risk scores and approve or reject applications within a single dashboard."
"Field technicians require the ability to access customer maintenance history while operating offline in remote areas."
"Warehouse supervisors need visibility into real-time inventory shortages to trigger supplier replenishment orders."
3. Solution Requirements
Definition: Describe the capabilities and qualities of a solution that meets stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution.
Solution requirements are formally split into two subcategories:
A. Functional Requirements
Definition: Describe the specific capabilities, behaviors, information transformations, and operations that the solution must be able to perform.
Characteristics: Focus on inputs, processing rules, calculations, data outputs, system responses, and error handling.
Examples:
"The system shall calculate sales tax based on the delivery postal code upon checkout."
"When an invalid password is entered three consecutive times, the system shall lock the user account and trigger a security alert email."
"The application shall generate a PDF invoice containing the order number, itemized totals, and VAT registration number."
B. Non-Functional Requirements (NFRs / Quality of Service Requirements)
Definition: Describe the environmental conditions, constraints, and quality attributes under which the solution must remain effective.
Characteristics: Do not describe what the system does, but how well it performs. They define the operational envelope.
NFR Category Quality Dimension Concrete Enterprise Specification Example
Performance & Latency Speed and response time "The search query shall return matching customer records within 500 milliseconds under a concurrent load of 5,000 users."
Security & Access Control Protection and privacy "All credit card data in transit and at rest shall be encrypted using AES-256 standards with role-based access control."
Reliability & Availability Uptime and fault tolerance "The payment gateway shall maintain 99.99% operational uptime during standard business hours (08:00–20:00 EST)."
Scalability & Capacity Growth handling "The database architecture shall support a 300% increase in daily transaction volume without degradation in processing latency."
Usability & Accessibility User experience standards "The public web application shall comply with WCAG 2.1 Level AA accessibility standards for screen readers and high contrast."
Maintainability & Portability Supportability and transfer "The solution microservices shall be deployable across both AWS and Azure containerized environments without code refactoring."
4. Transition Requirements
Definition: Describe the capabilities that the solution must have and the conditions the enterprise must meet to facilitate the transition from the current state to the future state, but which are not needed once the change is complete .
Characteristics: Temporary, time-bound, non-persistent, and discarded after go-live.
Key Categories of Transition Requirements:
Data Migration & Cleansing: Converting legacy customer account tables, cleaning invalid address strings, and loading 5 years of historical transactions into the new schema.
Training & Knowledge Transfer: Conducting 40 hours of instructor-led training for call center staff prior to cutover.
Parallel Operations / Dual-Running: Operating both the legacy billing system and new billing engine simultaneously for two billing cycles to reconcile balances.
Cutover & Rollback Contingency: Executing the database cutover within a 4-hour weekend maintenance window with automated rollback scripts in case of failure.
Warning
Common Exam Trap: Confusing Ongoing Operational Requirements with Transition Requirements . If a capability is required permanently (e.g., monthly archival of transactional records), it is a Solution Requirement . If a capability is required only during the rollout window (e.g., a one-time migration bridge script), it is a Transition Requirement .
3. The Requirements vs. Designs Continuum
In practical projects, the terms requirement and design are often confused. The BABOK® Guide v3 explicitly clarifies that requirements and designs exist along a continuous spectrum rather than as rigid opposites: REQUIREMENT ─────────────────────────────────────────────────────────► DESIGN
Focus: Need, Value, "WHAT" Focus: Solution Representation, "HOW"
- High Abstraction Low Abstraction
- ┌─────────────────────────────────────────────────────────────────────────────┐
- │ Level 1: "Reduce customer checkout abandonment rate by 15%." (Req - Business)│
- │ Level 2: "Shoppers need to check out as guests without creating passwords." │
- │ (Req - Stakeholder) │
- │ Level 3: "The checkout screen shall display a 1-click Apple Pay button." │
- │ (Req - Functional / Design Option) │
- │ Level 4: Wireframe showing button layout, pixel dimensions, and API payload.│
- │ (Design - Detailed Representation) │
- └─────────────────────────────────────────────────────────────────────────────┘
- BABOK Distinction Rules
Requirement: A usable representation of a need . It focuses on the problem to be solved, the capability requested, and the business value to be unlocked ( "What is needed" ).
Design: A usable representation of a solution . It focuses on the specific implementation approach, physical architecture, component structure, or visual layout ( "How the need will be satisfied" ).
Progressive Elaboration: What is a design at one level of abstraction becomes a requirement for the next lower level. For example, selecting a microservices architecture is a design decision for the enterprise architect, but it becomes an architectural requirement for the software development team.
Dimension Requirement Design
Primary Question What is needed and why? How will it be constructed and delivered?
Typical Artifacts User stories, business rules, acceptance criteria, use cases, process narratives. Screen mockups, wireframes, entity-relationship diagrams (ERDs), API specs, sequence diagrams.
Audience Business sponsors, end-users, product managers. Software engineers, system architects, database administrators, UI/UX designers.
Life Cycle Role Validates alignment with business goals and stakeholder needs. Guides construction, configuration, and physical implementation.
4. Requirements Architecture and Traceability
Requirements Architecture is the structure that gives shape to all requirements on an initiative. It ensures that requirements form a coherent, complete, and unambiguous whole.
Traceability Relationships in the Schema
Traceability tracks requirements backward to their origins and forward to the solution components that satisfy them:
Derive: A lower-level requirement is derived from a higher-level requirement (e.g., a Functional Solution Requirement is derived from a Stakeholder Requirement).
Depends: A requirement relates to another requirement where one must be implemented before the other (prerequisite).
Satisfy: A solution design element satisfies a specific functional or non-functional requirement.
Validate: A test case or acceptance criterion validates that a requirement achieves the desired business requirement outcome.
Exam Pointers for the CCBA
Identify the Level First: When a question presents a requirement statement, immediately categorize it: Business (Goal/ROI), Stakeholder (User perspective), Solution Functional (System capability), Solution Non-Functional (Quality/Constraint), or Transition (Temporary/Cutover).
Look for Keywords: "Shall compute/calculate/display" indicates Functional . "Shall respond in <2 seconds / 99.9% uptime / AES-256" indicates Non-Functional . "Data migration / user training / parallel run" indicates Transition .
Assess the Perspective: If the statement is written from the perspective of an external actor achieving a goal ( "The loan officer must be able to..." ), it is a Stakeholder Requirement .