Problem pyramid discovering REAL software requirements

Using the problem pyramid model developed by expert consultant Robin Goldsmith can help make requirements gathering a focused and effective process. By using Goldsmith's model REAL business requirement goal setting is made simpler and results can be more tangible.

Many colleagues, clients and students praise my Problem Pyramid™ tool but fail to gain its powerful payoffs.  The Problem Pyramid™ provides a systematic, disciplined guide which is central to discovering REAL, business requirements.  They in turn are key to avoiding the creep which causes most project overruns; and they also are the basis for persuasive marketing messages and right, reliable, and responsible REAL ROI™.

Most Problem Pyramid™ disappointments probably start with its seeming simplicity.  Results often are illusory when people proceed to apply the tool without appreciating its difficulty and especially its conceptual underpinnings.  It's difficult because it enforces a structured thought process that people are not accustomed to and that is used with equally unfamiliar discipline.  It's also difficult because discovering REAL requirements is hard.

Conceptual underpinnings

To realize the benefits of the Problem Pyramid, one must understand and appreciate its underlying concepts and methodology of discovering REAL business requirements.  In fact, these are three inter-related concepts.

First, requirements need to be discovered, not gathered.  Discovery is an active process involving integrated analysis and adjustment while eliciting data, as well as subsequently analyzing the data and tentative requirements based on the data.  In contrast, traditional requirements gathering is largely passive and generally leads to significant oversights, misunderstandings, and mistaken presumptions.  Moreover, traditional requirements methods mainly apply analysis to the flawed artifacts flowing from requirements gathering; and they don't seem to catch on that such methods create much of their creep.

Second, the methodology aims to discover the REAL requirements much more directly, without so many of the fits, starts and rework which typically tie up so much time, effort and credibility.  The REAL requirements are the ones we end up with after ordinarily wasting a lot of time identifying, throwing out and revising what turned out to be wrong requirements.  REAL is not an acronym.  Rather, I put the word in all capitals to distinguish it in ways that withstand common reformatting that often destroys usual highlighting methods, such as italics, boldface and underlining.

Third, the REAL requirements are business requirements.  This is the concept that many people have the greatest difficulty understanding.  Ironically, the more business and conventional requirements experience one has, the more likely they are both to misunderstand and to resist understanding this concept of business requirements.  They may be so locked into the conventional requirements model that they are unable or unwilling to see how REAL business requirements differ. 

Because they often mistakenly assume they already know and use the REAL business requirements concepts, many don't allow themselves to realize they misunderstand and thus don't open themselves to the different ideas needed for understanding.  To better explain how REAL business requirements differ, it's helpful to start by describing the commonly-held conventional requirements model.

Conventional requirements model

Most authors, developers, and business people use the term "requirements" to mean the requirements of the product, system, or software they expect to be created.  Such requirements often describe the features or functioning of the product, in which case they also frequently called "functional requirements" or "functional specifications."    Conventional approaches ordinarily separately identify "non-functional" requirements, which also are called "quality factors," "attributes," and "ilities" (because many of them end in "ility," such as usability, reliability, and portability). 

Many capture requirements in the form of use cases, which often are considered to be the user's requirements.  Use cases depict the step-by-step interaction of an actor (usually the user, but also possibly another system or piece of hardware) with the product or system.  If included, non-functional requirements typically are stored in a separate section.  Thus, use cases ordinarily actually are describing the usage (rather than user's) requirements of the expected product or system.  

Traditional requirements definition largely relies upon gathering these product requirements from various stakeholders and then analyzing them to more fully articulate detailed functional and non-functional product requirements.  Many organizations, most notably the U.S. Department of Defense, place considerable emphasis upon the precise wording.  For them, the words "must" or "shall" make it a requirement; whereas "should," "may," and "to be defined (TBD)" mean it's not a requirement.  

A widely-held conventional requirements model does refer to "business requirements," which the model considers high-level and vague—usually objectives—that decompose into the detailed product requirements.  Thus, according to this "levels model," the difference between business requirements and product requirements is simply a level of detail or abstraction.  The model says a detailed requirement is a product requirement, and a high-level vague requirement is a business requirement.   

"Creep" refers to changes to product requirements that presumably had been settled.  Creep is a major cause of project budget and schedule overruns.  Conventional requirements wisdom is that creep is caused by requirements which are not clear or testable.  A requirement is not testable when one cannot write test cases to demonstrate the product meets the requirement, usually because the requirement is not sufficiently clear.  A requirement that is unclear and untestable is likely to be implemented improperly; and, regardless, without applicable test cases, there's no way to tell whether it's been implemented correctly. 

REAL business requirements

I define business requirements as "what must be delivered to provide value."  Thus, REAL business requirements are deliverable whats that provide value when delivered, satisfied, or met by a product, system, or software how.

REAL business requirements are from the perspective of and in the language of the business, user, customer or stakeholder.  All users are customers, all customers are stakeholders, and the business is a stakeholder.  I use these terms interchangeably, because the user's requirements are to do their business, regardless whether it's 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

REAL business requirements are whats that provide value when they are delivered, satisfied or met.  Value comes from serving business objectives by solving problems, taking opportunities or meeting challenges.  Providing value, not use of particular words, makes it a requirement. There usually are many possible ways to accomplish a REAL business requirement.

In contrast, product requirements are human-defined or specified.  Humans define designs; and "specification" is a synonym for "design."  A design does not have to be technical or detailed.  A product or system is a design which presumably is one of the possible ways how to meet the presumed REAL business requirements.  The more one presumes, the more wrong one is likely to be.

A product provides value if and only if it satisfies a REAL business requirement.  Creep mainly occurs when the product fails to satisfy a REAL business requirement, largely due to failing to adequately define the REAL business requirements. This in turn usually is due to following conventional requirements models which say the product requirements are the requirements.

Requirements generally are hierarchical.  REAL business requirements are whats; and whats do not decompose into detailed product requirements howsHows are a response to whats; and the more attention to the detailed hows without knowing the whats, the more presumptions there will be creating creep. 

REAL business requirements are not just high-level.  They need to be driven down to detail.  No matter how far down in the hierarchy detail they are driven, they are always business deliverable whats that when delivered contribute to providing the value.  Driving whats down into more detail never turns them into hows

However, driving the REAL business requirements deliverable whats down to detail enables mapping them to a product, system, or software how that in fact will satisfy the whats and thereby provide the value.  This is the way to avoid much of the creep that conventional methods mistakenly think is inevitable.

Problem Pyramid™

The Problem Pyramid™ is a tool that both embodies and enforces these distinctions to reliably guide discovery of the REAL business requirements.  The tool consists of six steps (or boxes) that must be performed in the numbered sequence.

Box 1 identifies the Problem, Opportunity or Challenge that when addressed appropriately will provide meaningful value.  Many are projects are destined for failure from initiation because the REAL Problem was not identified accurately.  If the Problem is not right, there's little chance requirements or solution will be right.  Position within the organization does not assure rightly identifying the right Problem. 

Boxes 2 and 3 are measures that help get the Problem right.  Box 2 Current Measures tell us we've got a Problem.  Box 3 Goal Measures tell us the Problem has been solved, Opportunity has been taken or Challenge has been met.  Achieving the Box 3 Goal Measure(s) provides the value.  If appropriate, Measures and REAL meaningful Value cannot be identified, either the Problem, the Measures, or both are wrong.

Box 4 identifies the as-is process Causes of the Problem that are producing the Box 2 Current Measures that indicate there's a Problem.  The Causes must explain why the Problem occurs and account for all key Causes. 

Box 5 is the should-be process REAL business requirements deliverable whats that when delivered reasonably will achieve the Box 3 Goal Measures and thereby provide the Value.  These are high level in the Problem Pyramid™ and then later are selectively driven down to greater detail through additional data gathering and analysis.

Box 6 is the Design of a specific product, system, or software How the Box 5 whats can be satisfied.

It should be evident that an appropriate Box 6 How cannot be specified until Box 5 whats have been discovered adequately.  Yet, most projects pretty much start with Box 6, as does the conventional requirements approach.  That's why they virtually assure creep, overruns and disappointment.

In contrast, using the Problem Pyramid™ guides us to greater success.  The Problem Pyramid™ is developed iteratively, but still quickly because it's focusing on discovering the high-level REAL business requirements.  Once agreed upon by the relevant stakeholders, estimates can be made reliably and used to compute REAL ROI™ for informed tradeoff analysis. 

Subsets of the high-level REAL business requirements become the Scope for one or more negotiated Implementation Projects.  Then subsequent data gathering and analysis is used to drive just those selected high-level REAL business requirements down to detailed REAL business requirements.  That prevents analysis paralysis.  They in turn become the basis for designing product, system, software requirements and use cases which in fact will satisfy the detailed REAL business requirements.      

About the author: Robin F. Goldsmith, JD, is President of Needham, Mass., consultancy Go Pro Management, Inc.  He works directly with and trains business and systems professionals in requirements, quality and testing, metrics, ROI and project and process management.  A subject expert and reviewer for IIBA's BABOK, he is author of the Proactive Testing and REAL ROI methodologies and Discovering REAL Business Requirements for Software Project Success.

Dig Deeper on Topics Archive