Metrics derived from CR Register
CR metrics normally define the Requirements Stability. The following formula is used to compute Requirements Stability –
(Total number of requirements – number of CRs) / Total number of requirements
Another metric normally derived is the amount of relative effort (as a percentage) spent on resolving CRs using the formula below:
(Total effort spent on resolving CRs / Total effort spent on the project) X 100
Other metrics analysis that is carried out is the categorization of changes into various categories so that the origin of changes can be determined and draw inferences to find if any trend is emerging. Look at these possibilities:
Suppose that the bulk of CRs show that coding is the reason; then the organization realizes that additional training for coders is necessary
Suppose that bulk of CRs show that understanding of customer requirements was not satisfactory; the organization realizes that Analysts need to be trained in effective requirements for solicitation / elicitation / development
Suppose the bulk of CRs resulted due to defective design; then the organization realizes that software designers / architects should be improved.
And so on.
The resolution of analysis findings from CR Categorization, could be improved through:
Better software development process and procedures
Better standards and guidelines for coding, design, architecture, review etc.
More rigorous implementation of conformance and investigative audits
Progress / status reporting of CRs
Normally the status of implementation, progress of CR resolution and CR metrics are normally reported through Weekly Status Reports to the concerned executives for the purpose of records; and senior management intervention, where necessary or warranted.