13. ADM Architecture Requirements Management

This chapter looks at the process of managing architecture requirements throughout the ADM.

13.1 Objectives

The objectives of the Requirements Management phase are to:

• Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
• Manage architecture requirements identified during any execution of the ADM cycle or a phase
• Ensure that relevant architecture requirements are available for use by each phase as the phase is executed

13.2 Inputs

Inputs to the Requirements Management phase are:

• A populated Architecture Repository (see the TOGAF Standard — Architecture Content)
• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), 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 the TOGAF Standard — Architecture Content), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
• Architecture Vision (see the TOGAF Standard — Architecture Content)
• Architecture requirements, populating an Architecture Requirements Specification (see the TOGAF Standard — Architecture Content)
• Requirements Impact Assessment (see the TOGAF Standard — Architecture Content)

13.3 Steps

The steps in the Requirements Management phase are described in the table below:

	Requirements Management Steps	ADM Phase Steps
Step 1		Identify requirements (typically by analyzing how business goals/objectives can be met through the design of value streams, business scenarios, user experiences, or the provision of management information) and document them in the Architecture Requirements Specification and Requirements Repository.
Step 2	Establish baseline requirements: determine priorities, confirm stakeholder agreement to priorities, and document them in the Architecture Requirements Specification and Requirements Repository.
Step 3	Monitor baseline requirements.
Step 4		Identify new and 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 the TOGAF Standard — Architecture Content) 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 Architecture 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 Architecture Requirements Repository, and that the Target Architecture is revised accordingly.

13.4 Outputs

The outputs of the Requirements Management process may include, but are not restricted to:

• Requirements Impact Assessment (see the TOGAF Standard — Architecture Content)
• Updated Architecture Requirements Specification (see the TOGAF Standard — Architecture Content: Architecture Requirements Specification), if necessary

The TOGAF Standard — Architecture Content contains a detailed description of architectural artifacts which may be produced in this phase, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.

The Architecture Requirements Repository will be updated as part of the Requirements Management phase and should contain all requirements information.

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, and business metrics) on the architecture development. Once requirements for the current ADM cycle have been finalized then the Architecture Requirements Specification should be updated.

13.5 Approach

13.5.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, and also between cycles of the ADM.

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.

It is recommended that an Architecture Requirements Repository (see the TOGAF Standard — Architecture Content) is used to record and manage all architecture requirements. Unlike the Architecture Requirements Specification, and the Requirements Impact Assessment, the Architecture Requirements Repository can hold information from multiple ADM cycles.

13.5.2 Requirements Development

The first high-level requirements are articulated as part of the Architecture Vision, generated by means of the business scenario or analogous technique.

Each phase of the ADM, from Preliminary to Phase H, must select the approved requirements for that phase as held in the Architecture Requirements Repository and Architecture Requirements Specification. At the completion of the phase the status of all such requirements needs to be updated. During the phase execution, new requirements generated for future architecture work within the scope of the current Statement of Architecture Work need to be documented within the Architecture Requirements Specification, and new requirements which are outside of the scope of the current Statement of Architecture Work must be input to the Architecture Requirements Repository for management through the Requirements Management process.

In each relevant phase of the ADM the architect should identify types of requirement that must be met by the architecture, including applicable:

• Functional requirements
• Non-functional requirements

When defining requirements the architect should take into account:

• Assumptions for requirements
• Constraints for requirements
• Domain-specific principles that drive requirements
• Policies affecting requirements
• Standards that requirements must meet
• Organization guidelines for requirements
• Specifications for requirements

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).

13.5.3 Resources

The world of requirements engineering is rich with emerging recommendations and processes for Requirements Management. The TOGAF Standard 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).

13.5.3.1 Business Scenarios

A technique used to analyze how a business goal or objective can be met by a process or value stream. Analyzing where the activities in that process are performed by human and computer actors is a highly effective way to identify and clarify architecture requirements. The technique is detailed in the TOGAF® Series Guide: Business Scenarios.

13.5.3.2 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.

---

---