Latent Defect Requirements

Definition

A latent defect requirement is a correctness requirement that specifies a required degree of latent defects, which is a quality factor that is defined as follows:

Latent Defect

the degree to which a work product and its outputs are free from defects upon delivery to the customer organization.

Objectives

The typical objectives of a latent defect requirement are to:

• Minimize the number or density of latent defects in the work product.
• Ensure that the work product does not contain an unacceptable number or density of latent defects.

Measurements

Latent defect requirements are typically specified in terms of the following measurements:

• Direct Measurements:
  • Maximum estimated number of latent defects.
  • Maximum estimated latent defects density
    (e.g., maximum average number of defects per use case, maximum average number of defects per use case path, maximum average number of defects per textual requirement, maximum average number of defects per KSLOC).
  • Maximum number of known defects [by type] identified by testing.
  • Maximum known defect density [by type] identified by testing.
• Indirect Measurements:
  • Maximum number of failed tests [by type].
  • Maximum percentage of tests failed [by type].

Examples

The following are typical examples of latent defect requirements:

• “The maximum number of latent bugs in a delivered software component shall not exceed 10 for any release.”
• “The maximum density of latent bugs in a delivered software component shall not exceed 2 per thousand lines of code for any release.”
• “The maximum number of system-level tests that can fail when the application is shipped and deployed for beta testing shall not exceed 100.”
• “The maximum number of defects (organized by category ) found during acceptance-level testing that the application can have and still be placed into production with its users shall not exceed:
  • Minor Defects = 25.
  • Significant Defects = 5.
  • Critical Defects = 0.
  whereby:
  • Critical defects prevent the use of essential application capabilities and have no workarounds.
  • Significant defects do have workarounds.
  • Minor defects (e.g., misspellings, incorrect typeface) are merely inconvenient or annoying to the user.”

Guidelines

The following guidelines have been found to be useful when producing latent defect requirements:

• The scope of a latent defect requirement can be:
  • An application
  • A component
  • A document
• Latent defects requirements can be identified and specified in term of the following:
  
  

  Component of Requirement	Possibile Values
  Type of Defect	Data Hardware Software
  Criticality of Failure	Critical Significant Minor
  Type of Test Failed	System test Alpha test Beta test Acceptance test
  Measurement Type	Estimated defects Known defects Tests failed

  
  
• Whereas everyone would love for their work products to be without defects, the reality is that any nontrivial work product typically contains some defects and it typically costs more per defect to remove the last remaining defects than those that are initially discovered and removed. Thus, there is rarely either time or resources to remove all defects. Instead, one specifies latent defect in terms of the maximum number and type of latent defects that can exist and still release the work product (e.g., application) to its users.