|
"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: - understand the requirements
- (mostly) stay together to work on the project
- 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: - developing
a consistent understanding of requirements among all participants
- developing
the desire to work as a team on the project
- 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. | 
