CMMI, Requirements and Traceability
We will continue our review of CMMI and requirements management practices. As we have seen in the earlier posts, managing the requirements is necessary for efficient development and doing so has positive impacts on the project as well. Specifically, the project benefits when the organization stands behind attaining the requirements, and is in for a rough road when this commitment to the requirements is in fact not there. At the very least if the organization is not backing the project, the project manager will understand the risks this presents to the project. The project also benefits from controlling the changes to the requirements. We are going to learn as we do the work and that learning will be mechanisms for product updates.
In this post, we are discussing being able to trace the top level customer needs through the system and to the detailed level requirements for the product or system. We reduce the turbulence the project encounters when we connect requirements to specific scope attainment. In the end, when the project goes to close out contractual obligations, it will be necessary to trace what is actually delivered to this customer need. However, even before that, this traceability will come in handy for the test and verification personnel as it will be easier to ascertain the severity of failures found during testing. This is important for the severity part of the failure report and is a prioritization mechanism for what faults to address first and which ones can be delayed in resolution or perhaps acceptable.
The degree of difficulty we may have closing the project, will be influenced by the degree of diligence we have taken in building the requirements along with a way of tracing the connections from the top level scope, that is the customer needs, and the minutia of details that are commensurate with the product or system under development. If you are the customer, you should expect to see this table or matrix. Without this table, you are unsure if the project is actually in a position to be closed. Experience also suggests that customers miss this need and close the contract without knowing what part of the work is actually delivered.
Pingback: Good Requirements Attributes - Value Transformation