BABoK Terms That Confuse Us The Most

I have been studying and teaching BABoK® for quite a few years now. I became a CBAP about 8 years back when I took the certification examination in V2. After V3 was launched, I have helped more than 150 participants to successfully complete IIBA certifications such as CBAP, CCBA, and ECBA.

Between BABoK V2 and BABoK V3, BABoK V3 uses terms which are more generic and more encompassing, but more complex. For example, BABoK V2 mostly used the term "requirements", whereas, V3 uses the term "business analysis information".

Business analysis information contains not only requirements but also other information which is useful to business analysis, such as business analysis plan, traceability matrix, models and progress reports etc.  This is more accurate, no questions or doubts about the same, but at the same time, it puts an additional effort on the business analysis practitioners to use these new terms.

Again there are terms in BABoK V3 which are close to each other but are not exactly the same. Understanding search terms is valuable from the examination point of view as the IIBA certification examinations test your understanding of BABoK terminology. The challenge with these terms is that they are also associated with each other.

Here are the most common ones.

1.    Verify vs. Validate

These two tasks can look very similar. Often they are combined and in many organizations, it’s put under a single umbrella called V&V.

However, as per BABoK, they are distinct and defined as below:

Verification ensures that requirements and designs specifications and models meet quality standards and are usable for the purpose they serve. It ensures requirements elicited are of high quality. BABoK has defined the following 9 characteristics which should be checked for verifying requirements quality.

Figure: 9 critical parameters of requirements quality

Validation ensures all requirements, and designs align to the business requirements and support the delivery of the needed value. The 3 key aspects to look for during validation are:

1. Requirements are necessary - Does each requirement add value?
2. Requirements together are sufficient to meet future state objectives
3. Requirements are agreed upon by stakeholders
   

2. Requirements Traceability vs. Requirements Structure

Requirements traceability links requirements to other requirements, design, implementation and test components.

Figure: Sample Traceability Matrix

Requirements structure allows us to have requirements at different levels of abstraction or detail. Requirements structure does indicate the need to establish traceability but it’s only for tracing requirements, not to other requirements, design, implementation, and test components.

Figure: Sample Requirements Structure

3. Trace Requirements vs. Track Requirements

Requirements traceability is explained in point # 2.

Tracking of requirements involves tracking the status of requirements from its origin till retirement. Requirements can go through many statuses on their life journey.

Figure: Sample Requirements States

4. Business Analysis Plan vs Requirements Management Plan

Requirements management plan primarily deals with aspects on how the requirements shall be managed such as, how to plan to elicit requirements, what techniques we plan to use, how do we get requirements reviewed, how do we obtain approval on requirements.

Business analysis plan cover aspects such as tracking a change initiative from its inception to closure. It can include aspects such as key milestones for the change, stakeholder engagement approach, communication approach, solution evaluation approach etc. beyond the requirements management plan.

5. Viewpoints vs Views

BABoK introduces a very interesting new term called, viewpoint. Viewpoints essentially indicate a particular perspective. For example, one could look at requirements from a business owners perspective, or one could look at requirements from stakeholders perspective, or one could look at requirements from a development team's perspective.  Even within a development team, there could be a separate perspective for system architects versus system developers.

Views are actual requirements . A viewpoint contains many views.

I would love to hear from my BA friends if they found other interesting facets of BABoK which can be helpful to learn BABoK better.

Demystifying BABoK V3 terms

Applying BABoK to our personal lives

Structuring requirements in agile projects