Prototypes and Reality


When gathering requirements, you are asking your stakeholders to imagine what they need their future product to do. The results you uncover are limited by the stakeholders' imaginations and experiences, and by their ability to describe something that for the moment does not exist.

In contrast, a prototype gives the stakeholder something real, or at least something that has the appearance of reality. The prototype makes the product real enough for stakeholders to bring up requirements that might otherwise be missed. Our colleague Steve McMenamin refers to prototypes as "requirements bait": When stakeholders see the functionality displayed by a prototype, it inspires them to raise other requirements. In this way, by demonstrating possibilities through prototypes and giving stakeholders a seemingly real experience, you capture the additional requirementssometimes there are quite a lot of thesethat might otherwise have waited until the product was in use to come to the surface. See Figure 12.2.

Figure 12.2.

A requirements prototype is used to display the functionality of a potential product. The prototype's purpose is to prompt stakeholders to tell you whether you have understood the needed functionality and, as a result of "using" the prototype, to give you additional requirements suggested by it.


Prototypes are also used to play out the consequences of requirements. You inevitably come across those strange requirements that have a single advocate who swears he would be lost without it. Who knows whether his requirement is a great idea that will make the product better or merely a complex way of doing something that doesn't need to be done? The prototype does. Building a prototype of hard-to-fathom requirements makes them visible. It gives everyone the opportunity to understand them, discuss them, possibly simplify them, and then decide whether their merits warrant their inclusion in the final product.

The prototype makes the product real enough to prompt stakeholders to bring up requirements that might otherwise be missed.


As noted earlier, the prototypes discussed here are throwaway prototypes; they are not intended to evolve into the finished product. Of course, they might, but that is incidental to the requirements gathering. Requirements prototypes are intended to help elicit requirements. They are created to get feedback from the stakeholders and to generate new requirements.

A prototype is a simulation. It attempts to appear as if it is a product that the stakeholders could use to do their work. But not the work that they have been doing in the pastinstead, the prototype models the work that you envisage they might do in the future if given the help of the product that you are demonstrating. You show your stakeholders a prototype of a product possibly several alternative prototypesand ask if they could do their job using a product something like the prototype. If the answer is yes, then you capture the requirements demonstrated by that version of the prototype. If the answer is no, then you change the prototypes and test again.

Which aspects of reality are uppermost in the minds of the people you are dealing with? Which metaphors do they use for their work, and how do they envision themselves while they are doing their work?


The stakeholders who must decide whether your prototype is a reasonable demonstration of the proposed work face a somewhat difficult situation. They bring to the prototyping exercise some work-related baggage. They have been doing their job for some time (you probably wouldn't be asking them to test your prototypes if they hadn't), and their perception of their work may be very different from yours. This difference in perspectives requires tact on your part to discover which aspects of reality are uppermost in the minds of the people you are dealing with. Which metaphors do they use for their work, and how do they envision themselves while they are doing their work? On top of this, you are asking them how they feel about doing different workthe work that you are proposing for the future. Adopting the new product could mean jettisoning artifacts and ways of working that they feel quite comfortable with. It is no easy task for the stakeholders to turn away from their experience and their comfort, and to accept a new, as-yet-untried way of doing their work.

Build a prototype that relates to the physical anchors in the user's world.


The lesson is clear: We must always try to use prototyping techniques that conform, in some way, to the artifacts and experiences that are most familiar to the stakeholders. This means adjusting your prototyping approach for each work situation.

Let's look at some of the possibilities available for requirements prototypes. We can then talk about how they might be gainfully employed. We'll start with the simplest option: the Low-Fidelity prototype.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net