Chapter 2. The Requirements Process

in which we look at a process for gathering requirements and discuss how you might use it

The requirements process described in this book is the product of our experience. We developed the Volere Requirements Process and its associated specification template from the activities and deliverables we have found effective over years of working on projects and consulting with our clients. The result of this experience is a requirements-gathering and specification process whose principles can be applied to almost all kinds of application types in almost all kinds of development environments.

Whether you are building custom systems, building systems by assembling components, using comercial off-the-shelf software, accessing open source software, or making changes to existing software, you still need to explore, understand, capture, and communicate the requirements.

We want to stress from the very beginning that while we are presenting a process, we are using it as a vehicle for finding requirements. That is, we do not expect you to wave the process around and tell your coworkers that this is "the way to do it." We do expect you will find many useful things to do within the process that will help you to gather requirements more productively and accurately. We are sure of this fact, because we have personally seen hundreds of companies adapt the process to their own cultures and organizations, and we know of thousands more that have done so.

A requirements process is not just for waterfall development. Our clients use XP, RUP, and many other acronyms, as well as traditional waterfall, incremental, and all flavors of agile development processes. Over the years they have agreed with us: If the right product is to be built, then the right requirements have to be discovered. But requirements don't come about by fortuitous accident. To find the correct and complete requirements, you need some kind of systematic process.

The Volere Requirements Process Model in appendix A contains a detailed model of all of the activities and the connections between them. The model is very detailed. Rather than getting involved in that kind of detail and complexity right away, let's stand back and take a simpler view of the overall process. This simplified view is shown in Figure 2.1.

Figure 2.1.

This simplified map of the Volere Requirements Process shows the activities and their deliverables. We have used a stylized data flow notation. When you are looking at this diagram, keep in mind that the process is iterative and evolutionary. Each activity (the bubbles) and its deliverables (arrows or documents) are explained in the text.

See appendix A for the complete Volere Requirements Process.

This simplified version of the process model will reappear at various places throughout this book. For the most part, the simplified version is faithful enough to the complete version in appendix A. Sometimes, for the sake of making an explanation simpler or clearer, we will make minor changes to the model or show only part of it. Please be aware of this and use the detailed model for any of your important implementation decisions.

Figure 2.1 shows all of the main activities in the Volere Requirements Process, including how they are linked by their deliverables. The deliverables are shown as moving from one activity to the next. For example, the Trawling for Requirements activity would probably gather the requirements for one business use case at a time. The requirements would be written to demonstrate that they have been correctly understood and agreed, and then passed to the Quality Gateway for testing prior to being included in the Requirements Specification. Any rejects would be sent back to the originator, who probably would take them back to the trawling activity for clarification and further explanation. Don't take this apparent waterfall approach too literallythe activities usually iterate and overlap before producing their final output. As we go through this process in detail, we will explain where and how iteration and incremental delivery can be used.