Abstract
This paper’s primary purpose is to make educators aware of critical requirements concepts that customary courses and literature fail to address appropriately. Widely-accepted conventional requirements models continue to create creep—changes to settled requirements which are a major cause of project overruns. Business Analysts and others will continue to encounter such creep so long as they follow flawed models focusing on requirements of a product or system being created without adequately also discovering the REAL, business requirements the product must satisfy to provide value. Much of the difficulty comes from mistakenly trying to interpret these qualitatively different concepts in terms of familiar similar-sounding models, such as depicting them as merely different requirements levels. The two types of requirements are distinguished and the powerful Problem Pyramid™ tool is described as a way to more reliably get both right quicker with less effort and aggravation. Educational implications are discussed.
1. Introduction
Anyone who has ever done a project of practically any type is familiar with creep—changes to presumably settled requirements. Creep changes are a major cause of project budget and schedule overruns.
Creep continues despite considerable attention to defining requirements over the past 20 years. During that period, requirements have been recognized as a topic within their own right. Many courses and books, and more recently certifications and tools, now exist with respect to various aspects of requirements and Business Analysis, the discipline commonly charged in a project with defining requirements.
While each offers its respective benefits, they have not succeeded individually or collectively in coming close to curtailing creep. My analysis indicates that the root cause of this persistent problem is following a widely-accepted and widely-taught conventional, but flawed, model of requirements which cannot help but create creep.
The solution is adopting and learning to apply effectively a more appropriate model which this paper introduces. Said more appropriate model needs to be taught to Business Analysts (BAs) and others who define requirements.
The challenge is overcoming entrenched ways of thinking. Educators cannot look to a body of research, because few investigators are aware the second model exists. Moreover, those who are most familiar with the conventional requirements model often have the greatest difficulty understanding distinctions between the models. Instead, they mistakenly try to frame the new model in terms of the old one. For instance, they’ll dismiss the differences as merely differences in requirements level, which is a flawed concept in the conventional model.
In contrast, when experienced business analysts learn the differences between the two models, many indicate they finally understand why their customary practices haven’t curtailed creep; and many express gratitude and confidence that they now have a more reliable way to get requirements right.
2. Conventional Model and Creep
Books on requirements almost always state, usually in about their first paragraph, that they are dealing with requirements of a product, system, or software; and my informal surveys of attendees at my seminars and speeches confirm that when most people use the term “requirements,” they too are referring to requirements of a product/system/software.
Many people also refer to these as “functional requirements” or “functional specifications;” and those terms bring along with them their “nonfunctional” counterparts. To cut repetition, I’ll refer to all these as simply “product requirements.”
I’m highlighting the “product” aspect in order to make an important distinction between these requirements and what I call “REAL, business requirements.”
Figure 1 depicts graphically a widely-held and widely-accepted conventional model of requirements which indeed does refer to and distinguish “business requirements.”
Figure 1. Conventional Requirements Model
This conventional requirements model depicts the difference between business and product requirements as simply a difference in level of detail, which sometimes also is called a “level of abstraction.”
According to the requirements-levels conventional model, business requirements are high-level and vague and decompose into product requirements, which are detailed.
Thus, the model says that if a requirement is detailed, it’s a product requirement; whereas if it is high-level and vague, it’s a business requirement.
For instance, the increasingly influential International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK) [1] embraces this model. Section 1.3.2.1 of the recently-released BABOK v2 (Version 2) describes several requirements levels, including business requirements, stakeholder requirements, solution requirements consisting of functional and nonfunctional requirements, and implementation requirements. It defines business requirements as:
“higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things [as] the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.”
A related and also widely-held bit of conventional wisdom is that creep—changes to requirements after they supposedly have been settled—is inevitable and is caused by unclear product requirements.
In the quality assurance (QA) and testing community, the main issue with requirements is generally considered to be “lack of testability,” which is due to lack of clarity. If a requirement is not clear enough to create a test to demonstrate the requirement has been met, then it’s likely that the developer won’t know what to develop; and QA/Testing won’t be able to tell anyhow whether what’s developed is right.
3.1. REAL Is for Emphasis, Not an Acronym
To distinguish these from the flawed conventional levels-of-detail model, I refer to them as REAL, business requirement.
REAL is not an acronym but rather is all capitals to make it stand out even when automatic reformatting obscures italics, bold, underlining, and other typical means of emphasis.
Furthermore, REAL requirements are those one ends up with after making and correcting various false starts. The objective is to reach the REAL, ending requirements more immediately without having to spend so much effort circuitously defining and reworking incorrect requirements on the way.
3.2. Product vs. REAL, Business Requirements
REAL, business requirements are from the perspective of and in the language of the user, business, customer, or stakeholder. The user’s requirements are to do their business, whether at work or personal, for profit or not for profit. REAL business requirements are conceptual and exist within the business environment, which means they must be discovered rather than merely gathered.
REAL, business requirements are business deliverable whats that provide value when delivered (or are met or satisfied). Value comes from meeting business objectives through solving problems, taking opportunities, and meeting challenges. There usually are many ways to accomplishing the REAL, business requirements.
In contrast, product requirements represent a human-defined product which is presumably one of those possible ways how presumably to satisfy the presumed business requirements. Humans define designs; and a product is a design, albeit high-level.
The product provides value if, and only if, it meets the REAL, business requirements. Presumptions have a way of being wrong. The more one presumes, the more likely they will be wrong. Because product requirements so often involve presumptions, they often are wrong.
4. Real Cause of Creep
While clarity and testability are important, much of creep occurs because the product requirements, regardless of how clear and testable they are, turn out not to meet the REAL, business requirements.
The primary reason the product requirements don’t meet the REAL, business requirements is because the REAL, business requirements have not been defined adequately, which in turn is primarily due to people following the flawed conventional wisdom that the product requirements are the requirements.
The levels-of-detail model pictured in Figure 1 is flawed because business requirements are whats and product requirements are hows. Whats do not decompose into hows. Rather, hows are a response to whats. All the hows detail in the world will not make up for not knowing the whats detail. The conventional wisdom approach of emphasizing only the hows detail can lead only to presumptions; and presumptions cause errors and creep.
Figure 2. More Appropriate Model that Cuts Creep
In contrast, Figure 2 depicts the more appropriate model that is the key to cutting creep. REAL, business requirements need to be defined in detail. They are hierarchical; and no matter how far down in detail they go, they are always business deliverable whats that provide value when delivered, satisfied, or met. One goes to lower levels of detail to increase clarity, not to describe a product.
However, when REAL, business requirements have been defined in detail, which can be selective based on priorities, then it usually is a relatively straightforward process to translate them into a product which in fact meets the REAL, business requirements and thereby avoids creep.
Often one can do a lot of copy and paste, so the two may end up looking very similar. That can be a trap, because it can fool people into thinking they can skip the detailing of the REAL, business requirements, which of course is the flawed conventional wisdom model described in Figure 1 that causes creep.
Part of the flawed conventional wisdom, which of course can become a self-fulfilling prophecy, is that creep is inevitable because business situations and associated requirements change so constantly. Indeed, human-defined product requirements are very likely to change, especially when they were designed without being responsive to REAL business requirements.
On the other hand, REAL business requirements tend to change much less. It’s often the changing awareness of REAL business requirements that have been there all along that is characterized erroneously as requirements changes.
Consider the situation where a competitor comes out with a superior product, which is often cited as an inevitable but unpredictable source of requirements changes. Is it not clear that the change is a product? Its superiority is due to better meeting known REAL business requirements and/or meeting ones that the competitor is more aware of than we are.
Had we used appropriate techniques to discover the REAL business requirements that our competitor obviously was able to identify, we could have designed a product equal to or better than theirs. Often, superior design actually is due to more fully discovering REAL business requirements that some call “nonfunctional,” such as aspects of usability.
Furthermore, introduction of competitive products is hardly unpredictable; and REAL business requirements include likely competitive capabilities and other changes that product marketing specialists really ought to be able to anticipate to some extent. Effective Business Analysts find out about them.
5. Powerful Problem Pyramid™
Probably the thing that most people remember from my book is the powerful Problem Pyramid™ tool. It is eye-opening to see the tool reveal the mistaken thought processes that cause so many projects to fail to deliver value.
People’s fascination with the Problem Pyramid™ tool also is frustrating because it seems to distract them from the essential distinction between product and REAL, business requirements. Using the Problem Pyramid™ to perpetuate product focus will continue to cause creep. Rather the power of the tool is its ability to help discover the REAL, business requirements.
Figure 3. The Problem Pyramid™
Figure 3 shows the Problem Pyramid™, which consists of six boxes or steps that should be performed in the numbered sequence.
Box 1 must be done first. It involves identifying the problem, opportunity, or challenge that will provide value when addressed appropriately. Not surprisingly, it’s common for the problem not to be identified correctly, which makes chances for proper solution essentially impossible.
To help get the problem right, we identify measures of the problem. Box 2 describes the measures of how things are now that tell us we have a problem; and Box 3 identifies Goal Measures that tell us the problem has been solved, the opportunity has been taken, or the challenge has been met. Achieving the Box 3 Goal Measures provides the value, so identifying and quantifying the value is part of getting the problem right.
One doesn’t solve a problem directly. Rather one must identify and deal with the causes of the problem. Box 4 describes the current As Is process Causes that result in the Box 2 measures which tell us we have a problem.
Box 5 is the Should Be, the REAL, business requirements deliverable whats that when delivered reasonably will lead to accomplishing the Box 3 Goal Measures which achieve the value. The Problem Pyramid™ identifies the high-level REAL, business requirements which then need to be driven selectively down to greater detail. No matter how far down in detail they are driven, they are always business deliverable whats that provide value when delivered.
Box 6 is the design of a product how to satisfy the Box 5 REAL, business requirements whats. Box 6 is where we get the product requirements depicted on the right-hand side of Figures 1 and 2. Box 6 should be a response to Box 5.
However, instead people ordinarily start with Box 6 and not surprisingly fail to provide desired value, because they haven’t defined the Box 5 REAL business requirements whats that the Box 6 product how must satisfy in order to provide the Box 3 value. By following the numbered sequence from Box 1 through Box 5 before getting into the Box 6 how, project success improves dramatically.
Getting the REAL, business requirements right in the first place is the key to providing value and cutting creep. The Problem Pyramid™ is a difficult but powerful tool to get the problem, value, and REAL requirements right. It takes training, skill, and guided practice to develop proficiency; but the effort pays off.
6. Educational Implications
The first step in teaching these concepts and techniques to Business Analysts and others is to make the educators themselves aware that a different model exists and needs to be taught. Hopefully, this paper serves that purpose.
In order to teach the concepts and techniques, the educators must understand them. They must be clear on the difference between REAL business requirements and product requirements; and they must be proficient at applying the Problem Pyramid™. My book [2] and relevant articles available on the Internet, including [3], [4], and [5] are valuable resources for helping both educators and students understand these ideas.
I teach this information in a very interactive two-day seminar [6] which maps closely with my book and does not get into defining product requirements (which is the topic of a separate two-day class [7]). However, I’d guess most educators would be looking for ways to include the ideas along with other requirements topics in a broader class.
I’d suggest starting conceptually, describing REAL business requirements and how they differ from product requirements, including the flaws in treating them as different requirements levels, and why making these distinctions is essential.
Concrete examples help make the distinctions clearer. It’s usually easy to elicit likely requirements for generic types of projects; or students could offer requirements from real projects with which they are familiar.
Then the students analyze the requirements to determine whether they are product or REAL business requirements; and for ones that are product requirements, they must identify the REAL business requirements that the product presumably is satisfying. Some additional examples are included in reader discussion comments for article [3].
Learning to use the Problem Pyramid™ is more difficult. I ask each student to develop Boxes 1-5 of a Problem Pyramid™ for some problem, opportunity, or challenge they are currently encountering.
Then as a class, we apply the review guidelines to systematically evaluate and improve a Problem Pyramid™ shared by one of the students. We capture everything, using different colors to contrast the student’s original version with suggested changes and final agreed upon contents. As time permits, the class can review other students’ Problem Pyramids™ one-at-a-time. Then all students review and revise their own.
Traditional techniques for teaching the well-known elicitation and analysis techniques all can be used with respect to REAL business requirements. I have the class observe and then critique student groups who interview me playing various user roles for case study situations. Subsequently, students use various analysis techniques to help understand the data they and their classmates have uncovered, and especially to identify further questions they now realize need to be answered.
Students use a Problem Pyramid™ for the case situation to determine when they sufficiently have identified the Boxes 1-4 REAL problem, measures, value, and causes to warrant defining the Box 5 Should Be top-level REAL business requirements.
Then the students practice drafting top-level requirements and critiquing each other’s results. They can develop high-level conceptual designs to show how the requirements might be addressed and can develop implementation estimates. Based on this information, they can practice requirements prioritization, tradeoff analysis, and negotiation of implementation projects.
Students drive top-level REAL business requirements selected for implementation down to greater detail, typically two or three levels at a time, followed by reviews and adjustments. They should identify, and possibly carry out, needed additional data gathering and analysis.
This brings the students to a junction with conventional requirements education’s typical focus on writing product requirements specifications and use cases. The difference is that the product and actors’ usage of the product are specified based on satisfying the detailed REAL business requirements.
7. References
[1] International Institute of Business Analysis (IIBA), Business Analysis Body of Knowledge, Version 2 (BABOK v2), International Institute of Business Analysis (IIBA), Toronto, 2009.
[2] Goldsmith, Robin F., Discovering REAL Business Requirements for Software Project Success, Artech House, Boston, 2004.
[3] Goldsmith, Robin F., “Conventional Requirements Model Flaw Misses REAL Business Requirements,” Requirements Networking Group featured article, 2007-01-31.
[4 Goldsmith, Robin F., “ROI is Deceptive Without REAL Requirements and Quantified Intangibles,” Requirements Networking Group featured article, 2007-03-20.
]5[ Goldsmith, Robin F., “Should BABOK Include Shorthand?”, Requirements Networking Group featured article, 2008-11-11.
]6[ Go Pro Management, Inc., Defining and Managing User Requirements, two-day seminar presented in various public and in-house venues, see www.gopromanagement.com.
]7[ Go Pro Management, Inc., Writing Testable Software Requirements and Use Cases Workshop, two-day seminar presented in various public and in-house venues, see www.gopromanagement.com.
Author: Robin F. Goldsmith, JD is President of Needham, MA consultancy Go Pro Management, Inc., which he co-founded in 1982. He works directly with and trains business and systems professionals in requirements, quality and testing, project management, software acquisition and outsourcing, Return on Investment (ROI), metrics, and process improvement. A frequent speaker at leading conferences, he is the author of the Proactive Testing™ and REAL ROI™ methodologies, and the recent Artech House book, Discovering REAL Business Requirements for Software Project Success.
This paper was presented at IEEE 17th Requirements Engineering Conference (RE’09) in Atlanta, GA August 2009.
]