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 |
REAL business requirements usually are hierarchical
A business vision and its associated business features may well be high-level business requirements, which, if they are, ordinarily in turn can be broken down into more detailed business requirements. The sizing, or context, is determined by the size of the problem, opportunity, or challenge that the business requirements are addressing. The Problem Pyramidâ„¢ is invaluable in helping determine what the REAL problem (or opportunity or challenge) is and getting it down to the lowest level (since problems too usually are hierarchical) that produces REAL value when solved.
I’m qualifying a bit because I’ve found that just because someone calls something a business vision, feature, or requirement doesn’t mean that in fact it’s either business or REAL requirements. First, it must indeed be in business terms and from the business perspective, again recognizing that we use the term “business†broadly. I’ve found that people routinely and erroneously call products and even designs (such as a drop-down list on a screen) “business requirements.â€
Second, the vision, features, requirements must be addressing the REAL problem appropriately. In my experience, this is hardly a given. In fact, I’d say that it’s exceedingly common for requirements to be defined without adequate understanding of the REAL problem. For instance, many organizations assume that whatever a manager mandates makes it business requirements. I’ve found that managerial mandates quite frequently are not the REAL business requirements, because they don’t provide REAL value, because they don’t solve the REAL business problem, because the manager didn’t adequately understand what the REAL business problem was, usually because s/he confuses position with knowledge.
A use case is merely a format and can be used for both business and product/system requirements, although in practice use cases almost always describe product/system usage requirements.