7.2 Requirements Management
Key Takeaways
- Requirements Management operates the process of managing architecture requirements throughout the ADM and is a continuous phase at the center of the cycle.
- Requirements Management objectives are to sustain the process for all relevant phases, manage requirements identified during any ADM cycle or phase, and make relevant requirements available to each phase.
- The Requirements Management process does not dispose of, address, or prioritize requirements; that is done within the relevant ADM phase.
- The Requirements Impact Assessment identifies changes that should be made to architecture requirements and specifications and the implications of those changes.
- The Architecture Requirements Specification sets out quantitative statements of what an implementation project must do to comply with the architecture.
7.2 Requirements Management
Requirements Management sits at the center of the ADM cycle. The Foundation syllabus asks you to describe the objectives of the Requirements Management process and describe its purpose. The TOGAF Standard says Requirements Management "operates the process of managing architecture requirements throughout the ADM" and is a continuous phase that ensures changes to requirements are handled through appropriate governance processes and reflected in all other phases.
Purpose
The ability to deal with changes in requirements is crucial. Architecture is an activity that by its very nature deals with uncertainty and change — the "grey area" between what stakeholders aspire to and what can be specified and engineered. Requirements for architecture are seldom static; they evolve as the ADM proceeds, as new facts emerge, and as the business environment changes.
A critical point: the Requirements Management process itself does not dispose of, address, or prioritize any requirements. That is done within the relevant phase of the ADM. Requirements Management is the process for managing requirements throughout the overall ADM — identifying, storing, and making them available, and handling changes to them.
Objectives of Requirements Management
- Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
- Manage architecture requirements identified during any execution of the ADM cycle or a phase
- Ensure that relevant architecture requirements are available for use by each phase as the phase is executed
How the Process Works
TOGAF presents the Requirements Management steps alongside the ADM phase steps they interact with. In summary:
| Step | Performed by | Activity |
|---|---|---|
| 1 | ADM phase | Identify and document requirements, using business scenarios or an analogous technique |
| 2 | Requirements Management | Baseline requirements: determine priorities arising from current phase, confirm stakeholder buy-in, record priorities and place the requirements in the repository |
| 3 | Requirements Management | Monitor baseline requirements |
| 4 | ADM phase | Identify changed requirements: remove or re-assess priorities, add requirements, or modify existing requirements |
| 5 | Requirements Management | Identify changed requirements and record priorities; ensure conflicts are identified and managed; generate a Requirements Impact Statement to steer the architecture team |
| 6 | ADM phase | Assess the impact of changed requirements on the current and previous phases; decide whether to implement the change or defer it to a later cycle; issue a revised Requirements Impact Statement |
| 7 | Requirements Management | Implement requirements arising from Phase H |
| 8 | Requirements Management | Update the requirements repository with information about the changes, including stakeholder views affected |
| 9 | ADM phase | Implement the change in the current phase |
| 10 | ADM phase | Assess and revise gap analysis for past phases |
Notice the pattern: phases identify, prioritize, assess, and implement; Requirements Management baselines, monitors, records, and keeps the repository current.
Inputs and Outputs
| Inputs | Outputs |
|---|---|
| A populated Architecture Repository; Organizational Model for EA; Tailored Architecture Framework | Requirements Impact Assessment — assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes |
| Requirements-related outputs from each ADM phase | Changed requirements — reflected in the updated Architecture Requirements Specification and requirements repository |
The Requirements Impact Assessment typically contains a reference to specific requirements, stakeholder priority of the requirements to date, phases to be revisited, the phase to lead on requirements prioritization, results of phase investigations and revised priorities, recommendations on management of requirements, and a repository reference number.
Bidirectional Traceability Across the ADM
A primary objective of Requirements Management is establishing and sustaining bidirectional traceability across every deliverable produced by the ADM:
Business Goals (Phase A)
│
▼
Business Capabilities & Value Streams (Phase B)
│
▼
Data & Application Services (Phase C)
│
▼
Technology Infrastructure & Cloud Platforms (Phase D)
│
▼
Work Packages & Transition Roadmaps (Phases E & F)
│
▼
Architecture Contracts & Conformance Tests (Phase G)
│
▼
Operational Monitoring & Change Triggers (Phase H)
- Forward Traceability (Strategic Justification): Every technical component, software interface, and infrastructure node designed in Phases C and D must trace forward from a valid business capability in Phase B and a strategic business driver in Phase A. If a technical requirement cannot be traced back to an approved business objective, it represents architectural waste or unauthorized gold-plating.
- Backward Traceability (Impact Analysis): When an operational failure, security vulnerability, or vendor deprecation occurs in Phase H or Phase G, architects can trace backward from the affected component through the requirements hierarchy to immediately determine which business capabilities, value streams, and revenue channels are impacted.
Architecture Requirements vs. Solution / Implementation Requirements
A frequent point of confusion in enterprise architecture practice is the boundary between Architecture Requirements and Solution (Implementation) Requirements.
| Dimension | Architecture Requirements | Solution / Implementation Requirements |
|---|---|---|
| Primary Focus | "What" the enterprise must be able to do and "under what constraints" | "How" a specific software application or system will execute the functions |
| Level of Abstraction | High to intermediate; enterprise-wide, capability-level, cross-cutting | Detailed; component-specific, screen-level, algorithm-level |
| Typical Content | Business capabilities, enterprise principles, regulatory constraints, quality attributes (scalability, availability, latency, security) | User stories, acceptance criteria, database ER diagrams, wireframes, class definitions, API payload schemas |
| Governing Deliverable | Architecture Requirements Specification (ARS) | Product Backlog, Functional Specification Document (FSD), Jira Epics / Stories |
| Primary Owner | Enterprise Architect / Domain Architect | Product Owner, Business Analyst, Technical Lead, Agile Delivery Team |
| Lifecycle Horizon | Multi-year, enduring across multiple solution iterations and technology refreshes | Ephemeral, aligned with sprint cadences or project delivery milestones |
Rule of Thumb: An Architecture Requirement defines the enterprise guardrails, integration contracts, and non-functional quality standards. The Solution Requirement defines how an agile team builds software to operate safely within those guardrails.
Requirements, the ARS, and the ADD
- The Architecture Requirements Specification (ARS) provides a set of quantitative statements that outline what an implementation project must do to comply with the architecture. It is developed in Phases B–D and refined in Phases E and F.
- The Architecture Definition Document (ADD) describes the architecture itself across domains and states.
- The Architecture Requirements Repository in the Architecture Repository provides a view of all authorized architecture requirements agreed with the Architecture Board.
Requirements can be developed with business scenarios (Section 8.2) or other techniques, and requirements tools can help manage them.
Common Exam Pitfalls
- Saying Requirements Management prioritizes requirements. The process does not dispose of, address, or prioritize requirements; that is done in the relevant ADM phase.
- Treating Requirements Management as a phase you pass through once. It is continuous and interacts with every phase.
- Forgetting its output. The Requirements Impact Assessment is the characteristic output.
- Confusing the ARS with the ADD. The ARS states what implementations must do to comply; the ADD describes the architecture.
Which statement is an objective of the Requirements Management process?
Where are architecture requirements prioritized and addressed according to the TOGAF Standard?
What is the characteristic output of Requirements Management that assesses current architecture requirements to identify changes and their implications?
A new regulatory requirement emerges while Phase D is under way. Which response fits the TOGAF Requirements Management approach?