What Is a Fault Tree Analysis (FTA) and How Does It Connect to Requirements?
A fault tree analysis begins with something going catastrophically wrong and asks: what combination of events makes that possible? It is a top-down, deductive safety analysis method — you define an undesired top-level event (a loss of thrust, an uncommanded deployment, a reactor SCRAM), then systematically decompose the conditions that could cause it. The result is a logical diagram, not a narrative, and that precision is the point.
FTA is used across aerospace, automotive, nuclear, and industrial systems wherever regulatory frameworks or engineering judgment demands rigorous hazard analysis. MIL-STD-882 in defense, ARP 4761 in civil aviation, ISO 26262 in automotive, and IEC 61508 in industrial safety all reference fault tree analysis as a core technique. The method has been in use since the 1960s, originating at Bell Labs for the Minuteman missile program. Its durability is not nostalgia — it is that no better top-down deductive method has been developed for complex multi-failure scenarios.
What most introductions to FTA miss is the downstream consequence: a completed fault tree is a requirements source. The analysis does not end with a diagram and a probability number. It ends with design obligations that must be assigned, traced, and verified. Understanding that connection is what separates engineers who use FTA well from those who file it and move on.
How Fault Trees Are Constructed
A fault tree is built using a small vocabulary of logical gates and events. The top-level event — the hazard you are analyzing — sits at the root. Below it, AND gates and OR gates connect intermediate events and, eventually, basic events (component failures, human errors, environmental conditions) at the leaves.
An OR gate means any one of its inputs is sufficient to cause the output event. An AND gate means all inputs must occur simultaneously. The logical structure makes the combinatorics explicit: an OR gate directly above the top event tells you that any single input path can cause the catastrophe independently. An AND gate at the same position tells you that multiple independent failures must coincide.
Construction follows a disciplined process:
Define the top event precisely. Vague top events produce vague trees. “Loss of braking” is analyzable. “Brake problem” is not. The top event should be specific enough that you can state an unambiguous probability target for it.
Decompose through intermediate events. Each branch represents a subsystem or functional boundary. You are building a logical model of the system, so the tree structure should reflect system architecture — power, sensing, computation, actuation.
Reach basic events at the leaves. A basic event is a failure that is not further decomposed in this analysis — typically a component failure with an associated failure rate from a reliability database (MIL-HDBK-217, FIDES, manufacturer data) or a human error probability.
Apply consistent failure mode definitions. Every basic event should represent a specific failure mode, not a vague “failure of component X.” This precision matters when you connect FTA outputs to FMEA.
What Minimal Cut Sets Reveal
Once a fault tree is constructed, the quantitatively significant analytical output is the set of minimal cut sets (MCS). A minimal cut set is the smallest combination of basic events whose simultaneous occurrence is sufficient to cause the top event. “Minimal” means you cannot remove any event from the set and still have a sufficient cause.
A fault tree with hundreds of basic events may have thousands of cut sets, but the minimal cut sets organize the vulnerability landscape. Single-event minimal cut sets — where one basic failure alone causes the top event — are immediate red flags. They represent single points of failure. Double-event minimal cut sets represent two-failure combinations; their probability is the product of the two individual failure rates (assuming independence), and they are typically less concerning but must still meet the probability target.
The probability of the top event is approximated by summing the probabilities of all minimal cut sets (with corrections for shared basic events across cut sets). Modern FTA software — CAFTA, OpenFTA, Isograph FaultTree+, ReliaSoft BlockSim — automates this calculation. The calculation itself is not the hard part. The hard part is knowing what to do with the result.
If the top event probability exceeds the target (set by the applicable safety standard, by hazard classification, or by system-level allocation), something must change. That “something” is a design decision, and design decisions create requirements.
How FTA Outputs Drive Derived Safety Requirements
This is where FTA transitions from analysis to engineering obligation.
When a cut set is intolerable — either because a single-event MCS exists where one should not, or because a multi-event MCS has a combined probability above the allocated target — the engineering team has a bounded set of options:
Eliminate the failure mode. Design it out. If a single hydraulic line can cause loss of braking, add a second independent circuit. The design change eliminates the basic event from the tree or converts a single-event MCS into a multi-event MCS.
Reduce the failure rate. Specify a more reliable component, mandate a maintenance interval, or require environmental protection. Each of these is a requirement: a component reliability floor, a maximum maintenance interval, a qualification standard.
Add a monitoring or detection function. If a failure cannot be eliminated, a detection mechanism that removes the system from service before harm occurs changes the top-event logic. The detection function itself becomes a new safety function with its own reliability requirement.
Each of these responses produces what the safety community calls a derived safety requirement — a requirement that emerges from analysis rather than from customer specification. Derived requirements are not optional. They represent the analytical basis for meeting the top-level safety objective.
These derived requirements must be:
- Stated unambiguously (testable, with a pass/fail criterion)
- Assigned to a specific design element in the system architecture
- Traced to the FTA that generated them
- Verified through test, analysis, inspection, or demonstration
Without this chain, the safety case is a document asserting compliance rather than demonstrating it. Regulatory bodies — the FAA, EASA, NHTSA under FMVSS, the NRC — increasingly look for the chain, not just the document.
FTA and FMEA: Complementary, Not Redundant
A common misunderstanding is that FTA and FMEA cover the same ground from different angles, making one of them optional. They do not, and neither is.
FMEA (Failure Mode and Effects Analysis) is bottom-up and inductive. For each component in the system, it asks: if this item fails in this specific way, what happens? FMEA is exhaustive across failure modes of individual components. It is excellent at identifying single-point failures that affect specific functions and at feeding data into reliability allocation.
FTA is top-down and deductive. It starts with a specified undesired outcome and asks: what combinations of failures produce it? FTA is excellent at identifying multi-failure combinations that are individually non-catastrophic but collectively hazardous — combinations that FMEA, working component by component, never explicitly assembles.
The classic example: a hydraulic pump failure (FMEA flags it as high-criticality) and a backup pump test switch in the wrong position (FMEA flags it as low-criticality) may form a minimal cut set that causes loss of flight control. Neither FMEA alone would surface the combination as the critical vulnerability. The FTA surfaces it because it works from the top event downward.
In practice, the two analyses feed each other. FMEA provides failure modes and local effects that populate FTA basic events. FTA identifies which failure mode combinations require additional scrutiny in the FMEA. The safety case is built from both working together.
The ARP 4761 process for civil aviation explicitly uses both — FTA for functional hazard assessment follow-through, FMEA and FMES (Failure Mode and Effects Summary) for hardware implementation. ISO 26262 mandates both for ASIL-classified items. Using only one is not a defensible position in a certification program.
Connecting FTA-Derived Requirements to Architecture and Verification
Here is where the practice of safety engineering often breaks down. The FTA is completed, the derived requirements are written into a safety requirements document, and the document is submitted. The requirement text exists. The traceability to the fault tree — the justification for why the requirement exists — is in a separate file, possibly maintained by a different team. The verification evidence is in a test report that will not be written for two years. The connection is implicit, gestural, and fragile.
When the system design changes — a component substitution, a software update that changes detection latency, a scope change that adds a new load to a power bus — the derived safety requirements should be re-evaluated against the affected fault trees. In practice, they often are not, because the connection between the design model and the safety analysis is not maintained. The safety case becomes stale faster than anyone tracks.
Modern requirements traceability platforms address this directly. Flow Engineering, built specifically for hardware and systems engineering teams, implements graph-based traceability that connects FTA-derived requirements to the system architecture elements they constrain and to the verification activities that close them. Rather than a flat document, the safety case lives as a connected model: top-level safety objective → FTA → minimal cut sets → derived requirements → design element → verification record.
This matters operationally, not just conceptually. When an engineer changes a component reliability specification, Flow Engineering’s graph model can surface which derived safety requirements and which fault tree branches are potentially affected. The change does not propagate silently. A safety engineer does not have to manually search through a requirements database to find what a component spec change touches.
Flow Engineering also supports AI-assisted requirement derivation — given a fault tree cut set and the relevant safety standard, the platform can help draft the requirement language and suggest appropriate verification methods. This is not a replacement for engineering judgment, but it accelerates the translation from analysis output to traceable requirement, which is consistently the slowest step in safety programs.
The result is what the safety community calls a living safety case — not a document generated at program close to satisfy a certification checkpoint, but an artifact that stays current with the design and provides real-time visibility into open safety obligations. Auditors increasingly expect this. More practically, engineers benefit from it: the safety case is usable during development, not just during certification.
Practical Starting Points
If your program is running FTA for the first time or trying to close the gap between existing analyses and requirements traceability:
Start with the top event definition. Sloppy top events produce unactionable analyses. Spend time on the system-level hazard log before opening the FTA tool.
Document basic event assumptions explicitly. Every basic event failure rate carries assumptions about environment, maintenance, and operational profile. Those assumptions become requirements if the analysis is to remain valid.
Write derived requirements immediately after the MCS review. Do not leave a gap between the analysis and the requirement. The team that understands the cut sets should write the requirements, not hand off a table to a different team.
Trace bidirectionally. Every derived requirement should link to the cut set that generated it, and every cut set should be reachable from the requirement. This bidirectional link is what makes design change impact assessment tractable.
Treat the FTA as a living document. Schedule an FTA review trigger whenever a design change affects a component or function that appears in the tree. The review should be brief — it only needs to check whether the affected branches still meet their probability targets.
Fault tree analysis done well is not a compliance exercise. It is a systematic method for understanding how complex systems fail and for converting that understanding into specific engineering obligations. The fault tree tells you what the system must not allow. The requirements tell you what the design must guarantee. The safety case tells you that those guarantees have been met. Keeping those three connected, throughout the program and not just at its end, is the work.