This area of CMMI requirements management has big implications on the project.  Experience suggests project managers can get lost in the minutia of the work, but that is the connection to the project.  The reason we have taken on the project is to produce some result that is defined (or it should be) in the requirements.  Project work that does not support the requirements is work that may not be justified.  I say may not be justified, because there may be some elements in the project work that systematically support the scope.  I would not want to open the possibility for somebody to say, testing the product is not part of the product delivery.  That may be, but testing fulfills the system feedback role, are we delivering presently in a way that would allow us to predict success in the future.  At any rate, the project authorizes work to meet the objective defined in the scope, and supported in detail via requirements.

Requirements and Project Feedback

This specific practice serves as the control feedback loop for the project to monitor and then take subsequent controlling actions rather than blindly believe the plan will deliver to expectations.  With this process area, we will monitor key attributes, product, and project, using this information to guide our depending work and actions.  The CMMI standard describes the activities we take to learn and control.  According to the specific practices, the typical work products are[1]:

1. documentation of inconsistencies including sources, conditions, and rationale
2. corrective actions

When the work does not meet requirements.

The interpretation of the measurements will change the project execution and perhaps the project plan should we realize that our plan is incapable of meeting the demand. However, we will use this information to understand what we are doing that we should not be doing, that is, not part of the scope of the project.  There are studies from a variety of groups, The Standish Group 2014 chaos report, for example, listed Clear Statement of Requirements[2], in the top three reasons for project success as the opinion IT executive managers.  Without this clarity, the depending actions to meet the delivery expectation likewise will suffer from this lack of clarity.  Additional actions amount to gold plating or at best misdirection for the project and the product.

Monitor the gap between actions and objectives

To ensure the project results you desire, pay attention to the requirements and the work being performed presumably to meet the scope.  Do not do work that is not part of the project objective, and quickly identify instances where you may go astray, and make the necessary corrections.