Two standards become one
On June 10, 2020, NASA-STD-8739.8A absorbed the older NASA-STD-8719.13 outright — the document history log states plainly that the revision "combined the NASA Software Assurance Standard... with the NASA Software Safety Standard" and cancels NASA-STD-8719.13. If you read the companion page on 8719.13 first: this is that document's requirements, now living inside 8739.8A.
Performance-based, not technique-prescriptive
8719.13's Guidebook spelled out softare FMEA as a named, seven-step process in its own appendix. 8739.8A takes a different approach entirely: it maps every requirement to an NPR 7150.2 "SWE-###" engineering requirement in a mapping matrix (Table 1), and assigns each one a software assurance task — confirm, assess, analyze, perform — without dictating which named technique satisfies it.
Where software FMEA is implied rather than named
FMEA does appear once, by name — inside the standard's own definition of the verb "Analyze," which explicitly lists Failure Mode and Effects Analysis and Fault Tree Analysis as example methodologies. From there, it's implied wherever the standard requires an assurance "analysis" without naming the analysis method:
Each of these calls for the project to "analyze" or "assess" software against requirements, design, or hazards — software FMEA is a natural way to satisfy that obligation, but the standard leaves the choice of technique to the project.
Appendix A reads like a NASA 8739 software FMEA prompt list
The closest thing 8739.8A has to technique-level guidance is Appendix A, "Guidelines for the Hazard Development Involving Software," which poses roughly twenty specific yes/no questions to drive out software's contribution to hazards — functionally the same prompts an SFMEA's "identify failures" step would ask:
Where the how-to guidance lives now
NASA 8739.8A foreword explains the gap deliberately: the update "moved guidance text to an Electronic Handbook." That's NASA-HDBK-2203, the wiki-based NASA Software Engineering and Assurance Handbook — the direct successor to the old NASA GB-8719.13 Guidebook's role. The step-by-step SFMEA process that used to live in GB-8719.13 Appendix D now lives there, kept current outside the standard itself.
Closing the traceability loop
Whatever produces it, an SFMEA's findings have a specific, required place to land: SWE-052 requires bi-directional traceability from software requirements to system hazards, for every safety-critical software component. A software FMEA is one of the clearest ways to generate that evidence — each failure mode it identifies either maps to an existing hazard cause or becomes a new one that Appendix A's hazard analysis has to absorb.
The modern approach to software FMEA is the 6D CDE Software FMEA and is captured in the SAE 1025 FMEA section 7 and the IEEE 1633. The 6D is the 6 dimensions of failure 1) defect in the software 2) defect in the interface to hardware and electronics 3) defect in the interface to the system 4) defect in interface to user 5) defect in the ability to stay on for the entire mission and 6) defect in interface with the environment. The CDE is the Common Defect Enumeration, a structured list of root causes of real failures.