Sometimes requirements analysts get stuck. Sometimes there are requirements that are not properly formed, or the user can't explain them, or the requirements analysts can't understand them. Or maybe the product is so groundbreaking that nobody really knows the requirements. Or the analysts and stakeholders just need to work with something more concrete than a written requirement. This is when prototypes are the most effective requirements technique.
A prototype is a quick and dirty representation of a potential productprobably only part of the product. It is intended to present the user with some kind of simulation of the requirements. There are two approaches to building requirements prototypes: high-fidelity prototypes use specialized software tools and result in a partially working piece of software, and Low-Fidelity prototypes use pencil and paper, whiteboards, or some other familiar means, as shown in Figure 2.4. Teams generally like using the Low-Fidelity prototypes because they can generate them quickly and the users enjoy the spontaneous nature and inventiveness of these prototypes. Figure 2.4.A Low-Fidelity prototype built on a whiteboard to provide a quick visual explanation of some of the requirements, and to elicit misunderstood or missing requirements.
|