ANSI AAMI SW91:2018 pdf download.Classification of defects in health software.
This document identifies a defect classification system, or taxonomy, that can be used to classify the types of defects that might exist in software. The taxonomy applies to defect root causes in all types of software (including third-party software, medical device software, test software, and manufacturing software) throughout the software development lifecycle.
The classification system is meant to be neutral with respect to
• programming language,
• methodology,
• product,
• intended use,
• risk (the consequences of failure), and
• regulatory status.
The use of a common taxonomy allows industry-wide aggregation of defect occurrence data that can be used to improve software quality. Some examples of ways in which this may be accomplished are presented as use cases in Annex A.
The way in which the standard is to be used is not prescribed. The taxonomy does not attempt to classify the seventy
of defects, as the consequences of any defect can only be evaluated within the context of the software’s intended use.
It does not attempt to describe methodologies for analyzing root cause, managing defect resolution, or assigning risk.
It does not attempt to categorize defects in quality system processes.
Several annexes are included for information. Annexes B, C, and D are provided to illustrate how the taxonomy can be used to categorize various types of software problems. Annex E provides examples of cause analysis using the taxonomy. Annex F provides a reference table of all defect categories and codes, and Annex G provides the rationale for the types of defects that are in scope for the standard.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
ANOMALY
any condition that deviates from the expected based on requirements specifications, design documents, standards, etc. or from someone’s perceptions or experiences. ANOMALIES may be found during, but not limited to, the review, test, analysis, compilation, or use of SOFTWARE PRODUCTS or applicable documentation
[SOURCE: IEEE 1044:1993, definition 3.1; IEC 62304:2006, definition 3.2]
3.2
COMPONENT
a subroutine, function, macro, program, program segment, method, thread, process, or any other sensible processing
component
3.3
DEFECT
an imperfection or deficiency in a work product where that work product does not meet its requirements or specifications
Note I to entry: Cases where software meets its requirements and specifications but does not meet a user’s particular needs are not considered to be defects.
Note 2 to entry: DEFECT is a more specific term than ANOMALY. See IEEE 1044:2009 figure 1 for relationships among some common terms.
[SOURCE: IEEE 1044:2009, modified — By omitting both the statement uand needs to be either repaired or replaced” from the end of the sentence, and the accompanying note to the entry containing examples. Note I to entry and Note 2 to entry have been added.]
3.4
FAILURE
(a) termination of the ability of a product to perform a required function or its inability to perform within previously specified limits. (adapted from ISO/IEC 25000:2005); (b) an event in which a system or system component does not perform a required function within specified limits. (adapted from ISO/IEC 24765:2009)
NOTE—A failure may be produced when a fault is encountered.ANSI AAMI SW91 pdf download.