Writing DFMEA Failure Modes: Function-Based Structure, Verb-Noun Syntax, and Common Mistakes

The most common DFMEA quality issue is not missed failure modes but mis-written ones. The team lists “bracket fails” or “cracking” or “stress concentration at corner” in the failure mode column. None of these are failure modes — the first is too vague to be useful, the second is a failure type without context, and the third is a failure cause being recorded in the wrong column. A DFMEA team that does not write failure modes correctly produces an analysis that looks complete on paper and misses entire risk categories in practice.

This guide covers the function-based structure of a DFMEA failure mode, the verb-noun syntax the AIAG-VDA Handbook prescribes, the distinction between failure modes / failure causes / failure effects, and the specific writing patterns that produce audit-defensible failure-mode entries.

The Function-Based Structure

A DFMEA is organized by function, not by component. Every row starts from a function the design must perform. The failure mode is the way that function fails. This is the AIAG-VDA Step 3 (Function Analysis) feeding Step 4 (Failure Analysis) chain.

For a bracket whose function is “transmit torque from input shaft to output flange,” the failure modes are the ways torque transmission can fail:

Torque transmission interrupted (function does not occur)
Torque transmission reduced (function occurs but degraded)
Torque transmission delayed (function occurs but with timing error)
Torque transmission incorrect direction (function occurs incorrectly)
Torque transmission with side effect (function plus unintended effect)

Notice that “bracket cracks” is not on the list. Cracking is a failure cause — one mechanism by which torque transmission could be interrupted. The failure mode is the loss of function; the cause is the physical mechanism that produces it.

The Five Function-Failure Patterns The AIAG-VDA Handbook lists five generic failure patterns that apply to any function:

No function — the function does not occur at all
Partial function / over-function — the function occurs but at the wrong magnitude
Intermittent function — the function occurs sometimes but not reliably
Unintended function — a function not designed to occur, occurs
Function in wrong direction — the function occurs but with reversed sense

For every documented function, walk these five patterns. This is how teams find failure modes they would otherwise miss.

The Verb-Noun Syntax

Functions and failure modes use verb-noun construction. The verb describes the action; the noun describes what is being acted on. Examples:

Function: “Transmit torque” (verb: transmit; noun: torque)
Failure mode: “Fails to transmit torque” or “Transmits insufficient torque”
Function: “Seal hydraulic fluid”
Failure mode: “Fails to seal” or “Leaks hydraulic fluid past seal”
Function: “Position component within assembly”
Failure mode: “Mispositions component” or “Allows component free play within assembly”

Verb-noun syntax forces specificity. “Bracket fails” tells you nothing about what the bracket was supposed to do; “Bracket fails to maintain alignment between motor and gearbox shafts” tells you exactly which function is at risk and what failure looks like. The AIAG-VDA structure analysis exists to drive this specificity from the function definition forward.

Distinguishing Failure Mode, Failure Cause, and Failure Effect

The most common DFMEA writing error is putting the wrong concept in the failure mode column. The three concepts and where they belong:

Concept	Definition	Example (cracked bracket)
Failure cause	Root-level mechanism producing the failure	Fatigue at stress concentration; insufficient material thickness; thermal cycling
Failure mode	The way the function fails	Bracket fails to maintain motor-gearbox alignment
Failure effect	Consequence at system / user / regulatory level	Drivetrain vibration; eventual motor mount failure; service-call event

The chain reads cause → failure mode → effect. Mixing the categories is what produces FMEAs that pass internal review but fail OEM customer audits. Specifically:

Putting causes in the failure mode column — “fatigue cracking” as a failure mode rather than as a cause. Loses the function-failure framing and merges multiple potential failure modes into one row.
Putting effects in the failure mode column — “vibration” or “NVH issue” as a failure mode rather than as an effect. Skips the function-failure layer entirely.
Putting failure modes in the cause column — “misalignment” as a cause when misalignment is itself the failure mode (the root cause is something deeper like dimensional stack-up, weld distortion, or thermal expansion mismatch).

Step-by-Step: Writing One DFMEA Row

Start from the function. Read it off the boundary diagram and structure analysis. “Maintain motor-gearbox alignment within +/- 0.1mm under operating loads.”
Walk the five function-failure patterns. No function (no alignment); partial (degraded alignment); intermittent (alignment cycles in and out); unintended (over-constraint); wrong direction (alignment shifts in opposite direction from designed).
Pick the failure mode for this row. “Allows alignment offset greater than 0.1mm under load.” Verb-noun: “Allows offset.” Specific to the function.
Identify the failure causes — the root mechanisms that could produce this failure mode. Material yield under load; weld penetration insufficient; thermal expansion mismatch with mating components; bolt preload loss over time.
Identify the failure effects at sub-system level (drivetrain vibration), at system level (NVH issue), and at end-user / regulatory level (warranty return, in extreme cases safety event).
Rate Severity from the worst-case effect. Severity scoring uses the most serious effect, not an average. For ratings, see the 1-10 Severity scale.

Common Mistakes

Mistake 1: Component-Based Failure Modes “Bracket cracks,” “O-ring degrades,” “Wire chafes.” These describe what the component does, not what the function fails to do. A component-based DFMEA misses interface failures (where most warranty problems live) and produces failure-mode lists that look like a parts catalog rather than a risk analysis.

Mistake 2: Effect-Based Failure Modes “Customer dissatisfaction,” “Warranty claim,” “NVH.” These are effects, not failure modes. Putting them in the failure-mode column collapses the cause-mode-effect chain into one entry and breaks the link to specific design decisions.

Mistake 3: Failure Mode That Mixes Pattern and Cause “Bracket cracks at stress concentration due to fatigue.” This sentence contains a failure cause (fatigue at stress concentration), a hint at the failure mechanism, and no clear failure mode. Split it: failure mode is “Allows alignment offset under load”; cause is “Fatigue crack at corner radius after N cycles.”

Mistake 4: One Row Per Function A single function typically has multiple failure modes (one per pattern). A DFMEA with one row per function under-analyzes risk — it captured one way the function fails and missed the others. Walk the five function-failure patterns for every function before moving on.

Spot-Check Your Own DFMEA

For an audit-ready DFMEA, every row should pass three tests:

Function-anchored: the failure mode references a function, not a component or effect. You can read the row aloud as “the function [X] fails because [cause] producing [effect].”
Verb-noun specific: the failure mode uses verb-noun construction with enough specificity that a different team member could understand the failure without context.
Cause-mode-effect separated: the cause column does not contain failure modes; the failure-mode column does not contain effects; the effect column does not contain causes.

Rows that fail any of these tests need rewriting. The work is not glamorous but it is the difference between a living-document DFMEA and a file-stuffer.

For the upstream inputs that drive function-based structure (boundary diagrams and P-diagrams), see how to define DFMEA scope before the analysis starts. For the broader 7-step process the failure-mode work sits inside, see how the AIAG-VDA 7-step methodology is applied. To compute Action Priority on the failure modes once they are correctly written, the RPN and Action Priority calculator applies the AIAG-VDA logic to S/O/D inputs.

Summary

A DFMEA failure mode is the way a function fails — not the component that broke, not the consequence the customer sees, not the physical mechanism producing the failure. Verb-noun construction, function-anchored framing, and disciplined separation of cause / mode / effect produce DFMEAs that survive audit and surface real design risk. Component-based or effect-based failure modes look complete but miss entire risk categories. The AIAG-VDA Step 3 / Step 4 chain is the framework; the writing discipline is the practitioner’s job.