6.3 Requirements Management: Central Flow, Impact Analysis & Traceability

6.3 Requirements Management: Central Flow, Impact Analysis & Traceability

In the visual representation of the TOGAF Architecture Development Method (ADM) cycle, Requirements Management occupies the central hub around which all phases (Preliminary through Phase H) revolve. This visual positioning is intentional: Requirements Management is not a static phase that occurs at a single point in time. Rather, it is a dynamic, continuous process that operates in parallel with every phase of the ADM.

Every phase of the ADM both consumes existing requirements and generates new or refined architectural requirements. Business needs evolve, technical constraints emerge during Phase G implementation, and market shifts occur during Phase H operations. The Requirements Management process provides the disciplined framework required to capture, analyze, store, validate, prioritize, and track these requirements across the entire architecture lifecycle.

---

Distinction Between Requirement Categories

To manage requirements effectively, TOGAF distinguishes between different levels of abstraction:

• Business Requirements: High-level goals, business drivers, strategies, and operational needs defined by enterprise stakeholders (e.g., "Reduce customer onboarding time to under 5 minutes").
• Architecture Requirements: Technical and structural specifications derived by enterprise architects to satisfy business goals (e.g., "Identity service must support OAuth 2.0 / OIDC with automated sub-second token validation").
• Solution / System Requirements: Detailed functional and non-functional specifications consumed by software engineering and infrastructure teams during solution delivery (e.g., "Redis cluster configured with multi-region replication").

Requirements Management specifically focuses on maintaining line-of-sight between Business Requirements and Architecture Requirements.

---

The 5 Core Steps of the Requirements Management Process

TOGAF defines a structured 5-step process for managing requirements throughout the ADM:

          +-------------------------------------------------------+
          | 1. IDENTIFY REQUIREMENTS                              |
          |    - Elicit from stakeholders & ADM phase outputs     |
          +-------------------------------------------------------+
                                      |
                                      v
          +-------------------------------------------------------+
          | 2. STORE REQUIREMENTS                                 |
          |    - Catalog in central Requirements Repository       |
          +-------------------------------------------------------+
                                      |
                                      v
          +-------------------------------------------------------+
          | 3. IMPLEMENT REQUIREMENTS                             |
          |    - Feed into current ADM phase architecture design  |
          +-------------------------------------------------------+
                                      |
                                      v
          +-------------------------------------------------------+
          | 4. MONITOR REQUIREMENTS                               |
          |    - Track fulfillment during Phase G & Operations    |
          +-------------------------------------------------------+
                                      |
                                      v
          +-------------------------------------------------------+
          | 5. IDENTIFY CHANGED REQUIREMENTS                      |
          |    - Assess impact & trigger phase/ADM updates        |
          +-------------------------------------------------------+

Detailed Step Walkthrough

1. Identify Requirements: Capture requirements during Phase A (Vision), Phase B (Business), Phase C (Data/App), Phase D (Tech), and ongoing Phase G/H activities.
2. Store Requirements: Record validated requirements in the central Requirements Repository with mandatory metadata attributes (source, priority, rationale, owner, architectural domain).
3. Implement Requirements: Supply stored requirements to active ADM phases for incorporation into baseline and target architecture models, candidate solutions, and Architecture Contracts.
4. Monitor Requirements: Continuously track requirement status during solution implementation (Phase G) and operational governance (Phase H) to verify proper delivery.
5. Identify Changed Requirements: Detect changes in business environment, regulatory rules, or technical constraints. Perform impact analysis and determine whether to update the current phase or submit a Change Request in Phase H.

---

The Requirements Repository

The Requirements Repository is the authoritative store within the TOGAF Architecture Repository dedicated to cataloging all enterprise architectural requirements. A well-structured repository maintains key metadata attributes for every requirement:

---

Requirements Impact Analysis

When new requirements emerge or existing requirements change mid-ADM cycle, architects must execute a Requirements Impact Analysis. The purpose of impact analysis is to evaluate how a requirement change ripples across earlier ADM decisions, target blueprints, and active projects.

Key questions answered during Impact Analysis:

• Does this requirement change alter the agreed Architecture Vision (Phase A)?
• Which target domain models (Phases B, C, D) are invalidated or modified?
• Does the change disrupt the current Architecture Roadmap or Transition Architectures (Phases E, F)?
• Does the change break active Architecture Contracts in Phase G?
• Is a new ADM cycle required, or can the change be absorbed into the active phase?

---

Requirements Traceability & The Traceability Matrix

Traceability is the capability to trace a requirement bidirectionally—forward from business goal to technical implementation, and backward from technical asset to business justification. Traceability ensures that no technical component is built without a business rationale, and no business requirement is left unfulfilled.

The Requirements Traceability Matrix

A Requirements Traceability Matrix maps line-of-sight linkages across architectural abstractions:

Business Goal ---> Business Capability ---> Arch Requirement ---> Architecture Building Block (ABB) ---> Solution Building Block (SBB)

Through rigorous traceability, Enterprise Architecture guarantees transparency, simplifies audit reviews, and streamlines impact assessment when change occurs.