The Book of Life begins with a man and woman in a garden. It ends with Revelations.—Oscar Wilde, A Woman of No Importance
The requirements process begins with ambiguity. It ends not with revelations, but with agreement. More important, it ends.
But how does it end? At times, the requirements process seems like Oscar Wilde when he remarked, "I was working on the proof of one of my poems all the morning and took out a comma. In the afternoon, I put it back again."
A certain percentage, far too large, of development efforts never emerge from the requirements phase. After two, or five, or even ten years, you can dip into the ongoing requirements process and watch them take out a comma in the morning and put it back again in the afternoon. Far better the comma should be killed during requirements than allowed to live such a lingering death.
Paradoxically, it is the attempt to finish the requirements work that creates this endless living death. The requirements phase ends with agreement, but the requirements work never ends until the product is finished. There simply comes a moment when you decide you have enough agreement to risk moving on into the full design phase.
Nobody can tell you just when to step off the cliff. It's simply a matter of courage. Whenever an act requires courage, you can be sure that people will invent ways of reducing the courage needed. The requirements process is no different, and several inventions are available to diminish the courage needed to end it all.
One of the persistent "inventions" to substitute for courage is some form of automatic design and/or development.
In automatic development, the finished requirements are the input to an automatic process, the output of which is the finished product. There are, today, a few simple products that can be produced in approximately this way. For instance, certain optical lenses can be manufactured automatically starting from a statement of requirements.
In terms of the decision tree, automatic development is like a tree with a trunk, one limb, no branches or twigs, and a single leaf (Figure 25-1). With such a system, finishing requirements is not a problem. When you think you might be finished, you press the button and take a look at the product that emerges. If it's not right, then you weren't finished with the requirements process.
Figure 25-1. Automatic development is like a tree with a trunk, one limb, no branches or twigs, and a single leaf.
No wonder this appealing dream keeps recurring. It's exactly like the age-old story of the genie in the bottle, with no limit on the number of wishes. For those few products where such a process is in place, the only advantage of a careful requirements process is to save the time and money of wasted trial products. If trial products are cheap, then we can be quite casual about finishing requirements work.
Automatic development is, in effect, nothing but requirements work—all trunk and limb. At the other end of the spectrum is hacking, development work with no explicit requirements work. When we hack, we build something, try it out, modify it, and try it again. When we like what we have, we stop. In terms of the decision tree model, hacking is not a tree at all, but a bush: all branches, twigs, and leaves, with no trunk or major limb (Figure 25-2).
Figure 25-2. Hacking is not a tree at all, but a bush—all branches, twigs, and leaves, with no trunk or major limb.
Pure hacking eliminates the problem of ending requirements work, because there is no requirements work. On the other hand, we could conceive of hacking as pure requirements work—each hack is a way of finding out what we really want.
Almost any real project, no matter how well planned and managed, contains a certain amount of hacking, because the real world always plays tricks on our assumptions. People who abhor the idea of hacking may try to create a perfect requirements process. They are the very people who create "living death" requirements processes.
Paradoxically, hacking and automatic development are exactly the same process from the point of view of requirements. They are the same because they do not distinguish requirements work from development. Most real-world product development falls somewhere between pure hacking and automatic development, which is why we have to wrestle with the problem of ending.
Even when we have every requirement written down in the form of an agreement, we cannot consider the requirements process to be ended. We know those agreements will have to change because in the real world, assumptions will change. Some people have tried to combat their fear of changing assumptions by imposing a freeze on requirements. They move into the design phase with the brave declaration,
No changes to requirements will be allowed.
Those of us who understand the nature of the real world will readily understand why a freeze simply cannot work. We know of only one product development when it was even possible to enforce the freeze. In that instance, a software services company took a contract to develop an inventory application for a manufacturer. The requirements were frozen by being made part of the contract, and eighteen months later, the application was delivered. Although it met all the contracted requirements, the application was rejected.
This frozen product was totally unusable because in eighteen months it had become totally removed from what was really required in the here-and-now. The customer refused to pay, and the software services company threatened legal action. The customer pointed out how embarrassing it would be to a professional software company to have its "freeze fantasy" exposed in a public courtroom.
Eventually, the two parties sat down to negotiate, and the customer paid about one-fourth of the software firm's expenses. At the end of this bellicose negotiation, someone pointed out how with far less time negotiating, they could have renegotiated the requirements as they went along, and both parties would have been happy.
The freeze idea is just a fantasy, designed to help us cope with our fear of closure. But we cannot fearlessly close the requirements phase unless we know there is some renegotiation process available. That's why agreeing to a renegotiation process is the last step in the requirements process.
Working out the renegotiation process is also a final test of the requirements process itself. If the requirements process has been well done, the foundation has been laid for the renegotiation process. The people have all been identified, and they know how to work well together. They have mastered all the techniques they will need in renegotiation, because they are the same techniques the participants needed to reach agreement in the first place.
The agreement about renegotiation must, of course, be written down, and this act itself may strike fear in some hearts. Another way to avoid ending requirements is to avoid written agreements at the end of the requirements phase. Some designers are afraid of ending requirements because the explicit agreements would make certain assumptions explicit. An example may serve to make this surprising observation more understandable.
While working with the highway department of a certain state, we encountered the problem of what to do about a particularly dangerous curve on one of the state highways (see Figure 25-3). In an average year, about six motorists missed the curve and went to their death over a cliff. Because it was a scenic highway, it was neither practical nor desirable to eliminate the curve, but highway design principles indicated that a much heavier barrier would prevent wayward cars from going over the cliff.
Figure 25-3. What should be done about this dangerous curve?
Building the barrier seems an obvious decision, but there was another factor to consider. Perhaps once every three years, with a heavy barrier in place, one of these wayward cars would bounce off the barrier into a head-on collision with an oncoming vehicle. The collision would likely be fatal for all involved.
Now, on average, the number of people killed with the barrier in place would be perhaps one-fifth of those killed without the barrier, but the highway designers had to think of another factor. When a solo driver goes over the cliff, the newspapers will probably blame the driver. But what if a drunk driver bounces off the barrier and kills a family of seven who just happened to be driving in the wrong place at the wrong time? The headlines would shout about how the barrier caused the deaths of innocent people, and the editorials would scream for heads to roll at the highway department.
So, it's no wonder the highway engineers didn't want anything documented about their decision not to build the barrier. They were making life-and-death decisions in a way that covered their butts, and they could protect themselves by taking the position, "If I never thought about it, I'm not responsible for overlooking it in the design." And, if it was never written down, who could say they had thought of it?
Most engineers and designers react to this story by citing similar stories of their own to prove, yes, indeed, there are decisions it's better not to write down. We believe, however, this kind of pretense is an abuse of professional power, an abuse not necessary if we remember the proper role of the requirements process.
It's not for the designers to decide what is wanted, but only to assist the customers in discovering what they want. The highway designers should have documented the two sides of the issue, then gone to the elected authorities for resolution of this open requirements question. With guidance from those charged with such responsibilities, the engineers could have designed an appropriate solution.
But suppose the politicians came back with an impossible requirement, such as,
The highway curve must be redesigned so there will be no fatalities in five years.
Then the engineers would simply go back to their customers and state they knew of no solution that fit this requirement, except perhaps for a barricade preventing cars from using the highway. Yes, they might lose their jobs, but that's what it means to be a professional—never to promise what you know in advance you can't deliver.
The purpose of requirements work is to avoid making mistakes, and to do a complete job. In the end, however, you can't avoid all mistakes, and you can't be omniscient. If you can't risk being wrong—if you can't risk being inadequate to the task you've taken on—you will never succeed in requirements work. If you want the reward, you will have to take the risk.
1. If you want to be a professional designer, consider first the task of designing yourself, especially so you have the courage to act professionally. Don't spend all your time working on the technical side of requirements work, or on facilitating what other people do. Spend at least half of your time working on yourself.
Pay special attention to ending the requirements process because fears of imperfection can lead you into endless cycles.
You know when you have reached the end when you have all necessary agreements in hand. Fear of ending has nothing to do with defining the end, except you will never end if you don't face your fear.
All the people involved in the work must agree you have reached an end, otherwise they will never stop making changes. You know they have agreed when they have committed to a renegotiation process.
Ending requirements work is much like ending a book—especially a book on as open a subject as requirements definition. There comes a moment when you still have more to say, much more, but you find yourself taking out commas in the morning and putting them back in the afternoon. At that point, you simply accept the risk of leaving some ideas imperfect and some revelations invisible. You make sure you haven't lost any written material, you gather your courage, and you stop.
Alexander, Christopher. Notes on the Synthesis of Form. Cambridge, Mass.: Harvard University Press, 1979.
Design is examined as a generic activity practiced along a continuum from self-conscious to self-oblivious. The design process is viewed as one that attempts to find a fitness between two entities: the form in question and its context.
Ashby, W. Ross. An Introduction to Cybernetics. London: Chapman and Hall, 1964.
Contains the early frameworks of cybernetic or feedback systems. It is quite useful for exploring the design process as a feedback system with the client and designer as information channels.
Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, N.J.: Prentice-Hall, 1981.
Provides raw numbers collected from a large number of completed software projects and suggests various metrics.
Brooks, Frederick P. The Mythical Man-Month. Reading, Mass.: Addison-Wesley, 1982.
An extremely informative report of experiences gleaned during the design and development of what was at the time one of the most complex systems created by human—OS/360. There are many lessons here for both large and small systems design.
Buzan, Tony. Using Both Sides of Your Brain. New York: E.P. Dutton, 1976.
The original, and probably still the best, reference on the subject of mind maps.
Carroll, Lewis, and Martin Gardner. The Annotated Snark. New York: Simon and Schuster, 1962.
This is Lewis Carroll's Hunting of the Snark, with extensive annotations by Martin Gardner. Don says this book doesn't really have anything to do with design (or does it?) but thinks everyone should read it anyway. Jerry thinks it's a book about how projects are done without understandable requirements.
Case, Albert F., Jr. Information Systems Development: Principles of Computer-Aided Software Engineering. Englewood Cliffs, N.J.: Prentice-Hall, 1986.
An excellent survey of the case for CASE through 1986, as well as a good introduction to the ideas of using computers to aid computer software development projects.
Conte, S.D., H.E. Dunsmore, and V.Y. Shen, Software Engineering Metrics and Models. Menlo Park, Calif.: Benjamin-Cummings Publishing Co., 1986.
A formal statistical treatment of software engineering metrics. Of use primarily in estimating software complexity, productivity, and cost.
Curtis, Bill, ed. Tutorial: Human Factors in Software Development. Los Angeles: TFF.F. Computer Society, 1981.
A valuable collection that contains a reprint of the Weinberg and Schulman article, as well as other seminal articles on software development in general, and requirements in particular.
DeMarco, Tom. Structured Analysis and System Specification. Englewood Cliffs N.J.: Prentice-Hall, 1978.
The classic book on using structured English to specify requirements for software development projects. It's well-written, and well worth reading.
— Controlling Software Projects. Englewood Cliffs, N.J.: Prentice-Hall,
1982.
Contains useful information for both managers and developers involved in the planning, organizing, and time- and cost-estimating of large software development projects.
Deming, W. Edwards. Out of the Crisis. Cambridge, Mass.: MIT Center for Advanced Engineering Study, 1986.
Deming has influenced many people on the relationship of requirements work to quality, promoting such topics as the measurability of preferences.
Doyle, Michael, and David Straus. How to Make Meetings Work: The New Interaction Method. Chicago: Playboy Press, 1976.
A small, readable, inexpensive book to hand out to people who haven't had much experience with, or hope for, productive meetings.
Edwards, Betty. Drawing on the Artist Within. New York: Simon and Schuster, 1986.
Based on recent research in dual brain function, this work provides a means for enhancing creative activity within oneself by taking the reader on a trip of visual experiences and other right-brain exercises.
Freedman, Daniel P., and Gerald M. Weinberg. Handbook of Walkthroughs, Inspections, and Technical Reviews, 3rd ed. New York: Dorset House Publishing, 1990.
Contains a wealth of information on technical reviews, including checking test cases, a list of dangerous words to look for, heuristics for inspecting documents, and extensive checklists for reviewing requirements. It's in a question/answer format for easy access to just the information you need.
Gause, Donald C., and Gerald M. Weinberg. Are Your Lights On? How to Know What the Problem Really Is, 2nd ed. New York: Dorset House Publishing, 1989. eBook editions can be linked through http://www.geraldmweinberg.com.
In this book, we have addressed many difficulties encountered in the art of problem definition. The book is light enough to serve as a catalyst between systems designers—the problem solvers—and clients and end users—the people with the problems.
Glegg, G.L. The Design of Design. Cambridge, England: Cambridge University Press, 1969.
—The Science of Design. Cambridge, England: Cambridge University Press, 1973.
—The Selection of Design. Cambridge, England: Cambridge University Press, 1973.
—The Development of Design. Cambridge, England: Cambridge University Press, 1981.
Gregory, S.A., ed. The Design Method. London: Butterworth, 1966.
The four books by Glegg and this one edited by Gregory deal with methods for solving problems associated with the design of complex systems.
Grosser, M. Gossamer Odyssey. Boston: Houghton Mifflin, 1981.
Gives an interesting description of how designers have combined the self-propelled requirement with air transportation.
Halprin, Lawrence. The RSVP Cycles: Creative Processes in the Human Environment. New York: George Braziller, Inc., 1969.
The author, an environmental designer and planner by profession, introduces a design approach to the modeling of creative production in the arts. He then extends the approach to areas of traditional design as a generic design tool.
Hanks, Kurt, Larry Belliston, and Dave Edwards. Design Yourself. Los Altos, Calif.: William Kaufmann, Inc., 1977.
This workbook playfully introduces the reader to many proven means of breaking mind-sets in the quest for more creative solutions and problem-solving approaches.
Hatley, Derek J., and Imtiaz A. Pirbhai. Strategies for Real-Time System Specification. New York: Dorset House Publishing, 1987.
The title of this book is just about the only ambiguous part. It's not about how to specify a system in real time, but how to specify systems that will have realtime requirements. It's outstandingly thorough at covering the formal parts of the process, which makes it an excellent pair with Exploring Requirements and its human orientation.
Jones, David E.H. The Inventions of Daedalus. Oxford: W.H. Freeman and Co., 1982.
Contains 102 well-illustrated, outrageous ideas for products including audible vertigo, silenced and subverted sound, tired light, smell amplification, magnetic fur, and non-Newtonian trousers. Written by a British scientist, it is an excellent starting point for any design project requiring large amounts of innovation.
Jones, J. Christopher. Design Methods. New York: Wiley-Interscience, 1980.
Discusses many specific solution approaches to design problems.
Keirsey, David, and Marilyn Bates. Please Understand Me: Character & Temperament Types, 4th ed. Del Mar, Calif.: Prometheus Nemesis Book Co., 1984.
Still the best reference on the Myers-Briggs Type Indicator, a method of understanding and dealing successfully with the various personalities you encounter in life, and in requirements work.
Koberg, Don, and Jim Bagnall. The Revised All New Universal Traveller. Los Altos, Calif.: William Kaufmann, Inc., 1981.
To quote the authors, "Design is the process of making dreams come true." Fantasy, ideation, and creativity are introduced as an important part of the design and problem-solving process.
Marca, David A., and Charles L. McGowan. SADT™ Structured Analysis and Design Technique. New York: McGraw-Hill, 1988.
The authoritative coverage of the subject of information systems analysis using the techniques pioneered by Doug Ross, who wrote the Foreword.
Martin, James, and Carma McQure. Diagramming Techniques for Analysis and Programming. Englewood Cliffs, N.J.: Prentice-Hall, 1985.
The most comprehensive survey of notations for information systems analysis and design, including decision trees and tables, flow charts, HIPO (hierarchic input-process-output) charts, Jackson diagrams, Nassi-Shneiderman charts, state transition diagrams, structure charts, and Warnier-Orr diagrams.
McKim, Robert H. Thinking Visually. Belmont, Calif.: Wadsworth, Inc., 1980.
Approaches are introduced to aid the problem-solver in dealing with problems in nontraditional, visually oriented ways. Concepts involving ambidextrous thinking, relaxed attention, pattern-seeking, autonomous imagery, and idea-sketching are discussed.
McMenamin, Stephen M., and John F. Palmer. Essential Systems Analysis. Englewood Cliffs, N.J.: Prentice-Hall, 1984.
An excellent all-round introduction to information systems analysis, especially good on the subject of how to analyze existing systems.
Osgood, Charles E., George J. Suci, and Percy H. Tannenbaum. The Measurement of Meaning. Urbana, II.: University of Illinois Press, 1957.
The source of the idea of a semantic differential, which is the progenitor of our user satisfaction test.
Perry, William E. A Structured Approach to Systems Testing. Wellesley, Mass.: QED Information Sciences, 1983.
A comprehensive book on testing information systems that contains a useful chapter on testing during the requirements phase.
Petroski, Henry. To Engineer Is Human. New York: St. Martin's Press, 1985.
Deals primarily with mechanical and structural systems and provides excellent examples of systems failures due to misinformation or lack of information.
Satir, Virginia. Making Contact. Berkeley, Calif.: Celestial Arts, 1976.
Virginia Satir knew more about how people could work together than anybody else we can imagine. This little book is about the way we cope with stressful situations and present ourselves to others. It's a good place to start the adventure of getting to know her work, and yourself.
Spradley, James P. Participant Observation. New York: Holt, Rinehart & Winston, 1980.
An outstanding introduction to participant observation—and a book that requires no background in the social sciences.
Weinberg, Gerald M. The Secrets of Consulting. New York: Dorset House Publishing, 1985. eBook editions can be linked through
http://www.geraldmweinberg.com.
A guide for anyone who offers advice at the request of other people. It contains, among other topics, a complete explanation of the Orange juice Test.
Becoming a Technical Leader. New York: Dorset House Publishing, 1986. eBook editions can be linked through http://www.geraldmweinberg.com.
Full of ideas on self-development as a technical leader, including how to lead product development work.
Rethinking Systems Analysis & Design. New York: Dorset House Publishing, 1988. eBook editions can be linked through http://www.geraldmweinberg.com.
Takes off where introductory books on systems analysis leave off. It contains information on black boxes, a complete discussion of optimitis and its cure, a fuller development of the Railroad Paradox, complete discussion of Wiggle Charts, and many practical ideas about observing and interviewing.
—and E.L. Schulman. "Goals and Performance in Computer Programming" Human Factors, Vol. 16, No. 1 (1974), pp. 70-77.
—and Daniela Weinberg. General Principles of Systems Design. New York:
Dorset House Publishing, 1988. eBook editions can be linked through http://www.geraldmweinberg.com.
Shows how many of the deep principles of systems design can be derived from the necessity for survival.
Williams, C. Craftsmen of Necessity. New York: Random House, 1972.
Many examples of indigenous design are introduced. This unself-conscious design process involves the end user as the designer. The design and implementation, indistinguishable from one another, are accomplished in an evolutionary, trial-and-error process. The resultant product, incorporating vast amounts of environmental information, is likely to be highly successful.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you enjoyed this Volume, you can find all Jerry's ebooks listed at the Smashwords Store:
http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg
Below are book titles and links to web pages where you can sample Jerry's books at no cost and, if you'd like, buy them at low eBook prices in formats for all e-reading devices, or your computer.
Below are book titles and links to web pages where you can sample Jerry's books at no cost and, if you'd like, buy them at low eBook prices in formats for all e-reading devices, or your computer.
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
More Secrets of Consulting: The Consultant's Tool Kit
Are Your Lights On?: How to Know What the Problem Really Is
Weinberg on Writing: The Fieldstone Method
How Software is Built (Quality Software, Volume 1)
Why Software Gets in Trouble (Quality Software, Volume 2)
How to Observe Software Systems (Quality Software, Volume 3)
Responding to Significant Software Events (Quality Software, Volume 4)
Managing Yourself and Others (Quality Software, Volume 5)
Managing Teams Congruently (Quality Software, Volume 6)
Becoming a Change Artist (Quality Software, Volume 7)
CHANGE: Planned & Unplanned (Quality Software, Volume 8)
Change Done Well (Quality Software, Volume 9)
An Introduction to General Systems Thinking (Volume 1)
Passive Regulation: General Systems Design Principles (Volume 2)
Active Regulation: General Systems Design Principles (Volume 3)
Rethinking Systems Analysis and Design (Volume 4)
The Psychology of Computer Programming
Exploring Requirements 1: Quality Before Design
Exploring Requirements 2: First Steps into Design
Perfect Software And Other Illusions About Testing
Roundtable on Technical Leadership
Roundtable on Project Management
Understanding the Professional Programmer
Can naive mathematicians foil a sophisticated master criminal?
Six special young people become a team to defeat an armed secessionist militia.
First Stringers cope with a dangerous Stringer from South America.
Will a young woman's talent win her the freedom she lost when she lost both hands?
Two young inventors confront the problems accompanying fame.
Successful inventors assist in protecting an abused Navajo inventor.
Jigglers: Aremac a Century Later
(FREE BOOK, Aremac Power sequel)
Two people from different cultures, each with incredible powers, team up.
Earth's smartest living entity befriends humans to save itself from other humans.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To the thousands of product and systems designers worldwide whose ingeniously clever, elegantly conceived solutions so often amaze us by solving the right problems, we dedicate this book. We hope it meets your requirements.
This work represents a collection of ideas that have been developed, refined, and tested through more than a hundred total years of consultations and workshops with such organizations as IBM, Pacific Telesis, McDonnell Douglas, Philips, and Ericsson, as well as many smaller companies, less well-known but also vigorous. We express our appreciation to these organizations for encouraging our work.
We also appreciate the special efforts of Patty Terrien for following the first rough notes, asking critical questions, and providing background material; Ken de Lavigne and Eric MLnch for disambiguating some of our greatest ambiguities; Stiles Roberts, Jim Wessel, and Janice Wormington for their diligence and suggestions on our first drafts; and Marty Fisher and Howie Roth for providing a steady stream of real designers with real problems. Very special thanks go to Judy Noe, who had the vision to see the true forest of the book amidst the tangle of trees.
But most of all, we would like to thank the thousands of participants in our workshops and classes for inviting us to share their personal and professional joys, frustrations, and insights.