Chapter 12. Prototyping the Requirements

in which we use simulations to help find requirements

One of your authors, Suzanne, recently bought a phone to replace one that had decided to stop working. Time was pressingshe was trying to catch a train to a client meetingand as the brand of phone was known to her, the device never came out of the box before she produced a credit card, took delivery, and rushed to catch the 08:15 to Reading. Once settled into her seat on the train, she lifted the phone out of its box. The phone had all of the attributes advertised on the outside of the box, looked impressively smart, and functioned perfectly except for one thing: Several of the buttons were too small to use. Suzanne has average-sized hands and is quite dexterous, but the phone refused to be turned on or answered except by stabbing the buttons with surgical precision and a sharp instrument. On her return from the client the phone shop was still open and she was able to exchange the phone for an adult-hand-friendly model, but the question lingered: Why didn't this fairly straightforward requirement come to light prior to manufacture? Didn't anyone with adult hands try dialing using a prototype?

"By acting out their real work in the prototype, customers can make their unarticulated knowledge explicit. Fleshing out the prototype with the customers' own data and work situations gives them the touchstones they need to put them in the experience of doing the work."

Source: Hugh Beyer and Karen Holtzblatt, Contextual Design

Think about all those requirements your client requested after delivery of previous productsthe subtle little ones that seemed so obvious after the event. Why weren't they discovered earlier? The answer usually is that the potential users could not envision those requirements. Or, to be brutally honest, they were not given the right opportunity to envision the requirements. Prototypes help people to "see" their requirements when a text specification might not.

"Prototypes can reduce creeping requirements by somewhere between 10 percent and 25 percent."

Source: Capers Jones

We want to emphasize one point at the outset: We are talking here about using prototypes as a way of eliciting requirements from the stakeholders. We are not talking about using prototypes as a design tool, even though your designers may use them later for such purposes. The cool interfaces, the eye candy, the good-looking windows and panes are not the issue. Requirements prototypes are used to help your stakeholders understand and communicate the product's requirements. And, of course, they allow you to experiment and invent. Requirements prototypes should be seen as a trawling technique. You are gathering requirements, but in this case you are using prototypes to help elicit the stakeholders' needs. See Figure 12.1.

Figure 12.1.

During the trawling activity, some requirements may not be clear, or you may feel there is a need to experiment with them. The prototyping activity builds simulations of possible products and tests these models on the users. The intention is to give the users the opportunity to work with something real, and thus to have a better idea of what they need to do their work. The requirements discovered by this process are treated the same way as the requirements discovered by trawling techniques.

Sometimes when you are using a productbe it a hairdryer, a personal organizer, or a word processoryou may discover additional requirements:

• "I wish that this hairdryer had completely variable speeds, rather than just two."

• "I would like the organizer to dial the phone for me."

• "I want to 'save as' to the client's ftp site."

Requirements often do not emerge until someone actually uses the product. But by then it is too latethe product already exists. The objective of requirements gathering is to find the requirements before the product is built.

Prototyping is an adjunct to the other requirements-gathering techniques we discussed in Chapter 5, Trawling for Requirements. It is particularly useful in the following situations:

• The product has not existed before, and it is difficult to visualize.

• The stakeholders for the product have no experience with either the kind of product or the proposed technology.

• The stakeholders have been doing their work for some time and are stuck in the way that they do it.

• The stakeholders are having trouble articulating their requirements.

• The requirements analysts are having trouble understanding what is required.

• The feasibility of a requirement is in doubt.