6.4 Define Requirements Architecture

6.4 Define Requirements Architecture

Purpose of Task 23

The primary objective of Task 23: Define Requirements Architecture is to structure, synthesize, and organize all requirements and design options into a single, holistic, cohesive model that conveys the complete solution scope. Individual requirements rarely exist in total isolation; they form an intricate, multi-dimensional web of logical dependencies, structural hierarchies, behavioral workflows, and technical constraints. Without a formally articulated requirements architecture, stakeholders only view disconnected fragments of text or isolated diagrams. This lack of architectural cohesion inevitably leads to uncaptured system dependencies, redundant capabilities, conflicting business rules, and severe scope creep.

In the BABOK® Guide v3 framework, Requirements Architecture represents the structural blueprint of the solution. It demonstrates how individual functional, non-functional, transition, and business requirements interact to support high-level business goals. A robust requirements architecture enables senior business analysts to conduct rigorous impact analysis during change management, govern project boundaries across complex enterprise transformations, and ensure that technical delivery teams build components that fit together seamlessly.

---

IEEE 1471 / ISO 42010 Standards: Viewpoints vs. Views Architecture

BABOK Guide v3 aligns its architectural doctrine with international system and software engineering standards, specifically IEEE 1471 and ISO/IEC/IEEE 42010 (Systems and software engineering — Architecture description). These standards establish formal definitions for framing complex information systems across diverse stakeholder perspectives.

The Fundamental Distinction: Viewpoint vs. View

A critical distinction tested on the CBAP examination is the difference between a Viewpoint and a View:

• Viewpoint (The Lens / Pattern Criteria): The viewpoint defines how to construct a model. It establishes the perspective, audience boundaries, notation rules, and framing requirements. It acts as the camera lens through which a specific aspect of the enterprise is observed.
• View (The Photograph / Concrete Artifact): The view is the actual resulting model artifact created by applying the viewpoint criteria to a specific project. It represents the concrete snapshot or diagram containing actual requirements data.

                          IEEE 1471 / ISO 42010 ARCHITECTURE PATTERN
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │                               VIEWPOINT CRITERIA                                 │
 │ (Audience Rules: Focus, Framing, Notation Standards, Allowed Relationship Types) │
 └────────────────────────────────────────┬─────────────────────────────────────────┘
                                          │ generates / instantiates
                                          ▼
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │                                 SPECIFIC VIEW                                    │
 │ (Concrete Artifact: Business Capability Decomposition, BPMN Workflow, Logical ERD)│
 └────────────────────────────────────────┬─────────────────────────────────────────┘
                                          │ populates
                                          ▼
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │                           HOLISTIC REQUIREMENTS ARCHITECTURE                     │
 └──────────────────────────────────────────────────────────────────────────────────┘

---

Enterprise Architecture Frameworks (Zachman, TOGAF, FEAF)

Senior business analysts leverage established Enterprise Architecture (EA) Frameworks to structure requirements architectures systematically across large-scale organizational initiatives:

1. The Zachman Framework for Enterprise Architecture

The Zachman Framework is an enterprise ontology organized as a 6x6 matrix. It intersects six fundamental stakeholder perspectives (Rows) with six basic interrogative questions (Columns):

• Six Interrogative Columns: What (Data), How (Function), Where (Network), Who (People), When (Time), and Why (Motivation).
• Six Perspective Rows: Planner (Scope), Owner (Business Model), Designer (System Model), Builder (Technology Model), Subcontractor (Detailed Specifications), and Functioning Enterprise.
• BA Integration: Task 23 maps requirements into specific Zachman cells, ensuring that functional rules (How), data structures (What), user permissions (Who), and strategic goals (Why) are fully articulated at every depth.

2. TOGAF ADM (The Open Group Architecture Framework)

TOGAF structures architecture across four core domain layers using its Architecture Development Method (ADM):

• Business Architecture: Business strategy, governance, organization, and key business processes.
• Data Architecture: Structure of physical and logical data assets and data management resources.
• Application Architecture: Blueprint for individual application systems to be deployed, their interactions, and relationships.
• Technology Architecture: Software and hardware capabilities required to support deployment of business, data, and application services.
• BA Integration: The business analyst ensures that requirements architecture bridges Business Architecture down to Data and Application Architecture layers.

3. FEAF (Federal Enterprise Architecture Framework)

FEAF provides a standardized structure for government and enterprise initiatives, organizing architecture into Business, Service, Component, Technical, and Data Reference Models. It emphasizes multi-agency interoperability and shared service capability mapping.

---

Relational Dependency Taxonomy

Requirements within an architecture do not exist independently; they are connected through precise relational linkages. BABOK Guide v3 traces relationships as Derive, Depend (with the Necessity and Effort sub-types), Satisfy, and Validate — the four types covered in section 4.1 — and section 7.4 additionally requires every relationship in the architecture to be defined, necessary, correct, unambiguous, and consistent. Within that structure, senior BAs map the dependency patterns below. Note that Subset, Cover, and Value are carried over from the BABOK v2 relationship list: recognize them in practice, but do not name them as v3 traceability relationship types on the exam.

---

Architecture Completeness, Alignment, and Conflict Identification

A fully articulated requirements architecture acts as an enterprise quality control system to guarantee completeness and structural integrity:

1. Eliminating Orphan Requirements and Orphan Goals

• Orphan Requirements: Functional or technical requirements that cannot be traced up to any validated business objective. Requirements architecture flags these item for scope removal.
• Orphan Business Goals: Executive strategic objectives that lack supporting functional capabilities or requirements within the architecture. The architecture highlights these gaps for further elicitation.

2. Structural and Traceability Alignment

Requirements architecture establishes multi-directional traceability. It guarantees horizontal alignment (ensuring process flows align with data entity schemas) and vertical alignment (ensuring low-level user stories trace up through capabilities to strategic enterprise vision).

3. Conflict Identification

By synthesizing cross-functional requirements into a single model, the BA rapidly identifies contradictory business rules. For instance, if the Risk Management team specifies a 10-day holding period for foreign transfers while the Sales team specifies instant settlement, the architecture highlights this operational conflict for executive resolution.

---

Expanded Worked Example: Healthcare & Financial Banking Architecture

Consider an enterprise healthcare system deploying a Patient Financial Services & Billing Portal. A senior BA structures Task 23 across three distinct viewpoints:

                               HEALTHCARE BILLING ARCHITECTURE
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │ 1. EXECUTIVE VIEWPOINT (Capability Decomposition View)                            │
 │    [Patient Registration] ──> [Insurance Adjudication] ──> [Revenue Cycle Billing]│
 └────────────────────────────────────────┬─────────────────────────────────────────┘
                                          │ Traces Down
                                          ▼
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │ 2. OPERATIONAL VIEWPOINT (Activity Flow View - BPMN 2.0)                        │
 │    [Verify Eligibility] ──> (Parallel Gateway) ──> [Calculate Co-Pay & Dispatch] │
 └────────────────────────────────────────┬─────────────────────────────────────────┘
                                          │ Traces Down
                                          ▼
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │ 3. TECHNICAL VIEWPOINT (Data & Security View - ERD & NFRs)                       │
 │    Entities: Patient, Claim, Invoice | NFR: HIPAA AES-256 Data Encryption at Rest   │
 └──────────────────────────────────────────────────────────────────────────────────┘

1. Executive Viewpoint (Capability View): High-level capability breakdown framing Patient Onboarding, Insurance Adjudication, and Revenue Cycle Management.
2. Operational Viewpoint (Activity View): BPMN 2.0 process flow illustrating workflow steps, user roles, parallel verification gates, and exception paths.
3. Technical Architectural Viewpoint (Data & NFR View): ERD defining entities (Patient, Insurance Policy, Medical Claim, Invoice) and security constraints (HIPAA Compliance, AES-256 Encryption).

Outcome: By linking these views under a single architecture, a proposed change in federal HIPAA data privacy regulations (Technical View) immediately flags affected operational workflows (Operational View) and core corporate capability costs (Executive View).

---

CBAP Exam Strategy & Distractor Analysis

• View vs. Viewpoint Distractor: Exam questions frequently swap the definitions of view and viewpoint. Remember: The viewpoint is the framing criteria and pattern rules (the camera lens), while the view is the specific resulting model artifact (the photograph).
• Requirements Architecture is Not Technical Software Architecture: Do not confuse Requirements Architecture (Task 23) with software engineering architecture. Requirements architecture structures business analysis information and requirements, not server hardware node configurations.
• Impact Analysis Linkage: Whenever an exam scenario asks how a BA evaluates the domino effect of a proposed scope change across 500 requirements, the correct answer involves leveraging the Requirements Architecture.