Schedule a Software Walkthrough
SAE1025 — Failure Mode & Effects Analysis Issued Jan 2026 Clause 7 — SwFMEA Illustrative Summary
07
Section 7 · SwFMEA

Software Failure Modes & Effects Analysis

Where the rest of SAE1025 extends the classical hardware FMEA logic, Section 7 breaks from it. Software doesn't wear out, drift, or fatigue the way physical components do — so it needs its own failure taxonomy, its own risk scoring, and its own way of estimating occurrence. Section 7 is based on the Mission Ready Software 6D CDE software-centric SwFMEA approach. Requs AI Software FMEA is currently the only SwFMEA tool that fully supports every aspect of section 7 SAE 1025 FMEA standard.

1Approach

A software-centric approach

Section 7 does not treat software as a component to be plugged into a hardware-style FMEA. SwFMEA is scoped and structured around how software actually fails — through logic, requirements, interfaces, and state, rather than through physical degradation.

It's applied during the design phase and, like the rest of SAE1025, is treated as a living analysis: updated continuously as the software changes, not filed away once a form is completed.

2CDE

Built around the Common Defect Enumeration

Rather than asking analysts to brainstorm software failure modes from scratch, Section 7 is built around the Common Defect Enumeration (CDE) — a structured, pre-populated list of defect types that have historically and repeatedly shown up in software. The CDE gives teams a starting inventory to work from instead of a blank page.

Requirements omission
Requirements conflict
Boundary / edge case
Timing & race condition
Resource exhaustion
Error-handling gap
Interface mismatch
State-machine violation

Illustrative examples of the kind of defect classes a CDE-style taxonomy indexes — shown here to convey the approach, not reproduced from the standard's own list.

3Scoring

A risk table, not a Risk Priority Number

Classical FMEA multiplies Severity × Occurrence × Detection into a single Risk Priority Number. Section 7 rejects that for software: RPN's false precision doesn't hold up when occurrence and detectability are so hard to quantify continuously for code. Instead, it plots severity against occurrence directly on a risk table, sorting each failure mode into a small number of honest risk bands.

Not used for software
S × O × D = RPN

A single number built from three multiplied estimates. Two very different failure modes can land on the same score, and small changes in any one factor swing the result — precision the underlying judgments don't actually support.

Adopted in Section 7
Med
Med-Hi
High
High
Low
Med
Med-Hi
High
Low
Low
Med
Med-Hi

Severity and occurrence are each judged on their own terms and looked up in a matrix, not multiplied together. The result is a risk band the team can defend, not a number that only looks precise.

4Occurrence

Occurrence, assessed by evidence — not by guessing

The occurrence axis of the risk table doesn't come from an engineer's gut-feel probability estimate. Section 7 adopts the occurrence tables developed by Ann Marie Neufelder of Mission Ready Software, which score occurrence against four concrete, checkable questions about the failure mode itself.

Occurrence rating — four-factor evidence model Neufelder / Mission Ready Software
a
Requirements evidence
Is the failure mode clearly evident in the requirements — as an omission, a commission, or a conflict?
b
Test coverage
Has the failure mode been explicitly tested for, one way or another?
c
Control
Is the failure mode controlled — held in check by a mitigation, guard, or design safeguard?
d
Repeatability
Does the failure mode repeat across multiple systems, rather than being a one-off?
✓Compliance

Requs AI Software FMEA

Compliant with Section 7 of the SAE1025 FMEA standard SwFMEA

Requs AI's Software FMEA capability is built to Section 7 of SAE1025: it applies a software-centric failure model rather than a hardware-derived one, draws candidate failure modes from a Common Defect Enumeration–style taxonomy, scores risk on a severity/occurrence risk table instead of a multiplied RPN, and rates occurrence using the four-factor evidence model — requirements evidence, test coverage, control, and repeatability.