Schedule a Software Walkthrough
NASA-STD-8719.13 — NASA Software Safety Standard Rev C, 2013 Topic — Software FMEA fit Public — via NASA
SW
NASA-STD-8719.13 · Software Safety

Where Software FMEA Fits

The Standard defines who does what, and when. Its companion Guidebook (NASA-GB-8719.13) supplies the how-to — and gives Software FMEA a specific, repeated job across two lifecycle phases, paired with Fault Tree Analysis as its top-down counterpart.

1Docs

Two documents, one job split

NASA-STD-8719.13 addresses the who, what, when, and why of software safety — determining which software is safety-critical, scoping and tailoring the safety effort, documentation and traceability requirements, tool support, and waivers. It deliberately doesn't walk through specific techniques.

That job belongs to its companion, the NASA Software Safety Guidebook (NASA-GB-8719.13), which supplies the how-to — including detailed, step-by-step instructions for applying FMEA and Fault Tree Analysis to software specifically.

2Lifecycle

Software FMEA shows up twice

SFMEA — two points in the lifecycle Guidebook Ch. 6 & Ch. 7
Ch.6
Requirements phase — §6.6.8
Part of Software Safety Requirements Analysis, run alongside Software Fault Tree Analysis, to catch failure modes hiding in the specification before any design exists.
Ch.7
Design phase — §7.5.1.3
Revisited as one of the "Update Previous Analyses" tasks, catching failure modes the design itself introduces once architecture and interfaces are set.
3Paired

Paired with Software Fault Tree Analysis

The Guidebook treats SFMEA and SFTA as complementary halves of the same job, discussed together at both lifecycle points:

SFMEA — inductive

Bottom-up: start from a specific failure mode in a component or module, and ask what it does to the system. Good at finding failure modes nobody thought to ask about.

SFTA — deductive

Top-down: start from an unwanted top-level event, and work backward to what combination of conditions could cause it. Good at proving a specific hazard is (or isn't) reachable.

4Process

The SFMEA process, per Appendix D

The Guidebook devotes an entire appendix to SFMEA specifically, laying out the process as a sequence:

Identify components
Set ground rules
Identify failures
Identify consequences
Detection & compensation
Design changes
Impacts of corrective changes

Appendix D also addresses why to do an SFMEA and known issues with it — notably that, unlike hardware FMEA, software has no failure rate to anchor a quantitative severity/occurrence score to.

5Scope

Scoped by risk, not run at full depth by default

How much SFMEA effort a project actually does is tied to the System Risk Index — a combination of hazard severity and likelihood established during the Preliminary Hazard Analysis:

Index 1 — Prohibited, must redesign
Index 2 — Full safety effort
Index 3 — Moderate safety effort
Index 4–5 — Minimum safety effort
Index 6–7 — None required
6Context

Part of a bigger hazard-analysis chain

Where SFMEA sits system-wide PHA → SSHA → SFMEA/SFTA

SFMEA doesn't stand alone — it's downstream of a Preliminary Hazard Analysis and a Software Subsystem Hazard Analysis that first establish which software is safety-critical at all. And like SAE1025, IEEE 1633, and the standards elsewhere in this series, the Guidebook is candid that software occurrence is "mostly qualitative, and as yet, not quantitatively expressed" — echoing the line it quotes from Dr. Nancy Leveson of MIT: software doesn't fail, it just doesn't perform as intended.