home

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.

AttachmentSize
Conventional Requirements Model Flaw Misses REAL Business Requirements.pdf158.75 KB

Books 24-7 is also available free, I believe

It's my understanding that both IEEE and ACM offer Books 24-7 accessibility, and I think some degree of access is free to members.

Business requirements exist for whatever type of product/system solution one decides to implement. Since many of us work with information systems, they are a common context; but there are business requirements for manufactured products and for personal business.

In a seminar not long ago, a participant used the Problem Pyramidâ„¢ to discover her REAL business requirements for a problem which she defined initially as "ants in her kitchen."

    Sponsored Announcements & Special Offers

view counter

Whitepaper from HP - Why Focus on Requirements Definition Management in the Application Lifecycle?

Increasingly, smart businesses are looking much closer at requirements definition (RD) and requirements management (RM) (sometimes grouped together under the Gartner-coined phrase, requirements definition management (RDM)) to streamline the entire application lifecycle. Why? Because systematic and effective RDM captures software defects earlier in the lifecycle, and it reduces the overall likelihood that defects will be introduced. That’s important. How important? According to one study, the cost to fix a defect after delivery is more than 100 times the cost to fix it in the requirement and design phase. No business wants to be hit with that bill. Now to add to this the growing interest in agile development techniques as a way to deliver higher quality applications and we have an interesting recipe for success.

Download a Free Copy

view counter
© 2007-2010 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group