Stage Seven of the national methodology: a continuous stage that runs in parallel with every phase of the development cycle, carried out through three steps that cover approving requirements, monitoring their status, and assessing the impact of change on them.
In brief
Placement in NORA: Section II - Stage 7: Managing Enterprise Architecture Requirements.
Stage Seven of the methodology: a continuous stage that runs in parallel with every phase of the EA development cycle.
Three steps: approving EA requirements, monitoring requirement status, and assessing the impact of change on requirements.
Each requirement is documented through eight fields: requirement code, requirement text, requirement source, requirement domain, affected domains, related requirements, requirement state, and priority of implementation.
The register is held in the EA requirements repository, and is best paired with a digital EA tool.
Requirements management steps
01
Approving EA Requirements
Once the incoming requirements pass the "Defining the Scope of the EA Development Cycle" stage, the Chief Enterprise Architect documents them across the eight fields, then assesses the impact of each new requirement on the approved list and re-prioritises based on the dependencies between requirements, the entity strategic priorities, compliance with national policies and regulations, time constraints, and the availability of capabilities and staff.
02
Monitoring the Status of EA Requirements
The EA work team tracks each requirement from inception to closure and updates its state after every phase of the development cycle, when a requirement is cancelled for technical or procedural reasons, when the relevant stakeholder changes it, during initiative execution under the EA governance procedures, or when a newly approved requirement affects priority. The team contacts stakeholders to explain the reason behind any update.
03
Assessing the Impact of Changes in EA Requirements
The size of impact on the cycle scope is measured: no scope change for minor impact, rescope and reschedule for moderate impact, or stopping the cycle and re-running "Defining the Scope of the EA Development Cycle" for substantial change. The same logic applies to digital initiatives and projects through the EA governance procedures.
Inputs and outputs
Inputs
Outputs
Enterprise Architecture Development Cycle Charter
Updated Enterprise Architecture Requirements
Incoming Enterprise Architecture Requirements
Status of Enterprise Architecture Requirements
Outputs of the EA Governance Procedures
Assessment of the Impact of Changes in EA Requirements
Enterprise Architecture Requirements Repository
Requirements list linked to the future state, the domain principles, and compliance status
Wrap-up
Requirements management does not stop. It works when there is steady contact with project managers and stakeholders, when every change is logged with a clear reason, and when each requirement is weighed before it is approved against its assumptions and constraints, the principles of the affected domains, the relevant policies, standards, and guidelines, and is tied back to the entity EA governance procedures.
Key takeaway
The stage produces a live list of requirements: linked to the future-state components, mapped against the principles of the affected domains, and kept current with one of the eight defined states (Approved, Suspended, Cancelled, Current State, Future State, Planned for Implementation, In Progress, Completed). Running this register through a digital EA tool makes it the single source the entity relies on.
