Recommendations For Updating The BABOK

Suggested Improvements To BABOK v3

These are my findings from analyzing the Business Analysis Body Of Knowledge, version 3 (BABOK). These findings are presented in the form of, suggestions for improvement, potential errors and omissions. They are the result of creating an object-oriented model of the structure and information of the BABOK. This model captures 461 pages of the BABOK - from the Business Analysis Key Concepts chapter through to the end of the Techniques To Tasks Mapping chapter.

If you would like to learn about this model, an overview is described in my Analysis Of The BABOK document, here.

Object-Oriented Analysis And Design

Object-Oriented Analysis and Design is mentioned in one paragraph of the BABOK, section 10.15. This paragraph is concerned with the data modeling technique. Quote from section 10.15 – ‘a logical or physical class diagram would be used to support object-oriented software development’.

The primary component of Object-Oriented Analysis is the class diagram. Class diagrams are extensions to the entity relationship diagram (ERD), intended to model requirements and design options. Classes include operations (requirements) or methods (procedures). Class diagrams allow encapsulation (grouping) of related requirements and can be used to identify relationships (traceability) between requirements.

Figure 10.15.2: in the BABOK, shows a UML Class Diagram that is described as a data modeling diagram. This class diagram is not just modeling data and relationships. It shows operations attached to classes. If this is an analysis diagram, then these operations represent functional requirements.

Recommendation:

Include an OOA/D technique that shows how class diagrams can be used to model and analyze requirements.

Reference this technique whenever requirements are modeled or analyzed.

Remove class diagrams as a technique for data modeling (ERDs include the same data modeling capabilities as class diagrams).

External Objects

Needs and Proposed Change are not marked as external, even though neither is produced by any analysis task.

Recommendation:

In sections 3.1, 3.2, 4.1 and 6.1, indicate that business need is an external input.

In section 5.4 indicate that Proposed Change is an external input.

Any Stakeholder

Any stakeholder may provide useful input to any task. Unless the BAOK intended to prohibit stakeholders from contributing to certain tasks, then the Any Stakeholder role may be shown as a contributor to all tasks. Thus, the Any Stakeholder role serves no purpose.

Recommendation:

Reword section ‘1.4.3.7 Stakeholders’ to state ‘The Stakeholders section is composed of a generic list of stakeholders who are required to participate in performing that task or who will take ownership of its output. The BABOK® Guide does not mandate that these roles be filled for any given initiative, or that other roles may contribute to the task.’

Remove the ‘Any Stakeholder’ actor and only show stakeholders that are required to perform a task, in the task stakeholders sections. (It is assumed that any stakeholder may contribute, if desired.)

Stakeholder Requirement

There is no input or output artifact named Stakeholder Requirement. A stakeholder requirement is represented by the generic Requirement artifact. The Business Objective artifact is identified as an input artifact.

Recommendation:

Since Stakeholder Requirement is not an explicit output from the process, but Business Objective is, in figure 5.1.2 of the BABOK, replace Stakeholder Requirements with Business Objectives to show traceability between business requirements and business objectives.

Glossary

The BABOK glossary appears to be missing some useful analysis terms.

Recommendation:

Add the following terms to the BABOK glossary.

• Analysis/Analyze
• Business Analysis Performance Assessment
• Business Rules Analysis
• Change Assessment
• Concept Modeling
• Current state
• Customer
• Elicitation Activity Plan
• Elicitation Result
• Enterprise Limitation
• Future State
• Governance Approach
• Implemented Solution
• Influence
• Information Management Approach
• Performance Objective
• Potential Value
• Proposed Change
• Recommended Action
• Recommended Solution
• Risk Analysis Result
• Solution Limitation
• Solution Performance Analysis
• Solution Performance Measure
• Stakeholder Engagement
• Stakeholder Engagement Approach
• Synthesis/Synthesize

Trace Requirements Stakeholders

There are too many stakeholders involved with tracing requirements. (Only the regulator is not listed.) In my experience, the only essential stakeholders are the business analyst (who does the work), testers (who will need to derive test cases from the requirements) and the project manager (who will adjust the project schedule accordingly). Anyone on the project may decide they wish to view or contribute to traceability (but this is unusual).

Recommendation:

In section 5.1 Trace Requirements, show Tester and Project Manager as the only required stakeholders.

Make Traceability An Output From Trace Requirements

The BABOK shows traced requirements to be attributes of Requirements and attributes of Designs. Requirement Traceability may be thought of as an output from the Trace Requirements task. In this manner Requirements and Design do not change, instead a trace object is created. Figure 1: shows Traced Requirements as an output from the Trace Requirements task.

Figure 1: Traced Requirements Artifact

When a change occurs to a requirement, then the Traced Requirements artifact can be used to determine the impacts of that change. I think this is a more elegant way to describe a change assessment instead showing the whole requirement as an input.

Recommendation:

Create an output from the Trace Requirement task (named Traced Requirements). This artifact has the same elements, guidelines and tools and stakeholders as described in section 5.1 of the BABOK. Show Traced Requirements as an input to Assess Requirement Changes, (BABOK section 5.4).

Wrong Object Referenced

Traceability is documented in the Information Management Approach, not the Information Management Approach.

Recommendation:

Replace business analysis approach with information management approach, in section 5.1.3.

Business Objective vs. Business Requirement

The following 3 definitions are taken from the BABOK glossary.

• A goal is a state or condition that an organization is seeking to establish and maintain, usually expressed qualitatively rather than quantitatively.
• An objective is a measurable result to indicate that a business goal has been achieved.
• A requirement is a representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed.

Traditionally, a requirement is a measurable, unambiguous, time-boxed specification of a need (or want). A requirement does not include a description of ‘why’ the change is needed. The reason why can be derived by traversing the requirement traceability back to the business need (or goal).

Recommendation:

Modify the definitions for business requirement and business objective, so that a requirement includes measurable results and an objective includes the reason why the change is needed.

Figure 2: Proposed Business Requirement and Objective Relationships

Figure 2: shows that a business objective is the result of analyzing the current state and a business requirement is a result of analyzing the future state. Business requirements are traced from business objectives.

Design Artifact

The Design artifact is only used where the Requirement artifact is used. The design artifact tasks are named Assess Requirement Changes, Approve Requirements, Maintain Requirements, and Trace Requirements (all show both Requirement and Design as inputs or outputs).

Designs are not shown as an input to Define Design Options. This is confusing, because it is not obvious how Designs are related to Design Options. (I assume that there is no direct relationship between a Design and a Design Option.)

Similarly, the Requirement and the Design Change Assessments are only used by the Assess Requirement Change task. None of these tasks make a clear distinction between which elements are design, and which are requirements.

The tasks descriptions using the Design and for the Design Change Assessment do not distinguish between requirement and design elements, so these do not need to change.

Recommendation:

Combine the Requirement and Design artifacts (also Requirement and Design Change Assessments) into a single artifact named Requirement (also Requirement Change Assessment). Indicate that these artifacts include design components.

Change Assessment

A Change Assessment is defined as ‘the recommendation to approve, modify, or deny a proposed change to requirements.’

A Change Assessment is derived from a Proposed Change, by the Assess Requirement Changes task, but it is not used as an input anywhere in the BABOK. Therefore it is not clear how the Change Assessment impacts the requirements for the project.

Recommendation:

In section 5.4, add the result of the Proposed Change proposal as an element of the Change Assessment.

In section 7.1.3, show the Change Assessment as an input to the specify and model requirements task.

Risk analysis Result

Defined as ‘an understanding of the risks associated with achieving the future state, and the mitigation strategies which will be used to prevent those risks, reduce the impact of the risk, or reduce the likelihood of the risk occurring’. It appears that the BA is identifying and mitigating project risks.

Recommendation:

Explain the difference between a Risk Analysis Result and a Risk, and how they are related.

Define Future State

The Figure 6.2.1 shows Constraint as a guideline, but it is not described in section 6.2.

Recommendation:

Add Business Constraint as a guideline and tool to Section 6.2.5. Or identify the difference between a Constraint and a Business Constraint in the glossary.

Author: Leslie Munday, Sr. IT Professional

Leslie is a Senior level Information Technology (IT) professional with expertise in Business and Systems Analysis, Process Analysis, Requirements Analysis and Project Management.

Previously, I published a book titled “Analysis Through Pictures”. This book details the knowledge, skills, methods and best practices that I used as a systems analyst, up to 2011. It shows how the Rational Unified Process can be used effectively, to produce quality software systems. I have been actively involved with the International Institute of Business Analysis. I joined the IIBA after they asked me to give a presentation about traceability. Since then I have presented an analysis model of the Business Analysis Body Of Knowledge, and published several analysis presentations to various business analysis organizations. My website is intended to share my analysis knowledge skills and presentations with anyone who is interested in learning about the role of a business analyst.