Prototyping the Requirements


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.

We look at innovative products in Chapter 5, Trawling for Requirements.


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.


Prototyping as a requirements-gathering technique is fully explained in Chapter 12, Prototyping the Requirements.


This part of the process is shown in detailed model form in Prototype the Requirements (Diagram 5) in the Volere Requirements Process model in appendix A.





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