togaf

Many Business Analysts are using the IIBA’s BABOK 2.0 (Business Analyst Body of Knowledge ) which contains information about a Requirements Management process, from identifying organizational situations that give cause to a project, through to starting the requirements gathering process, to delivering a solution to the business or a client. TOGAF 9 from an Enterprise Architecture viewpoint also provides some techniques to gather requirements to equally deliver business solutions. This paper illustrates the two processes, defines the mapping between the two approaches and identifies gaps in each.

BABOK 2.0 Knowledge Area (KA) 4 covers Requirements Management and Communication which “describes the activities and considerations for managing and expressing Requirements to a broad and diverse audience” (The other KAs: Plan Requirements, Management Process, and Requirement Analysis will not be included here).

The tasks from this KA “are performed to identify business needs (the why of the project; whereas requirements are the how), the state the scope of their business solutions, ensure that all stakeholders have a shared understanding of the nature of these solutions and that those stakeholders with approval authority are in agreement as to the requirements that the business solution shall meets.”

It manages a baseline, tracks different versions of Requirements documents, and trace requirements from origin to implementation.

This area includes five steps described below.

1. Manage Solution Scope and Requirements

In this step, we “obtain and maintain consensus among stakeholders regarding the overall solution scope and the requirements that will be implemented”. Requirements may be baseline following an approval and a signoff. That means that all future changes are recorded and tracked, and the current state may be compared to the baselined state. Subsequent changes to the requirements must follow a Change Management process and will require additional approval. As changes are approved, a Requirements Management Plan may require that the baselined version of the requirements be maintained in addition to the changed Requirement. Additional information is often maintained such as a description of the change, the person who made the change, and the reason for the change. As requirements are refined or changed as the result of new information, changes will be tracked as well.

A signoff formalises an acceptance by all stakeholders that the content and presentation of documented requirements is accurate and complete. This can be done in a face to face meeting.

2. Manage Requirements Traceability

Traceability consists of understanding the relationship between Business Objectives, the requirements, the stakeholders, other deliverables and components to support the business analysis among other activities. It also allows documenting “the lineage of each requirement, its backward and forward traceability, and its relationship to other requirements”. The reasons for creating relationships are “Impact Analysis”, and “Requirements coverage and allocation”. A coverage matrix may be used to manage tracing.

3. Maintain Requirements for re-use

Requirements re-use is another important aspect in the process and there is a need to manage knowledge of requirements following their implementation, identify the requirements that are candidates for long-term usage by the organisation. “These may include requirements that an organisation must meet on an ongoing basis, as well requirements that are implemented part of a solution” (e.g. regulatory, contractual obligations, quality standards, service level requirements, etc.). Each will have to be clearly named, defined, and available to all analysts.

4. Prepare Requirements Package

This step consists in selecting and structuring a set of requirements “in an appropriate fashion to ensure that the requirements are effectively communicated to, understood and usable” by the various stakeholders. This Requirements Package could have different forms such as a documentation (can be managed in a Requirements Repository), presentations, templates, etc.

5. Communicate Requirements

This step relates to the communication of requirements to the various stakeholders for a common understanding. It may happen that new requirements have to be considered.

The BABOK bundles Requirements Communication together with Requirements Management.

Requirements Analysis is another KA which describes “how we progressively elaborate the solution definition in order to enable the project team to design and build a solution that will meet the needs of the business and stakeholders. In order to do that, we have to analyze the stated requirements of our stakeholders to ensure that they are correct, assess the current state of the business to identify and recommend improvements, and ultimately verify and validate the results”. BABOK 2.0 Requirements Analysis being not really covered within TOGAF 9, there are no comparisons done at this stage.

Within TOGAF 9, the objective of the Requirements Management activity is to define a process whereby all kinds of requirements, including most notably business drivers, concerns, and new functionality and change requests for Enterprise Architecture are identified, stored, and fed into and out of the relevant Architecture Development Method (ADM) phases. As such it forms part of the activities and steps carried out in each of the ADM Phases. Architecture requirements are subject to constant change, and requirements management happens throughout the entire Enterprise Architecture implementation lifecycle.

It is important to note that the Requirement Management circle denotes, not a static set of requirements, but a dynamic process.

As indicated by the Requirements Management circle at the centre of the ADM graphic, the ADM is continuously driven by the Requirements Management process.

Enterprise Architecture has specific techniques to gather requirements. TOGAF as a framework uses a method based on what we call a “Business Scenario” which is used heavily in the initial phases A & B of the ADM to define the relevant business requirements and build consensus with business management and other stakeholders.

A Business Scenario ensures that there is a complete description of business problem in business and architectural terms. Individual requirements are viewed in relation to one another in the context of the overall problem; the architecture is based on complete set of requirements that add up to a whole problem description; the business value of solving the problem is clear and the relevance of potential solutions is clear.

Below is a mapping between the two approaches.

BABOK 2.0 sets up a framework for the requirements development and management, which seems to appear as a standard used by many organizations around the world. Between TOGAF 9 and BABOK 2.0, there is almost 1:1 correspondence but there may be more details and activities in the first one. TOGAF is a methodology whereas the BABOK is methodology agnostic, so it can be tricky to translate between the two but nothing prevent an Enterprise Architecture team to use this analogous technique.

If an organization follows the TOGAF methodology and Business Analysts use BABOK, the later will provide a lot of useful information, as a reference; BABOK won’t give you direction for an Enterprise Architecture.

Sources: Chapter 4 IIBA’s BABOK 2.0, TOGAF 9