Managing Requirements from a Business Analyst or an Enterprise Architect perspective using BABOK 2.0 and/or TOGAF 9

Featured
23185 Views
3 Comments
16 Likes

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 & TOGAF 9 - 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.

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”

  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.

     

    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”

     

    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.

     

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

     

  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.

     

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

     

  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.

     

    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.

     

  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.

 

Communicate Requirements - This step relates to the communication of requirements to the various stakeholders for a common understanding.

 

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.

 

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.

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.

 

Below is a mapping between the two approaches: BABOK 2.0 and TOGAF 9

 

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

Author: Serge Thorn, CIO of Architecting the Enterprise

Ask the expert

 

Architecting the enterprise offers support and answers to any questions. We'll query the experts for an answer.

Send your question by email to EAexperts@architecting-the.enterprise.com . Please include your name, general location, and email address. Questions may be edited for clarity. The most interesting exchanges will be posted on our web site

Architecting the Enterprise is pleased to announce that we have trained over 2000 people in TOGAF 9 since its launch in February in 2009.

You can reach the author at www.architecting-the-enterprise.com or you can sales@architecting-the-enterprise.com.

Like this article:
  16 members liked this article
Featured
23185 Views
3 Comments
16 Likes

COMMENTS

Wendy1 posted on Tuesday, June 14, 2011 12:43 PM
I am confused on the main premise of the article. I agree that these are two different methodologies used by two different groups - Business Analysts and Enterprise Architects. These two groups can fill different roles on the same project. In my experience, the business analyst is responsible for putting together the software requirement specification to record the requirements, or some other type of formal documentation of the requirements for the project - user requirements, business requirements, system requirements, etc. I would then expect the enterprise architect to analyze my final requirement documentation to design a technical solution. In designing this technical solution, it would be appropriate to follow the TOGAF 9 model. The two methodologies could not be used in place of each other. As a business analyst, my work is appealing to a broad group of stakeholders representing different areas - Operations, Product Management, Quality Assurance, App Dev, etc. The BABOK model is designed to gather requirements and produce output in such a way that will be equally useful by all of these stakeholders. The work of the enterprise architect would come behind the BA work and would use a more iterative and less formally defined process to look at the requirements from a technical standpoint. In doing so, it is important to understand the requirements from a business standpoint, but that understanding is achieved mainly from the enterprise architect's involvement in the requirement facilitation and requirement review sessions facilitated by the BA.

I am speaking primarily from waterfall and hybrid SDLCs. These tend to require at least some formalized documentation, sign-offs, and processes. Perhaps in looking at the Agile methodology, one would find that the BABOK and TOGAF 9 could be more easily compared as interchangeable processes for requirement management. But, from where I am sitting, it seems like comparing apples and oranges.
SergeThorn posted on Thursday, June 16, 2011 12:36 PM
You are confused because you believe that Business Analysts are not really involved in Enterprise Architecture. Most of the time, people acting as Business Architects are in reality Business Analysts (if you are interested, I wrote an article a while ago comparing the two roles: http://sergethorn.blogspot.com/2009/12/are-you-business-architect-or-business_09.html). Requirements management is also a key activity in Enterprise Architecture, therefore I do not see what the issue is if you simply work in close collaboration. I believe that you probably should look at are the TOGAF activities such as the Phase A: Architecture Visio, where you collect these requirements. This is not at all apples and oranges I’m afraid. Why don’t you want to create a combined team?
Wendy1 posted on Thursday, June 16, 2011 12:48 PM
Serge, I appreciate that you took the time to respond to my comments. I read your article comparing the two roles and it still does not apply to my business analyst experience. I am sure in some companies and industries this would be the case, but not in mine. It's definitely food for thought, though.
Only registered users may post comments.




Latest Articles

What’s Missing from Agile?
Oct 20, 2019
0 Comments
John Seddon launches an attack on the value of Agile as practiced and charts a better way to analyse and design for improvement, making information te...

Copyright 2006-2019 by Modern Analyst Media LLC