1.3 Requirements Classification Schema & Architecture

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.

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.

---

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

1. 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).
2. 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.
3. 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.