What needs to be finished first
A sufficiently detailed system description with components, interfaces, and dependencies is available (architecture diagram, C4 model, or causal chain).
Possible failure scenarios have been sketched so that the top event and plausibility are contextualized.
What needs to be ready before start
Large whiteboard or digital diagram tool (e.g., draw.io, Lucidchart, OmniGraffle); FTA symbols (AND gate, OR gate, basic event, top event); system documentation; template for probabilities and sub-events.
An FTA coach with experience in reliability or safety analysis; 3-6 experts from affected domains (software, hardware, network, data, operations); a scribe for assumptions and sources; independent reviewer for critical systems.
Top event as a precise undesired state (e.g., "Wrong dose administered to patient"); system diagram; available failure rates or estimates per component; standards or regulations if relevant.
Initial 4-8 h, then iterative refinements per sub-tree
Place top event clearly at top of board as rectangle. Make FTA notation visible. Keep an "assumptions" section separately and number each assumption. Rule: AND gates connect events that must occur together; OR gates connect alternative causes.
The one question this method answers
Which logical combinations of basic events lead to the undesired top event, and which minimal cut sets are critical enough to trigger action?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Top event and system boundary | 30-45 min | Formulate top event precisely: state, threshold, time window, affected system. Define system boundary: what is in the tree and what stays black-box. | If top event is not unambiguous (for example, "system down" without definition), the tree is arbitrary. Define it with testable acceptance criteria. |
2Phase 2: First branch layer | 45-60 min | Identify immediate preconditions that must hold for top event to occur. Differentiate AND (all together) and OR (one is enough). Place this layer as sub-events under the top event. | Common mistake: refining too quickly. First layer must be complete; otherwise structural logic is wrong. Test: would this layer alone explain the top event if fully verified? |
3Phase 3: Iterative refinement | 2-4 h | Further decompose each sub-event until base events are reached (component failure, operator error, external cause). Document assumptions and data sources per layer. | Stop when additional refinement adds no value or no data is available. Trees can be infinitely deep in theory; practical stop at 4-6 levels or at measurable base events. |
4Phase 4: Minimal cut sets | 45-90 min | Identify minimal cut sets: smallest combinations of basic events whose simultaneous occurrence triggers the top event. Do manually or with tools. | Cut sets of size 1 are single points of failure and often critical. Cut sets with high joint probability are also critical. Prioritize by impact times likelihood. |
5Phase 5: Actions and review | 45-90 min | Derive measures for each critical cut set: redundancy, detection, recovery, prevention. Assign owner and date. For critical systems, an independent review is mandatory. | Actions without independent review are prone to blind spots. In regulated systems, review is required, not optional. |
What comes out at the end
FTA diagram with top event, complete branches, notation (AND, OR, basic events), assumptions table, identified minimal cut sets, and derived actions with owner and date. Include review note for regulated systems.
One FTA per system and top event. Record version with date, author, and reviewer. For system changes, create a new FTA version with diff and keep predecessor.
Compact working template for Fault Tree Analysis with context, input, output artifacts, and next step.
What is this method used for?
Which question should be answered at the end?
Which data, observations, or materials are available?
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
System boundary: Smart pump including operator app, pump microcontroller, sensor, wireless channel. CGM sensor as black box.
Independent reviewer Dr. Schulze, approval 2026-05-02.
Recognize symptoms and steer against them
Top event reads "system down" or "error occurs," no measurable state.
Refine top event with state, threshold, time window, and affected system. Test: can an observer consistently determine whether top event has occurred.
Gates are not clearly marked, tree logic is ambiguous, cut sets cannot be derived.
Use strict notation and label gates clearly. If uncertain, ask: must A and B hold simultaneously, or is A or B sufficient?
Refinement goes to components without available failure rates, and effort explodes.
Define stop criteria: base event is reached when data is available or direct measure exists. Deeper detail only with proven value.
Tree contains probabilities and relationships without documented sources or assumptions.
Keep assumptions table in parallel: at least one numbered assumption per layer. In review, this table is the primary source.
Actions are generic ("more testing", "better documentation") and not linked to identified cut sets.
Define one action per prioritized cut set. If no specific action can be derived, re-evaluate cut set or increase depth.
Team creates and approves FTA alone, blind spots remain.
For regulated systems, independent review is mandatory. For non-regulated systems at least one person outside team should cross-check.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.