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 1 of 2
Apparently my verbosity exceeds the comment limit, so I'm breaking this long answer to a short question into two posts.
First, thanks to David and Joel for their nice words. Becoming aware of the distinction between the REAL, business requirements and what people have been calling "the requirements" can help one understand why frustrations persist and provide a basis for communicating with business folks more effectively.
I also can appreciate how difficult it could be to comprehend the distinction. I hate to use the term, because it's so often overused, but it really does involve a paradigm shift; and that's hard for anyone, but especially for those who have invested heavily over an extended period of time in the conventional requirements model's mindset.
I agree that concrete examples can be very helpful. In fact, I posed the same request for examples to clarify terminology a few days ago on a different RQNG discussion; and on my website people can take a “What is a test case?†survey that demonstrates how a concrete example can reveal markedly disparate interpretations of a term for which people use virtually identical definitions.
My book is essentially one big concrete example of working through a real business case fact situation discovering REAL business requirements and how they differ from product/system/software requirements. That's why I advise readers to go through the full text and not skip sections they assume they already know--because there's a pretty good chance that working through the example exercises reveals important and perhaps previously unrecognized distinctions.
The book also contains numerous additional smaller concrete examples of the REAL business vs. product/system/software requirements distinction which I'm not going to repeat here. I do give two simple examples inthe next comment post. I encourage readers of this comment post to offer their own examples.