Covering the basics: keep track of requirements

This is the last posting in a series on TOGAF’s ADM. In this final post we zoom in on the Requirements Management phase which is central to the ADM. We will start this post with a discussion of the formal objectives, steps, inputs and outputs of this phase. After that we will discuss best practices for effective requirements management in the architecture space. We will end this series by discussion TOGAF and ArchiMate integration.

Objectives, steps, inputs and outputs

The Requirements Management phase forms the heart of the ADM; all other phases interact with it. This again stresses the nature of architecture work, which revolves around structured and controlled change of the enterprise. If you want to change, you’d better have some idea of where you’re going (vision). Since this vision is not yet achieved, there are certain requirements that have to be met to get there – or at least to move in the right direction.

The TOGAF standard defines a requirement as “A quantitative statement of business need that must be met by a particular architecture or work package”. The objective of this phase is simple: to define a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases. In other words, the RM phase at the center of the ADM “crop circle” should not be seen as a static document but an active process of management requirements in the context of change.

Key activities in this phase are prototypical for the requirements discipline and involve the identification and definition of requirements, prioritization, recording requirements and priorities in the repository, identifying changing requirements and priorities as well as handling their impact etcetera. Furthermore, it should be noted that the TOGAF standard does not propose or mandate a particular form for recording requirements.

The outputs for this phase as defined by the TOGAF standard are the requirements impact assessment (asserting the impact of changing requirements or priorities) and the architecture requirements specification (see our earlier posting on ADM Phases B, C, and D).

Best practices

Getting requirements right is essential in realizing the goals of any architecture initiative. Without clear requirements, defining and realizing an architecture quickly degenerates into a guessing game.

In itself this is not new as this fact has been established in the field of software engineering a long time ago (Note: see e.g., the seminal book “the mythical man month” by Freddy Brooks Jr., published in 1975). Unfortunately, both in the field of software engineering and enterprise architecture alike, requirements management still does not get the attention it deserves. More often than not, requirements management is something “we do on the side”.

In order to be successful with requirements management in the context of the ADM, requirements modeling and architecture modeling should be integrated as much as possible. In previous postings of this series we already advocated the use of ArchiMate as a language for architecture modeling. Recently the ArchiMate language has been extended to be able to model requirements and directly relate it to concepts from the ArchiMate core.

The above diagram illustrates the use of (part of) this extension. Starting at the top, it shows a stakeholder (claim reviewer) with his concern (claim handling). Associated to this concern are three assessments which lead to the goal to revise the claim handling process. This goal is decomposed in three sub goals, two of which are realized by requirements. These requirements, in turn, are to be realized by the application service Registration Service.

This way of integral modeling has many benefits, including improved traceability, tool support (e.g. BiZZdesign Architect), advanced analysis etcetera.

TOGAF and ArchiMate integration

To finish this series we briefly discuss TOGAF and ArchiMate integration. Both standards are currently maintained by the Open Group and complement each other.

The TOGAF standard focuses on the process of doing architecture, whereas ArchiMate focuses on architecture descriptions. Both standards leverage the three domains (business, information systems, technology) and the ArchiMate concepts map well on TOGAF’s content meta-model. The development of ArchiMate – especially the recently proposed extensions for motivation and implementation & migration are focused on further integration between the two standards

Questions

We hope that you found this series of articles on TOGAF’s ADM useful and help you use TOGAF in your own organization. If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.