< Zurück | Inhalt | Weiter >

11.7.3 Prototyping

Prototyping can be an effective way to carry on the discussion of both require- ments and user interface design. Given only a hypothetical or abstract descrip- tion of some software, it can be very difficult for people to imagine what the implications of its use will be. A simple prototype can immediately bring the discussion down to the concrete; people can point at things and say “I like this” and “I don’t like that” and “How would I do so-and-so” and then see whether or not it would work. Sometimes, ideas that sound great on paper turn out to be pretty poor ideas when realized. Prototypes can help you discover that quickly and easily.

One very useful but inexpensive prototyping mechanism can be HTML—that is, creating Web pages. Simple static HTML can be fast and cheap to build, but can begin to approximate what the user interaction will look like—especially for, but not only for, Web-based solutions. It may not be an exact replica of the final product, but for a first step it can really get the discussion moving.

If the UI is too complex for a Web page mock-up, you can still use HTML for prototyping by getting images (screenshots) of what you want your final solution to look like and then making these images clickable on Web pages, to simulate some simple user interaction with hyperlinked image sequences.

The idea is to get something “tangible” in front of people as soon as possi- ble, to further the discussion in a way that written descriptions never can. (“A picture is worth a thousand words.”)

Once you’ve built a prototype, shop it around. Hold informal meetings where you demonstrate the basic functions to stakeholders. We recommend, as much as possible, meeting with one group of stakeholders at a time. That way you can keep your conversations focused. If you have two different stake- holder groups represented and their expertise and interests are wildly different, you’ll be boring ½ the participants all the time. Even if their expertise is similar, you may have groups with competing or conflicting requirements. While you need to understand such conflicting requirements and eventually come to some detente, this meeting is not the best venue for settling those issues; it would more likely simply scuttle your meeting and void any value from it.


that Dale Carnegie is as important to the software designer as Yourden or Booch. Your users need to be your friends if you want to succeed.

After each meeting, review your requirements and see what more you need to add. Likely at such meetings, you’ll begin to get requests for new features.

You have, in fact, begun the iterative process. Even the most bare-bones prototype that may only consist of a sequence of pictures is a first cut of your product. The sooner you can get to a running version, the sooner you will be able to respond to stakeholder suggestions by adding real features.


A good requirement is one that states a need but not a solution. Your first step is to uncover the needs, while listening to everyone’s solutions. These require- ments will develop into feature descriptions. These should be documented and then prototyped. The prototype, which is in effect the first release of your product, can then be shown to various groups—stakeholders—as a way to elicit their feedback. This feedback should begin to factor in to what you will build, so now you need to move quickly on to building the real product; do not get stuck enhancing the prototype.


Writing good requirements is as much art as it is science, and it involves politi- cal science as well. This is not something easily taught in a book, but learned through hard experience.


One of the original purposes of the World Wide Web was to allow researchers to share their results. So, you should be able to search the Web for requirements documents from various projects for examples of requirements specification. As with any Web search, remember to consider your source. Just because someone has posted a requirements specification or a template doesn’t make it a good example.

Here are three examples that we found on a single simple Google search.

They may still be there by now.

11.11 Exercises 277





For those who are serious about their software development process, the Capability Maturity Model for Software from the Software Engineering Insti- tute at Carnegie Mellon University is the standard. Visit their Web site at http://www.sei.cmu.edu/cmm/.

If you would like to know more about the spiral approach to software de- sign, you might want to start with the seminal paper on the topic, “A Spiral Model of Software Development and Enhancement,” in Computer 21, no. 5 (May 1988), pages 61–72.

To see how the director of the Software Engineering Institute views the spiral approach, check out the short and readable introduction at http://www.dacs.dtic.mil/awareness/newsletteres/technews2-1/ disciplined.php.

Another good look at the spiral, or iterative, approach can be found at http://www.stickyminds.com/se/S3420.asp which has a hyperlink for a PDF file of a paper by Philippe Kruchten of Rational Software. The paper covers some pitfalls common to the first uses of the iterative approach; worth the read.

A great survey of key papers on three major approaches—spiral and related topics (including newer work by Boehm), aspect-oriented programming (AOP), and the rational unified process—is at http://www.rspa.com/reflib/ PrescriptiveModels.php.


1. Write requirements for a simple word processor or spreadsheet. Start with some obvious functionality. Add only enough “bells and whistles” for it to be usable for beginners. Show this list to others, especially people famil- iar with similar applications. What features do they find missing that are important to them? How quickly does your list expand? What might you do to limit the size and the rate of growth of the features list?

2. Discuss the requirements for your application with someone who has no experience with a similar product. How difficult is it to get useful feed- back? Now show them (the simple features of ) a working spreadsheet or word processor, as if it were your prototype. Does the conversation change? In what ways? Is the feedback now more or less useful than before they saw the prototype?