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


by Donald C. Gause and Gerald M. Weinberg

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

"There's no sense being exact about something if you don't even know what you're talking about."

—John von Neumann

Development is the process of transforming someone's desires into a product that satisfies those desires. This book is about the requirements process—the part of development in which people attempt to discover what is desired.

To understand this process, the reader should focus on five critical words: desire, product, people, attempt, and discover.

First, consider the word "desire." Some readers would prefer that we say "attempt to discover what is needed," but we don't know how to figure out what people need, as opposed to what they desire. Besides, people don't always buy what they need, but they always desire what they buy, even if the desire is only transitory. We do observe, however, that by clarifying their desires, people sometimes clarify what they really need and don't need.

By "product," we mean any product that attempts to satisfy a complex set of desires. One reason the desires are complex is that they come from many people. When we create a product to satisfy our own desires—as when we build a garden, for example, or a bookcase—we don't often need an explicit requirements process. We simply build something, look at it, and make adjustments until we are satisfied.

But "people" might include many different people, and discovering who "people" are is a major part of the requirements process. When many people are involved—and when the product is large—the kind of iterative process used to discover personal requirements may simply prove too drawn out, too costly, and too risky.

What about "attempt"? If we're writing a book, shouldn't we be more certain, more positive? Shouldn't we guarantee results? Well, we've used the requirements techniques in this book to help our clients develop all types of products—computer hardware, computer software, automobiles, furniture, buildings, innovative consumer products, books, films, organizations, training courses, and research plans. Nobody yet has demanded money back, but we can't prove no client ever will, because we do not know how to make product development into an exact discipline.

Before working with us, many of our clients hoped that product development was an exact discipline. Many of those clients were in the software business—a business that has been plagued by ill-founded fantasies of an exact discipline for developing products. We like to quote John von Neumann because many of our clients consider him to be the foundling father of software. They pay attention when he says, "There's no sense of being exact about something if you don't even know what you are talking about."

If people don't know what they want, no development process—no matter how exact, how clever, or how efficient—will satisfy them. And that's why we do requirements work—so we don't design systems that people don't want.

Effectiveness always comes before efficiency. But even if efficiency is your hot button, the most important route to efficiency in development is to eliminate those products nobody wanted in the first place. Another way to put this is,

Anything not worth doing is not worth doing right.

Which brings us to "discover," the most critical word. In this book, we're trying to help people discover what's really worth doing.

Dwight Eisenhower once said, "The plan is nothing; the planning is everything." We agree, and we also extend the same thinking to the requirements process.

The product is nothing; the process is everything.

Or, put another way,

The discovery is nothing; the discovering (the exploring) is everything.

which explains the title, Exploring Requirements.

A data dictionary, for example, is a way of preserving the definitions that are painstakingly derived with the aid of some of the methods in this book. In practice, however, hardly anybody reads the data dictionary, or possibly any of the documents that are developed in the requirements process. That observation bothers some people, but not us because we believe that

The document is nothing; the documenting is everything.

If you watch how people really develop systems, you'll see that the process of developing requirements is actually a process of developing a team of people who:

  1. understand the requirements
  2. (mostly) stay together to work on the project
  3. know how to work effectively as a team

We believe that if one of these conditions is not met, the project will probably fail. Of course, there are many other reasons why a product development project might fail, and there are many books about methods to avoid such pitfalls. This book, however, will concentrate on these three critical but neglected human aspects of the requirements process:

  1. developing a consistent understanding of requirements among all participants
  2. developing the desire to work as a team on the project
  3. developing the necessary skills and tools for working effectively as a team to define requirements

Because these topics are somewhat neglected in the systems development literature, Exploring Requirements can be used as a supplement to any requirements process that you now use, formal or informal. Most of the chapters are designed as stand-alone modules, each presenting one or more tools or methods to enhance your requirements process. You can read the book from cover to cover, or read only the one chapter that's most needed at any given moment. Either way, it should help you do a better job of knowing what you're talking about.

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