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 |
Expected solution form doesn't change REAL business requirements
One’s business requirements exist within the business environment (using the term broadly) and don’t change as a function of whether one’s solution takes the form of a physical product, an intangible product, a service, an information system with or without computer hardware and/or software, some other system in the broad sense (essentially equivalent to a “processâ€), or however else one chooses to characterize it.
The adjectives “product,†â€system,†and “software†taken together reasonably thoroughly cover the various characterizations of requirements of a presumed way how to meet the REAL business requirements. “Product requirements,†“system requirements,†and “software requirements†are all talking about the same things—high-level design of a solution which provides value if and only if it meets the REAL, business requirements.
REAL business requirements usually are hierarchical. One increases clarity by driving down to lower levels of detail. No matter what the level of detail, REAL business requirements have the same characteristics: hierarchical itemized business deliverable whats that when delivered (or satisfied or accomplished or met) provide value.
To put the ATM example in context, the first set of ATM requirements (mag stripe, etc.) was consolidated from talks and writings of numerous other supposed requirements authorities (practically everyone uses an ATM example), many of whom explicitly referred to them as “business requirements.†Regardless of what terms they use, they’re talking about product/system requirements, not the REAL business requirements.
“Perform ordinary bank transactions†is indeed a high-level business requirement, for which the example in the book didn’t need further detailing. Such detail would include: accepting cash and checks for deposit and issuing cash for withdrawals from customer accounts. Even lower-level detail would get to business rules about funds availability and the like. Internet banking is not an appropriate product/system solution, because it can’t handle cash and checks.
We need only sweet- and neutral-smelling requirements.