Accession Number:



White Paper: A Defect Prioritization Method Based on the Risk Priority Number

Descriptive Note:

White paper

Corporate Author:


Report Date:


Pagination or Media Count:



Most software systems have some defects that are identified by users. Some of these are truly defects in that the requirements were not properly implemented, some are caused by changes made to other systems, still others are requests for enhancements that would improve the users experience. These defects are generally stored in a database and are worked off in a series of incrementally delivered updates. For most systems, it is not financially feasible to fix all of the concerns in the near term, and indeed some issues may never be addressed. The government program office has an obligation to choose wisely among a set of competing defects to be corrected, especially in a financially constrained environment. Selecting the best set of fixes for the next incremental release is a difficult chore as there are many possible ways to prioritize the work. The release may be selected from defects that focus on the workflow of select system users. Since there may be distinct user groups, this method may generate conflict when a high-priority deficiency report is of great importance to one user community and fails to address the concerns of other user communities. Alternatively, an increment or part of an increment may address the full set of issues related to a specific function of the system. It also is possible to plan an increment to eliminate requirements for contractor field support, or some other existing work-around that is part of a complex workflow. A mathematical view of all the possible methods of selection quickly reveals there are hundreds of thousands if not millions of potential solutions to grouping, ordering, and packaging releases. This white paper provides a description of a generalized technique that could be used with any type of system to assist the program office in addressing and resolving the conflicting views and creating a better value system for defining releases. This technique was developed with the help of a DoD program office.

Subject Categories:

  • Computer Programming and Software

Distribution Statement: