-
17. ADM Architecture Requirements Management
This chapter looks at the process of managing architecture requirements throughout the ADM.
Figure 17-1: ADM Architecture Requirements Management 17.1 Objectives
The objectives of the Requirements Management phase are:
- To define a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases
17.2 Approach
17.2.1 General
As indicated by the "Requirements Management" circle at the center of the ADM graphic, the ADM is continuously driven by the requirements management process.
It is important to note that the Requirements Management circle denotes, not a static set of requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases.
The ability to deal with changes in requirements is crucial. Architecture is an activity that by its very nature deals with uncertainty and change - the "grey area" between what stakeholders aspire to and what can be specified and engineered as a solution. Architecture requirements are therefore invariably subject to change in practice. Moreover, architecture often deals with drivers and constraints, many of which by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.), and which can produce changes in requirements in an unforeseen manner.
Note also that the requirements management process itself does not dispose of, address, or prioritize any requirements; this is done within the relevant phase of the ADM. It is merely the process for managing requirements throughout the overall ADM.
17.2.2 Resources
The world of requirements engineering is rich with emerging recommendations and processes for requirements management. TOGAF does not mandate or recommend any specific process or tool; it simply states what an effective requirements management process should achieve (i.e., the "requirements for requirements", if you like).
17.2.2.1 Business Scenarios
One effective technique that is described in TOGAF itself is business scenarios, which are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios are described in detail in Part III, 26. Business Scenarios .
17.2.2.2 Volere Requirements Specification Template
Architecture requirements is very much a niche area within the overall requirements field. One useful resource is the Volere Requirements Specification Template, available from Volere1 (refer to www.volere.co.uk/template.htm). While not designed with architecture requirements in mind, this is a very useful requirements template, which is freely available and may be modified or copied (for internal use, provided the copyright is appropriately acknowledged).
One interesting item in this template is the "waiting room", which is a hold-all for requirements in waiting. There are often requirements identified which, as a result of the prioritization activity that forms part of the requirements management process (see below), are designated as beyond the planned scope, or the time available, for the current iteration of the architecture. The waiting room is a repository of future requirements. Having the ability to store such requirements helps avoid the perception that they are simply being discarded, while at the same time helping to manage expectations about what will be delivered.
17.2.2.3 Requirements Tools
There is a large, and increasing, number of Commercial Off-The-Shelf (COTS) tools available for the support of requirements management, albeit not necessarily designed for architecture requirements. The Volere web site has a very useful list of leading requirements tools (see www.volere.co.uk/tools.htm).
17.3 Inputs
Inputs to the Requirements Management phase are:
- A populated Architecture Repository (see Part IV, 36.2.5 Architecture Repository),
- Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
- Scope of organizations impacted
- Maturity assessment, gaps, and resolution approach
- Roles and responsibilities for architecture team(s)
- Constraints on architecture work
- Budget requirements
- Governance and support strategy
- Tailored Architecture Framework (see Part IV, 36.2.21 Tailored
Architecture Framework), including:
- Tailored architecture method
- Tailored architecture content (deliverables and artifacts)
- Configured and deployed tools
- Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
- Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
- Architecture requirements, populating an Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification)
- Requirements Impact Assessment (see Part IV, 36.2.18 Requirements Impact Assessment)
The first high-level requirements are articulated as part of the Architecture Vision, generated by means of the business scenario or analogous technique.
Each architecture domain then generates detailed design requirements specific to that domain, and potentially to other domains (for example, areas where already designed architecture domains may need to change to cater for changes in this architecture domain; constraints on other architecture domains still to be designed.)
Deliverables in later ADM phases also contain mappings to the design requirements, and may also generate new types of requirements (for example, conformance requirements, time windows for implementation).
17.4 Steps
The steps in the Requirements Management phase are described in the table below:
Requirements Management Steps
ADM Phase Steps
Step 1
Identify/document requirements - use business scenarios, or an analogous technique
Step 2
Baseline requirements:
- Determine priorities arising from current phase of ADM
- Confirm stakeholder buy-in to resultant priorities
- Record requirements priorities and place in requirements repository
Step 3
Monitor baseline requirements
Step 4
Identify changed requirements:
- Remove or re-assess priorities
- Add requirements and re-assess priorities
- Modify existing requirements
Step 5
Identify changed requirements and record priorities:
- Identify changed requirements and ensure the requirements are prioritized by the architect(s) responsible for the current phase, and by the relevant stakeholders
- Record new priorities
- Ensure that any conflicts are identified and managed through the phases to a successful conclusion and prioritization
- Generate Requirements Impact Statement (see 36.2.18 Requirements Impact Assessment) for steering the architecture team
Notes
- Changed requirements can come in through any route. To ensure that the requirements are properly assessed and prioritized, this process needs to direct the ADM phases and record the decisions related to the requirements.
- The Requirements Management phase needs to determine stakeholder satisfaction with the decisions. Where there is dissatisfaction, the phase remains accountable to ensure the resolution of the issues and determine next steps.
Step 6
- Assess impact of changed requirements on current (active) phase
- Assess impact of changed requirements on previous phases
- Determine whether to implement change, or defer to later ADM cycle; if decision is to implement, assess timescale for change management implementation
- Issue Requirements Impact Statement, Version n+1
Step 7
Implement requirements arising from Phase H
The architecture can be changed through its lifecycle by the Architecture Change Management phase (Phase H). The requirements management process ensures that new or changing requirements that are derived from Phase H are managed accordingly.
Step 8
Update the requirements repository with information relating to the changes requested, including stakeholder views affected
Step 9
Implement change in the current phase
Step 10
Assess and revise gap analysis for past phases
The gap analysis in the ADM Phases B through D identifies the gaps between Baseline and Target Architectures. Certain types of gap can give rise to gap requirements.
The ADM describes two kinds of gap:
- Something that is present in the baseline, but not in the target (i.e., eliminated - by accident or design)
- Something not in the baseline, but present in the target (i.e., new)
A "gap requirement" is anything that has been eliminated by accident, and therefore requires a change to the Target Architecture.
If the gap analysis generates gap requirements, then this step will ensure that they are addressed, documented, and recorded in the requirements repository, and that the Target Architecture is revised accordingly.
17.5 Outputs
The outputs of the requirements management process itself are:
The requirements repository contains the current requirements for the Target Architecture. When new requirements arise, or existing ones are changed, a Requirements Impact Statement is generated, which identifies the phases of the ADM that need to be revisited to address the changes. The statement goes through various iterations until the final version, which includes the full implications of the requirements (e.g., costs, timescales, business metrics) on the architecture development.
Footnotes
- The Volere web site is hosted by the Atlantic Systems Guild (see www.systemsguild.com).