The Volere Requirements Process Model


This requirements process model is organized as a hierarchy of processes. To find more about the details of a process, look at the diagram or process notes with the same number. For example, the Requirements Process Model Summary (the first diagram) includes a process (number 1) called Project Blastoff. Diagram 1 will show you more details about this process. When you look at Diagram 1, you will see that it contains processes 1.1, 1.2, and 1.3. To find the details of each of these processes, look at the diagram or process note with the same number. At the end of the model, a dictionary specifies the terms used in the model.

This is a model of the generic processes necessary to elicit, specify, and review requirements. The model focuses on content. The dependencies between the processes are defined by the interfaces. This model does not imply any sequence, but rather is an asynchronous network. Any combination of processes can be active at any time.

Making This Work for You

Suppose that you want to make improvements to the way that you discover and communicate requirements. but you are not sure where to start. Clearly, you do not want to change everything. You need to identify where you would realize the greatest benefits. Here's how you can use the model to help you do that.

Start with the process model summary and concentrate not on the processes but on the flows of information. For each flow of information, ask these questions:

  • Do we have this information defined in our project?

  • Who are the stakeholders who originate this?

  • Who takes responsibility for it?

  • Are there other stakeholders who should be involved?

  • How do we record it?

  • Do we have anything missing (refer to the definition of the flow to help here)?

  • Are there any negative impacts from the way that we are gathering or communicating this information?

  • Is there any way we could minimize fragmentation of this information flow?

  • Are there benefits in making a change?

  • Does the change involve procedures, job specifications, or training?

When you discover flows that you think you would benefit from changing, then delve deeper into the generic process for hints on how to make appropriate and effective change to your own processes. Your improvement might be a combination of things like these:

  • Add a new procedure

  • Change an existing procedure

  • Involve different stakeholders at different stages

  • Communicate knowledge in a different form

  • Replace or refine one of your existing documents

  • Provide training and coaching

  • Adopt different trawling techniques

  • Partition the work more functionally

  • Formally define and track a project goal

The list of possibilities is a long one, but all of them are contained in the process model.

The process model is a summary of all the things that you need to dosomehow or other, to some degree of detailto discover and communicate requirements. The model is intended to provide a requirements process that you can use to improve your own environment. When you tailor the model, you synchronize it to your own environment by repartitioning it to add checkpoints (reviews, milestones) that are suitable for your environment and by identifying who will be responsible for carrying out each process. You also package the interfaces in the form that suits the way that you work.

Finding More Information

The chapters in this book contain additional information about all the subjects covered in the process model.

Diagram 0. Requirements Process Model Summary


Diagram 1. Project Blastoff


Diagram 1.1. Prepare for Blastoff Meeting





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