What Is FMEA and How Does It Connect to System Requirements

Failure Mode and Effects Analysis (FMEA) predates most of the systems engineering frameworks engineers use today. Developed formally by the U.S. military in MIL-P-1629 in 1949, it has since been codified across every major safety-critical industry: AIAG/VDA for automotive, SAE ARP5580 for aerospace and general industry, ISO 14971 for medical devices. It is, in the most straightforward sense, a method for asking: what can fail, what happens when it does, and what are we doing about it?

That question sounds simple. In practice, FMEA is one of the most labor-intensive, disagreement-prone, and frequently misused artifacts in an engineering program. Teams produce them because customers and regulators require them. They complete them as standalone documents. And then — in most programs — the findings sit in a spreadsheet or a PDF, disconnected from the requirements that govern what the system must actually do.

That disconnection is the problem this article addresses. Understanding FMEA structure is necessary but not sufficient. Understanding how FMEA outputs are supposed to drive safety requirements — and how those requirements should trace back to the analysis that motivated them — is what separates a compliance exercise from an engineering discipline.

FMEA Structure: The Core Anatomy

Every FMEA, regardless of domain or format, works through a chain of related concepts. The specific column headers and rating scales differ by standard, but the logical structure is consistent.

Function describes what the item or process step is supposed to do under defined conditions. A brake caliper applies clamping force to the rotor. A weld joint maintains structural integrity under specified load cycling. A software validation routine confirms data integrity before write operations. The function statement is the baseline — everything else in the FMEA row is defined relative to it.

Failure Mode is the way in which the item or process step fails to perform its function. A failure mode is not an effect (what the failure causes) or a cause (what triggers the failure). It is the failure behavior itself: the brake caliper applies insufficient clamping force. The weld joint fractures under load. The validation routine passes corrupt data. Getting this distinction right matters because confusing failure modes with causes leads to analyses that don’t actually isolate what can go wrong.

Effect describes the consequence of the failure mode — typically analyzed at multiple levels: the local effect (on the item itself), the next higher level effect (on the subsystem), and the end effect (on the system or the user). In automotive FMEA, severity is assessed against the end effect. A loss of braking at the caliper propagates to loss of vehicle deceleration, which has a severity consequence for the vehicle occupant.

Cause identifies what initiates the failure mode. Causes are the actionable element in an FMEA: they’re what prevention controls target. A caliper can deliver insufficient clamping force because of a worn seal, an air pocket in the hydraulic line, or a manufacturing defect in the piston bore. Each cause may warrant different prevention controls.

Controls fall into two categories. Prevention controls reduce the likelihood of the cause occurring — tighter manufacturing tolerances, material specifications, design margins. Detection controls identify that a failure mode or its cause has occurred — inspection steps, in-process testing, sensor monitoring. Both types of controls inform the final risk characterization.

Risk characterization has evolved. The traditional approach uses Risk Priority Number (RPN), calculated as Severity × Occurrence × Detection, each rated on a 1–10 scale. RPN has well-documented weaknesses: a score of 100 can result from many different combinations, and the multiplicative structure means that a high-severity, low-occurrence failure can appear lower priority than a low-severity, high-occurrence nuisance failure.

The 2019 AIAG/VDA harmonized FMEA handbook introduced Action Priority (AP) as a replacement. Rather than calculating a composite score, AP uses a structured table that first fixes severity, then evaluates occurrence and detection against it. High severity failures are treated as requiring action regardless of how infrequent or detectable they are. This is a meaningful methodological improvement — severity is no longer dilutable by detection ratings.

Design FMEA, Process FMEA, and System FMEA

These three variants address different scopes of risk and answer different engineering questions.

Design FMEA (DFMEA) analyzes the risk associated with a design’s ability to meet its intended function. The scope is the product design — components, subassemblies, interfaces between them. DFMEA is performed during the design phase, before manufacturing processes are finalized. Its outputs drive design changes, specification tightening, and design verification requirements. In automotive programs, DFMEA is a required deliverable in APQP and is reviewed during customer design reviews.

Process FMEA (PFMEA) analyzes the risk associated with the manufacturing or assembly process. The “item” being analyzed is a process step, and the function is what that step is supposed to do to the product. PFMEA is scoped to the manufacturing floor, not the design office. A PFMEA for a torque-sensitive fastening operation would identify failure modes like over-torque, under-torque, or cross-threading — the product design might be sound but the process step can still introduce variation that causes field failures.

System FMEA (SFMEA) operates at a higher level of abstraction, analyzing failure modes at system and subsystem interfaces rather than at the component level. SFMEA is particularly relevant in complex, multi-supplier architectures where the integration risk is as significant as the individual component risk. In aerospace programs structured around ARP4754A, system-level hazard analysis and SFMEA are inputs to the functional allocation process that determines which subsystems bear which safety requirements.

The three types are related but not redundant. SFMEA identifies system-level interface risks that then get allocated to subsystems. DFMEA addresses how the design of each subsystem manages the risks allocated to it. PFMEA addresses how the manufacturing process preserves the design intent established in DFMEA. In a rigorous program, findings flow down and traceability flows up.

Here is the gap that most programs leave open.

An FMEA identifies that a particular failure mode has high severity — for example, loss of position sensing in an electromechanical actuator causes uncommanded motion with potential for personnel injury. The team rates it, assigns action items, and logs it as closed when the actions are documented. But those actions — a redundant sensing channel, a software watchdog, a mechanical travel limit — are not requirements. They’re recommendations. Until they become verifiable requirements, they’re not part of the system’s formal behavioral specification.

This matters for several concrete reasons.

First, verification planning. If a safety measure identified in FMEA isn’t captured as a requirement, it doesn’t generate a test case. The measure may exist in the design without any formal verification that it works as intended.

Second, change impact. When a design change is proposed, engineers query the requirements database to assess impact. If the rationale for a design feature — its redundant sensor, its watchdog timer — lives only in an FMEA spreadsheet and not in the requirements, change analysis will miss it. The protection identified through months of FMEA work gets quietly removed.

Third, supply chain communication. Derived safety requirements flow to subsystem suppliers. If the requirement to “detect loss of position sensing within 50ms and command a safe state” exists only as an FMEA action item in an internal document, it may never reach the supplier responsible for implementing it.

The formal connection is this: every high-severity failure mode in an FMEA, and every significant action item that addresses a cause or adds a control, should generate or modify a system or subsystem requirement. And every such requirement should carry a trace link back to the FMEA row that motivated it. This bidirectional link makes the risk basis for each requirement explicit and keeps the two artifacts synchronized when either changes.

Industry standards acknowledge this. ISO 26262’s functional safety concept and technical safety concept are explicitly derived from hazard analysis and risk assessment — and the same traceability logic applies to FMEA-sourced requirements. DO-178C and ARP4754A embed requirements traceability to safety analyses in their process tables. But standards describe the requirement; they don’t enforce the practice. In most programs, the connection is manual, informal, and fragile.

How Modern Tools Help Close This Loop

The challenge is architectural. Traditional requirements management tools — IBM DOORS, DOORS Next, Jama Connect — manage requirements well, but they don’t natively understand FMEA structure. FMEA tools — spreadsheets, dedicated FMEA software, some PLM-embedded modules — manage failure mode analysis well but don’t connect to requirements databases with meaningful link semantics. The result is that engineers maintain two separate artifact sets and attempt to keep them synchronized manually, usually through meeting notes and version-controlled exports.

Flow Engineering was built around a graph-based model of system knowledge, which changes the architectural problem. Rather than treating FMEA and requirements as separate documents that need to be reconciled, Flow Engineering represents them as nodes and relationships in a connected graph. A failure mode node can link directly to the requirement it generated. A requirement node can carry a back-link to the FMEA row that motivated it. When the FMEA is updated — because a new cause is identified or an action item is redesigned — the affected requirements are immediately visible in the graph, and their verification status is reflected in real time.

This matters practically in several ways. First, it makes impact analysis tractable. An engineer proposing a change to a control measure can query the graph to find every requirement that references that control, every test case that verifies those requirements, and every FMEA row where the control appears — without opening three separate tools and cross-referencing manually. Second, it surfaces coverage gaps. If a high-AP failure mode has no requirement linked to it, the gap is visible in the traceability view, not buried in a spreadsheet audit. Third, it supports AI-assisted analysis: Flow Engineering’s AI layer can suggest requirement language based on the failure mode and effect description, flag requirement nodes that lack a safety rationale link, and identify clusters of requirements that share a common FMEA source — useful for subsystem specification development.

Flow Engineering is not a full FMEA authoring environment. Teams doing AIAG/VDA-format PFMEA with detailed occurrence ratings and supplier-specific control plan integration will still use dedicated FMEA tools or structured spreadsheet templates for initial analysis. Flow Engineering’s role is at the boundary: importing or representing the FMEA findings, establishing the requirement links, and maintaining those links as the program evolves. For teams that already manage their requirements in Flow Engineering, this means FMEA-derived requirements become first-class citizens in the same model that contains the system architecture, verification plan, and traceability matrix — rather than a separate artifact that gets updated out of sync.

Practical Starting Points

If your program currently produces FMEA as a compliance deliverable but doesn’t formally connect it to your requirements, the following steps represent a realistic path to closing that loop:

Establish a triage rule for requirement generation. Not every FMEA row warrants a new requirement. Define a threshold — for example, any failure mode with AP High, or any failure mode with Severity ≥ 9 under the traditional RPN scheme — that triggers a formal review for requirement generation. This scopes the work without losing the high-value connections.

Write requirements in response to controls, not just to effects. A common mistake is writing requirements that describe the system behavior under failure (e.g., “the system shall not produce uncommanded motion”) without also writing the requirements that specify the controls that prevent it (e.g., “the position sensing subsystem shall detect loss of signal within 50ms”). Both are necessary; only the second is verifiable through testing.

Tag requirements with their FMEA source. Even in a tool that doesn’t natively support FMEA-to-requirement linking, a structured attribute — FMEA_ID, FMEA_Row, or a custom field — creates a queryable connection that survives tool transitions and supports change analysis.

Audit at milestones, not just at program start. FMEA and requirements both evolve. At each major design review, run a reconciliation check: are there high-priority FMEA findings with no corresponding requirement? Are there requirements whose FMEA source has been updated in ways that make the requirement outdated? These questions catch drift before it becomes a verification gap.

Honest Assessment

FMEA is a mature, well-understood methodology that does its job well when applied rigorously. The problem is rarely the method — it’s the institutional boundary between risk analysis and requirements definition. Organizations that treat FMEA as a design input rather than a compliance document, and that maintain explicit links between failure mode findings and system requirements, build programs where safety analysis actually governs what the system must do and how that’s verified.

The tooling to support this has historically been weak because FMEA tools and requirements tools evolved separately. That’s changing. Graph-based requirements platforms that can represent both failure modes and requirements as connected nodes — and that can maintain those connections across program evolution — make the disciplined practice tractable rather than heroic. The methodology has always pointed in this direction. The infrastructure to support it is now available.