Every reliability team runs Software FMEA. Almost none of them measure whether it's working.
Over 27 years and across ground-based, airborne, industrial, space, smart-device, and traffic-control systems, we tracked one number for every Software FMEA we ran: critical issues found per work hour. Not opinions about which method feels more rigorous — a hard, comparable rate, computed the same way every time, whether the approach was a hardware-centric checklist in 1999 or the Requs AI-driven 6D CDE process in 2026.
The rate went from zero to as many as 12 critical issues per hour. Here's the data, stage by stage.
The Six Stages
This wasn't a single insight or a clean roadmap followed on purpose. It was nearly three decades of trial, error, and standards catching up to what the data already showed. Six distinct approaches, each with its own real-world case study proving (or disproving) that it worked.
-
1
Hardware-Centric (CSCI)
The starting point was a hardware FMEA template pointed at software: failure modes written at the level of "the entire CSCI shuts down." It rested on a faulty assumption — that a software failure takes out the whole computer software configuration item — and it only ever surfaced failure modes so obvious they added no value. Result: zero critical issues found in 40 hours of effort.
-
2
Software-Centric, SME-Driven, Unstructured
The focus shifted to software-specific failure modes — out-of-range data, stale data, corrupted data — found mostly through subject-matter-expert brainstorming. It worked better than stage 1, but the results depended entirely on which expert was in the room and produced no repeatable set of failure modes from one project to the next. Rate: 0.14 to 0.49 critical issues per hour.
-
3
Structured Process, Pre-CDE
IEEE 1633 brought a repeatable, structured process to the table — state management, error handling, sequencing — for the first time. What it didn't have yet was a defined, common taxonomy of defect types, so analysts still had to invent their own categories. Rate: 0.84 critical issues per hour.
-
4
+ Common Defect Enumeration
Applying an early version of the Common Defect Enumeration (CDE) gave the structured process something it was missing: a standard vocabulary of how software actually fails. This case study found undetected misprocessing and multiple ways the equipment could exceed its maximum allowed downtime — the kind of finding a generic checklist never surfaces. Rate: 2.05 critical issues per hour, a 2.4x jump from stage 3.
-
5
+ Updated Standards, Still Manual
By the time IEEE 1633 and SAE 1025 FMEA were updated to formally incorporate both the structured process and the CDE, the approach was standards-compliant end to end — but still hand-run, without tooling. Rate: 2.94 critical issues per hour.
-
6
+ Requs AI Tool
The same standards-compliant 6D CDE process, now run through Requs AI instead of by hand. This is where the numbers stopped looking incremental: 6.0, 6.2, 8.4, and 12.0 critical issues per hour across four unrelated industries — traffic control, smart devices, ground-based, and airborne. Even the smallest analysis in this group — a 2-hour review of a smart traffic light — still found 6 critical issues per hour, more than double anything achieved without the tool. The jump isn't a tooling convenience; it's the difference between a team that can afford to review every relevant defect category and one that has to pick and choose under time pressure.
All 10 real case studies, broken down by issue type — mission loss, safety event, both, and critical downtime, 1999–2026.
The Trend Holds Across Every Case, Not Just on Average
Averages can hide a lot. Stage 6 alone spans four industries with almost nothing in common — a traffic control system, a smart device, a ground-based system, and an airborne platform — and every one of them lands well above anything from stages 1 through 5. That's the difference between "the average improved" and "the method itself changed what's findable."
It's Not Just Finding More — It's Finding More of Everything
The easiest way for a "critical issues per hour" number to go up is to find more of one cheap, easy category and call it a win. That's not what happened here. Look at the composition of each bar above: mission loss, safety events, cases that are both, and critical loss-of-uptime issues that don't rise to mission or safety level but still matter.
Early stages are lopsided — 2017 is almost entirely mission-loss findings (dark red), 2020 is almost entirely downtime findings (grey), because each approach was only equipped to see one kind of problem. The Requs AI-driven case studies find meaningful volume across every category, in every industry tested. More structure doesn't just mean more issues — it means fewer blind spots.
Why the Airborne Case Study Led the Pack
Airborne software is already subject to some of the most rigorous verification in the industry — MC/DC structural coverage and extensive shall-based requirements testing. Those methods are genuinely good at proving the code does what its requirements say. What they are not built to find are the state-management and error-handling defects that don't trace back to any single requirement: MC/DC confirms a decision was exercised, not that the software recovers correctly when it lands in a state nobody wrote a requirement for.
Requs AI doesn't run a generic, one-size-fits-all FMEA. It tailors the analysis to the Common Defect Enumeration categories that are historically relevant to the application type — and for the airborne case study, that meant deliberately weighting toward state management and error handling: exactly the categories that airworthiness testing structurally can't reach, no matter how thorough it is. That's not a coincidence in the data above. It's the reason the airborne case study posted the highest rate in the entire dataset — it wasn't duplicating what MC/DC and shall testing already covered, it was finding what they structurally cannot.
What This Means for Your Program
If your Software FMEA is producing a handful of obvious findings your team already knew about, you're likely still somewhere around stage 1 or 2 — regardless of how much time you're putting into it. The data above says the ceiling isn't a people problem or an effort problem. It's a method and tooling problem, and it's been solved: a defined common defect taxonomy, a structured bottom-up process aligned to IEEE 1633 and SAE 1025, and a tool built to run it consistently.
See the 6D CDE process behind these numbers
Requs AI Software FMEA is the tool used in every stage-6 case study above.
Explore Requs AI Software FMEA