How to build a software fault tree that actually finds something
Adding "software failed" to a fault tree isn't analysis — it's a placeholder. This class teaches how to write what the software actually did wrong, guided by the Common Defect Enumeration.
"Software failed" is a dead end, not an analysis
A fault tree with a leaf node that just says "software failure" doesn't lead anywhere — it can't be designed against, and it can't be tested. An effective software fault tree names the specific behavior instead: not "software failed," but something like "the software transitioned from flight to ground state while the aircraft was still in the air." This class teaches how to write that level of specificity, using the Common Defect Enumeration as a guide.
What the class covers
Three modules, covered in a single self-guided day.
Why "software failed" isn't effective fault tree analysis
Why a generic "software failure" leaf node is the most common mistake in software fault tree analysis — and why it makes the tree useless past that point.
A tree that stops at "software failed" gives design and test engineers nothing to act on. Recognizing this pattern is the first step to fixing it.
The popular but ineffective approach: "Software Failure" sits as a single, generic leaf node — a dead end that can't be designed against or tested.
How to describe what the software actually did wrong
How to replace a generic "software failed" node with the specific software behavior involved — for example, "the software transitioned from flight to ground state while the aircraft was still in the air" — down to the specific condition that triggered it.
A specific behavior is something a designer can build a control against and a tester can write a test case for. A generic failure isn't.
The effective approach: the tree branches all the way down to specific software behaviors — failing to handle spiked values, stale data, stuck values, and invalid values — each one something a designer or tester can actually act on.
Using the Common Defect Enumeration as a guide
How to use the Common Defect Enumeration as a checklist while building out a software fault tree, so the specific behaviors you write aren't limited to whatever the team happens to think of.
The CDE turns "what could the software have done wrong here" from an open-ended brainstorm into a structured review of known failure modes.
Format, duration, and prerequisites
1 Day
Delivered as a single day of self-guided instruction.
Virtual, Self-Guided
Work through the material on your own schedule, at your own pace.
The Most Common Edge Cases
Required before taking this class.
Build a fault tree that actually leads somewhere.
Register for the class, or explore the Common Defect Enumeration it's built on.