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