Overview
Requirements Management sits at the centre of the ADM cycle diagram because it serves every phase. It does not itself discover or document requirements; that happens in the phases, often using business scenarios and stakeholder work. Its job is to manage those requirements once identified: baseline and prioritize them, store them, monitor them, handle changes and assess impact on the current and earlier phases.
The syllabus has three Understanding-level outcomes. You need to know the inputs that feed Requirements Management, how its steps pair with the steps carried out in the ADM phases, and the purpose of its outputs. The key outputs are the Requirements Impact Assessment, which records the effect of a new or changed requirement and recommends a response, and updates to the Architecture Requirements Specification held in the requirements repository. The process is dynamic: requirements change throughout a cycle, and the architecture must remain consistent with them.
How it's tested
Expect a requirement to change part-way through a scenario. The best answer records and prioritizes it, assesses its impact on the current and earlier phases with a Requirements Impact Assessment, involves stakeholders and governance, and only then changes the architecture or schedules the change.
-
Mid-cycle change
A new requirement appears in a later phase. Strong options assess impact on completed phases and decide whether to implement now, defer or revisit earlier work.
-
Where it belongs
Options confuse discovering requirements in the phases with managing them centrally. The best answer keeps each activity in its proper place.
-
Priority conflict
Competing requirements cannot all be met. Higher-scoring options reprioritize with stakeholders and record the outcome rather than silently dropping one.
During Phase D at a pharmaceutical firm, quality assurance adds a requirement for validated audit trails on all lab systems. Adding it straight into the technology design misses its effect on Phases B and C. The best option records the changed requirement, prioritizes it with stakeholders, produces a Requirements Impact Assessment covering earlier phases, updates the Architecture Requirements Specification and revisits gap analysis where needed.
Learning outcomes 3
Official learning outcomes from the The Open Group outline, in outline order.
7.1 Understand the inputs that feed Requirements ManagementBloom level 2. Where managed requirements come from.
- What it means
- Inputs include the requirements captured during each ADM phase, the populated Architecture Repository, the organizational model for EA, the tailored framework, the Statement of Architecture Work, the Architecture Vision and an existing Architecture Requirements Specification and Requirements Impact Assessments.
- What to understand
- Requirements originate in the phases, from stakeholders, business scenarios, gap analysis, compliance reviews and Phase H change requests. Requirements Management receives them and governs their life. The quality of these inputs, such as clear priorities and traceability to stakeholders, affects how well changes can be assessed later.
- How it shows up
- Questions may test that requirements are identified in phases and then passed to Requirements Management, not generated by it.
- Common confusion
- Believing Requirements Management is where requirements are first discovered.
7.2 Understand how Requirements Management steps map to ADM phase stepsBloom level 2. The paired steps between phases and the central process.
- What it means
- The TOGAF Standard shows two columns of steps. When a phase identifies or documents requirements, Requirements Management baselines them, sets priorities, confirms stakeholder buy-in and records them. Requirements Management then monitors the baseline. When a phase identifies a changed requirement, Requirements Management records it, reprioritizes and assesses impact.
- What to understand
- After impact assessment, the change may be implemented in the current phase, or earlier phases may need revision; Requirements Management updates the repository and may trigger assessment and revision of gap analysis for past phases. Requirements arising from Phase H are also implemented through this process.
- How it shows up
- Scenarios ask what to do with a changed requirement; the answer follows the record, reprioritize, assess impact, decide sequence.
- Common confusion
- Thinking a changed requirement only affects the current phase.
7.3 Understand the purpose of the Requirements Management outputsBloom level 2. Requirements Impact Assessment and updated requirements.
- What it means
- The main outputs are the Requirements Impact Assessment and an updated Architecture Requirements Specification. The assessment identifies which phases need revisiting, the impact of the change, and recommendations; the specification and repository record the current requirement set.
- What to understand
- The Requirements Impact Assessment is iterated as changes are analysed and decisions are made. It supports governance and stakeholder decisions by making consequences visible. The updated specification becomes the reference against which implementations are later checked for compliance.
- How it shows up
- When asked what documents the effect of a changed requirement, the answer is the Requirements Impact Assessment.
- Common confusion
- Confusing the Requirements Impact Assessment with a Compliance Assessment.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Requirements Management is central
A continuous process serving every ADM phase.
- Remember
- It manages requirements; phases identify them.
- Tested as
- Where an activity belongs.
- Trap
- Treating it as a separate phase run once.
-
Baseline requirements
Prioritized, agreed set of requirements recorded in the repository.
- Remember
- Stakeholder buy-in is confirmed.
- Tested as
- Starting point for change control.
- Trap
- Skipping prioritization.
-
Changed requirement
A new, modified or removed requirement arising during the cycle.
- Remember
- Recorded, reprioritized and assessed for impact.
- Tested as
- Mid-cycle scenarios.
- Trap
- Adding it directly to the design.
-
Requirements Impact Assessment
Assesses effect of changed requirements on current and earlier phases, with recommendations.
- Remember
- Iterated as analysis proceeds.
- Tested as
- Output questions.
- Trap
- Confusing it with a Compliance Assessment.
-
Architecture Requirements Specification
Holds the agreed, measurable requirements for the architecture.
- Remember
- Updated through Requirements Management.
- Tested as
- Reference for compliance in Phase G.
- Trap
- Thinking it is fixed after Phase B.
-
Requirements repository
Part of the Architecture Repository where requirements are stored.
- Remember
- Supports traceability.
- Tested as
- Recording options.
- Trap
- Keeping requirements in project files only.
-
Revisiting gap analysis
Re-assessing gaps in earlier phases after a requirement changes.
- Remember
- Part of implementing a changed requirement.
- Tested as
- Late-change scenarios.
- Trap
- Updating only the current phase.
-
Business scenarios for requirements
Technique to discover and document business requirements.
- Remember
- Used in phases, not inside Requirements Management itself.
- Tested as
- Distinguishing discovery from management.
- Trap
- Placing discovery in Requirements Management.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Requirements Impact Assessment vs. Compliance Assessment
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Requirements Impact Assessment | Analysis of how a changed requirement affects the architecture and phases | About requirements change | Using it to judge implementation conformance |
| Compliance Assessment | Result of reviewing an implementation against the architecture | About implementation conformance | Using it to analyse new requirements |
ADM phase step vs. Requirements Management step
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Identify or document requirements (phase) | Phases capture requirements from stakeholders and analysis | Discovery happens here | Expecting the central process to discover them |
| Baseline and record (Requirements Management) | Prioritize, confirm buy-in, store in the repository | Control happens here | Skipping stakeholder confirmation |
| Identify changed requirement (phase) | A phase notices a new or changed need | Trigger for change control | Implementing immediately |
| Assess impact (Requirements Management) | Reprioritize and assess effect on current and earlier phases | Decides where to act | Looking only at the current phase |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Direct implementation
- What candidates pick
- Update the Phase D design immediately to meet the new requirement.
- Why it looks right
- It is quick and responsive.
- Why it's wrong
- Changed requirements must be recorded, prioritized and assessed for impact on earlier phases first.
Clue to watch for A requirement appears late in the cycle.
-
Ignore until next cycle
- What candidates pick
- Log the requirement for a future ADM cycle without analysis.
- Why it looks right
- It protects the current schedule.
- Why it's wrong
- Without impact assessment, a critical requirement such as a legal obligation could be wrongly deferred.
Clue to watch for The requirement is regulatory or safety related.
-
Current phase only
- What candidates pick
- Assess the requirement's effect on Phase C, where it was raised.
- Why it looks right
- That is where the team is working.
- Why it's wrong
- The impact may reach completed phases, whose gap analysis may need revision.
Clue to watch for The requirement touches business processes or data already designed.
-
Wrong assessment
- What candidates pick
- Run a compliance review to evaluate the new requirement.
- Why it looks right
- Compliance sounds relevant to rules.
- Why it's wrong
- A compliance review checks implementations; the Requirements Impact Assessment analyses changed requirements.
Clue to watch for The issue is a new need, not a deviating implementation.
-
Silent drop
- What candidates pick
- Remove the lower-priority requirement from the specification to resolve a conflict.
- Why it looks right
- It resolves the conflict quickly.
- Why it's wrong
- Reprioritization needs stakeholder agreement and should be recorded.
Clue to watch for Two requirements conflict and stakeholders differ.
Answer framework
Apply this sequence whenever a requirement changes in a scenario.
- Confirm that the requirement was identified in an ADM phase or by Phase H, and record it in the requirements repository; note its source and the stakeholder who raised it.
- Prioritize it against existing requirements with the relevant stakeholders, confirming buy-in and noting any conflict, since a later conflict is harder to resolve.
- Produce or update a Requirements Impact Assessment that covers the current phase and any earlier phases affected.
- Decide with governance whether to implement the change in the current phase, revisit earlier phases, or defer it, and record the decision.
- Update the Architecture Requirements Specification and revise gap analysis where needed so later compliance reviews use the current requirements.
Practice question
Want more like this? The TOGAF Practitioner practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin by reading the Requirements Management section of the ADM and its two-column table of phase steps and Requirements Management steps. Copy the table by hand; the pairing is the heart of outcome 7.2 and is easy to recall once written out.
Next, study the Requirements Impact Assessment and the Architecture Requirements Specification. Note who uses each, when it is updated, and how the specification later becomes the yardstick for compliance in Phase G.
Then trace a single requirement through a whole cycle. Imagine a privacy requirement first captured through a business scenario in Phase A, baselined, then changed in Phase C, and finally checked during a compliance review in Phase G. Writing this story once makes the abstract steps concrete.
Finally, practise scenarios where a requirement arrives late. Train yourself to ask two questions before reading the options: has the requirement been prioritized and recorded, and has its impact on earlier phases been assessed? Options that skip either question rarely earn 5 points. Because this area overlaps with stakeholder management and Phase H, a few hours here also strengthens your answers in those areas.
FAQ
Is a weight published for Requirements Management on OGEA-102?
No. Requirements Management is one of the eight syllabus areas behind the 8 scenarios, without a published weight, and its ideas usually appear when a requirement changes inside a scenario about another phase.
Does Requirements Management identify requirements?
No. Requirements are identified in the ADM phases. Requirements Management baselines, stores, monitors and controls changes to them.
What is a Requirements Impact Assessment?
A document that assesses the impact of a new or changed requirement on the current architecture and phases and recommends how to respond. It is updated as analysis continues.
Why is Requirements Management drawn in the centre of the ADM?
Because it serves every phase continuously; requirements can arise or change at any point in the cycle.
Can a changed requirement send work back to an earlier phase?
Yes. If the impact assessment shows earlier work no longer fits, the affected phases are revisited and their gap analysis revised.
Where are requirements stored?
In the requirements repository within the Architecture Repository, with the agreed set captured in the Architecture Requirements Specification.
Other Enterprise Architecture & IT Governance certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 7 knowledge
You have studied inputs, paired steps and outputs of Requirements Management. Test whether you can handle a late requirement without skipping impact assessment.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the TOGAF Practitioner AI tutor Get any concept explained your way