Recommended resources
The freely available resources this lesson will direct you to.
Welcome back. In the previous lesson, Phase A turned a request for change into a high-level Architecture Vision and an agreed scope of work. It also surfaced initial requirements—but those requirements will not stay fixed while the architecture is developed. Some will become more precise; others will conflict, prove infeasible, or arise later.
This lesson explains how Requirements Management keeps requirements visible and controlled throughout the Architecture Development Method (ADM). You will follow a requirement from its discovery through storage, prioritization, traceability, and change. The aim is to understand a continuing responsibility, not memorize another phase to place between A and B.
Why Requirements Management sits at the center
Consider the customer-service initiative from Phase A. A service manager wants customers to stop repeating their issue whenever a case moves between teams. That concern might first become a high-level requirement: “Receiving teams must have the information needed to continue a customer case.” Later work will reveal what information, receiving teams, and continue mean in practice.
The ADM diagram places Requirements Management in the center because requirements can enter and change during any phase. The center is not a waiting room where architects finish requirements before beginning the rest of the cycle. It represents an ongoing process that supplies relevant requirements to phase work and records what that work discovers.
Read the opening of Visual Paradigm’s A Comprehensive Beginner’s Guide to TOGAF ADM: Requirements Management. It introduces the three purposes to keep in mind: sustain the process, manage requirements as they arise, and make them available to the phases that need them.
A Comprehensive Beginner’s Guide to TOGAF ADM: Requirements Management
Read Visual Paradigm’s introduction to see why Requirements Management operates continuously rather than once at the beginning of an initiative.
In Section 1, “What is Requirements Management in TOGAF?”, read the opening explanation. Then read Section 2, “Core Objectives”, and Section 3, “Position & Role in the ADM Cycle”, from objectives through role. Focus on the movement of requirements into and out of phase work, rather than treating the central circle as a store of unchanging statements.
A useful distinction will organize the rest of the lesson: Requirements Management maintains the continuity of requirements; the relevant ADM phases do the architecture work needed to address them. Managing a requirement does not, by itself, decide whether to redesign a process, change an application, or defer an implementation. It ensures that the people making those decisions have the current requirement and that their decisions are recorded.
Identify requirements and keep a dependable record
Requirements can come from stakeholder concerns, business goals, policies, constraints, or discoveries made while examining an architecture. Phase A may identify the first high-level ones. Phase B might reveal that two teams use different definitions of a “resolved case.” Phase C might reveal a need to share case status between applications. Implementation work might expose a requirement that the earlier design did not adequately address. No single phase has a monopoly on discovering requirements.
A requirement should be clear enough to examine, while allowing detail to emerge as the work progresses. “Improve handoffs” describes an aspiration. “An authorized receiving team must be able to see the current case status and relevant history without asking the customer to repeat them” is more useful for architecture work. It describes a needed capability without prematurely selecting a product.
Once identified, a requirement needs a dependable record. A Requirements Repository can hold its wording, source, status, version, priority, related stakeholders, and decisions made about it. A simple entry for our example might include:
| Field | Example |
|---|---|
| Identifier and statement | R-12: An authorized receiving team must be able to see the current case status and relevant history. |
| Source | Concern raised by service and field teams |
| Status | Proposed; awaiting assessment |
| Scope | Customer-case handoffs in the approved initiative |
| Links | Architecture Vision, affected business process, related information-access requirement |
The fields are illustrative, not a prescribed TOGAF template. Their value is practical: six months later, someone should be able to find out why R-12 exists, which wording was agreed, what happened to it, and what it affected. Keeping earlier versions also prevents a rewritten requirement from silently erasing the reason for an earlier architecture decision.
The next reading is an older TOGAF presentation hosted by the QualiWare Center of Excellence. It is useful for understanding the mechanism, but its TOGAF 9.1 labels and section numbers should not be treated as a source of 10th Edition exam wording.
ADM Architecture Requirements Management | QualiWare Center of Excellence
Read the QualiWare Center of Excellence account for two important boundaries: Requirements Management records and circulates requirements, while ADM phases address them; and requirements within the approved work are distinguished from those outside its scope.
In “17.2 Approach”, subsection “17.2.1 General”, find the paragraph beginning “Note also that the Requirements Management process itself” and read the role boundary. Continue into “17.2.2 Requirements Development”, reading development and scope. Notice when the text calls for updating a requirement’s status and how it handles a newly discovered requirement outside the current Statement of Architecture Work.
That scope distinction matters. The Architecture Requirements Specification documents requirements for the current architecture work as they are developed and agreed. The repository provides continuing management of requirements, including information that may be relevant across ADM cycles. If a stakeholder requests a feature unrelated to the approved customer-case initiative, architects should not quietly add it to the current design. They should record it and have its scope and priority considered through the appropriate process.
TOGAF describes what effective management needs to accomplish; it does not require a particular software tool. A repository could be implemented in different ways, provided the organization can maintain reliable records and make the right requirements available.
Prioritize in the phase, preserve the decision centrally
Not every requirement can receive equal attention at the same time. Suppose service teams want immediate access to complete case history, while an information-governance stakeholder requires access to be restricted to staff with a legitimate need. Both concerns are important. Prioritizing and resolving them requires understanding the business process, information involved, risks, constraints, and stakeholder views.
Requirements Management ensures that the requirements and their priorities are recorded, kept current, and presented to the relevant work. It does not independently decide which requirement wins. Architects working in the relevant ADM phase assess the requirements with stakeholders and decision-makers. They may clarify the wording, agree a priority, identify a conflict, or determine that a requirement cannot be met as originally stated. Requirements Management then preserves that outcome for subsequent phases.
For R-12, an agreed decision might specify that receiving teams see the case history needed for their work, subject to defined access restrictions. The record should retain both the service concern and the access concern. Otherwise, a later designer could see only the latest wording and miss the reason for the restriction.
This is where traceability becomes valuable. Traceability means being able to follow a requirement’s relationships in both directions. From R-12, you can find the stakeholder concern it addresses and the architecture work that addresses it. From a proposed design choice, you can find the requirement that justifies it. In our example, the record might link the concern about repeated explanations to R-12, then link R-12 to a business handoff description, an application or data decision, and an eventual implementation check.
Those links do not mean every requirement needs an elaborate document trail. They mean an important choice should not become an unexplained choice. Traceability helps architects ask two different questions: “Have we addressed this requirement?” and “Why are we proposing this change?”
Control change without freezing the architecture
Requirements change for legitimate reasons. A stakeholder may understand a process better after seeing its current-state description. A constraint may make a proposed target impractical. A new policy may alter who can see case information. Continuous Requirements Management makes such changes assessable rather than treating the original wording as untouchable—or letting it be replaced without a record.
Read the steps and outputs in the QualiWare account for a closer look at how a change is handled. Again, use it for the underlying process, while remembering that it presents older-edition terminology.
ADM Architecture Requirements Management | QualiWare Center of Excellence
The “Steps” table separates requirements-management actions from actions performed within ADM phases. Read it to see who assesses a change, what is recorded, and why earlier work might need revisiting.
In “17.4 Steps”, read the steps table, paying particular attention to the rows on changed priorities, impact on current and previous phases, and repository updates. Then read “17.5 Outputs”, especially the impact discussion. Notice how the impact information identifies work that may have to be reconsidered; it is not merely a note that a request arrived.
Imagine that, during Phase C, a new policy requires some case notes to be hidden from particular receiving teams. A controlled response would establish what changed and who requested it, then assess its implications. Does R-12 need revised wording? Does the Phase B handoff process assume those teams can see all notes? Does the proposed data or application architecture need another access rule? The relevant architects and stakeholders assess those questions, including any conflict with the original service goal.
An impact assessment gives decision-makers a basis for choosing how to handle the change. Depending on its significance and scope, they might accept it in the current work, defer it to a later ADM cycle, or decline a proposed formulation while retaining the underlying concern for further resolution. The decision, rationale, affected requirements, stakeholder views, and updated status belong in the requirements record. If a change affects work completed in an earlier phase, that work may need to be revisited; moving forward in the ADM does not make earlier assumptions immune to correction.
Controlled change is not the same as preventing change. It means that a changed requirement is visible, assessed by the people responsible for the affected architecture work, and reflected in the records used by subsequent phases.
Follow one requirement across the ADM
The lifecycle of R-12 brings the roles together without requiring a detailed tour of every phase:
- Phase A identifies the need. Stakeholders describe repeated explanations during handoffs; the Architecture Vision captures the high-level requirement.
- Requirements Management records it and makes it available. R-12 has a source, status, agreed wording as it develops, and links to related concerns.
- Relevant phases examine it. Business Architecture work clarifies the handoff; Data and Application Architecture work considers what information authorized teams need and how it can be made available. Each phase updates the status of requirements it has considered.
- A change is assessed rather than silently applied. The new access policy prompts the affected architects and stakeholders to reconsider R-12 and any earlier decisions it touches. Requirements Management records their decisions and revised priorities.
- Later work can verify the result. During implementation governance, the requirement and its links help assess whether the implemented change conforms to the agreed architecture. Any newly discovered requirement or substantial change remains subject to management.
The sequence is illustrative: requirements may first emerge later, affect several domains at once, or carry into another ADM cycle. The constant is the management process that keeps their history, availability, and decisions connected.
Key takeaways
Requirements Management is continuous, not a one-time requirements phase. It captures requirements wherever they emerge, maintains them in a dependable record, makes relevant requirements available to ADM phases, and tracks their status and relationships. Prioritization and decisions about how to address a requirement happen in the relevant phase with the appropriate stakeholders, while Requirements Management preserves and communicates those decisions. When requirements change, impact is assessed and the resulting decision is recorded rather than silently changing the architecture.
Next, you will examine iteration in the ADM. The ability to revisit work after a changed requirement is one reason an ADM engagement need not be a single pass through its phases.