Design FMEA Guide: Keep Failure Modes Tied to Requirements

Most hardware teams treat the design FMEA as paperwork due right before a program milestone. A cross-functional team sits in a conference room for two days, builds a 500-row spreadsheet, assigns arbitrary risk priority numbers, and files it away. Three weeks later, a mechanical engineer changes the bolt pattern on an enclosure flange in SolidWorks to clear a manufacturing interference. Nobody opens the risk table to check whether that change breaks the ingress protection rating or invalidates a vibration control.

A design FMEA has to be a working engineering ledger, not audit theater. When a failure mode floats free of any engineering requirement, nobody can tell whether a design change introduced new risk. This guide gives you an operating framework: anchor failure modes to parent requirements, record the engineering decisions behind each control, catch risk shifts during CAD updates, and close corrective actions with physical verification evidence.

You need three things before you start: an explicit system architecture, a documented set of engineering requirements, and an active CAD repository.

Step 1: Give every failure mode a requirement or function it threatens

A failure mode doesn't exist in a vacuum. It is the anti-function of a specified engineering requirement. Write failure modes before defining functional performance targets and engineers invent theoretical disasters that clutter the risk register while missing the real operational boundaries.

Anchor every failure mode row to a quantified functional requirement. The AIAG and VDA FMEA Handbook (2019) formalized this linkage with a seven-step approach in which structure analysis and function analysis precede failure analysis. Say requirement REQ-104 states that an optical housing must hold bore concentricity within 12 microns across -20C to +60C. The failure mode isn't simply "housing distorts." It is "housing bore loses concentricity beyond 12 microns under thermal soak."

This matters because it sets the severity rating. When a failure mode describes a generic physical behavior instead of a requirement violation, engineers argue over whether severity is an 8 or a 4. Tied to REQ-104, severity maps to the system-level effect. If 13 microns of runout causes optical beam clipping that drops signal transmission below threshold, the system requirement fixes the severity.

Put explicit requirement identifiers in the leftmost column of your register. Before anyone adds a failure mode, they point to the parent requirement ID. If no requirement exists for that failure condition, your requirements document has a gap, and you fix that first.

Step 2: Write failure modes, effects and causes against the design element, not the part number alone

Part numbers change constantly during detailed design. Tie a failure mode strictly to part number bracket-4022-rev-B and the whole analytical history breaks the moment an engineer splits the bracket into a sheet metal weldment and an extrusion, creating two new part numbers.

Write the structural analysis column against the functional design element or interface. A design element is the physical entity that fulfills a system function: the structural load path between the motor mount and the chassis, the seal interface between the upper lid and the gasket, or the thermal interface material between the power inverter and the cold plate. The part numbers on those elements will increment, split, or consolidate. The physical interfaces stay put.

Focus the root cause on the geometric, material, or environmental vulnerability your team controls. A bad cause reads "supplier sends defective seal." That belongs in a process FMEA (PFMEA) or incoming quality control inspection, not a design FMEA. A proper design cause reads "compression set of fluorosilicone elastomer exceeds 25 percent after 1,000 hours at 85C, reducing contact pressure below 0.3 MPa."

When the design element is the analytical subject, your team doesn't rewrite the risk analysis every time an assembly gets restructured. It also stops duplicate failure modes from spreading when identical fastening patterns or sealing glands show up across multiple subassemblies.

Step 3: Record the design decision behind each prevention and detection control

The controls columns in a standard design FMEA template tend to fill up with vague phrases like "good engineering practice," "FEA," or "lab test." Those entries tell a future engineer nothing about why the design is safe or which verification passed.

Every prevention control must document the engineering decision that lowered the occurrence rating. Say the occurrence rating for an aluminum bracket cracking under cyclic load dropped from a 7 to a 2. The prevention control can't say "FEA analysis completed." It has to say: minimum fillet radius set to 3.5mm to keep peak von Mises stress below 140 MPa, giving a 1.8 factor of safety against the fatigue endurance limit (calculation CALC-082). The prevention control is the design geometry or material choice, backed by a traceable calculation.

Detection controls need the same specificity. Detection isn't hoping a problem surfaces during system-level bring-up. It is a targeted evaluation protocol that catches the specific cause before tooling release. Write the detection control with the exact test parameter: static tension test per ASTM E8 on three coupon batches subjected to accelerated thermal aging.

Recording the rationale preserves the institutional memory of why a dimension or alloy was chosen. When a new engineer tries to thin a wall to save mass or cost, the design FMEA explains which failure mode that wall thickness was preventing.

Step 4: Define what triggers a DFMEA re-check when a CAD change touches a part with an open failure mode

CAD geometry changes daily. Risk tables get reviewed quarterly. That gap is the main reason hardware teams get blindsided by prototype failures. To keep your analysis useful, define the exact physical triggers that force an engineer to re-evaluate the risk table.

Set explicit geometric and interface criteria that require a design FMEA review before a CAD commit or release. Triggers should include any change to a fluid boundary or sealing gland dimension, changes to fastener edge margins, alterations to wall thicknesses on thermal conduction paths, and material specification changes. When an engineer alters these features in SolidWorks, Onshape, Fusion, or NX, the CAD change should trigger a check against the linked failure modes. You can read more about this cadence in our guide on DFMEA after design changes.

Take an engineer rerouting a wire harness inside an actuator housing to simplify assembly. The CAD model clears the dynamic envelope of the gear train by 4mm. The original design FMEA flagged harness abrasion against gear teeth as a high-severity failure mode, and the prevention control was a fixed chassis clip holding 12mm minimum clearance. The reroute silently breaks that control.

Linking CAD revisions back to the engineering constraints they affect catches these regressions. When a change violates an assumption recorded in a prevention control, the occurrence rating gets reset and the failure mode reopens until the team validates the new geometry.

Step 5: Link each DFMEA action to a change and to the verification evidence that closes it

The classic risk management failure is the phantom action closure. An engineer opens a design FMEA, sees an Action Priority rated High, assigns an action to add stiffening ribs to reduce resonant displacement, and marks it Closed two weeks later. No test report is referenced, no CAD revision is cited, and nobody verified that the ribs moved the natural frequency away from motor excitation harmonics.

An action item in a design FMEA stays open until two artifacts exist: a released configuration change that implements the prevention control, and empirical or analytical evidence that the detection control succeeded. If the action was to switch to 17-4 PH stainless steel to eliminate galling on a sliding shaft, it can't close until the drawing update is released and wear test data shows the galling has stopped.

Keep this linkage in a traceable structure, such as a verification cross reference matrix. When closing an action row, require the engineer to fill in three fields: the engineering change identifier, the verification report number, and the newly calculated occurrence or detection ranking.

If the verification test shows the mitigation missed the required performance boundary, the action stays open. The occurrence score stays high, the risk stays visible on program dashboards, and the team has to iterate instead of sweeping the issue under a spreadsheet filter.

Step 6: Review the DFMEA at design reviews against current requirements and change history

Don't treat the design FMEA as a standalone slide at a gate review. A risk table pasted as a screenshot on slide 48 means nobody reads the line items. Reviewers nod, assume someone else checked the numbers, and approve the gate.

Build the design FMEA into the assessment of subsystem maturity at formal milestones. As we describe in our overview of what hardware teams bring to a critical design review package, technical risk gets reviewed side by side with current CAD assemblies and physical test data. Filter the risk register to show every failure mode touched by a design change since the preliminary review.

Walk the panel through the high-risk lines one thread at a time: here is the parent requirement, here is the failure mode we evaluated, here is the CAD feature that prevents it, and here is the test data proving the prevention works.

This format changes the tone of a gate review. Instead of debating whether a severity number should be a 6 or a 7, the panel looks at physical evidence. If an open failure mode has no test data, or relies on a prevention control that a CAD change invalidated, the review flags it immediately. Design reviews become real technical assessments instead of procedural formalities.

Where Tandem stops

Tandem is an AI-native hardware development platform that connects design intent, requirements, CAD changes, and validation evidence in a single system. It is not an FMEA authoring tool, it does not calculate Risk Priority Numbers or Action Priorities, and it is not a quality management system (QMS).

Tandem does not generate engineering change orders (ECOs), author 2D drawings, perform design for manufacturability (DFM) analysis, or run engineering calculations. It does not replace your PLM or PDM system, and it is not CAD agnostic. Tandem integrates off the shelf with SolidWorks, Onshape, Fusion, NX, Excel, Google Sheets, and Slack, with custom integrations available for Teamcenter and 3DExperience.

Tandem is the context layer your design FMEA depends on. Your team keeps risk tables in whatever format you choose. Tandem tracks the engineering requirements that failure modes threaten, tracks the CAD modifications that touch those interfaces, and links the verification evidence needed to close risk actions. It keeps the engineering context intact across the product development lifecycle, so the design intent behind every control stays visible and connected to the underlying geometry.

Troubleshooting and what to do next

If your team's design FMEA has already gone stale, don't try to overhaul the whole spreadsheet in one marathon session. Start by auditing your highest-severity rows. Pull the top ten failure modes rated severity 8 through 10 and check whether their prevention controls still match the active CAD geometry.

Common failure patterns and their direct fixes:

1. Orphan failure modes: If rows describe component failures with no linked requirement ID, map them back to functional specifications. If no requirement exists, write the functional performance requirement first.

2. Subjective scoring disputes: If the team is deadlocked on whether an occurrence score is a 3 or a 5, look at the detection control. If no physical verification data or calibrated calculation exists, default to the higher risk score until test data says otherwise.

3. Zombie actions: If your register has action items open for six months with no progress, reassign them to the CAD owners responsible for the associated interface. Tie completion of those actions to the next scheduled drawing release.

Set one rule for your next design cycle: no CAD model enters a release workflow until the engineer can show that linked failure modes have been evaluated against the latest geometry. A risk register protects you only when it reflects the physical reality of the hardware being built.

Conclusion

A design FMEA is only as reliable as its connection to your engineering baseline. When failure modes detach from requirements, CAD revisions, and test evidence, your risk register turns into shelfware that blindsides your team during environmental testing or production scale-up.

Keeping those artifacts connected takes an active context layer. Tandem links your system requirements, CAD changes in SolidWorks, Onshape, Fusion, or NX, and incoming validation evidence in one shared system. To see how Tandem gives your hardware team full traceability from functional requirements to verification evidence, request a demo at tandem.inc.