Adapting the Process

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.

The complete Volere Requirements Process model is in appendix A.

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:

• What is the deliverable called within your environment? Refer to the definitions of the terms used in the generic process model and identify the form of the equivalent deliverable in your organization.

• Does your current name for the deliverable facilitate communication, or would changing it help clarify any misunderstandings? For example, many projects have a deliverable called "high-level requirements," but no two people seem to have the sameidea as to what "high-level" means. This loose terminology results in an enormous amount of wasted time.

• What is the deliverable used for within your environment? If the deliverable does nothave an agreed-upon purpose within your project, and if that purpose does not havea quantifiable benefit, then omit it from your process.

• Does the deliverable have to be a physical artifact? Can it be trusted to be remembered without recording it?

• Who produces the deliverable? Specify which parts of the deliverable are produced by whom. Also, when several people are involved, define the interfaces between their work.

• When is the deliverable produced? Map your project phases to the generic process.

• Where is the deliverable produced? A generic deliverable is often the result of fragments that are produced in a number of geographical locations. Define the interfaces between the different locations and specify how they will work.

• Who needs to review the deliverable? Look for existing cultural check-points within your organization. Do you have recognized stages or phases in your projects when peers, users, or managers review your specification?

• Now turn your attention to the generic processes that produce the deliverables. How do they fit into your project? You might already have done a great deal of this thinking by examining the deliverables; this examination is simply a double check of your earlier work.

• To summarize the answers to the preceding questions, create a rough sketch of the process model and relevant detail levels for your project. Use this sketch to help plan who does what and how they communicate with each other.

• When you discover deliverables that are already effectively produced by your current process, retain those parts of your process and use the generic process to improve or replace the parts where you discover problems.

• Question any existing procedures. Is there a good business reason for each activity that touches this deliverable?

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.