Almost a million failures, a few hundred root causes
Most defect taxonomies are built from intuition or a handful of case studies. The CDE is different — it comes from analyzing nearly a million real software failures for root cause, across decades of programs. What that analysis found is that the sheer diversity of software failures is deceptive: underneath it, the same few hundred generic, functional root causes keep repeating.
Those root causes are cataloged across four levels of analysis — Top Level (the whole software LRU), Capability Level (one feature or use case), Specification Level (one requirement statement), and Interface Level (the boundary between two systems or organizations) — so a software FMEA can be scoped to whatever level actually fits the time available, without starting from a blank page.
A software FMEA built from scratch asks engineers to invent every failure mode from memory — slow, inconsistent, and dependent on who's in the room. A software FMEA built from the CDE asks engineers to recognize which of a few hundred known root causes apply to their design — faster, more repeatable, and not dependent on any one person's experience.
10 failure mode categories
Every root cause in the CDE falls into one of ten failure mode categories. Each category has its own letter code, used as the middle segment of every CDE identifier (for example, TL-SM-2 — a Top Level, State Management root cause).
Where these defects actually originate
Most defect taxonomies are built around code — the bug in the function, the off-by-one error, the null pointer. That's a real category of defect, but Mission Ready Software's own benchmarking study of real project data found that coding defects account for only about 30% of the failures that actually happen. The rest originate earlier — in the specifications, the architecture, and the design — long before anyone writes a line of code.
Organized around coding constructs — the kind of defect a static analyzer or code reviewer can catch. Covers roughly 30% of what actually causes software to fail, and can't be applied until code exists to analyze.
Organized around functional root causes that trace back to specifications, architecture, and design — the majority of what actually causes software to fail, and can be applied before a single line of code is written.
The categories aren't just where the defects originate earlier — they're also easier to spot once an analyst knows what to look for. A state transition matrix either has a prohibited transition path or it doesn't. A unit of measure either matches across components or it doesn't. The CDE turns "what could go wrong" into a checklist of specific, recognizable questions instead of an open-ended brainstorm.
Built into the 6D CDE Software FMEA
The CDE isn't just a reference document — it's the engine behind the 6D CDE Software FMEA. During Structure Analysis, root causes are brainstormed across six causal design element (CDE) categories — Software, Electronics, System, Users, Mission Time, and Environment — and mapped directly to the failure mode categories above. From there, Failure Analysis connects each root cause to system effects and hazards, and Risk Analysis and Optimization turn the results into design controls and test cases.
Because the categories are already validated against nearly a million real failures, teams using the CDE aren't guessing at what could go wrong — they're working through a known, closed list.
Further reading
Where to go next to see the CDE in the source document, in a short video walkthrough, or applied inside the Software FMEA product and process.