As we mentioned earlier in this book, the Volere Requirements Process is a distillation of experience from many different projects that built different products in different countries under different circumstances. The process provides a source from which you can select the parts that apply to your particular project. We have found the most effective way to adapt the process is to focus on the deliverables. This adaptation reflects what quality and quantity of each deliverable you need, what form the deliverable should take, who should produce it, and how it should be reviewed.
Look at the process model in appendix A, and specifically at the generic deliverables produced by the process. In particular, examine the interfaces between the processes on Diagram 0 of the process model. For instance, between the processes called Project Blastoff and Trawl for Knowledge is an interface representing a deliverable called Work Context. When you adapt the generic process, you decide how this deliverable (and all other deliverables) are produced by your project. Sometimes this deliverable is produced by a number of people, possibly working in a number of locations. In that case your process must define who will do what and how you will keep track of the pieces and fit them together.
If you have a current process for producing requirements specifications, then sketch out a rough model of your current process to help get your thoughts in order. Mark any areas where you would like to make improvements to this model. Your aim is to discover where and how you would most benefit from changes to your way of specifying requirements. If you have a current process for producing requirements specifications, then sketch out a rough model of your current process to help get your thoughts in order. Review this model, marking any areas where you know you would like to make improvements. To begin, concentrate on the deliverables on Diagram 0 of the generic process model; these deliverables, which are at a summary level, provide a way of talking about the big picture. When you are considering the overall requirements process, you identify those parts of the process where you think it will benefit you to explore the deliverables described in the detailed lower levels of the model. For each deliverable, consider how each one would best be produced within your projectenvironment using your resources:
An important issue when designing a process to fit your project is to consider your needs for the publication of the requirements specification. Some of these needs mightbecome clear to you when you are reviewing the activities in your process. However, we find it is a good way to discover misunderstandings is to ask, "When and why do we publish the requirements specification?" We shall look at this issue later in this chapter. First, however, let's consider how you might store your deliverables. |