SOFTWARE FAILURE MODE AND EFFECT ANALYSIS (SFMEA) - Software Design for Six-Sigma: A Roadmap for Excellence - page 427

TABLE 16.3 SFMEA Severity Rating

Severity of Hazard/Harm

Rating
1-5

Rating
1-10

Criteria Description

Catastrophic Product Halts/Process Taken Down/Reboot

Required : The product is completely hung up, all
functionality has been lost, and system reboot is
required

5 9-10

Serious Functional Impairment/Loss : The problem will not

resolve itself, and no “work around” can bypass the
problem. Functionality either has been impaired or
lost, but the product can still be used to some extent

4 7-8

Critical Functional Impairment/Loss : The problem will not

resolve itself, but a “work around” temporarily can
bypass the problem area until fixed it is without
losing operation

3 5-6

Marginal Product Performance Reduction : Temporary

through time-out or system load; the problem will
“go away” after a period of time

2 3-4

Negligible Cosmetic Error : No loss in product functionality.

Includes incorrect documentation

1 1-2

occurrence also is the likelihood of the failure mode. Occurrence is rated on a
scale of 1 (almost never) to 10 (almost certain) based on failure likelihood or
probability, usually given in some probability metric as shown in Table 16.4 10 .
In addition to this subjective rating, a regression correlation model can be used.
The occurrence rating is a ranking scale and does not reflect the actual
likelihood. The actual likelihood or probability is based on the failure rate
extracted from historical software or warranty data with the equivalent legacy
software.
In SFMEA, design controls help in preventing or reducing the causes of
failure modes, and the occurrence column will be revised accordingly.
6. Current controls: The objective of software design controls is to identify and
detect the software nonconformities, deficiencies, and vulnerabilities as early
as possible. Design controls usually are applied for first-level failures in the
respective hierarchy (Figure 16.3). For hardware, a wide spectrum of controls
is available like lab tests, project and design reviews, and modeling (e.g.,
simulation). In the case of a redesign software DFSS project, the team should
review relevant (similar failure modes and detection methods experienced on
surrogate software designs), historical information from the corporate memory.
In the case of a white-sheet design, the DFSS team needs to brainstorm new

10 Reproduced from Table 15.3.