dfmea-designBuild a design risk analysis, DFMEA worksheet, or interface analysis using the AIAG-VDA FMEA Handbook 2019. Covers design intent, interface failures, boundary diagram, and design robustness before manufacturing. Use during new product development, design changes, or when a field failure reveals a design weakness. Required for IATF 16949 §8.3 scope.
Independent GitHub snapshot · Automated classification · Original documentation governs
Identify and mitigate design risks by analysing functions, interfaces, and failure modes — so that design weaknesses are resolved before release to manufacturing, and the results feed directly into the DVP, PFMEA, and Control Plan.
Key difference from PFMEA: DFMEA analyses the design intent and design robustness. PFMEA analyses the manufacturing process. DFMEA comes first — its failure effects and severity ratings inform the PFMEA.
Define scope:
Map the product hierarchy:
System (e.g., Steering Column)
└── Subsystem (e.g., Tilt Mechanism)
└── Component (e.g., Pivot Pin)
└── Interface (e.g., Pin-to-Bracket contact)
Interface matrix: For each component, identify:
Interfaces are where most design failures occur. Each interface must be analysed as a potential failure location in its own right — not just the components that share it. In practice, at least 50% of DFMEA effort should focus on interfaces and interactions; component-only analysis misses the most common field failure modes.
For each element in the structure, define its design function:
Format: Verb + Noun + Measurable Standard
Examples:
Identify Special Characteristics from the drawing — these get S = 9 or 10 in Step 5.
Testability rule: Every function must be measurable and verifiable — a test or analysis method must exist in the DVP. A function with no verification method cannot receive a credible D rating in Step 5.
The failure chain for DFMEA: Failure Effect → Failure Mode → Failure Cause
Failure Effect (FE):
Failure Mode (FM): How does this component fail to perform its design function?
Failure Cause (FC): What design parameter or design decision causes the failure mode?
Failure Cause validation: Failure Causes must be validated using engineering analysis (FEA, structural calculation, thermal simulation) or test evidence. Unverified assumptions — "probably," "likely," "may be" — are not acceptable as final Failure Causes. Use CAE (FEA, simulation), test data, and field return data to support both the failure modes identified and their causes. For post-field-failure DFMEA updates, the FC must match the validated root cause from the 8D or field investigation.
Use the same S/O/D ratings and AP table as PFMEA (see action-priority-ap and pfmea-process for the tables).
Key DFMEA-specific notes:
Occurrence (O) in DFMEA considers:
Detection (D) in DFMEA considers:
D = 10 means no design verification for this failure mode. This is common for new features — it drives the DVP.
Ratings justification: All S/O/D ratings must be justified using analysis, test data, or design history. A rating without documented justification will not withstand OEM audit. Where design history exists from similar components, reference it explicitly. Where data is absent, mark O and D as preliminary and flag the DVP entry that will confirm them.
For H-AP items in DFMEA, actions typically fall into:
DFMEA → DVP linkage: Every detection control (D rating improvement) must have a corresponding entry in the Design Verification Plan (DVP). If you improve D because "we will test it," the test must exist in the DVP.
Action tracking: All actions must be tracked to closure with objective evidence — test results, simulation output, or updated analysis. Actions marked "complete" without verification evidence are not acceptable. Open H-AP items past their target date must be escalated to the design review owner or programme manager, with a revised date and documented reason for delay.
DFMEA outputs that feed other APQP documents:
The DFMEA and PFMEA are linked:
| DFMEA | → | PFMEA |
|---|---|---|
| Design Failure Effects (end-user impact) | → | Severity ratings in PFMEA |
| Special Characteristics | → | SC flagging in PFMEA process steps |
| Interface failure modes | → | PFMEA failure modes for assembly steps |
| Design intent (function) | → | Process step function requirements |
| Trigger | Required action |
|---|---|
| New product development | Start DFMEA at APQP Phase 2 — before design freeze. DFMEA initiated after freeze has no corrective value. |
| Engineering change request (ECR) | Review and update the DFMEA for all functions, failure modes, and interfaces affected by the change — before the change is released. |
| Design milestone / design review | Present DFMEA status: open H-AP items, actions, and revised ratings. DFMEA must be current at each gate. |
| Field failure with confirmed design root cause | Update FC, ratings, and actions to match validated root cause from 8D/field investigation. Update DVP to include the failure mode. |
A DFMEA that is not updated through the programme lifecycle is a design quality assurance gap — not a living document.
At the start of each use, ask the user:
"How would you like to receive the output? A — Structured Markdown (formatted tables and sections, ready to copy) B — Plain tables (simplified structure for Excel or Word) C — Narrative report (flowing text for a formal document or email)
Default: A."
Adapt all output sections to the chosen format. If the platform or session context already defines a format preference, skip this question.
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | 2026-06-01 | @RBraga01 | Initial release |
| 1.1 | 2026-06-03 | @RBraga01 | Added interface matrix integration and DFMEA-to-PFMEA handoff workflow |