home
Home » Methodology

Conventional Requirements Model Flaw Misses REAL Business Requirements

Submitted by RobinGoldsmith on Wed, 2007-01-31 15:15.

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
» login or register to post comments | printer friendly version | 4240 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Great read!

Submitted by dwright on Tue, 2007-02-13 15:38. *

Robin, thanks for this. It has sent me back to look at your book again (I can get it on a web library service). The first time I saw it, I am not sure I fully bought in to the basic concept(s), but this time will likely be different.

David Wright
Member, IIBA
"It is difficult to get a man to understand something when his salary depends upon his not understanding it.." ...Upton Sinclair

» login or register to post comments

A new hero for frustrated Business Analysts!

Submitted by jfries on Wed, 2007-02-14 21:45. *

Great article, Robin! If I didn't know better, I'd bet you've been spending days sitting with our Business Analyst team with my current client. After a year+ of trying to make the point that the organization has been way too product/app/system focused, we were beginning to wonder if we were the only ones who thought there was a key missing ingredient - the REAL business requirements. It was great to read this and realize that we ARE on the right track, however frustrating it is! This article, and your book, may end up being required reading for this agency's Business Analysts! Great stuff...

» login or register to post comments

REAL Examples

Submitted by kmatthews on Thu, 2007-02-15 07:18. *

I find trying to relate this article to what I may or may not be doing, difficult, as the terminology used, although defined, may be defined in terms of the authors usage.

I beleive that I would find the article clearer if it contained specific examples of the different classifications of requirement and how they may be differently expressed as REAL requirements vs. functional requirements etc., or how one may trace to another.

» login or register to post comments

Examples of REAL business reqs vs. product/system reqs 1 of 2

Submitted by RobinGoldsmith on Thu, 2007-02-15 13:05. *

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.

» login or register to post comments

Examples of REAL business reqs vs. product/system reqs 2 of 2

Submitted by RobinGoldsmith on Thu, 2007-02-15 13:12. *

If you’re taking me up on my request for your own examples of REAL business requirements differing from product/system/software requirements, often one can identify such examples by reanalyzing a creep situation you have experienced, but from this perhaps different REAL business requirements perspective. That is, what is called creep often reflects new awareness of REAL business requirements that hadn't been recognized previously, often because of premature focus on a product/system presumed solution.

Also, examples generally surface quite readily when working through a Problem Pyramid™, as we do when consulting directly with clients and in my Defining and Managing User Requirements seminar.

Example 1: Your business person/user tells you that a screen or report needs to be changed by adding or changing a particular field in a particular way; and then they tell you that the change you've made exactly as they specified is not right. They had leaped to a product solution, in fact beyond product requirements to detailed design; and it turned out to be wrong because it ended up not satisfying the REAL business requirement, which everyone skipped discovering because they thought the product/system specification was the requirement, which was especially easy to presume since it made the user finally seem to "know what they want."

Example 2: Colleague Dick Bender reminded me of this well-known example by mentioning it in a webinar a few days ago. The story goes that the US space program had a requirement for a pen that writes in zero gravity. They spent over a million of our dollars, back when a million bucks was worth something. The Russians were on a bit tighter economic leash and spent only a nickel, for an ordinary lead pencil, because they realized the REAL, business requirement was to be able to write in zero gravity. A pen and its various functional and nonfunctional characteristics requirements represented a presumed product solution.

» login or register to post comments

The Fisher Space Pen

Submitted by Kevin Brennan on Thu, 2007-02-15 14:11. *

It makes a great story, in fact I used to use it myself. However, the reality is a little more prosaic.See http://history.nasa.gov/spacepen.html

In fact, the pen was developed with private funding as a marketing gimmick and adopted by NASA once it proved effective, and the Soviets use them too. (Pencils are actually not good in space as the shavings from sharpening them cause all sorts of problems as they float around the cabin).

Proves nothing, I know--it's just that it's one of those cases where the urban legend is probably more interesting than the reality. ;-)

---------------------------------------
Kevin Brennan, PMP
Sr. Consultant, blue sands Inc.
Vice-President, Body of Knowledge, IIBA

» login or register to post comments

You're right

Submitted by janderson on Thu, 2007-02-15 15:08. *

The urban legends is better :)

» login or register to post comments

Example just gets better

Submitted by RobinGoldsmith on Thu, 2007-02-15 15:49. *

Hi Kevin,
Thanks for the historical update. I think the definition of an urban legend is that it _is_ more interesting than the reality.

The key point of the example is that the astronauts did not require a pen or a pencil; even though many people would say the requirement was a pen or pencil. That's a product requirement, which is high-level design of a presumed way how to meet the REAL, business requirement whats. As you mention, a traditional wooden pencil meets the product requirement (as described by Dick Bender) but fails to provide needed value because it doesn't meet the REAL, business requirements, which include being able to write in zero gravity over the duration of the space flight without creating debris (perhaps this is my chance to use the term "flotsam" too, which alliterates nicely with "floating").

» login or register to post comments

Did the pencils have erasers on the end?

Submitted by dwright on Thu, 2007-02-15 16:53. *

OK, no one has to answer that, really...

Its about this point in discussions where I am still sure I am producing useful outputs that say what a solution must do to be effective for the business paying for it, without specifying that solution... but that (for a moment or two, maybe more) I have no idea what to call that output anymore. I repeat my favourite back-up definition of a Requirement: "I know one when I see one."

Now, for what I do most of the time, I will slightly contradict myself when I say it is Information System Requirements I am producing. That does already presume that an Information system is what you want, but certainly does not dictate what form that system will take given the myriad technology and product choices available these days. I humbly suggest that most of what we talk about at this RQNG site is Information System Requirements.

But if you have not made the assumption that you are going deliver an Information System, then you do need another adjective to stick in front of 'Requirements'. 'Business' works for me, at least at this moment(!).

Here's a related plug for which I gain no direct benefit: as I said earlier, I have access to Robin's book on-line, through a service my company pays for called Books 24-7, from a company whose name is Skillport. No russian novels, its a business site, lots of IT and general business titles, like Wieger's requirements books. Skillport is also an e-learning company, again a mix of IT and general topics. So, check it out. Don't know what it costs, but we still have it, so it can't be extravagant.

David Wright
Member, IIBA
"It is difficult to get a man to understand something when his salary depends upon his not understanding it.." ...Upton Sinclair

» login or register to post comments

Books 24-7 is also available free, I believe

Submitted by RobinGoldsmith on Thu, 2007-02-15 19:10. *

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."

» login or register to post comments

  Sponsored Announcements & Special Offers


FREE Web-based Requirements Management (not just a trial, no time limit)
Lighthouse is a web-based IT project workspace for managing requirements, change requests, project scope, and much more. Lighthouse also automates traceability through the entire life cycle so you will always know the impact of change requests and whether requirements have been built, tested and fulfilled. Free for 5-users, sign-up today.

Download a free trial of ActiveVOS for BPM application development for a chance to win an ultra-portable Lenovo IdeaPad S10 netbook
With the ActiveVOS Business Process Management system (BPMS), the creation of compelling business process applications is compatible, scalable and affordable for everyone from the developer to the business analyst. Download a free, 30-day supported trial of ActiveVOS for the chance to win a Lenovo IdeaPad S10 netbook. No purchase necessary. Download ActiveVOS today at www.wheel-of-function.com.

Writing Use Cases with Word and Excel? Suffered enough?
Create use cases, requirements, diagrams, test cases, and screen prototypes - in one easy-to-use tool. Generate Word and Excel specifications automatically. Consistent, traceable requirements in less time. Try CaseComplete FREE for 30-days.


© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group