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 |
Extension of Examples
I am not sure the examples really clarify anything other than the differentiation that REAL business requirements do not have any presumed product solution, and maybe that is the point.
But if that is the point where does one stop?
What are the REAL business requirements for a Bank (if we are allowed to say Bank?)?
Can I say that the Bank has REAL business requirements such as "to be able to give Loan's" or "to be able to sell GIC's" or "to be able to give Mortgages (a type of Loan)"? as, after all, Loans, GIC's and Mortgages are also a types of product solution?
How far up the chain of abstraction do I go? Is the REAL (and possibly only) business requirement for a Bank that "Something can manipulate some financial instrument in some way"?
Do I have to start of with some initial level of context to define my REAL business requirements within?
Typically I would take:
- work with the business to write a business vision for what the business wants, expressed in business terms
- break the business vision down into business features, expressed in business terms, to realize the business vision
- break the business features down into business requirements (with no implementation or product characteristics)to realize the business features
- write the use cases to indicate how the specific actor would interact with an information system to implement the business requirements
if there were several possible implementations for the business requirements then we may have several use cases e.g. "Make a withdrawal" may be a different implementation via an ATM vs the Internet.
Maybe everything up to the Use Case is a REAL business requirement?