What is the requirements process?

There are many ways to develop the deliverables of a project. It is important that a procedure be established for each project that will ensure that all of the necessary deliverables of the project are found and that all unnecessary requirements are eliminated from the list of deliverables.

All of the stakeholders of the project must be considered in the development of the deliverables list. The deliverables of the project can come from many different sources. The client or customer and the user will usually have the bulk of the specified deliverables, but special care must be taken to avoid overlooking deliverables because of the other stakeholders.

The requirements process should identify at least 95 percent of the deliverables that will be required for the project. This will vary with the project. Projects that have a great deal of uncertainty associated with them, such as research and development projects, have more poorly defined deliverables. All projects have a certain amount of uncertainty associated with them. Depending on the uncertainty, it will be necessary to discover and define some of the deliverables as the project develops. This is called progressive elaboration.

Tell me more …

One of the greatest reasons for failed projects is poorly defined project deliverables. If the project deliverables are poorly defined at the beginning of the project, the budget and schedule will be understated. The resources for the project will be understated as well. While this simply makes the project a smaller project than it really is, the missing deliverables will be discovered at some point, and they will have to be provided. Now we are getting into the execution part of the project, and we have to add new requirements and find the budget and resources to do them.

There are many ways to arrive at the required deliverables list. Figure 2-7 suggests a process that has many of the characteristics of a good deliverables definition process.

Figure 2-7: REQUIREMENTS PROCESS

We begin by listing the needs and desires of the stakeholders. This is not too difficult, although it will take some time and will be a lengthy list. At this point we allow anything that anyone wants to become part of the "wishes and desires" list. Many of these items will be quickly eliminated from the project. For the proper care and feeding of the stakeholders, it is good to allow this kind of list to be created. It ensures that everyone has had a chance to state his or her favorite requirement.

Next we review the wishes and desires. We eliminate any of the items on the wishes and desires list that can be agreed to unanimously. If there is an objection, the item should remain on the list for the time being until further investigation can be made. The group reviewing the lists can be all of the stakeholders on a small project. On larger projects, review committees of specific stakeholders can be organized to review groups of items that are related. The result of this meeting or this series of meetings is the list of "needs".

The items that are on the list of needs now are investigated. Some items will require individual justifications while others will require minimal investigation. Regardless of the investigation that takes place, items that are excluded are documented as to why they have been excluded from the project. At this stage in the process, the items excluded as well as the items not excluded will have their descriptions elaborated to reduce any misunderstanding. The items that remain are the potential deliverables for the project. We will call them the "requirements".

The requirements are not the final deliverables of the project. For many reasons some of the requirements may be eliminated before the scope baseline is established. Until we establish the scope baseline, there is no requirement to process a change request through the change management process to add or delete requirements.