ANSI AAMI SW91-2018 pdf download
ANSI AAMI SW91-2018 pdf download.Classification of defects in health software
4.2. Defect code use
To use this taxonomy, root cause analysis is performed to the greatest depth possible. If an appropriate defect category exists, the defect code for that category is assigned to the identified software defect. In cases where the cause cannot be determined to the level of detail of an individual category, then the lowest level subcategory that best captures the type of defect should be selected. For example, root cause analysis has determined that a defect exists in a third-party device driver module, but further details are not available. Information about the possible defect is consistent with the category description in the General section for Third-Party Software (3.7). In this case, the subcategory Third-Party Software (3.7) itself may be selected rather than a more specific subcategory within 3.7, such as 3.7.1, 3.7.2, 3.7.3, or 3.7.4. Identifying the best candidate for a root cause can be aided by considering at what point in the design cycle the defect was introduced. For example, a problem is identified with a data compression algorithm. Care should be taken when considering the cause(s) associated with the algorithm problem to ensure that deficiencies in requirements and implementations are not accidentally captured as design defects. If the identified problem stems from an unclear requirement, then Requirement Clarity (2.1.2) may apply, or if a requirement was not considered at all, then Requirement Scope (2.2.2) may apply. In general, design errors that result from defective requirements are not defects with the design, nor are errors in the resulting implementation if the implementation is otherwise true to the design. In a different situation, a designer reading a correct requirement may have misinterpreted the requirement and selected an algorithm that was inappropriate for the defined requirement. In this case, the defect is a design defect (Algorithm Selection (3. 10)) even if the selected algorithm correctly implements the misunderstood requirement.
Determining root causes in features such as security and interoperability that span multiple disciplines or vendors can be challenging. Using this taxonomy, cause analysis should discover why the defect exists without focusing on the functionality of the module that contains the defect. For example, the taxonomy does not contain a category for malware detected. Instead, it contains several causes that may lead to malware arriving on the system. One possible cause may be a buffer overrun in evaluating a Loop Exit Condition (4.3.3.3). In many cases, it may be impossible to identify the exact cause, especially those caused by maintenance updates and the use of third-party software. General categories for third-party software and software updates are provided for cases where more in-depth analysis is not feasible. It is up to the analyst to decide what level in the hierarchy is adequate to capture a defect. If it is determined that there is no value to be gained by selecting a particular subcategory in the hierarchy, the analyst should stop at the level where sufficient granularity is achieved. Groups within an organization may aim for different hierarchy levels depending on their needs.
In cases where the root cause analysis uncovers several issues, the analyst should report all appropriate categories. This includes when the defect is introduced as the result of a process error. For example, while investigating a system crash due to an external stimulus, the analyst realizes that there is no requirement for what the system should do when the stimulus occurs. One root cause is what actually caused the system to crash. The missing requirement would be listed as an additional root cause (Requirement Scope (2.2.2)). In another case illustrating multiple causes, a failure occurred because the functionality in legacy code used in the device was misunderstood. Both the implementation defect and any architecture and design defect would be captured. It is important to understand that the root cause, for the purposes of using the taxonomy, is generally not an observable symptom or related process issue. For example, consider the situation where an off-by-one error causes the system to reset. The symptom is the reset but the reset itself is not the defect. Testing may have been inadequate (and an appropriate testing defect may also be identified), although this does not mean that inadequate testing caused the reset failure. The root cause of the system reset is the off-by-one error, or Reference to Wrong Element (4.2.2.3). It is left to the company to decide if and how to capture symptoms and whether to report how the defect manifested.
