Conventional Requirements Model Flaw Misses REAL Business Requirements
by Robin F. Goldsmith, JD
A fundamental flaw in the widely-held conventional model of requirements creates much of creep and other requirements difficulties. This flaw involves misunderstanding of the nature and role of REAL business requirements. The term “REAL” relates to requirements in two ways. The first way is widely recognizable and is represented in lower-case. People think they know what the requirements are and then learn differently and must revise their requirements definition. Thus, the “real” requirements are what one ends up with, as opposed to what one may have thought initially.
The second use of “REAL” warrants distinguishing with upper case because it represents breakthrough awareness that REAL requirements are business requirements, which are in business terms and are what must be delivered to provide value.
| Attachment | Size |
|---|---|
| Conventional Requirements Model Flaw Misses REAL Business Requirements.pdf | 158.75 KB |
Examples of REAL business reqs vs. product/system reqs 2 of 2
If you’re taking me up on my request for your own examples of REAL business requirements differing from product/system/software requirements, often one can identify such examples by reanalyzing a creep situation you have experienced, but from this perhaps different REAL business requirements perspective. That is, what is called creep often reflects new awareness of REAL business requirements that hadn't been recognized previously, often because of premature focus on a product/system presumed solution.
Also, examples generally surface quite readily when working through a Problem Pyramidâ„¢, as we do when consulting directly with clients and in my Defining and Managing User Requirements seminar.
Example 1: Your business person/user tells you that a screen or report needs to be changed by adding or changing a particular field in a particular way; and then they tell you that the change you've made exactly as they specified is not right. They had leaped to a product solution, in fact beyond product requirements to detailed design; and it turned out to be wrong because it ended up not satisfying the REAL business requirement, which everyone skipped discovering because they thought the product/system specification was the requirement, which was especially easy to presume since it made the user finally seem to "know what they want."
Example 2: Colleague Dick Bender reminded me of this well-known example by mentioning it in a webinar a few days ago. The story goes that the US space program had a requirement for a pen that writes in zero gravity. They spent over a million of our dollars, back when a million bucks was worth something. The Russians were on a bit tighter economic leash and spent only a nickel, for an ordinary lead pencil, because they realized the REAL, business requirement was to be able to write in zero gravity. A pen and its various functional and nonfunctional characteristics requirements represented a presumed product solution.