Some of our readers would readily agree with the need to resolve the ambiguities in requirements, but they would argue the problem is not with the techniques, but with the technicians. In order to do a better requirements job, they would claim, remove the people from the process and instead use a methodology. Indeed, their preference would be a totally automated methodology, with no people in the development process whatsoever.
When we started teaching software development in 1958, there were few organized development methods. Today, however, packaged methodologies flood the market and almost everyone who develops software has some sort of organized process. For many years, computer-aided software engineering (case) and computer-aided design (cad) dominated the news, both promising to eliminate people from the process. More recently, the Agile movement seems to have rediscovered people, and they are seeing the need for a book about "people-oriented" tools to support their approach. But regardless of the approach, it must ensure everyone gets the right requirements, and gets the requirements right. Won't automated tools do the job without people? We think not, and the story of the Guaranteed Cockroach Killer will tell you why.
For many years, a man in New York made a living selling his Guaranteed Cockroach Killer through the classified ads. When you sent your check for five dollars, he cashed it and sent you the kit shown in Figure 1-1.
Figure 1-1. The Guaranteed Cockroach Killer kit. All you have to do is place the roach on block A and then strike it with block B.
The instructions read
1. Place cockroach on block A.
2. Hit cockroach with block B.
If you follow these instructions, you are guaranteed to kill the cockroach. By rights, there should have been a third instruction:
3. Clean up mess.
Quite likely, nobody ever needed the third instruction—which also meant nobody could collect on the iron-clad guarantee.
Now, what has the Guaranteed Cockroach Killer to do with automated tools? One case document told us case tools are comprised of three basic application development technologies:
1. analysis and design workstations to facilitate the capture of specifications
2. dictionaries to manage and control the specification information
3. generators to transform specifications into code and documentation
In our experience, "analysis and design workstations" resemble block A of the cockroach killer. "Dictionaries" resemble block B. If you can somehow figure out the specifications, the workstations will "capture" them and the dictionaries will "manage" them. Once these two steps are done, the generators will clean up the mess and provide your product.
These automated tools are guaranteed to do their job if you simply do your part. This book is about doing your part: getting the roach on the block, and convincing it to stand still long enough for you to deliver the crushing blow.
Whether it's roaches or requirements, the hard part is catching them and getting them to stand still. Generating the code and cleaning up the squashed roach are messy jobs, but in a different way than the first two steps. That's why we think you'll still need the tools described in this book. Not only that, but the better your automated tools, the more you'll need our people-oriented tools. Let's see why.
Without a doubt, formal methods—especially automated formal methods—have transformed systems development work. Today, we routinely watch our clients build systems in hours that would have taken weeks to build in 1958. Yet even though projects take a fraction of the time, developers still find themselves wallowing for years in other projects. Because there are now superior tools and methods, developers attempt systems they never could have been imagined in 1958.
Not only that, but within the same systems the problems most amenable to formal solutions are quickly eliminated, leaving a residue of "messy" problems not amenable to formal solutions. As a result of these two effects, the nature of the problem has been transformed, as suggested in Figure 1-2.
Figure 1-2. How methods change problems: First, problems amenable to formal methods are eliminated, leaving a higher percentage of "messy" problems. Then, because of the promise of the formal methods, ambition grows, leaving more problems of every kind.
People who have worked in product and systems development for many years have noticed this transformation in their own daily work. They spend less time on technical tasks and more time dealing with people, less time on small closed tasks and more time working on large ones that never seem to finish. Our work, as well as this book, is devoted to tackling those "messy" problems that the formal methods don't touch, as well as the more ambitious problems that arise from expecting too much from the formal methods.
Our methods have been applied in conjunction with many case and cad tools and many different formal methods of development. We've worked with information systems approaches such as Warnier-Orr, Jackson, Ross's SADT™, Yourdon- Constantine, Gane-Sarson, and a variety of Agile approaches. Even more, we've also used our tools with traditional engineering disciplines such as electrical engineering, mechanical engineering, architecture, and city planning.
An essential part of any method of developing systems is the notation, its own symbolic way of representing system ideas. In terms of our exploration metaphor, we would say there are many systems of map-making. In city planning, many of the maps are recognizable as conventional maps. In architecture, some of the maps, such as floor plans and sketches, are quite literal pictures of what they represent. Others, such as wiring diagrams and materials lists, are rather abstract. Renderings of machines and parts are maps, and so are tables of strengths of materials.
Figures 1-3 and 1-4 are two different maps of
the same process—writing and sending a letter. Figure 1-3 uses
pictures, and is easier to understand at one glance. The words in
Figure 14 prevent a quick and universal understanding, but also
avoid perhaps unintended implications the pictures may
convey.
Figure 1-3. A stylized map of the process of writing a letter. The graphic form of this map makes it easier to apprehend at a glance during a presentation, but may make it difficult to modify as changes are made.
Figure 1-4. Another map of writing a letter, in a notation that is less visual than Figure 1-3, but more amenable to modification.
For instance, the typewriter in Figure 1-3 is a manual typewriter, whereas Figure 1-4 leaves the nature of the machine open. If it were important that an electric typewriter be used, the notation of Figure 1-4 would allow us to write, "electric typewriter." In Figure 1-3, we would have to draw a different picture. Which notation is better? Although case proponents argue interminably, there is no one answer to this question because each notation shows the system in different ways. Therefore, each view can be useful, and even necessary.
Another important property of a good notation is that easily revised diagrams—not interfering with the fluidity of the requirements process. We wouldn't want to leave an overly rigid implication in the map just because it would be too much bother to change it. A good case or cad tool can really shine, by allowing us to keep the most current maps in front of us all of the time.
The particular symbols used in mapping systems are not as important as their proponents would have you believe. Although each notation has advantages, disadvantages, and a variety of tools for working with it, the most important tool for working with a map is the human mind. Consequently the most important quality of a map is everyone's ability to understand it.
Proponents of each notation claim their maps are "intuitive," and "easy to read." These statements are true in the same sense Chinese is intuitive—in Beijing. Virtually any notational system becomes intuitive after someone has spent weeks and months working with it. In requirements work, however, most of the participants will not be professional requirements writers, so they may be working with such maps for the first time.
In light of the "amateur" standing of most participants, at least some of the maps should be familiar to everyone without special training. When special notations must be used, plan for a familiarization period. There are several exercises for this purpose.
Exercise #1: Have each map presented by someone who does not know the notation. This exercise reveals ambiguities in the notation, but also reveals ambiguities in the specification itself.
Because each method shows and conceals different aspects, ideally everyone involved in the requirements work should know several methods of mapping.
Exercise #2: Ask each person to translate a map from one notation to another. In translating Figure 1-3 to Figure 1-4, the translator assumed the same typewriter was used for writing the letter and addressing the envelope. This assumption prompted a discussion, which revealed other assumptions about how the letter and envelope would be prepared.
Even better would be to use a case or cad system with several embedded notations plus the instant ability to transform a map from one notation to another. With such a system, the same maps could be presented in different ways so each participant could see a familiar form. On the other hand, a completely automatic process does not really substitute for exercises 1 and 2, which force more intimate involvement with the map and thus foster deeper learning.
Exercise #3: The most common method for addressing the problem of familiarization (when it is addressed at all) is delaying the start of requirements work until everyone has attended a course on the common notation. Although we applaud the recognition of this problem, we deplore the solution method. By the time everyone is scheduled, and then rescheduled because of changed plans, your requirements process will have lost all its momentum. Better to conduct the class as part of the requirements meetings, perhaps keyed to specific examples from the system being developed.
In exploring requirements, developers work with maps of requirements, not the requirements themselves. While working with a client in Sweden, we learned a useful rule that's taught to every recruit in the Swedish army:
When the map and the territory don't agree, always believe the territory.
When participants become entangled in formal systems development, especially when supported by automatic mapping tools, they sometimes forget the territory and begin to believe the map is the territory. For example, in using Figure 1-3, you might unconsciously assume the person performing the steps is a woman because the symbolic figure seems to be female. You might also assume only one person works on a step, and it is the same woman in each step, because the same symbol is used on the map.
Or, using Figure 1-4, you might assume the file copy must be developed in the same step as stuffing the envelope, which would preclude a system in which writing the letter produced the copy—as with a multi-copy printer. Figure 1-5 is another diagram in the same notation, showing a process in which the copy is produced in the same step as the letter-writing process.
Figure 1-5. Yet another map of writing a letter, in the notation of Figure 1-4, but with a different handling of the filing process. Both these maps may show more precision than was intended, as no specific manner of filing may have been implied.
Figure 1-6 shows a version of Figure 1-5 in another popular notation for describing processes. Some people believe that this notation is clearer than Figure 1-5, others believe the reverse. We believe that it's mostly a matter of taste, and experience with each notation. But most of all, it's a matter of purpose—what types of exploration are being done, and what types of errors are being targeted to avoid.
Figure 1-6. The same map as in Figure 1-5, but in a different notation. Here, nothing is implied about the devices used to accomplish the actions, such as the typewriter. Some people prefer the curved lines, and some the straight, but is the difference worth destroying a project over?
1. Another source of complexity in development projects is the desire of non-experts to be involved in the design of complex products. Most customers naturally prefer to learn as little as possible about product design, yet still have all their wishes met in the requirements process. When customers prefer to remain naive about the product design process, most of the burden falls on the notation—a lot to ask of a notation. The design complexity problem can be solved by creating a tutorial to convert a naive customers into an expert—but not if the customers doesn't want to invest that kind of effort.
2. Customers often turn away from the design process because the professional designers treat them in a patronizing manner. Remember, most participants are naive only about the development process, and are themselves experts in subjects about which the designers are naive. Such expertise is why their participation is essential. We're much more likely to have their full participation if we create an environment of shared expertise.
3. Methodology experts underestimate the difficulty of understanding their notations, which they believe to be "intuitive." To understand how difficult it really is to define an "intuitive" notation, consider the problem of designing universally understood international road signs.
4. When two sets of experts participate in the same requirements process, there's often a conflict about which notation is intuitive. Children reared in Paris think French is intuitive, but children reared in Montreal may think both French and English are intuitive. In the same way, experts often share a "first love" syndrome for notations. This first-learned-first-loved bias can be prevented in the same way bilingual children avoid a bias for one language. If you are teaching a notation, instruct your students in two at the same time. Do all maps in both notations, and compare the pair of maps explicitly.
5. Mastery of the notation may give one party dominance in the requirements process, while excluding those who haven't mastered the notation. To avoid political wars, you must devote attention to depoliticizing the language issue. Try following the Swiss example: All "first love" notations of participants are declared to be "official" languages of the requirements process. Every official document must be presented in all of the official languages before the process is considered complete.
6. Although this multilingual approach may seem burdensome, the Swiss example shows it can work if done in the right spirit. Indeed, in Swiss meetings, people from the "dominant" language group often present their ideas in the "secondary" languages, as a courtesy to the minority participants and as a strong indication of how much they value their participation. In our experience with requirements work, this multilingual approach always yields a more accurate definition of requirements as well as a more complete involvement of all participants.
7. Our colleague Eric Minch suggests a theoretical model: all descriptions of the designed system—including the various constituencies' requirements and satisfactions, the constraints and decisions, and the final specifications for implementation—can be considered statements in different "languages." In other words, instead of seeing all of these as different descriptions in a single language, we can think of them as the same description in different languages. The full design task then involves finding a way of translating among these languages, and the final product is such a translation strategy.
8. Minch 's idea stimulated us to recall "translation" is not quite the simple one-to-one task we often assume. Some translations are works of art in themselves, like Edward FitzGerald's English translation of The Rubaiyat of Omar Khayyam. Consider the famous quatrain:
A Book of Verses underneath the Bough,
A Jug of Wine, a Loaf of Bread—and Thou
Beside me singing in the Wilderness—
Oh, Wilderness were Paradise enow!
What part is original with Omar the Tentmaker, astronomer and mathematician from eleventh century Persia? What part has been added (or subtracted) by FitzGerald, the nineteenth century Suffolk gentleman? What part has been added by us, in reading?
9. Experiencing the final product, we don't so much care if it's an exact translation, but only whether we like the product. This verse reminds us: value can be added at any stage of the product development cycle. Requirements are merely a guide. They are to be taken literally, but not too literally. There are many roads to Paradise.
10. These observations connect directly with a remark by Ken de Lavigne, our colleague at IBM: "Your discussion of maps brings out the great problem introduced by 'stepwise refinement' approaches: although they claim to postpone decisions until the time comes to make them, in fact the most far-reaching decisions are made first, when one has the least amount of information." Always be prepared to go back and revise the "translation," or "map," when further exploration shows there was a wrong branch higher in the decision tree. To do this, let go of the idea of the "one right way," or "the perfect translation."
"Exploring" comes from the idea of working with maps of requirements, not the requirements themselves. People explore to make maps, and eventually create a map close enough to the territory to represent it for "practical" purposes.
Always work with maps, not with the territory itself, and so always work to ensure common understanding of the various maps used. The question, "Could you please explain your notation?" is always in order in the requirements process, and nobody should be made to feel foolish or uncooperative for asking it.
Mapping is not so much a process as it is an awareness and a commitment to clear communication. To avoid communication problems, consider the following:
1. Don't leave all the hard parts to be handled by someone else, as in the Guaranteed Cockroach Killer kit.
2. Be prepared for changes introduced by new methods, and especially don't underestimate the difficulties for some people in adapting to new methods and new notations.
3. People are different, so each mapping technique will appeal in different ways to every participant. Accept these differences. Don't try to force people to conform, nor belittle them for being "stupid."
4. Instead, make sure at every step that everyone can read the map so you don't exclude anyone.
5. If you find yourself growing touchy about notational nuances, remember the map is not the territory and there's no such thing as a perfect translation.
Everybody uses maps, though not everybody is equally facile with each system of mapping. Those who are more facile have the responsibility to assist those who are less so—and not in a condescending way.