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 |
Are these concepts in fact becoming more recognized?
I’ve seen lots of evidence that many/most companies continually have been burnt by not getting the REAL business requirements right. I’ve seen only a fraction of those companies even recognize that they need to get better at requirements and even fewer that realize it starts with getting the REAL problem right. Some may simply allocate more time for requirements, though I sense that’s seldom done; and it’s probably just as well, since spending more time on ineffective practices doesn’t improve results.
My perception is that the overwhelmingly most common improvement activity is to send staff to a requirements seminar. Frankly, though, I’m not conscious of any appreciable industry-wide improvement in organizations as a whole getting the REAL, business requirements right.
In my experience, there are three main reasons why organizations fail to improve. First, too few organizations recognize their need to get better at requirements, which in turn is due largely to lacking appropriate measures of their REAL development process. Instead they dissipate time and resources by throwing all manner of presumed solution tools, technologies, and methodologies at the symptoms, while all the while ignoring the cause.
Second, they tend to pay lip service by engaging requirements training but then not implementing the important lessons; and their lack of adequate measures hides their failure to follow through.
Third, regardless of the training’s use of terms like “real requirements†and “business requirements,†it almost certainly actually is teaching the flawed conventional model that considers product/system requirements to be “the requirements.†The focus is on clearly specifying the product/ssytem to be created, not on clearly understanding the problem to be solved.
I can appreciate how difficult it is for a company to tell the difference between training that actually teaches how to discover REAL business requirements and one that merely sounds as if it does, especially because the latter’s instructor probably sincerely but mistakenly believes the conventional model s/he presents is defining real “business requirements.â€