EA requirements management
A structured way to manage EA requirements through a central register and three steps: adopt requirements, track status, and study impact of change until closure.
What is EA requirements management?
Objectives of EA requirements management
Clarify the procedures needed to manage requirements across EA domains and ensure they are tracked through all stages of the EA development cycle.
Document EA requirements in a central register.
Update and govern requirement status from inception to implementation or closure.
Achieve greater effectiveness in governing and tracking requirements; using a digital EA tool to digitize EA office operations is recommended.
Central requirements register (EA requirements repository)
After studying incoming requirements and adopting them as valid EA requirements during the cycle scope phase, the Chief Enterprise Architect documents each requirement in the register as follows.
Requirement documentation fields
Requirement code: the identifier used for tracking.
Requirement text: a description of the requirement and the challenge to be addressed through EA components.
Requirement source: the origin of the requirement.
Requirement domain: the primary EA domain the requirement relates to.
EA domains affected by the requirement: the domain(s) whose components must be developed to address the challenge (based on EA team analysis).
Related requirements: code(s) of linked requirements that may affect this one.
Requirement status: progress in addressing the requirement. Possible values: adopted, suspended, cancelled, current-state phase, target-state phase, planned for implementation, in progress, completed.
Implementation priority: importance of addressing the requirement (high, medium, low) according to the priority criteria below.
Priority criteria for requirements
After adopting a new requirement, the Chief EA and team assess its impact on the approved list and reprioritize, taking into account:
Dependencies between requirements.
Alignment of the requirement with entity strategic priorities.
The requirement’s contribution to compliance with national policies or legislation.
Time constraints for implementing the requirement; non-compliance may have negative effects on the entity.
Available capacity and human resources to work on the requirement.
Steps of the EA requirements management phase
Step 1: Adopt EA requirements
Inputs: EA development cycle charter, EA requirements, EA governance procedure outputs, EA requirements repository.
Outputs: updated EA requirements.
This step documents and adopts EA requirements that reach the EA team. Each requirement is documented with the fields above; then the impact of the new requirement on the approved list is assessed and priorities are updated according to the priority criteria.
Step 2: Track status of EA requirements
Inputs: updated EA requirements.
Outputs: status of EA requirements.
This step tracks the status of adopted requirements. The EA team ensures that requirements included in a development cycle have started to be addressed and updates requirement status. Tracking runs from creation to closure (by completion or suspension and closure). Status is updated: at the end of each phase of the cycle; when a requirement is cancelled for business or technical reasons; when a stakeholder changes the requirement; during initiative execution via EA governance procedures; when a new requirement is adopted that affects the priority or scope of the current one. The team communicates with stakeholders to explain reasons for change and discuss impact per the next step (impact of change study).
Step 3: Study impact of change on EA requirements
Inputs: updated EA requirements, development cycle charter, all outputs of EA development cycle phases.
Outputs: study of impact of change on EA requirements.
This step studies the impact of changes on requirements being addressed in a development cycle or phase. During cycle execution: the team assesses the impact of a requirement change on cycle scope. The outcome is: no need to change scope (minor impact), need to change scope and reschedule (moderate impact), or stop the cycle and restart the cycle scope phase (major impact). During digital initiatives/projects (via EA governance): either project outputs align with requirements (update requirement status only), or there is minor variance (apply temporary exemption management and update the requirement with exemption/exception), or project outputs do not align (study causes and take action: reject the change if unjustified, or update the requirement and its status based on valid justification).
Guidance considerations for EA requirements management
The following are guidance considerations when applying the EA requirements management phase:
The EA team should track changes to requirements (whether by a stakeholder or the team) and document the reason for the change.
Apply EA governance procedures when reviewing the list of current and scheduled projects and deciding to adjust their scope in the entity’s interest.
When studying and adopting EA requirements, the Chief EA should consider: assumptions and constraints of the requirements; principles for the domain(s) the requirement affects; policies that affect the requirement; standards the requirement must meet; guidelines related to the requirement.
EA requirements management is linked to EA governance procedures in the entity; it is important to take them into account when executing the requirements management steps.
Ongoing communication with project managers who address EA requirements is important to ensure a clear and accurate view of the status of requirements linked to those projects.
Responsibility assignment matrix (RACI)
The same assignment applies to all three steps (adopt requirements, track status, study impact of change):
Chief Enterprise Architect: Accountable (A)
EA team: Responsible (R)
Relevant organisational units in the entity (e.g. organisational excellence, business process management, service design, policy development, HR, etc.) and business and IT stakeholders: Consulted / Informed (C / I)
Expected outputs
According to the guideline, expected outputs of the EA requirements management phase include:
List of EA requirements linked to the target state (projects, capabilities, gaps, changes to designs or architectures).
Linking of EA requirements to EA principles (per domain).
Compliance status for EA requirements (compliant, non-compliant, partially compliant, not applicable, unknown) — for project technical specifications, workbooks, designs, technical proposals, etc.
Illustrative examples
The guideline includes examples of: a requirements list with links to the target state; a matrix linking business requirements to business principles (and similarly for other domains); and a table of compliance status of project technical specifications against EA requirements. Entities use these as reference when preparing the register and impact and compliance reports.
Process inputs
Inputs vary by step: for step 1 (cycle charter, requirements, EA governance outputs, repository); for step 2 (updated requirements); for step 3 (updated requirements, charter, all cycle phase outputs).