In the TOGAF Architecture Development Method (ADM), Requirements Management is not a sequential phase with a start and end date. Instead, it is a central, continuous, and dynamic process that runs alongside and intersects with every phase of the ADM cycle. Its primary purpose is to ensure that architecture requirements are properly identified, securely stored, and systematically delivered to the appropriate ADM phases so they can be addressed, prioritized, and acted upon.
Think of Requirements Management as the “central nervous system” of the ADM. It doesn’t build the architecture itself, but it ensures that every decision, design choice, and implementation step is directly tied to what the business and stakeholders actually need.
The Requirements Management process is designed to achieve three fundamental goals:
Sustain Continuous Operation: Ensure the process remains active and operational across all relevant ADM phases.
Capture & Manage Identified Requirements: Handle any architecture requirements that emerge during any execution of the ADM cycle or within a specific phase.
Ensure Availability: Guarantee that the correct requirements are readily accessible and usable by each ADM phase as it executes its work.
If you visualize the TOGAF ADM as a circular diagram with phases arranged around it (Preliminary, A through H), Requirements Management is placed dead center. This positioning is intentional:
It acts as the hub that feeds into and receives inputs from every phase.
It continuously validates that the architecture remains aligned with evolving business needs, stakeholder concerns, and market realities.
Because architecture deals with uncertainty and long time horizons, requirements will inevitably change. The central process ensures these changes are captured, tracked, and routed correctly without derailing the overall project.
| Concept | Explanation |
|---|---|
| Dynamic & Continuous | Requirements are never static. They evolve as stakeholders gain clarity, technology changes, or business strategies shift. The process must adapt in real-time. |
| Central Driver | The ADM cycle is continuously driven by Requirements Management. Without it, phases would work on outdated or misaligned assumptions. |
| Bridge Between Aspiration & Reality | Architecture exists to turn high-level stakeholder visions into practical, deliverable solutions. Requirements Management ensures this bridge stays intact. |
| Repository-Centric | TOGAF strongly recommends using an Architecture Requirements Repository to record, version, and manage all architecture-related requirements systematically. |
Although TOGAF does not mandate a rigid step-by-step workflow, the practical flow of Requirements Management follows this pattern:
Identify: Capture new or changing requirements from stakeholders, business scenarios, compliance mandates, or lessons learned during phase execution.
Store: Log the requirement in the Architecture Requirements Repository with metadata (source, priority context, related architecture domain, version, status).
Route/Feed In: Distribute the requirement to the relevant ADM phase(s). For example, a data privacy requirement goes to Phase C (Information Systems Architecture) and Phase D (Technology Architecture).
Phase Processing: The receiving ADM phase evaluates, addresses, prioritizes, or disposes of the requirement as part of its specific deliverables.
Feed Back/Update: Once the phase processes the requirement, the outcome (approved, deferred, modified, or implemented) is fed back into the Requirements Management process and the repository is updated.
Validate Continuously: At every iteration, check that current requirements still align with the Architecture Vision and business objectives. Adjust scope, detail, or timelines if needed.
A common beginner misconception is that Requirements Management decides what gets built. It does not. TOGAF explicitly clarifies this boundary:
| Requirements Management Process | Individual ADM Phases |
|---|---|
| ✅ Identifies & captures requirements | ✅ Evaluates & prioritizes requirements |
| ✅ Stores & versions requirements | ✅ Addresses or disposes of requirements |
| ✅ Feeds requirements to the correct phase | ✅ Translates requirements into architectural artifacts & deliverables |
| ✅ Tracks requirement lifecycle & status | ✅ Validates requirements against feasibility & constraints |
Analogy: Requirements Management is like a library’s catalog system. It tracks what books (requirements) exist, where they belong, and who checked them out. But the librarians (ADM phases) are the ones who actually read, recommend, and use the books to solve problems.
Scenario: A mid-sized retail company wants to launch a new omnichannel shopping platform.
| Step | What Happens |
|---|---|
| 1. Identification | During initial stakeholder interviews, a key requirement emerges: “Customers must be able to return online purchases at any physical store, with inventory and loyalty points updated in real-time.” |
| 2. Storage | The architect logs this in the Architecture Requirements Repository, tagging it under Business, Application, and Data domains. |
| 3. Routing to Phases | – Phase A (Vision): Validates the requirement aligns with the strategic goal of “seamless customer experience.” – Phase B (Business): Maps the return process and defines required business capabilities. – Phase C (Data/App): Specifies that the POS system, e-commerce platform, and inventory database must share a unified customer & transaction data model. – Phase D (Tech): Mandates real-time API integration and cloud-based message brokers. |
| 4. Phase Processing | Phase C discovers that the legacy inventory system cannot support real-time updates. The requirement is prioritized and flagged for a middleware solution in Phase E. |
| 5. Feedback Loop | The change is recorded in the repository. Requirements Management updates the status to "Addressed via Integration Layer" and notifies stakeholders. |
| 6. Continuous Validation | During Phase G (Implementation Governance), a tester verifies the real-time sync. Requirements Management confirms the requirement is "Implemented & Verified" and closes the loop. |
This example shows how a single requirement flows through the central process, gets handled by multiple phases, and is continuously tracked until fulfillment.
TOGAF does not enforce a specific tool, but recommends proven techniques to make Requirements Management effective:
Business Scenarios: A structured technique to discover, document, and validate business requirements. It links business processes, actors, and desired outcomes directly to architectural needs. Highly effective in Phase A and Phase B.
Architecture Requirements Repository: A dedicated system (can be part of a larger Enterprise Architecture toolset) to store, version, trace, and manage requirements.
Commercial Off-The-Shelf (COTS) Requirements Tools: Modern requirements management platforms (e.g., Jira, DOORS, Polarion, or dedicated EA tool repositories) can automate traceability, impact analysis, and stakeholder sign-offs.
Traceability Matrices: Simple spreadsheets or tool-generated maps that link requirements → architectural components → implementation work packages → test cases.
Start Early, Never Stop: Begin capturing requirements in the Preliminary Phase and Phase A. Keep the process alive through Phase H and beyond.
Use a Single Source of Truth: Maintain all requirements in a centralized repository. Avoid scattered emails, sticky notes, or unversioned documents.
Keep Requirements SMART: Ensure they are Specific, Measurable, Actionable, Realistic, and Time-bound so phases can actually implement them.
Separate Concerns from Requirements: A “concern” is an area of interest (e.g., security, performance). Requirements are the decomposed, actionable statements derived from those concerns.
Embrace Iteration: Revisit requirements at the end of each phase. Validate scope, detail, and priorities before moving forward.
Link to Governance: Use the Architecture Board and compliance reviews to ensure requirements aren’t quietly dropped or bypassed during implementation.
Requirements Management is the central, continuous engine of the TOGAF ADM.
Its job is to identify, store, and route requirements, not to prioritize or implement them (that’s the job of the individual ADM phases).
It bridges the gap between stakeholder aspirations and practical, deliverable architectures.
A well-maintained Architecture Requirements Repository is essential for traceability and consistency.
Techniques like Business Scenarios and modern requirements management tools greatly enhance effectiveness.
Success depends on treating requirements as living artifacts that evolve alongside the architecture, requiring constant validation and stakeholder alignment.
By mastering Requirements Management, architects ensure that every phase of the ADM cycle delivers real business value, stays aligned with strategic goals, and adapts gracefully to change.
