Planning and preparation
The Handbook's "5 T's" — Intent, Timing, Team, Task, Tools — carry over directly, with software-specific answers: the team includes software engineers and test leads alongside systems and safety engineers, and the tools are requirements management, static analysis, and version control rather than gauges and process sheets. Scope and boundaries are drawn around a software system or subsystem, not a physical assembly.
Requs AI Software FMEA guides the user through the boundary setting process.
Structure analysis
DFMEA breaks a product into system → subsystem → component. The software equivalent breaks an architecture into viewpoints. The top-level viewpoint focuses on what can go wrong with the entire system. The capability viewpoint focuses on what can go wrong with a single major feature or subsystem. The interface viewpoint analyzes what can go wrong with major interfaces. The requirement viewpoint analyzes what can go wrong with a single requirement. A code-level FMEA walks through the code. The code-level FMEA is not recommended as per the IEEE 1633 due to the low coverage and astronomical expense. Code coverage tools are more efficient. The requirement viewpoint is also very expensive compared to the roughly 9% of defects that originate in a single shall statement. INCOSE requirements analyzer tools can analyze the requirements more efficiently. The interface FMEA covers about 9% of what can go wrong. A good review of the interfaces for inconsistencies could be equally effective. The top-level and capability level FMEAs cover more than 50% of what has historically gone wrong and are relatively easy to analyze, particularly with tools like Requs AI Software FMEA.
Requs AI Software FMEA guides the user through the top-level and capability-level failure modes, which aren't easily detectable in other analyses and account for the bulk of the hidden root causes.
Function analysis
Each structural element gets its intended function and the requirement it's judged against — for software, that's usually a traced functional or behavioral requirement rather than a dimensional spec, which is why a mature requirements baseline matters more for software FMEA than it does for hardware. The 6D CDE FMEA developed by Ann Marie Neufelder of Mission Ready Software is a systematic approach that focuses on the historical root causes of the world's software failures. The 6 dimensions are defects in the product, defects in the interfaces to electronics, defects in the interfaces with the system, defects in the user interface, defects in how the software works over a long period of time and defects in how the software works within it's intended physical environment.
Requs AI Software FMEA guides the user through the 6 dimensional CDE FMEA process recommended in the SAE 1025 FMEA section 7 and the IEEE 1633.
Failure analysis
This is where software diverges most from hardware. Failure modes aren't wear-out or fracture — they're logic, timing, and data problems. Practitioners typically seed this step from a defect taxonomy similar to the Common Defect Enumerations used by SAE1025 and IEEE 1633:
Requs AI Software FMEA guides the user through the common defect enumeration, which was authored by the founder of Mission Ready Software. The CDE was built from observations from the world's largest database of software failures analyzed by root cause
Risk analysis
The Handbook's Severity / Occurrence / Detection ratings, rolled into Action Priority (AP) in place of the old RPN, are the part that needs the most adaptation for software:
Occurrence is rated from historical failure-rate data — parts-per-million, warranty returns, physical test data accumulated across a production run.
Software doesn't wear out, so practitioners substitute evidence-based occurrence — closer to the requirements-evidence / test-coverage / control / repeatability model used elsewhere in software reliability practice — and score Detection against test and static-analysis coverage rather than inspection sampling.
Requs AI Software FMEA computes the occurrence for each failure mode based on a machine learning models built from the world's largest database of software failures analyzed by root cause
Optimization
Where DFMEA optimization actions might be a design change or a tolerance adjustment, software optimization actions are things like additional unit or boundary tests, added input validation, defensive error handling, continuous monitoring, and independent design controls — changes aimed at lowering occurrence or improving detection the same way the Handbook intends, just implemented in code instead of geometry.
Requs AI Software FMEA provides suggestions for design controls, corrective actions and test cases for each common defect enumeration
Results documentation
The final step is unchanged in spirit: a documented, traceable record of functions, failure modes, risk ratings, and actions taken. For software, this record typically also traces back to requirements, design and test cases, so the FMEA can serve as audit and certification evidence alongside the test suite rather than as a standalone artifact.
Requs AI Software FMEA provides reports by hazard or risk level. It supports import/export so that multi-functional teams can collaborate.