6.4 Define Requirements Architecture (Task 7.4)
Key Takeaways
- Task 7.4 structures all requirements and designs into a cohesive, harmonious framework that ensures all components collectively satisfy business objectives.
- A Viewpoint is the architectural template, conventions, and modeling standards used to construct a view; a View is the actual instantiated artifact created for a specific stakeholder audience.
- Common business analysis viewpoints include Business Process, Data/Information, User Interface, and Audit/Security/Compliance viewpoints.
- BABOK v3 identifies five core requirement relationship types: Necessity (dependency), Effort, Subset (decomposition), Cover, and Value (synergy).
- Requirements architecture manages architectural trade-offs, detects orphan requirements, prevents circular dependencies, and guarantees structural completeness.
6.4 Define Requirements Architecture (Task 7.4)
Quick Summary: BABOK® Guide v3 Task 7.4 (Define Requirements Architecture) is the structural synthesis of business analysis. It organizes, interconnects, and contextualizes individual requirements and designs into a cohesive, holistic architecture that ensures all business objectives are fully addressed without gaps, contradictions, or unaligned elements.
Purpose and Definition of Task 7.4
The purpose of Define Requirements Architecture is to structure all requirements and designs so that they support the overall business purpose and objectives of the change. Individual requirements are like individual bricks; without a master architectural blueprint, a pile of bricks will never form a stable building. Requirements architecture ensures that requirements work together harmoniously as a unified system.
A complete requirements architecture enables business analysts to:
- Demonstrate how high-level strategic goals decompose into stakeholder needs and granular functional/non-functional solution requirements.
- Identify architectural gaps, duplicate features, and orphan requirements (requirements that do not trace to any business need).
- Understand the systemic ripple effects and trade-offs when requirements change or constraints shift.
+-----------------------------------------------------------------------------------+
| BABOK Task 7.4 Structure |
+-----------------------------------------------------------------------------------+
| INPUTS: |
| * Information Management Approach (from Task 3.4) |
| * Requirements (Any State: specified, verified, validated) |
| |
| ELEMENTS: |
| 1. Requirements Viewpoints and Views |
| 2. Template Architectures |
| 3. Completeness |
| 4. Relate and Verify Requirements Relationships |
| 5. Business Analysis Information Architecture |
| |
| OUTPUTS: |
| * Requirements Architecture |
+-----------------------------------------------------------------------------------+
Viewpoints vs. Views: The Foundational Architectural Duality
A critical distinction on the CCBA examination is the conceptual difference between a Viewpoint and a View:
- Viewpoint: A set of conventions, definitions, modeling techniques, and guidelines used to construct and interpret a view. It serves as the architectural pattern, template, or lens.
- View: The actual instantiated deliverable or representation created using a specific viewpoint to address the concerns of a particular stakeholder group.
VIEWPOINT (The Template / Lens) ──────────> VIEW (The Actual Instantiated Model)
"BPMN 2.0 Process Viewpoint Standard" ──> "Global Inbound Warehouse Receiving Flow v3"
"Relational Data Modeling Viewpoint" ──> "Customer Order Management Logical ERD"
"Role-Based Access Security Viewpoint" ──> "Claims Adjudication RBAC Matrix"
Core Business Analysis Viewpoints
| Viewpoint | Target Stakeholder Audience | Standard Modeling Techniques Used | Core Questions Addressed |
|---|---|---|---|
| Business Process Viewpoint | Operations Managers, Business Process Owners, End-Users | BPMN Flowcharts, Swimlane Diagrams, Value Stream Maps | "How does work flow across departments? Where are the manual handoffs, bottlenecks, and decision points?" |
| Data / Information Viewpoint | Data Architects, Database Engineers, Analytics Leads | ERDs, Data Dictionaries, Class Diagrams, Data Flow Diagrams | "What business entities exist? How are they structured, related, and transformed across systems?" |
| User Interface / Interaction Viewpoint | UI/UX Designers, Product Managers, Usability Testers | Wireframes, Mockups, Storyboards, User Journey Maps | "How do human actors navigate screens, input information, and interact with the solution?" |
| Audit / Security / Compliance Viewpoint | Compliance Officers, Information Security, Regulators | Roles & Permissions Matrices, Threat Models, Audit Logs | "How is sensitive data protected? Who has access rights? How are regulatory audit trails maintained?" |
| Infrastructure / Technical Viewpoint | Cloud Architects, DevOps Leads, Systems Engineers | Deployment Topologies, Component Diagrams, Network Maps | "Where is the solution hosted? What hardware, cloud services, and network channels support execution?" |
The Five Requirements Relationship Types in BABOK v3
Within a requirements architecture, requirements do not exist in isolation; they are connected by explicit relational dependencies. BABOK v3 defines five foundational relationship types:
+-----------------------------------------------------------------------------------+
| The 5 BABOK v3 Requirement Relationships |
+-----------------------------------------------------------------------------------+
| |
| 1. NECESSITY (Dependency) 2. EFFORT 3. SUBSET (Decomposition)|
| Req A requires Req B to Req A makes Req B Req A is a decomposed |
| exist or function. easier or harder. sub-component of Req B. |
| |
| 4. COVER 5. VALUE (Synergy) |
| Req A completely satisfies Req A enhances the |
| or encapsulates Req B. business value of Req B. |
| |
+-----------------------------------------------------------------------------------+
| Relationship Type | Formal BABOK v3 Definition | Practical Enterprise Example |
|---|---|---|
| 1. Necessity (Dependency) | Requirement A cannot be implemented or function unless Requirement B is implemented first. | A user cannot "Export Payment History to PDF" (Req A) unless "Authenticate User via OAuth2" (Req B) exists. |
| 2. Effort | Implementing Requirement A significantly increases or decreases the effort required to implement Requirement B. | Implementing a "Centralized Microservice API Gateway" (Req A) reduces the engineering effort for "Mobile App Integration" (Req B). |
| 3. Subset (Decomposition) | Requirement A is a specialized part, decomposed component, or sub-requirement of a higher-level Requirement B. | "Verify Card CVV Code" (Req A) is a decomposed subset of "Process Credit Card Payment" (Req B). |
| 4. Cover | Requirement A satisfies or encapsulates the functional scope of Requirement B in its entirety or across multiple contexts. | An enterprise "Single Sign-On (SSO) Protocol" (Req A) covers the login requirements of four distinct departmental portals (Req B1..B4). |
| 5. Value (Synergy) | Implementing Requirement A increases the business value, ROI, or effectiveness derived from Requirement B. | An "Automated SMS Delivery Tracking" module (Req A) dramatically increases customer satisfaction value from "Online Order Placement" (Req B). |
Managing Trade-Offs, Conflicts, and Structural Completeness
A primary responsibility in Task 7.4 is identifying and resolving conflicts across competing requirements and viewpoints. Requirements architecture provides the framework for structured trade-off analysis.
Resolving Architectural Conflicts
- Security vs. Usability: Multi-factor authentication adds security but increases user login friction. The BA architectures tiered authentication (biometrics on mobile, step-up MFA for large transactions).
- Performance vs. Cost: Sub-millisecond database replication requires costly multi-region active-active clusters. The BA works with architects to evaluate asynchronous replication trade-offs against business recovery time objectives (RTO).
- Standardization vs. Local Customization: Global ERP rollouts balance standardized corporate workflows against localized statutory tax requirements.
Ensuring Structural Completeness
A requirements architecture is structurally complete when:
- Every business requirement decomposes into stakeholder and solution requirements without dangling gaps.
- No Orphan Requirements exist (every functional feature traces up to an approved business need).
- No Circular Dependencies exist (e.g., Module A requires Module B, which requires Module C, which requires Module A).
- All Transition Requirements (data migration, staff training, parallel run procedures) are accounted for to bridge current and future states.
Enterprise Scenario: Omnichannel Retail Architecture
A global retail enterprise redesigns its customer engagement architecture to unify in-store point-of-sale (POS), mobile e-commerce, and warehouse fulfillment:
- Viewpoint Integration: The lead BA establishes four distinct views:
- Process View: End-to-end Buy Online, Pick Up In Store (BOPIS) customer journey and store associate fulfillment flow.
- Data View: Logical ERD linking Customer Account, Unified Order, Inventory SKU, and Store Geolocation.
- Security View: PCI-DSS compliant tokenization matrix for credit card storage.
- Relationship Mapping: The BA identifies a Value relationship between the Real-Time In-Store Inventory Locator and the Mobile Checkout Engine—implementing the inventory locator increases the mobile app's sales conversion by 28%.
- Completeness Check: An architectural review reveals that while online order placement and in-store pickup are fully specified, the Customer In-Store Return of Online Purchases workflow was completely missing. The BA catches the gap before software development begins.
Key BABOK v3 Techniques for Task 7.4
- Architectural Frameworks: Employs established enterprise frameworks (e.g., TOGAF, Zachman) to structure business analysis information across standardized layers.
- Data Modeling & Process Modeling: Structures data entities and business workflows into cohesive, interconnected viewpoints.
- Functional Decomposition: Breaks down large enterprise capabilities into hierarchical trees of sub-capabilities and requirements.
- Mind Mapping: Used to brainstorm and visualize relational connections and clusters among requirement packages.
- Scope Modeling: Defines systemic boundaries, interfaces, and external integration points across the architecture.
[!TIP] CCBA Exam Tip: Scenario questions often test your ability to identify the correct requirement relationship type. If a question states that "Building the centralized customer database first will cut the development time of the billing engine by 40%", this is an Effort relationship. If it states that "The billing engine cannot run without the customer database", it is a Necessity relationship.
[!WARNING] CCBA Exam Trap: Do not assume that "Requirements Architecture" is the exclusive responsibility of IT Technical Architects. In BABOK v3, Requirements Architecture is a core Business Analysis task. While technical architects design software/hardware infrastructure, the Business Analyst architects the holistic structure of business rules, user needs, process flows, data models, and functional capabilities.
A business analysis team is developing the requirements architecture for a global supply chain initiative. The lead BA creates a standardized modeling template that specifies the notation standards, symbol conventions, visual layout rules, and semantic guidelines for representing cross-docking workflows across all regional distribution centers. Regional analysts then use this standard to generate four specific warehouse workflow diagrams. In BABOK v3 terminology, how are the standard template and the resulting regional diagrams classified?
A business analyst is structuring requirements for an enterprise human capital management platform. The analyst notes that implementing a 'Self-Service Employee Profile Portal' (Requirement A) is not technically mandatory for the 'Automated Annual Benefits Open Enrollment Module' (Requirement B) to operate. However, implementing Requirement A first will dramatically increase employee adoption of Requirement B and boost overall benefits enrollment satisfaction by 45%. Which requirements relationship type connects Requirement A to Requirement B?
During the synthesis of a requirements architecture for an online brokerage platform, the business analyst identifies a fundamental conflict: the Information Security Officer mandates a 12-character alphanumeric password with mandatory SMS two-factor authentication upon every trade submission (Security Viewpoint), while the Head of Active Trading insists that high-frequency day traders will abandon the platform if trade execution requires more than a single click (Usability Viewpoint). What is the MOST appropriate action for the business analyst to take within Task 7.4?