Software Engineering
Home Planning Requirements Writing Hazard Analysis Requirement Analysis Config Control Software Design Software Testing Software Standards Basic Logic

Software Hazard Analysis - Procedure

The purpose of hazard analysis is to identify all possible software hazards and mitigate them to an acceptable level. The overall process is :

1.   Identify all hazards caused by software and determine the level of concern.

2.   Mitigate hazards. The preferred order of mitigations is:

  1. By Design (most effective method). This results in a change to the design that mitigates the hazard. For example, scanning a barcode to prevent mistyping.
  2. Protective Measure. This is a passive measure that, it followed, will mitigate the hazard. For example, double entry when changing your password - the two entries must match.
  3. Warning (least effective method). Basically - "don't do that!"

3.  Determine the residual risk. If not yet at an acceptable level, repeat until hazard is at an acceptable level.

Identifying Hazards

To identify hazards in software, examine the flow of information (data) through the system, from the user's perspective, and ask the following questions:

  • As the data flows through the system, where can it be corrupted or altered, and in what way?
  • What downstream filters or processes exist to detect data corruption or alteration? Downstream filters act as mitigations, reducing the chance that the hazard could go undetected.
  • What effects will the corruption or alteration have on the end result? Rate the severity of the hazardous condition as Minor, Moderate, or Major.

Mitigating Hazards

Mitigations can take three forms (listed in order from most effective to least effective):

1.  By design. Mitigation becomes a software or hardware design requirement. This is the most effective form of mitigation. Mitigation is generally verified by testing; however,  design reviews may also be used for verification if testing is not feasible.

2.  Protective measures. Passive measures that protect the patient or operator from injury. Passive measures do not require any action on the part of the user. For example, removing administrative rights after software installation would be considered a protective measure. Protective measures will be verified by visual inspection that the measure exists and is appropriate.

3.  Warning. Warnings may involve the use of labeling or procedures to specify safe operation. A warning requires some action or knowledge on the part of the user to be aware of the warning and take the appropriate action. For example, a users manual may contain warnings about safe operation of the software. Warnings will be verified by visual inspection that the warning exists and is appropriate.

Determining Residual Risk

The results of the software hazard analysis will be assessed for the residual risk. For a residual risk to be acceptable:

    • Risks that have been mitigated to a Minor Level of Concern are acceptable without further mitigation.
    • Risks that have been mitigated to a Moderate Level of Concern must either have Quality Assurance Management review and approval, or be further mitigated to a Minor level.
    • Risks that are still at a Major Level of Concern after mitigation must have Executive Management review and approval, or be further mitigated to a Moderate or Minor level.