high-fidelity Prototypes

high-fidelity prototypes are built using software tools and have the appearance of working software products. They appear to do whatever the use case does, and they display most of the characteristics of working software products. Development of such a prototype gives stakeholders the opportunity to "use" a realistic-looking product and decide whether the product displays the correct requirements.

Because the prototype behaves as the stakeholders would expect the final product to behave, it gives them the chance to explore the potential of the product, ideally leading them to suggest improvements and new requirements. But herein lies a problem: Because the prototype looks so much like a working product, the stakeholders may be tempted to concentrate on its appearance and possibly forego making functional improvements. To do so would defeat the purpose of requirements prototyping.

Putting aside the slight risk of stakeholders misunderstanding their role in the prototyping activity, the high-fidelity prototype has a lot to offer. It is interactive, which encourages the user to explore. The icons and data displayed on the screen are representative of the data and icons used to do the actual work. The stakeholders should feel at home with the prototype: They can open windows, update data, and be told whether they have made an error. In other words, the prototype simulates the real work.

The requirements analyst creates lifelike work situations, then asks the stakeholders to operate the prototype as if they were doing real work. By observing the stakeholders' reactions and noting their comments, the analyst finds even more of the product's requirements.

"Prototypes are requirements bait."

Source: Steve McMenamin

Prototyping has a beneficial effect on the discovery of requirements that otherwise might be missed. The high-fidelity prototype, because it is more detailed than the Low-Fidelity version, gives the stakeholders greater opportunities to explore all the possibilities for the use case. For example, stakeholders may explore the exception and alternative paths: "What happens if no more trucks are available, but some of the trucks have been scheduled to treat secondary roads?" "Can I bypass the parameter stage or set up a default set of parameters?"

An extensive set of high-fidelity prototyping tools is available to the requirements analyst. In many cases, the tool indicates how you should go about collecting your requirements. Tools can be of the interface builder types, which incorporate functionality to easily build screens and simulate functionality. Many of these tools are backed by a database, thereby enabling you to construct small to medium-size working applications.

Slightly more formal in their application are programming languages such as Visual Basic, REALbasic, and Perl. They can also be used to quickly construct lifelike prototypes. In some cases prototypes built in these languages go on to become the working product, but that is not the initial intention of the requirements prototype.

Content management systems such as Mambo and Drupal allow prototyping of Web-based products. These tools are more than just prototyping toolsthe final result may be the full-strength version of the product. Care must be taken to ensure the requirements for the other aspects of the productsecurity, maintainability, and so onkeep pace with the front end as it is being prototyped.

We will not attempt to list all products that could be used for high-fidelity prototypes. Any such list would be out of date before you picked up this book. We suggest searching the Web and, in particular, the open source community (sourceforge.net) as the best resource for software suitable for requirements prototyping.

The high-fidelity prototype is effective for discovering usability requirements. As the user attempts to work with it, the analyst observes which parts of the prototype are pleasing and easy to use, and which usability features need improvement (see Figure 12.7). The user's actions thus provide input to the usability requirements.

Figure 12.7.

The high-fidelity prototype is a faithful demonstration version of the proposed product. This example shows a screen shot from Mambo (used with permission), an open source content management system. Users are invited to log on the demonstration site and alter the prototype as they wish, thereby demonstrating the ease of using such products for prototyping.

In addition to analyzing the feedback you get from stakeholders, consider the designer's contribution. Any good designer will likely have something to say and ideas to contribute to the prototype. Designers, being the people they are, are usually happier working with real and visual objects than with abstract concepts. They typically see the prototype as a natural artifact that they can try out and improve. By showing your prototypes to your designers, you almost certainly will benefit from their ideas.

Also consider the value of a high-fidelity prototype when you are developing a product for the mass market. In this situation, the prototype serves as a vehicle for soliciting feedback from customer representative groups. Your potential customers will voice their preferences and explain whether your product is something they are willing to buy. At the same time, the high-fidelity prototype is useful for making realistic comparisons with competing products. Your product must match, and preferably beat, anything available elsewhere.