TOGAF Requirements Management: The Cross-Phase ADM Process

Look at any diagram of the TOGAF ADM and you will notice something unusual. In the centre of the wheel, surrounded by all the numbered phases arranged in a circle, sits a single process labelled Requirements Management. It is not Phase A or Phase B or any numbered phase at all. It is in the centre because it is always active regardless of which ADM phase the organisation is currently in.

Requirements Management is the most misunderstood element of the ADM. Many candidates assume it is a phase like the others, to be visited once and ticked off the list. It is not. It is a continuous, cross-cutting process that runs for the entire duration of every architecture development effort. Understanding this distinction is essential for both the certification exam and for effective real-world practice.

What Requirements Management Does

Requirements Management in TOGAF serves a single core purpose: ensuring that architecture requirements are identified, stored, managed, and fed into the appropriate phases of the ADM throughout the entire architecture lifecycle.

It handles requirements from the moment they are first identified through to the point where they are addressed by the architecture and verified during implementation. It also handles the inevitable situation where requirements change after they have already been incorporated into the architecture.

In practical terms, Requirements Management is responsible for:

Maintaining a central repository of architecture requirements
Ensuring that requirements are traceable to their source stakeholders and business drivers
Feeding relevant requirements into each ADM phase at the right time
Managing changes to requirements and assessing the impact of those changes on existing architecture work
Ensuring that delivered architectures can be verified against the requirements they were built to address

Why Requirements Management Is Placed at the Centre

The positioning of Requirements Management at the centre of the ADM wheel is deliberate and meaningful. It reflects three important truths about requirements in enterprise architecture.

Truth 1: Requirements Exist in Every Phase

Every ADM phase generates, uses, and evolves requirements:

The Preliminary Phase generates governance and principle requirements
Phase A generates the high-level vision requirements from stakeholder engagement
Phase B generates business requirements for the information systems and technology domains
Phase C generates application and data requirements for the technology domain
Phase D generates infrastructure requirements that constrain implementation choices
Phase E and F generate requirements for work sequencing and transition management
Phase G generates compliance requirements that implementations must satisfy
Phase H generates new requirements triggered by business and technology changes

A process that only captured requirements in one phased pass would miss the requirements that emerge later. Requirements Management must operate across all of them continuously.

Truth 2: Requirements Change

Enterprise architecture engagements often run for months or years. During that time, business priorities shift, regulations are updated, technology landscapes evolve, and stakeholder expectations change. Requirements that were accurate at the start of an engagement may need revision by the time Phase D is reached.

Without active Requirements Management, those changes get lost. Architecture decisions get made against outdated requirements, leading to a target architecture that does not actually reflect what the business needs when the project completes.

Truth 3: Requirements Must Be Traceable

Architecture decisions should always be explainable: why was this technology chosen? Why was this application decomposed in this particular way? The answer should always trace back to a documented requirement, which in turn traces back to a stakeholder concern and a business driver.

Requirements Management creates and maintains this traceability throughout the ADM cycle.

Requirements Management Is Not a Phase

The TOGAF Foundation exam commonly tests whether candidates understand that Requirements Management is a process, not a phase. It appears at the centre of the ADM wheel, not as one of the numbered phases. It has no defined start point or end point — it is active throughout the full lifecycle.

How Requirements Management Works in Practice

Step 1: Requirements Identification

Requirements are identified from many sources throughout the ADM:

Stakeholder interviews and workshops conducted in Phase A
Business capability assessments in Phase B
Regulatory and compliance reviews
Technical assessments of existing systems
Architecture principles that impose requirements on solutions
Gap analyses that reveal capability deficiencies

When a requirement is identified, it is captured in the Requirements Repository with key properties: the requirement statement, its source, the priority, the rationale, and any dependencies on other requirements.

Step 2: Storing Requirements

The Requirements Repository is the home for all captured requirements. It is part of the Architecture Repository and holds requirements in a structured form that allows them to be searched, filtered, and linked to the architecture components that address them.

Different categories of requirements are stored here:

Business requirements: What the business needs the architecture to enable
Architecture requirements: The formal specifications the architecture must meet, derived from business requirements and principles
Transition requirements: Requirements specific to the migration from baseline to target, rather than the target state itself

Step 3: Feeding Requirements to ADM Phases

As each ADM phase begins, Requirements Management provides that phase with the relevant requirements it needs to address. For example:

Phase B receives the business requirements that the Business Architecture must satisfy
Phase C Application Architecture receives requirements for the application landscape derived from Phase B's business services
Phase G receives the compliance requirements that implementation projects must satisfy

This feeding mechanism is what ensures that requirements do not get forgotten as work progresses through the cycle.

Step 4: Managing Changes

When a requirement changes — either because a stakeholder's need evolves or because a new constraint is identified — Requirements Management handles the change through a structured process:

The change is formally logged against the existing requirement
The impact on current architecture work is assessed: which phases, deliverables, and design decisions are affected?
The affected phases are notified and their work is updated to reflect the changed requirement
The decision and its rationale are recorded for traceability

Informal Requirements Changes Are Dangerous

When requirements change informally — through a conversation, an email, or a decision made in a project meeting without going through Requirements Management — the architecture team may never know. This leads to architecture designs that quietly diverge from what stakeholders actually need. Requirements Management exists to prevent exactly this.

Requirements vs Constraints

A distinction that often trips up candidates in the exam is the difference between requirements and constraints.

A requirement is something the architecture must achieve or provide. It describes a desired outcome. A requirement can theoretically be met in multiple ways.

A constraint is an absolute restriction that the architecture must work within. It is not a desired outcome — it is a hard boundary. Unlike requirements, constraints cannot be designed around or negotiated away.

Examples:

Requirement: The system must support 10,000 concurrent users — this is a performance requirement. The architecture team can choose from multiple technical approaches to meet it.
Constraint: All customer data must be stored within the United Kingdom — this is a regulatory constraint from UK data protection law. There is no design choice that makes this optional.

Both requirements and constraints are managed within the Requirements Repository, but constraints are flagged separately because they take precedence over design preferences and cannot be subject to trade-off analysis.

Requirements and the Architecture Requirements Specification

The formal output of Requirements Management feeding into the architecture development phases is the Architecture Requirements Specification. This document consolidates the quantified requirements the architecture must satisfy from a given set of stakeholders.

We cover the Architecture Requirements Specification in detail in the next post. As a brief summary here: it is the document that gives architecture teams a precise, measurable set of criteria to design to, review against, and verify the delivered architecture against.

Requirements Management in Agile Architecture

In organizations using agile delivery methods alongside TOGAF, Requirements Management takes on additional nuance. Requirements must be articulated at multiple levels of granularity:

Epic level: High-level business requirements that span multiple sprints or releases
Feature level: Mid-level requirements that can be delivered within a programme increment
Story level: Specific, testable requirements that individual development teams work to within a sprint

The Architecture Requirements Specification typically operates at the epic and feature level, providing the architecture constraints within which story-level decisions are made by delivery teams.

TOGAF 9.2 includes specific guidance on integrating TOGAF with agile methods, acknowledging that the traditional heavyweight requirements documentation approach does not always fit agile delivery contexts. The principle, however, remains the same: requirements must be managed, traced, and kept current regardless of the delivery method.

Common Mistakes in Requirements Management

Mistake 1: Treating requirements as fixed at Phase A

Requirements are not locked in Phase A and then static forever. They evolve throughout the ADM cycle. Requirements Management must actively monitor and update them.

Mistake 2: Not distinguishing between requirements and solutions

A requirement says what is needed. A solution says how to provide it. When stakeholders describe solutions as requirements ("we need to implement Salesforce"), this conflates the two. Good Requirements Management disentangles them, capturing the underlying need ("we need an integrated customer relationship management capability") separately from the solution preference.

Mistake 3: Failing to maintain traceability

If requirements cannot be traced from business drivers through to architecture decisions and down to implemented components, it becomes impossible to verify that the architecture actually addresses what it was built to address or to understand the impact of changing a requirement later.

Summary

Requirements Management is the process at the centre of the TOGAF ADM that:

Identifies requirements from stakeholders, gaps, and principles throughout the full ADM lifecycle
Stores requirements in a structured Requirements Repository
Feeds requirements to each ADM phase at the right time
Manages changes to requirements and assesses their impact
Maintains traceability from business drivers through requirements to architecture decisions

It operates continuously and is never "complete" within an active architecture engagement.

In the next post, we explore the formal output of Requirements Management feeding into architecture design: the Architecture Requirements Specification, which defines the precise, measurable criteria the architecture must satisfy.

This post is part of the TOGAF 9.2 Masterclass series. For broader context on the ADM structure, revisit What is TOGAF 9.2? which introduces the full ADM wheel and all its phases.