Section 1: Requirements Management Overview
Requirements Management is the only ADM element that is not a sequential phase. While all other phases — Preliminary through Phase H — form a clockwise cycle, Requirements Management sits permanently at the centre of the ADM wheel, operating continuously in parallel with every phase from start to finish.
The process of managing architecture requirements throughout the ADM lifecycle. Its purpose is to ensure requirements are identified, stored, fed into the relevant ADM phases, and kept consistent as the architecture evolves. It does not gather requirements — that work is done within each phase.
All ADM phases interact bidirectionally with Requirements Management: each phase pulls prioritised requirements as inputs and pushes newly elicited or changed requirements back for storage and impact assessment. The relationship is depicted in the TOGAF Standard as a hub-and-spoke model with Requirements Management at the hub.
Requirements gathering (eliciting and analysing requirements from stakeholders) happens within each ADM phase. Requirements Management stores those requirements, tracks changes, and routes them as inputs to the correct phases. Think of it as a registry and router, not a collector. It does not control other phases and does not manage their sequence.
Section 2: What Requirements Management Does
Requirements Management performs four core functions throughout the ADM lifecycle:
- Stores requirements: Maintains a persistent Requirements Repository within the Architecture Repository, ensuring requirements are never lost between phases.
- Manages changes: When requirements are modified, added, or withdrawn, Requirements Management records the change, assesses its impact, and notifies affected phases.
- Maintains traceability: Links each requirement to the architecture artefacts, work packages, and implementation projects that address it — forming the traceability matrix.
- Ensures requirements drive decisions: Feeds prioritised requirements as formal inputs at the start of each phase so that architecture decisions are grounded in stakeholder need.
Requirements Management's two named outputs in TOGAF are: (1) Requirements Impact Assessments and (2) an updated Requirements Repository. Part 1 frequently asks for these by name. Requirements Management does NOT produce domain architectures, roadmaps, or contracts.
Section 3: Types of Requirements in TOGAF
Requirements in TOGAF are domain-specific and are gathered within each domain phase. They must be distinguished from constraints (non-negotiable limits such as budget or legal mandates that must be respected without trade-off) and principles (standing enterprise rules requiring Architecture Board dispensation to override).
| Requirement Type | Phase | Examples | Flexibility |
|---|---|---|---|
| Business requirements | B | Capability goals, process targets, regulatory obligations | Can be prioritised or deferred |
| Data requirements | C | Data quality standards, retention policies, master data definitions | Can be prioritised or deferred |
| Application requirements | C | Integration interfaces, functional capabilities, SLAs | Can be prioritised or deferred |
| Technology requirements | D | Platform standards, security protocols, infrastructure performance | Can be prioritised or deferred |
| Constraints | All phases | Budget ceiling, legislative deadline, vendor lock-in prohibition | Non-negotiable — must be respected |
| Principles | Preliminary | "Data is an Asset", "Technology Independence" | Deviation requires Board dispensation |
Section 4: Requirements Repository
The Requirements Repository is a component of the Architecture Repository. It is not a simple list — it is a structured store with four key properties:
- Traceability matrix: Links each requirement to the artefact(s) that address it, the work package that implements it, and the project that delivers it. This chain — requirement → artefact → work package → implementation — enables end-to-end impact analysis.
- Volatility analysis: Classifies requirements by how likely they are to change. High-volatility requirements are monitored actively and may influence phasing decisions.
- Priority levels: Requirements are prioritised (e.g., Must Have / Should Have / Could Have) so that phases can make trade-off decisions when capacity is limited.
- Lifecycle status: Each requirement is tracked through states — proposed, approved, allocated, implemented, retired — so that no requirement is silently dropped.
Section 5: Impact Assessment
When a new requirement emerges mid-ADM — from a regulatory change, a new executive sponsor, or an emerging technology constraint — Requirements Management triggers an Impact Assessment:
- Record the requirement in the Requirements Repository with source, date, and priority.
- Assess impact on architecture artefacts: which Baseline or Target documents are affected?
- Assess impact on the Architecture Roadmap: does the requirement shift work package priorities or scope?
- Feed updated requirements into the current phase as revised inputs and notify affected stakeholders and the Architecture Board.
- Determine whether a new ADM cycle is needed if the impact invalidates the existing Architecture Vision.
"A new regulatory requirement emerges while the team is in Phase D — what should the architect do?" Correct answer: (1) log in Repository, (2) perform impact assessment, (3) feed into Phase D as revised input, (4) notify stakeholders. Do NOT simply continue nor restart from Phase A unless the impact assessment concludes the Architecture Vision is invalidated.
Section 6: Requirements in Each ADM Phase
| Phase | Requirement Activity | Outputs to Repository |
|---|---|---|
| P Preliminary | Establish the requirements management process; identify overarching business drivers | Architecture principles (governing requirements); process definition |
| A Phase A | Gather high-level stakeholder requirements; define business goals and constraints | Initial requirements set; Architecture Vision requirements |
| B Phase B | Elicit detailed business requirements; validate against architecture principles | Prioritised business requirements added to repository |
| C Phase C | Elicit data and application requirements; trace to business requirements | Data and application requirements; traceability links updated |
| D Phase D | Elicit technology requirements; confirm all higher-level requirements are traceable to technology components | Technology requirements; full traceability matrix completed |
| E Phase E | Confirm all requirements are addressed by work packages; identify unmet requirements | Unmet requirements flagged; work package-to-requirement mapping |
| F Phase F | Prioritise requirements for migration planning; defer low-priority items | Prioritised requirement list per transition architecture |
| G Phase G | Verify implementation projects satisfy requirements; handle change requests that add new requirements | Requirements compliance status; new requirements from change requests |
| H Phase H | Monitor for new or changed requirements; trigger impact assessment as needed | Updated requirements; decision to trigger a new ADM cycle |
Section 7: Gap Analysis and Requirements
Gap analysis (performed at the end of Phases B, C, and D) interacts directly with Requirements Management. Two types of gaps must be distinguished:
- Architecture gaps: Components present in the baseline but not the target (to be decommissioned), or in the target but not the baseline (to be built). These are architectural in nature.
- Requirements gaps: Requirements that cannot be satisfied by any component in the Target Architecture. These are fed back to Requirements Management, logged as unmet, and must never be silently dropped. Resolution options: deferred to a future ADM cycle, accepted as out-of-scope, or escalated to the Architecture Board.
Section 8: Part 2 Exam — Requirements Scenario Questions
Requirements Management is a high-value Part 2 topic because it tests judgment, not just recall. Common scenario patterns:
| Scenario Pattern | Best-Fit Response |
|---|---|
| "A new requirement emerges in Phase D" | Log it, perform impact assessment, feed into Phase D as updated input, notify stakeholders |
| "Two requirements conflict with each other" | Escalate to Architecture Board; prioritise using agreed principles and business drivers from the Architecture Vision |
| "A requirement was missed during Phase B" | Add to repository, assess impact on Phases C and D artefacts, update traceability matrix |
| "A previously approved requirement is withdrawn" | Mark as retired in repository, assess impact on work packages, notify affected projects |
| "The new requirement invalidates the Architecture Vision" | Trigger a new ADM cycle from Phase A with updated scope |
Revision Summary — Chapter 11
- Requirements Management sits at the centre of the ADM wheel — continuous, not sequential, interacting bidirectionally with every phase.
- It stores, routes, and tracks requirements; it does NOT gather them. Gathering happens within each domain phase (B, C, D).
- Requirements map to BDAT domains: Business (Phase B), Data and Application (Phase C), Technology (Phase D). Constraints are non-negotiable; principles require dispensation to override.
- The Requirements Repository holds traceability matrices, volatility classifications, priority levels, and lifecycle status. Its two formal outputs are: Requirements Impact Assessments and an updated Requirements Repository.
- New mid-ADM requirements: log, assess impact, feed into current phase, notify stakeholders, decide if a new ADM cycle is needed.
- Requirements gaps (unmet after gap analysis) must be formally resolved — deferred, accepted out-of-scope, or escalated to the Architecture Board. Never silently dropped.
Practice Questions
Five exam-style questions covering this chapter. Click a question to reveal the answer and explanation.
A. It is the first sequential phase, executed before Phase A
B. It sits at the centre of the ADM cycle and operates continuously throughout all phases
C. It is performed only at the end of each domain phase to validate outputs
D. It is a sub-phase of Phase A that populates the Architecture Vision
Explanation: B is correct. Requirements Management is explicitly positioned at the centre of the ADM wheel, reflecting its continuous, cross-phase nature. Options A, C, and D all incorrectly confine it to a specific sequential position or a single phase. It is active from the Preliminary Phase through Phase H and interacts bidirectionally with every other phase.
A. Record the requirement in the Requirements Repository and perform an impact assessment
B. Immediately restart the ADM from Phase A with the regulation as a constraint
C. Defer the requirement to Phase H, which handles changes to the architecture
D. Incorporate the regulation directly into the Technology Architecture without formal logging
Explanation: A is correct. The first action is always to formally record the requirement and assess its impact. Restarting from Phase A (B) is a possible outcome of the impact assessment — not the immediate response. Deferring to Phase H (C) allows Phase D work to proceed on a potentially flawed basis. Option D skips the formal governance process entirely.
A. A requirement is legally binding; a constraint is aspirational
B. A requirement is defined by the architect; a constraint is defined by stakeholders
C. A requirement can be prioritised or traded off; a constraint is non-negotiable and must be respected
D. A requirement applies to all ADM phases; a constraint applies only to Phase B
Explanation: C is correct. A requirement is a condition the architecture should satisfy and can be subject to prioritisation, deferral, or trade-off. A constraint is a non-negotiable boundary — such as a budget ceiling, legal mandate, or fixed deadline — that must be complied with regardless of trade-off considerations. Options A, B, and D misstate both definitions.
A. Remove it from the Requirements Repository as it is unachievable
B. Convert it into an architecture principle for future reference
C. Hold it until Phase G when implementation teams can address it
D. Log it as an unmet requirement and formally resolve it — deferred, escalated, or accepted out-of-scope
Explanation: D is correct. Unmet requirements must never be silently dropped. TOGAF requires a formal resolution: deferral to a future cycle, escalation to the Architecture Board, or deliberate acceptance as out-of-scope. Removing it (A) is explicitly prohibited. Converting it to a principle (B) misapplies that construct. Deferring to Phase G (C) passes an unresolved design problem to implementation governance.
A. The architect selects the technically superior requirement and rejects the other
B. Escalate to the Architecture Board; prioritise using architecture principles and business drivers agreed in the Architecture Vision
C. Accept both requirements and design an architecture satisfying both simultaneously, regardless of cost
D. Defer both requirements to Phase H for resolution by the change management process
Explanation: B is correct. TOGAF does not grant the architect unilateral authority to reject stakeholder requirements (A). Conflicts are escalated to the Architecture Board, which resolves them by reference to architecture principles and business drivers already agreed in the Architecture Vision. Option C ignores the conflict. Option D carries the conflict through all subsequent phases — conflicts must be resolved as early as possible.