1.3 Key Concepts, Terms & Requirements Classification

1.3 Key Concepts, Terms & Requirements Classification

The BABOK® v3 Requirements Classification Schema

In business analysis, requirements are structured representations of needs. The BABOK® Guide v3 establishes a precise four-tier taxonomy for requirements classification. Understanding this hierarchy is essential for organizing requirements architecture, maintaining traceability, and ensuring that technical solution specifications directly align with strategic business goals.

                               REQUIREMENTS CLASSIFICATION HIERARCHY
 ┌───────────────────────────────────────────────────────────────────────────────────────────┐
 │ 1. BUSINESS REQUIREMENTS                                                                  │
 │    High-level enterprise goals, objectives & strategic outcomes ('Why the change exists')   │
 └─────────────────────────────────────────────┬─────────────────────────────────────────────┘
                                               │
                                               ▼
 ┌───────────────────────────────────────────────────────────────────────────────────────────┐
 │ 2. STAKEHOLDER REQUIREMENTS                                                               │
 │    Needs & expectations of specific user groups ('Bridge between business & technical')   │
 └─────────────────────────────────────────────┬─────────────────────────────────────────────┘
                                               │
                                               ▼
 ┌───────────────────────────────────────────────────────────────────────────────────────────┐
 │ 3. SOLUTION REQUIREMENTS                                                                  │
 │    Specific capabilities & qualities the target solution must possess                        │
 │                                                                                           │
 │   ┌───────────────────────────────────────────┐ ┌─────────────────────────────────────┐   │
 │   │ FUNCTIONAL REQUIREMENTS                   │ │ NON-FUNCTIONAL REQUIREMENTS         │   │
 │   │ System behaviors, data actions & rules    │ │ Quality of service, performance,    │   │
 │   │ ('What the system must do')               │ │ availability & security constraints │   │
 │   └───────────────────────────────────────────┘ └─────────────────────────────────────┘   │
 └─────────────────────────────────────────────┬─────────────────────────────────────────────┘
                                               │
                                               ▼
 ┌───────────────────────────────────────────────────────────────────────────────────────────┐
 │ 4. TRANSITION REQUIREMENTS                                                                │
 │    Temporary capabilities needed strictly during migration/cutover ('No longer needed post') │
 └───────────────────────────────────────────────────────────────────────────────────────────┘

---

1. Business Requirements

Business Requirements are high-level statements of goals, objectives, and outcomes that describe why an enterprise change initiative is undertaken. They articulate the strategic purpose of the initiative from an executive enterprise perspective rather than detailing software features or user actions.

• Primary Purpose: Establish strategic alignment, justify capital expenditure, and set measurable business outcome targets.
• Example Statement: "The commercial banking division must reduce loan application processing lead time from 14 business days to under 48 hours to prevent customer attrition to digital competitors."

2. Stakeholder Requirements

Stakeholder Requirements describe the needs of specific stakeholders or stakeholder groups that must be met in order to achieve the overarching business requirements. They serve as the functional bridge between high-level executive business goals and detailed technical solution requirements.

• Primary Purpose: Articulate user expectations, workflow interactions, and role-based operational needs.
• Example Statement: "Loan Underwriters must be able to view an applicant's real-time credit score, cross-collateralized assets, and outstanding debt obligations on a single consolidated risk dashboard."

3. Solution Requirements

Solution Requirements describe the specific capabilities and qualities of a solution that meet stakeholder requirements and business requirements. They provide the detailed specifications used by developers, system architects, and testers to build the target solution. Solution requirements are sub-classified into two distinct categories:

A. Functional Requirements

Functional requirements describe the capabilities, behaviors, and data manipulation rules that the solution must perform. They specify how the system processes inputs, executes calculations, responds to user actions, and enforces business logic.

• Example Statement: "When an underwriter submits a approved loan decision, the system shall automatically generate a standardized PDF approval letter, populate key loan terms from the database, and trigger an automated email notification to the applicant within 60 seconds."

B. Non-Functional Requirements (Quality of Service)

Non-Functional requirements (also referred to as Quality of Service requirements) describe the conditions, environmental qualities, performance thresholds, and operational constraints under which the solution must function. They do not describe specific system behaviors; instead, they define how well the system must perform.

• Common Non-Functional Categories: Performance, Reliability, Availability, Scalability, Security, Maintainability, Usability, Accessibility, and Compliance.
• Example Statement: "The loan decision engine must support up to 5,000 concurrent user sessions during peak hours while maintaining response times under 800 milliseconds for 99.5% of database queries."

4. Transition Requirements

Transition Requirements describe the capabilities that the solution must possess to transfer the enterprise smoothly from its current operational state to the desired future state, but which are no longer needed once the transition is complete.

• Primary Purpose: Govern data conversion, legacy system migration, dual-running operations, employee training, and cutover protocols.
• Key Exam Distinction: Once cutover is complete and the future state solution is fully operational, transition requirements become obsolete and are not maintained in the ongoing solution requirements baseline.
• Example Statement: "The migration utility must extract 10 years of historical legacy paper loan records, transform the unstructured text into searchable JSON schemas, and load the validated data into the new database prior to go-live."

---

Critical BABOK® Terminology & Distinctions

Requirements vs. Designs

One of the most critical conceptual distinctions in BABOK Guide v3 is the relationship between Requirements and Designs. Many practitioners incorrectly assume that requirements are textual and designs are visual. According to the BABOK, the true distinction relies on intent and perspective:

• Requirements focus on NEED: Statements of what is needed to deliver value to stakeholders.
• Designs focus on SOLUTION REPRESENTATION: Physical, logical, visual, or structural representations of how a solution will fulfill those requirements.

Requirements and Designs exist at every level of abstraction, as illustrated in the comparison table below:

Domain vs. Solution

• Domain: The sphere of the organization, business area, problem space, and environment in which the business need exists.
• Solution: The specific set of changes to domain capabilities—encompassing software applications, business workflows, policy frameworks, organizational structures, and hardware—that satisfies the need.

Risk vs. Risk Tolerance

• Risk: The effect of uncertainty on the achievement of objectives. Risks can represent threats (events that degrade value) or opportunities (unexpected events that enhance value).
• Risk Tolerance: The degree of uncertainty an organization or stakeholder is willing to accept in pursuit of value. An organization with low risk tolerance (such as a nuclear plant or commercial bank) demands stringent requirements verification, extensive non-functional testing, and formal governance approvals.