If commitment to the requirements is a significant source of failure, it is followed close behind by the management of changes or additional requirements that come from doing the work.  Though many project managers may believe that once a project is underway, there shall be no changes; that is a myopic approach.  Change happens.  As we conduct our project we will learn as we learn we will update the expectation and details of our product via specifications and requirements documentation.  Our project life-cycle layout will facilitate this incremental and iterative approach to the product which will include the requirements. For example, in the automotive world, we typically have a project life-cycle that produces a variety of prototypes that increase in sophistication as we make progress and approach the final production iteration of the product.  We may have a first part that may be largely a mock up from which we will learn, update the specifications and then move to the next level of refinement.  As we produce a part, test and otherwise explore the part, we will learn things that the next iteration of the product will need to have incorporated.  We will update drawings, specifications, and other documentation and update the revision level and release these for the next round of work.  All of which will fall under our configuration and change management for the project.

We do not just increment these changes into the product, via some email or telephone call. We will review the consequences and impact of these changes and go through some type of approval process. Once we understand the impact, we will either choose to incorporate the change (approve) or reject the change (disapprove).  The CMMI standard describes the situation in which our requirements are well under control.  According to the specific practices, the typical work products are[1]:

1. Requirements status
2. Requirements database
3. Requirements decision database

With this approach we are able to trace the requirements and how these change over the course of the project and product development.  This can provide us with some indication as to the volatility of the requirements.  The ability to trace the requirements to scope and vice-versa provides us with a way to understand the consequences of a failure from testing. We are then able to trace what is found during testing all the way back to a specific part of the scope and make an informed decision on the severity of the impact, which leads us to the traceability portion of requirements management, coming up next.