- Agility Guide
- Requirements Process in Context
- The Process
- A Case Study
- Trawling for Requirements
- Prototyping the Requirements
- Scenarios
- Writing the Requirements
- The Quality Gateway
- Reusing Requirements
- Reviewing the Specification
- Iterative and Incremental Processes
- Requirements Retrospective
- Your Own Requirements Process
- In Conclusion
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.
A prototype is a quick and dirty representation of a potential product—probably 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.