DFMEA (Design Failure Mode and Effects Analysis) is a structured method for identifying how a product design can fail, evaluating the consequences of each failure for the end user, and prioritizing design changes before the design is released to tooling. Each potential failure mode is rated for severity, occurrence, and detection, producing a ranked list of design risks and the actions that close them.
DFMEA stands for Design Failure Mode and Effects Analysis, and it is sometimes written as "design FMEA." It is one of two main applications of FMEA the other being PFMEA, which analyzes the manufacturing process rather than the design.
The distinction that matters in practice: a DFMEA assumes the product will be built exactly as drawn, and asks whether the design itself is adequate. Manufacturing variation is explicitly out of scope that belongs to the PFMEA. This boundary is the single most common source of confusion on cross-functional teams, and getting it wrong produces a DFMEA cluttered with process defects and blind to genuine design weaknesses.
DFMEA is required or expected under IATF 16949 in automotive supply chains, referenced in APQP and SAE J1739, aligned with ISO 14971 risk management practice in medical devices, and used inside Six Sigma programs during the Analyze and Improve phases of DMAIC.
The purpose of DFMEA is to find and eliminate design weaknesses while changing the design is still cheap. A failure mode caught during concept design costs a CAD revision. The same failure mode caught after tooling costs a tool modification and a schedule slip. Caught in the field, it costs a recall.
Beyond risk reduction, a completed DFMEA produces several downstream artifacts teams rely on:
FMEA (Failure Mode and Effects Analysis) is the parent methodology. DFMEA and PFMEA are its two dominant applications, distinguished by what is being analyzed:
The relationship is sequential, not competitive. The DFMEA feeds the PFMEA. When a DFMEA identifies a high-severity failure effect tied to a specific design characteristic say, a sealing surface whose finish determines whether an enclosure passes its ingress rating that characteristic arrives in the PFMEA as something the process must control. Teams that run the two analyses in isolation end up with process controls aimed at the wrong features.
Severity carries across the handoff. A failure effect rated severity 9 in the DFMEA stays severity 9 in the PFMEA, because severity describes the consequence to the end user, and the consequence doesn't change based on which analysis you happen to be filling in.
Start the DFMEA during concept design, as soon as a system architecture exists and functions can be defined not after the design is finished. A DFMEA run at design freeze can only document risk; a DFMEA run during concept can still change the architecture that causes it.
Practical triggers for creating or revising a DFMEA:
In hardware programs, the DFMEA should mature alongside the design maturity gates. By the time you enter engineering validation, the DFMEA should be defining what the test plan must prove which is why the analysis and the EVT/DVT/PVT validation stages are best planned together rather than sequentially.
DFMEA is a cross-functional exercise led by the design owner usually the responsible design engineer or a design quality engineer but the analysis is only as good as the room. A useful DFMEA team includes design engineering, test and validation, manufacturing or process engineering (who will inherit the handoff), quality, service or field support, and where relevant, the supplier responsible for a subsystem.
A common failure pattern: one engineer completes the worksheet alone, the week before a design review. That produces a document, not an analysis. The value of the method comes from the disagreement the test engineer who knows the failure mode from a previous program, the field technician who has seen the actual return.
The AIAG-VDA FMEA Handbook, published jointly by the Automotive Industry Action Group and the German VDA in 2019, defines a seven-step approach that has replaced the older format across most regulated supply chains:
Every failure chain carries three ratings on 1–10 scales. The anchors below follow the AIAG-VDA convention; individual companies calibrate the wording to their products, but the structure is consistent.
Three points that trip teams up:
The traditional method multiplies the three ratings into a Risk Priority Number (RPN = S × O × D), from 1 to 1,000. RPN is easy to sort but treats a severity-9 failure with RPN 36 as equivalent to a nuisance issue with the same product, which is not how engineering risk works.
The AIAG-VDA handbook replaced RPN with Action Priority (AP) a lookup table returning High, Medium, or Low from the S/O/D combination, weighting severity first, then occurrence, then detection. High AP requires action or a documented justification for inaction.
If you supply automotive customers under IATF 16949, use AP. Outside that supply chain, RPN remains workable provided you add a hard severity rule: any failure mode rated S ≥ 9 gets reviewed and actioned regardless of its RPN.
A condensed but realistic row from a design that has to survive water ingress the kind of tradeoff that surfaces constantly in consumer and medical hardware:
Note what makes this row useful. The function is quantified, so the failure mode is objectively definable. The cause is stated at the design level wall deflection between fasteners rather than as a vague "poor sealing." And the optimization changed the design rather than adding a test, which is what actually moved occurrence from 4 to 2. Finally, the row ends by naming what the process now has to control, which is the DFMEA-to-PFMEA handoff working as intended.
A working DFMEA template whether in dedicated software or a spreadsheet carries these columns:
Two structural additions that separate a mature DFMEA from a checkbox one: a boundary diagram and P-diagram attached as inputs, and a link column mapping each high-severity row to the verification test that proves it. The second turns the DFMEA into a live document during validation instead of an artifact filed at design freeze.
Increasingly, teams are using large language models to draft first-pass failure modes from requirements documents and to check an existing DFMEA for coverage gaps asking, in effect, "what failure modes for this function are missing?" That's a reasonable use: generating candidate failure modes is genuinely tedious, and models are good at breadth.
What AI cannot do is assign defensible ratings. Severity depends on the specific product's use context and user population; occurrence depends on your organization's design precedent and field history; detection depends on your actual test capability. All three are institutional knowledge, not general knowledge. Treat AI output as a brainstorming input to the cross-functional review, never as the analysis itself and in regulated contexts, be deliberate about what design information goes into an external tool.
DFMEA stands for Design Failure Mode and Effects Analysis. It is a structured method for identifying how a product design could fail, rating the risk of each failure mode by severity, occurrence, and detection, and prioritizing design changes before release.
FMEA is the general methodology for analyzing failure modes in any system. DFMEA is the application of that methodology specifically to a product design. The other main application, PFMEA, analyzes the manufacturing process. When someone says "FMEA" without qualification, the intended variant depends on context.
DFMEA analyzes the product design and asks how it can fail in use, assuming it is manufactured as specified. PFMEA analyzes the manufacturing process and asks how defects can be introduced during production. The DFMEA is performed first and hands its critical characteristics and severity ratings to the PFMEA.
Under the AIAG-VDA FMEA Handbook, the seven steps are: planning and preparation, structure analysis, function analysis, failure analysis, risk analysis, optimization, and results documentation.
To identify and eliminate design weaknesses while design changes are still inexpensive, and to generate the verification requirements, critical characteristics, and design review evidence that downstream activities depend on.
FMEA predates Six Sigma, having originated in aerospace and defense reliability work before its adoption in automotive. It is nonetheless widely used within Six Sigma programs, typically during the Analyze and Improve phases of DMAIC, as well as within APQP and lean product development frameworks.
The design owner leads it typically the responsible design engineer or design quality engineer but the analysis is performed by a cross-functional team including test, manufacturing, quality, and where relevant, suppliers and field service.
There is no universal threshold, because rating anchors differ between organizations and RPN values are only comparable within a single analysis. Rather than a fixed cutoff, act on the highest RPNs, mandate review of any failure mode with severity 9 or 10 regardless of RPN, or adopt the AIAG-VDA Action Priority table, which applies that weighting for you.
Andrews Cooper develops products where design risk carries real consequence medical devices, precision instruments, and the automation that builds them. If you need a design partner who runs the analysis rather than filing it, talk to our product development team.
