|
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 Objective | Rank
on Primary | | minimize core storage | 1 |
| maximize output readability | 1 | | maximize
program readability | 1-2 | | minimize statements | 1 |
| minimizing programming hours | 1 |
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). |
