Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features
Features       Excerpts       Interviews


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

Negotiating a Common Understanding

by Donald C. Gause and Gerald M. Weinberg

Adapted from Exploring Requirements. Reprinted by permission. All rights reserved. See below for copyright notice.

Before you invest your time in a book, you want to know what you'll get from reading it. This book is about development projects. In particular, it's mostly about the early part of development projects, or at least what should be the early part.

Similarly, in the early part of a development project before you are willing to invest much of your time, you want to know what you'll get from doing it. Well, unless you know what you want, you'll never be very sure of what you'll get.

If you employ other people to help you develop what you want, you'd describe what you want for them. That description is called a problem statement or a set of requirements, and that's what this book is about. Obviously, requirements are important because if you don't know what you want, or don't communicate what you want, you reduce your chances of getting what you want.

Some years ago, we performed experiments to determine how computer programmers were influenced by what they were asked to do.[1] The experiments were simple, but they revealed the essential dynamics underlying all requirements work:

  • If you tell what you want, you're quite likely to get it.
  • If you don't tell what you want, you're quite unlikely to get it

In a typical experiment, five teams were given the same requirement for a computer program except for a single sentence that differed for each team. One team was asked to complete the job with the fewest possible hours of programming, another was to minimize the number of program statements written, a third was to minimize the amount of memory used, another was to produce the clearest possible program, and the final team was to produce the clearest possible output. The actual results are shown in Figure I-1.

 Primary ObjectiveRank on Primary
minimize core storage1
maximize output readability1
maximize program readability1-2
minimize statements1
minimizing programming hours1

Figure I-1. Experiments show that programming team performance is highly sensitive to stated requirements.

In short, each team produced exactly what it was asked to produce, and didn't produce what it wasn't asked to produce. Before these experiments, we had often heard software buyers complaining about the inability of programmers to give them what they wanted. The experiments convinced us that in many cases, the buyers simply did not tell the programmers clearly what they wanted.

In the ensuing years, we have confirmed this observation in software development organizations all over the world. Moreover, we've found that the difficulty in stating requirements is not confined to software development, but is found whenever people design and build products for other people. Between your two authors, we've devoted more than sixty years to overcoming this difficulty. We've developed techniques to help people negotiate a common understanding of what they want. If you require such techniques, then this book was designed for you.

[1] G.M. Weinberg and E.L. Schulman, "Goals and Performance in Computer Programming," Human Factors, Vol. 16, No. 1 (1974), pp. 70-77. Reprinted in Bill Curtis, ed. Tutorial: Human Factors in Software Development (Los Angeles: IEEE Computer Society, 1981).

AddThis Social Bookmark Button




COPYRIGHT NOTICE: This excerpt from Exploring Requirements: Quality Before Design [ISBN: 978-0-932633-73-6] appears by permission of Dorset House Publishing. Copyright © 1989 by Donald C. Gause and Gerald M. Weinberg. All rights reserved. See http://www.dorsethouse.com/books/er.html. The material contained in this file may be shared for noncommercial purposes only, nonexclusively, provided that this Copyright Notice always appears with it. This material may not be combined with advertisements, online or in print, without explicit permission from Dorset House Publishing. For copies of the printed book or for permissions, contact Dorset House Publishing, 1-800-342-6657, 212-620-4053, http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.



New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044
Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal