Key takeaways
- Requirements Management is a central, continuous process, not a sequential phase.
- Its purpose: understand and manage requirements, with end-to-end traceability.
- Phases address and prioritize requirements; the process manages them and makes them available.
- The Requirements Impact Assessment shows which phases to revisit after a change.
- The Architecture Requirements Repository holds authorized requirements.
Purpose: understanding and managing requirements
The practitioners’ guide sums up the purpose of Requirements Management in two verbs: understand and manage requirements. TOGAF puts it at the center of architecture development, because every phase produces, consumes, or changes requirements.
It works well only when every detailed requirement can be traced back to the organization’s vision, mission, business model, and strategies. The process is dynamic: requirements change along the way and must be reassessed without waiting for the end of the cycle.
A frequently misunderstood point: the process does not itself address or prioritize requirements. That work happens in the relevant phase; Requirements Management takes care of identification, storage, tracking, and distribution.
Three objectives
The process objectives are framed from the viewpoint of the service provided to the ADM phases.
- Keep requirements management running over time for all relevant phases
- Manage the architecture requirements identified during any execution of the cycle or of a phase
- Make relevant requirements available to each phase when it runs
Steps: a dialogue between the process and the phases
FURTHER STUDY · APPLICATION DETAILS
The steps alternate between what Requirements Management does and what the current phase does. The first high-level requirements appear with the Architecture Vision in Phase A; each phase then adds or changes some.
- The phase identifies and documents its requirements; the process baselines them (priorities confirmed, stakeholder buy-in, recording)
- The process monitors the baseline and spots requirements that are changed, added, or removed
- The impact of changes on the current and past phases is assessed
- Requirements arising from Phase H are taken into account and the repository is updated
- The phase applies the change and, if needed, revises the gap analysis of earlier phases
Outputs and repository
Authorized requirements are gathered in the Architecture Requirements Repository, a component of the Architecture Repository. Techniques such as Business Scenarios help discover them, but the standard mandates no particular tool.
- Changed requirements
- Requirements Impact Assessment: phases to revisit and, in its final version, full implications (costs, timescales, business metrics)
- Updated Architecture Requirements Specification, a quantitative and measurable view of the solution
TERMS TO KNOW
The terms, in context.
- Architecture Requirements Repository
- The part of the Architecture Repository that gives a view of all authorized architecture requirements.
- Requirements Impact Assessment
- An assessment of how a requirement change affects the cycle, naming the phases to revisit.
- Architecture Requirements Specification
- The set of measurable requirements that implementation must meet; complements the qualitative view of the Architecture Definition Document.
- Traceability
- An explicit link between the organization’s vision and strategies and each detailed requirement.
- Requirements baseline
- A set of prioritized, stakeholder-accepted, recorded requirements used as the reference for tracking change.