Requirements Management across the ADM

In plain terms, Requirements Management is the ongoing job of capturing what the architecture has to satisfy, keeping those statements current, and making sure every phase works to the same agreed set. The correct technical term is Requirements Management, and in the TOGAF Standard it is the one activity that is not a phase in the ring at all. It sits in the centre of the Architecture Development Method wheel, connected to every phase around it.

The reason it is drawn there is structural, not decorative. Each phase of the method produces decisions, and every one of those decisions exists to satisfy some requirement: a business need, a regulatory duty, a stakeholder concern, a constraint. If the requirements are held in one place and fed to each phase, then each phase can be checked against them, and a change to any requirement can be traced to the phases it affects. If instead each phase keeps its own private list, the programme loses the thread the moment anything changes, which is the exact position London Grid Distribution found itself in.

The strategic reading for a leader is that Requirements Management is where an architecture programme keeps its accountability. A regulator, an audit committee, or an incoming director can ask why a decision was made, and a programme with a live requirements spine can answer with the requirement that drove it. A programme without one answers with a search through old documents.

A requirement, in this context, is a stated need the architecture must satisfy, recorded clearly enough that you can later test whether it has been met. The place these are held is the Requirements Repository: the working store that keeps every requirement, its source, its status, and its relationship to the decisions that address it.

A useful requirement record carries more than a sentence. It names where the requirement came from, so its authority can be checked. It records who owns it and what its current status is: proposed, agreed, in progress, satisfied, or retired. Above all, it records which architecture decisions depend on it, so that when the requirement changes, the affected decisions can be found without a manual search. That last link, requirement to decision, is what turns a list into a repository.

For London Grid Distribution, the repository is not a document. It is the answer to the programme director's question. A well kept repository would have listed the existing interruption-reporting requirement, tagged its source as the Ofgem licence obligation, and linked it to the outage data model in Phase C, the reporting components in Phase E, and the cutover sequence in Phase F. The ripple would have been visible in one query instead of reconstructed by hand.

Not every requirement carries the same weight, and Requirements Management is where that is settled. Prioritisation ranks requirements so that a phase working under real constraints knows which needs to satisfy first and which can wait. A regulatory duty that cannot be missed sits above a convenience that would be nice to have. Recording the priority alongside the requirement means a phase does not have to re-argue it each time.

Feeding each phase is the outbound half of the hub. When a phase begins, it draws the requirements relevant to it from the repository. Phase B, the business architecture, works to the business and stakeholder requirements. Phase C, the information systems architecture, works to the data and application requirements. Phase D works to the technology requirements. In each case the phase is not inventing its scope; it is taking the agreed requirements that apply to it and producing decisions that satisfy them.

The document that carries the agreed set into and across the phases has a name. The Architecture Requirements Specification is the deliverable that states the quantitative and qualitative requirements the architecture must meet, phase by phase. It is the contract between Requirements Management and the phases: the phases build to it, and any change to it is a change every affected phase has to account for.

The inbound half of the hub is where the method earns its central diagram. When a phase changes a requirement, or when a new requirement arrives from outside, the change does not simply get edited into a document. It triggers a Requirements Impact Assessment: the structured check of which parts of the architecture the changed requirement affects, and therefore which phases have to revisit their work.

The assessment is what makes a change controlled rather than chaotic. It reads the requirement-to-decision links in the repository, identifies every affected decision, and states which phases need to reopen and in what order. Because the links are already recorded, the assessment is a traversal, not an investigation. It ends with a clear statement: these requirements have changed, these decisions are affected, these phases must be revisited, and this is the sequence.

This is why the hub figure at the end of 65.3 draws two directions on every spoke. One direction feeds the phase the requirements it must satisfy. The other carries the Requirements Impact Assessment back to the hub when a phase changes something, so the change is assessed centrally and re-fed to every phase it touches. A change never enters the cycle through a side door; it always returns to the hub first.

Return to the opening case with the discipline in place. The new Ofgem interruption reporting duty arrives in month seven. Rather than a scramble, it enters through Requirements Management as a changed requirement against the existing interruption-reporting obligation, and a Requirements Impact Assessment is raised.

The assessment reads the repository links and reports the ripple across Phases B to F in order.

• Phase B, Business Architecture. The regulatory reporting capability and the process that produces interruption reports must reflect the finer detail and shorter window. The business architecture is revisited to confirm the capability still holds.
• Phase C, Information Systems Architecture. The outage data model must capture interruption events at the new granularity. The data and application architecture reopens to extend the model and the reporting component that reads it.
• Phase D, Technology Architecture. The shorter reporting window is checked against the platform's ability to collect and process the data in time. If the current technology cannot meet the window, the technology architecture must respond.
• Phase E, Opportunities and Solutions. The work packages are re-scoped so the reporting change is delivered as an identifiable piece of work rather than smuggled into unrelated packages.
• Phase F, Migration Planning. The migration plan and cutover sequence are adjusted so the new reporting capability is live by the regulatory deadline, ahead of the milestones that depend on it.

Because every step began from recorded requirement-to-decision links, the programme director's original question, which decisions does this change touch, is answered by the assessment rather than by re-reading documents. The change is real work, but it is bounded, ordered, and traceable. That is the difference Requirements Management at the hub makes: the same regulatory shock that stalled the programme in the opening story becomes a managed re-entry into the cycle.