Defect per Requirement
This report shows how defects relate to project requirements. Larger numbers of defects on some requirements might indicate problems with the specification, design, or implementation of that requirement. It might also help with the decision to drop a requirement with too many associated defects if the requirement is low priority. Similarly, defects on a high priority requirement might warrant reassigning resources from lower priority work.
Release Readiness (Requirement)
This chart shows the number of Requirements currently with status "Approved" or "Proposed", categorized by Priority for each requirement type. Requirements with these status values are assumed to not be completely implemented. The number of requirements shown should decrease over time, as work progresses on the project. If the number of unimplemented requirements (especially those with Priority = "Must") does not decrease towards zero late in the project, then the project might not be ready for release because it has not implemented all of its requirements.
Requirement Delivery
This report shows how many Requirements were implemented and how many remain to be done. The number implemented should start small and grow over time, while the number remaining should decrease. Having too many requirements that have not been completed late in the project might indicate a problem.
Requirement List
This report shows selected details for each requirement.
Requirement Volatility Churn
A set of relatively stable requirements makes any project easier. However, requirements do change during the course of a project. Recognizing the amount of change is essential to managing the project. Generally, changes are easier to deal with early in the project, so look for the lines to decrease over time. An upward slope or large number later in the project might indicate problems.
Requirements Distribution
This report shows the number of requirements for each Status, Priority, and Stability. As the project progresses, the number in the initial statuses, such as "Proposed" should decrease and the number in later statuses, such as "Incorporated" should increase. Otherwise, some requirements might not be satisfied. Look for a reasonable distribution by priority and stability. Not everything can be high priority, and too many "Low" Stability might indicate a problem.
Requirements Traceability Matrix
This report categorizes requirements from IBM® Rational® RequisitePro® by type. For each requirement, it shows related requirements and activities.
Requirement and related UCM Activities
This chart shows how much work is being done on each requirement. Look for requirements that have significantly more or less than expected or other requirements. This might result from the relative difficulty of the work, or might indicate that the work was mis-estimated or is not being done efficiently.