- The Requirements Process in Context
- A Case Study
- Project Blastoff
- Trawling for Requirements
- Quick and Dirty Modeling
- Scenarios
- Writing the Requirements
- Quality Gateway
- Reusing Requirements
- Reviewing the Requirements
- Iterative and Incremental Processes
- Requirements Retrospective
- Evolution of Requirements
- The Template
- The Snow Card
- Your Own Requirements Process
- Formality Guide
- The Rest of This Book
This chapter is from the book
This chapter is from the book
This chapter is from the book
Quick and Dirty Modeling
Models can be used at any time in the Volere life cycle; in Figure 2.1, we show this activity as “Prototype the Work.” There are, of course, formal models such as you would find in UML or BPMN, but a lot of the time business analysts can make productive use of quick sketches and diagrams to model the work being investigated. One quick and dirty modeling technique we should mention here is using Post-it notes to model functionality; each note can be used to represent an activity, and the notes can be rapidly rearranged to show different ways the work is done or could be done. We find that stakeholders relate to this way of modeling their business processes, and are always willing to participate with hands-on manipulation of the Post-its to show what they think the work should be. We discuss this kind of modeling more fully in Chapter 5, Investigating the Work.
){kind=link}
In Chapter 8, Starting the Solution, we examine how you move into an implementation of the requirements discovered so far. At this point, your models change from being something to explain the current work, to something to explain how the future product will help with that work.
We can now start to refer to this type of model as a prototype—a quick and dirty representation of a potential product using pencil and paper, whiteboards, or some other familiar means, as shown in Figure 2.4. Prototypes used at this stage are intended to present the user with a simulation of the requirements as they might be implemented. The IceBreaker business analysts sketch some proposed interfaces and ways that the needed functionality might be implemented—this visual way of working allows the engineers and other stakeholders to coalesce their ideas for the future product.
)
Figure 2.4. A quick and dirty prototype built on a whiteboard to provide a rapid visual explanation of how some of the requirements might be implemented, and to clarify misunderstood or missing requirements.