What’s in a BABOK Name?


On page one of the IIBA BABOK® Guide, the first sentence under the heading 'Purpose' is the phrase “… commonly accepted practices.” I have great admiration for the people involved in the guide’s production and publication. They did an excellent job on 499 of its 500 pages. But on page 16, ‘for the purposes of the guide’, a Requirements Classification Schema was introduced that identifies and defines the terms Business Requirement, Stakeholder Requirement, and Solution Requirement. The problem I have with this scheme is that those terms, as defined, fall outside of commonly-accepted practices. I believe that the more traditional terms Goal/Objective, High-level Requirement, and Detailed Requirement would be more in keeping with the overall purpose of the guide.

What is in a BABOK name

Business Requirement vs Goal/Objective

The following is the BABOK definition of the Business Requirement category:

“Statements of goals, objectives, and outcomes that describe why a change has been initiated.”

The first problem is that the term Business Requirement is a commonly used term, but with a meaning very different from the above definition. For example, a Business Requirements Document (BRD) is the standard name for a document that contains project-specific, high-level and/or detailed requirements. Such a document may make reference to applicable goals or objectives. But those would be sourced from a business case, not a deliverable of a requirements effort.

The second problem is that the fundamental aspect of a requirement is that it represents a need and should be ‘testable’. Goals and objectives are management-level wants. A goal represents a desired state (e.g. “To be the #1 service provider in the industry.”). An objective represents an attainable, timeframe-specific target (e.g. “Within one year, improve our industry ranking by two places”). An objective is expected to be measurable, but neither a goal nor an objective is expected to be testable.

Where significant funding is needed to achieve an objective’s target, a business case is typically produced. It’s expected to include some number of options including estimated costs, risks, etc. Ideally one of the options will be deemed the most suitable solution and taken forward to be implemented. 

When the implementation of a solution requires formal managing, a project is initiated — ideally led by a person with project management skills. If it’s considered necessary for business needs to be formally documented as part of the delivery process, requirements elicitation is planned and undertaken — ideally led by a person with business analysis skills.

Stakeholder Requirements vs High-Level Requirements (HLRs)

The following is the BABOK definition of the Stakeholder Requirement category:

”Describes the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.”

The first question is, “Wouldn’t the validity (and therefore quality) of needs expressed by a stakeholder be proportional to his/her level of expertise in the domain being analyzed?” The second question is, “If stakeholder needs are captured in stakeholder requirements, whose needs are captured in solution requirements?”

NOTE: Because standard practice is for the more detailed requirements to be produced subsequent to HLRs, the bridge analogy is not appropriate. Appropriate is an HLR acting as a context for subsequent details.

A significant problem with HLRs is the lack of clear guidelines regarding how much or how little detail they should include (spoiler alert — no detail). Just re-branding HLRs to stakeholder requirements does nothing to alleviate the problem. (See Keeping High-level Requirements High-level).

Solution Requirements vs Detailed Requirements

The following is the BABOK definition of the Solution Requirement category:

“Describes the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution.”

Using the term solution to discriminate this type of requirement from stakeholder requirements has the same problem we saw with stakeholder requirements — both types of requirements should involve stakeholders, and both types of requirements should relate to the solution the project is chartered to deliver. Therefore neither term is appropriate to designate the difference between those two types of requirements.

As with the term ‘high-level’, the term ‘detailed’ is common usage. Detailed requirements have a similar but opposite problem to HLRs — guidelines as to how detailed a detailed requirement needs to be (spoiler alert — very). (See the Trips-R-You Case Study for examples of the level of detail needed to allow for the development and implementation of the solution.)

Updating the BABOK?

Am I the only person who has a problem with the BABOK requirements classification schema terms? In spite of having retired from a 48-year career in IT, I still write articles about requirements. I’m tired of apologizing in those articles for using the ‘old’ terms rather than the BABOK terms.

Even though the guide states that this schema is intended for use within the context of the guide, what is the point of certifying business analysts in the use of those terms and not expect the terms to be used outside of the certification process?

As discussed above, the existing industry-standard terms Goal/Objective, High-Level Requirement, and Detailed Requirement do not seem inappropriate. Hopefully I have made a case for using these terms both in and outside of the BABOK guide.

If you are a current IIBA member and agree with the points I’ve raised, do share and discuss this with other members of your local chapter. And as a chapter, encourage the IIBA to update the BABOK to use the more traditional, best-practice terms.

Author: Dan Tasker

Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].

Like this article:
  9 members liked this article


Karl Wiegers posted on Saturday, December 26, 2020 3:29 PM
When Joy Beatty and I co-wrote the third edition of my "Software Requirements" book in 2013, we carefully considered whether to adapt my previous terminology to conform to IIBA. We decided not to. I'm still comfortable with the 3-level model and terminology of business/user [not stakeholder]/functional+nonfunctional requirements that I developed almost 25 years ago. (Although I'm okay with "solution requirements" for FR+NFR.)

The definitions I provide make the distinctions clear. Colloquially:

* business reqs describe why we're undertaking the project (like your goal/objectives)
* user requirements describe what users will be able to do with the product (use cases, some user stories)
* functional requirements describe what developers build.

I find this distinction more meaningful than the less clearly distinguished (to me) high-level/detailed phrasing. The user/functional distinction is not just a question of detail; they are qualitatively different.
Dan Tasker posted on Monday, February 1, 2021 12:44 AM

It's nice that you agree with me that the BABOK terms are not the best.

In my personal experience, 'high-level' and 'detailed' were the terms used at the project level. A project initiated to deliver an IT-based solution would have a project charter what would include a stated objective. If you want to call that a requirement, as BABOK does, I won't argue. It's just a name.

That said, I've often started a project to deliver a particular solution where I've been handed a document titled "Business Requirements", filled not with objectives but with pages and pages of text describing what the business says they want (i.e. their needs). That's why I shy away from that term to represent that level. Also, I claim that neither goals nor objectives are 'testable' (a standard requirement quality attribute) within the life of a deliverable. Only 'in the fullness of time' can it be determined if a goal or objective has been achieved.

So that just leaves 2 levels, and I agree that the 'top' one of those should be at the 'named' use case level (not fully dressed), nor a user story that talks about field-level details - just the need for something at the same level as a 'named' use case.

Given that, there is then the need for the 'last' level - the detail behind a use case, or a user story 'refined' to the point that it can be developed. Again, we agree. Whatever they are called, they need to be detailed enough that developers can build them.

Thanks for taking the time to present your thoughts.

Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC