The Prototyping Loop

Although you can employ a variety of techniques for prototyping, the same strategy applies to using any of them. This strategy consists of three prototyping activities: design and build, test, and analyze (Figure 12.11). Let's look at them in more depth.

Figure 12.11.

Prototyping begins with a "Requirement for experiment." This could be a single requirement, a product use case, or some hypothesis to be proved or disproved. The user tests the prototype, and the results are analyzed. Note the output of the Analyze process: "Potential requirements." The requirements learned from the test are recorded. Any needed modifications to the prototype are used to redesign and rebuild it. The process continues until the Analyze process ceases to reveal further requirements.

Design and Build

Design is the activity of deciding what you are trying to model with your prototype and what you are trying to achieve. The subject of the prototype may be a single requirement or (more likely) a product use case. Similarly, the prototype might be built to prove some idea, to disprove some idea, or for any other reason. For the sake of simplicity, we will assume you are prototyping a product use case. Now, what is the use case meant to achieve, and what are its functional outcomes? Once you have decided the functional outcome of the prototype, then that part of its design becomes clearer.

The other question is harder: What are you trying to achieve with this prototype? Are you looking for the functional requirements or nonfunctional ones such as usability, operational, or security requirements? Are you exploring a use case that is largely unknown, or are you building a prototype to confirm the requirements for a fairly well-understood piece of work? Are you trying to prove a proposed requirements is not workable? For any of these questions, consider how you will know when you have achieved your purpose. To put it another way, how will you measure the success of the prototype?

Also consider these issues:

• Identify the operational environment in which the product will eventually be used to do work. For example, it could be an office, a factory, a school, a laboratory, a family household, or a public building. (You might already have defined the environment in section 13, Operational Requirements, of your requirements specification.)

• Identify the stakeholders whose input you need to get information for this prototype. (You might already have defined these people in sections 2 and 3 of your requirements specification.)

• Decide how you will make clear to each person why you need his input and what advantage he will get from being involved in the prototyping effort.

• Plan how you will run each prototyping session. Will you work with the stakeholders, or will you leave the prototype with them and return when they have had a chance to assess it?

The answers to these questions provide you with the input needed to slant the design of the prototype to fit the particular situation. Designing is mapping the world of the user into the prototype. What artifacts does the user want represented in the prototype? What are the user's metaphors for this use case, and how does he see the product's contribution to the work that he is doing?

Designing is mapping the world of the user into the prototype.

We have already discussed building prototypes, so we will not linger on that part of the process. Suffice it to say that given today's high-fidelity prototyping tools and the wide variety of Low-Fidelity methods, the actual construction of the prototype is a relatively straightforward affair. This means you might be able to build your prototypes with your stakeholders present, and it should leave you more time to spend testing the prototype together.

Testing in the User Environment

In testing, the users and other stakeholders use the prototype as a simulation of their work while you objectively record their feedback.

The exact way you run the tests depends on the kind of prototype you are using and your objectives in using prototypes in the first place. Stakeholders can be left alone for some time to experiment with high-fidelity prototypes; later you can meet to discuss the results. You usually have to demonstrate the Low-Fidelity prototypes to the stakeholders, so the testing is more casual and the feedback is more interactive.

Include usability experts in your prototyping cycle.

We recommend that you include your usability experts in this kind of testing. It has been our experience that usability people are often not invited to become involved until the product has very nearly reached the production stage. It is assumed that only a few fine-tuning corrections to the usability aspects will be necessary to complete the product. However, this is far too late to consider this critical issue. Usability must be built into the product from the beginning, not bolted on at the last moment. We have included usability (section 11 in the template) for a very good reason: Usability is a nonfunctional requirement. That is, it is an integral part of the product and not an optional accessory that can be sprayed on like a last-minute paint job.

The objective of prototyping is to get feedback. Let's look at how we analyze this feedback.

Analyzing the Results

There are two things you are looking for with your analysis. First, you want to see whether the stakeholders uncovered any new potential requirements. Second, you want to determine whether it is worth modifying the prototype and running more tests.

Your aim in analyzing the prototyping results is to identify potential requirements and to determine whether it is worth modifying the prototype and running more tests in the user environment.

In Figure 12.11, note that one of the outputs of the analysis activity is a flow of requirements. When you examine the results of the prototype test, you are looking for requirements. Either the test confirms the requirements you thought were correct and built into the prototype, or the stakeholders discovered new requirements by using the prototype.

It is important you capture these requirements. The prototype is not sufficient by itself, because it is only a simulation of the specification. You still need to extract the real requirements; otherwise, you are left with prototyping code that may not convey the underlying requirements to the developer.

A prototype is not the same thing as a requirements specification; it is a simulation of the specification. You still need to extract the real requirements.

Sometimes your prototyping results may indicate that it would be worth modifying your prototype and conducting further tests with it. For example, the road engineers told us that they would like the IceBreaker product to identify roads in danger of closing; then they could make rescheduling decisions based on the seriousness of the closure.

The seriousness factor was something new, and its inclusion affected a number of other requirements. We decided that a good way of learning more about the potential new requirements was to modify the prototype and ask the engineers to test it again and provide more feedback.

Review the results of your prototyping. Are you still discovering new requirements? The number of potential requirements your analysis reveals is significant. Consider whether you have found enough requirements to make it worthwhile to continue modifying and testing that prototype. Or were there too many? If you have a truly large number of requirements, does it indicate that you may not know enough about the work situation? Would other methods be more appropriate to learn how the work should be done?

Is your prototyping effort still contributing to your stated reason for building the prototype? If the answer is yes, then you might decide to put more effort into modifying and testing the prototype. If your measurements indicate that you are learning less, then the prototype has probably served its purpose.

You are likely to go around the prototyping loop several times, each time getting a different result. Revisit your objectives and results each time.

When you build a requirements prototype, think of it as a technique for helping you learn about the requirements so the eventual product is based on real, well-defined user needs.