Skip to content
logo_color
  • Free FMEA Course
  • Services
Contact Us
Contact Us
logo_color

Introduction to FMEA

5
  • What is Risk in FMEA? Why Prevention Important?
  • Introduction to FMEA | Purpose & Key Benefits
  • History of FMEA – NASA to AIAG to AIAG-VDA
  • Types of FMEA – DFMEA, PFMEA, and FMEA-MSR
  • FMEA in APQP & IATF 16949 Context

Foundations of FMEA

7
  • Function Requirement Failure in FMEA
  • Severity in FMEA (AIAG-VDA) | Explained with Examples
  • Occurrence in FMEA (AIAG-VDA) | Explained with Examples
  • Detection in FMEA (AIAG-VDA) | Explained with Examples
  • RPN vs Action Priority (AP) – Why RPN is Outdated
  • FMEA Linkages – ISO 9001, IATF 16949, APQP, PPAP.
  • Why AIAG-VDA 7-Step Approach?

Step-1: Planning & Preparation in FMEA

4
  • Step 1 – Planning & Preparation in FMEA (AIAG-VDA Standard)
  • The Five Ts in FMEA – Intent, Timing, Team, Task, Tools
  • Defining Scope, Boundaries & Assumptions in FMEA
  • Cross-Functional Team Formation in FMEA

Step 2: Structure Analysis in FMEA

4
  • Step 2 – Structure Analysis in FMEA
  • System, Subsystem, and Component Breakdown in FMEA
  • Process Flow – Structure Tree & Block Diagram in FMEA
  • Motor Stator Winding – Structure Analysis in FMEA Example

Step 3: Function Analysis in FMEA

3
  • Step 3 – Function Analysis in FMEA
  • Defining Functions & Requirements in FMEA
  • How to Write Measurable Requirements in FMEA

Step 4: Failure Analysis in FMEA

6
  • Step 4 – Failure Analysis in FMEA (Failure Modes, Effects, Causes)
  • Function Net in FMEA | Chain of Functions
  • Failure at Mode Level – Failure Modes
  • Effects of Failure in FMEA
  • Causes of Failure in FMEA (Design vs Process)
  • Cascading Failures – Failure Cause Mode Effect Relationship in FMEA

Step 5: Risk Analysis in FMEA

9
  • Current Detection Controls in FMEA
  • Current Prevention Controls in FMEA (AIAG-VDA Standard)
  • Risk Evaluation in FMEA
  • Action Priority (AP) vs RPN in FMEA
  • Action Priority in FMEA (AIAG-VDA Standard)
  • Step 5 – Risk Analysis in FMEA
  • Severity in FMEA (AIAG-VDA) | Explained with Examples
  • Occurrence in FMEA (AIAG-VDA) | Explained with Examples
  • Detection in FMEA (AIAG-VDA) | Explained with Examples

Step 6: Optimization in FMEA

2
  • Tracking & Closing Actions in FMEA
  • Step 6 – Optimization in FMEA

Step 7: Results Documentation in FMEA

3
  • Customer Communication & Lessons Learned in FMEA
  • FMEA Report (Summary Table)
  • Step 7 – Results Documentation in FMEA

1

3
  • Doc 1
  • 1.1
    • Doc 1.1
  • 1.3
    • Doc 1.3

2

1
  • 2.1
    • Doc 2.1

4

1
  • Doc 4
View Categories
  • Home
  • FMEA Knowledge base
  • Step 3: Function Analysis in FMEA
  • Defining Functions & Requirements in FMEA

Defining Functions & Requirements in FMEA

FMEA Expert
Updated on September 6, 2025

3 min read

In Step 3: Function Analysis of the AIAG-VDA 7-Step FMEA approach, the first sub-step is defining functions and requirements.

👉 This step answers two key questions:

  1. What is the item supposed to do? (Function)
  2. How well should it do it? (Requirement)

Defining functions and requirements properly is critical, because they form the foundation for identifying failures in Step 4 (Failure Analysis).


What is a Function in FMEA? #

A function describes the intended purpose or task of a system, subsystem, component, or process step.

📌 Functions should be written in clear, action-oriented terms.

Examples of Functions

  • DFMEA (Design FMEA):
    • Brake system → Provide vehicle deceleration.
    • Motor winding → Generate magnetic field.
  • PFMEA (Process FMEA):
    • Welding process → Join two metal sheets.
    • Painting process → Apply protective coating.

👉 Weak Function: “Motor rotation”
👉 Strong Function: “Provide rotation at specified torque and speed.”


What is a Requirement in FMEA? #

A requirement is the measurable criterion that determines if the function is being performed correctly.

📌 Requirements must be:

  • Specific – Clearly state what is expected.
  • Measurable – Define numerical or testable criteria.
  • Verifiable – Able to be checked through testing or inspection.

Examples of Requirements

  • Motor Function: Provide rotation.
    • Requirement: 2000 ± 50 RPM at 12V supply.
  • Brake Function: Provide vehicle deceleration.
    • Requirement: Stop from 100 km/h within 40 m.
  • Welding Function: Join two metal sheets.
    • Requirement: Weld strength ≥ 5 kN shear load.

👉 Weak Requirement: “Strong enough weld.”
👉 Strong Requirement: “Weld must withstand 5 kN shear load.”


Why Functions & Requirements Must Be Defined Together #

  • Functions show intent (what should happen).
  • Requirements show criteria (how success is measured).
  • Without requirements, teams cannot identify when a function has failed.

📌 Example – Bolting Process (PFMEA):

  • Function: Secure bolt in assembly.
  • Requirement: Torque 100 ± 5 Nm.
  • Failure = Under-torque (<95 Nm) or Over-torque (>105 Nm).

Industry Examples – Functions & Requirements #

DFMEA – Electric Motor Stator

  • Function: Generate magnetic flux.
  • Requirement: Maintain flux density at 1.2 T ± 0.1.

PFMEA – Painting Process

  • Function: Apply corrosion protection coating.
  • Requirement: 30 ± 5 microns coating thickness.

FMEA-MSR – ABS Braking System

  • Function: Monitor wheel speed.
  • Requirement: Detect slip ratio within 20 ms.

Best Practices for Writing Functions & Requirements #

  1. Always use action verbs in functions (e.g., provide, generate, deliver, apply).
  2. Ensure requirements are quantifiable (numbers, tolerances, time limits).
  3. Define both primary and secondary functions.
  4. Link requirements to customer and regulatory specifications.
  5. Review definitions with the cross-functional team for clarity.

Common Mistakes to Avoid #

  • Writing vague functions (“Motor rotates” instead of measurable criteria).
  • Using subjective requirements (“good strength” instead of “≥ 5 kN shear load”).
  • Ignoring secondary functions (comfort, durability, appearance).
  • Not linking functions/requirements to customer-specific requirements (CSRs).

Case Study – Seatbelt DFMEA #

  • Function: Restrain passenger in case of crash.
  • Requirement: Withstand 10 kN tensile force for 5 seconds.
  • Failure Mode (Step 4): Seatbelt breaks under 6 kN force.
    👉 Because the function & requirement were defined clearly, the team could identify the failure and take preventive actions (material upgrade).

Key Takeaways #

  • Function = What the item/process should do.
  • Requirement = How well it should do it (measurable criteria).
  • Functions must always be paired with requirements for effective FMEA.
  • Clear functions & requirements → enable accurate failure analysis.

Next Lesson #

👉 Continue with Lesson 3.4.2: How to Write Measurable Requirements in FMEA

Updated on September 6, 2025

Are this content helpful..

  • Happy
  • Normal
  • Sad

Share This Article :

  • Facebook
  • X
  • LinkedIn
  • Pinterest
Step 3 – Function Analysis in FMEAHow to Write Measurable Requirements in FMEA

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Table of Contents
  • What is a Function in FMEA?
  • What is a Requirement in FMEA?
  • Why Functions & Requirements Must Be Defined Together
  • Industry Examples – Functions & Requirements
  • Best Practices for Writing Functions & Requirements
  • Common Mistakes to Avoid
  • Case Study – Seatbelt DFMEA
  • Key Takeaways
  • Next Lesson
  • Free FMEA Course
  • Services
Contact Us
Contact Us
logo_color

One touch solution for FMEA documentation training or creation and support.

Learn

  • Knowledge base
  • Training
  • Newsletter

Company

  • About Us
  • Contact
  • Services
  • Products

Connect

© 2025 Quality Assist

Powered by Quality Assist