Schedule a Software Walkthrough Free Trial
Home / Product / Software FMEA
Product — Software FMEA

Software failure modes & effects analysis

The software FMEA can be conducted at the top, capability, requirements, interface, and detailed level. With a multi-functional team of subject matter experts from software and systems engineering, these FMEAs are the fastest and most effective — but they need to happen before code is finished to stay cost-effective.

Approach

Which viewpoints Requs AI Predict supports

Supported by Requs AI Predict:

  1. Top level — focuses on the software system as a whole, analyzing the failure modes that have historically been most common and severe.
  2. Capability level — works the same as a top-level FMEA, except the scope is more narrowly defined to one capability of a larger system.
Not supported by Requs AI Predict Requirements level — labor-intensive, and assumes a failure can be caused by a single software specification; it misses failures caused by a collection of requirements or missing requirements.

Interface level — labor-intensive, effective only if requirements are pre-filtered for the most critical; the top-level FMEA already captures notorious interface issues like the metric/English defect.

Detailed level — exceptionally labor-intensive, useful only for a very small portion of ultra-high-criticality code, and can only be done by the engineers writing the code. Typically misses the ~70% of defects that originate in specifications and design.
Before You Begin

What to gather first

The software FMEA is a design FMEA — the goal is to affect design controls, specifications, and test procedures early, to reduce cost and eliminate critical defects. It is not a FMECA: the goal isn’t to identify maintenance schedules for users, but to identify failure modes and root causes that reviews and testing often miss. The earlier the FMEA is executed, the cheaper it is to mitigate.

Analysts must retrieve the software specifications and design, as well as system specifications. Test procedures are needed to assess whether a failure mode is tested. Analysts should also gather any applicable user manuals.

The FMEA needs input from people who understand software and how it can fail. Software test engineers are often excellent sources, alongside the software engineers most experienced with the system. Systems engineers may be needed to assess top-level hazards of a software/hardware system.

Inputs

The eight-step FMEA workflow

The software FMEA uses inputs from the Survey tab to determine which Common Defect Enumerations (CDEs) are relevant. Questions used by the FMEA are flagged in column J of the import template; a dedicated import_template_SFMEA.xlsx contains only the FMEA-relevant inputs. Answer as many of these as possible before proceeding with the tabs below.

#
Input
Tab
1
Controls, type of software, design & testing focus
Survey tab — Product Information determines relevant CDEs; Failure Modes determines controls and CDE likelihood. Requirements, design, code, unit test, and test tabs also feed the FMEA — see the import template for details.
2
Hazards identification
Hazards & Criticality — define hazards and their severity so failure modes can be tagged to them.
3
States
State transitions — define states and transitions so state-related failure mode rows (TL-SM-x) auto-generate.
4
Hardware & communication elements
HW/comm interfaces — auto-generates TL-EH-x rows for detecting and handling hardware faults and loss of communication.
5
Effects
Effects — a cross-functional team identifies local, system, user, mission and safety effects, and tags the relevant hazard.
6
Likelihood
Likelihood — auto-identified by the software; you can override the calculation and justify why.
7
Mitigation
Mitigation — changes to specifications, design, code, test procedures, or user manuals, which may need scheduling and approval by software management.
8
Residual
The updated risk after mitigations are implemented and tested. If a test procedure explicitly verifies the root cause is mitigated, detectability can be set to lowest risk; if a control was put in place, control likelihood can drop; if the root cause was proven removed, existence likelihood drops. Manifestation likelihood rarely changes. The residual RPN is computed from the residual likelihoods and severity.
Outputs

Exporting the worksheet

The Effects, Likelihood and Mitigation tabs display both inputs and outputs. The CTQ tab lets you filter which rows to export.

#
Output
Tab
8
Critical to Quality
Watch the Software FMEA Video
Failure Modes

Built on the Common Defect Enumeration

The FMEA is based on the list of failure modes and root causes that have caused mission and safety failures since 1962, published as the Common Defect Enumeration (CDE) on the Defense Acquisition University Reliability & Maintainability Community of Practice website. Requs AI Predict identifies which CDEs are relevant for your system from your Product subtab answers, then determines likelihood from the design controls you selected in the Failure Modes subtab and the testing planned in the Unit Test and Test subtabs.

Start the FMEA workflow.

Define your hazards and criticality first — everything else tags back to this list.

Start with Hazards & Criticality → ← Back to Dashboard