Diese Website verwendet Cookies.
Wir verwenden Cookies, um Funktionen für diese Webseite anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie akzeptieren unsere Cookies, wenn Sie diese Webseite nutzen.Mehr lesen

Akzeptieren
info@dietz-consultants.com

Functions and Requirements in FMEA

Against the mixing of functions and requirements in FMEA

1. Objectives & Requirements

Handling Functions and Requirements

The mixing of "functions" (eg "Diesel injection") and "requirements" (e.g. "two million load changes") can lead to uncertainties, inconsistencies in the analysis results and unnecessarily high FMEA ranges in FMEA developments.

We therefore reccomend the following goals:

  1. Functions and requirements remain "galvanically" separated in the data sheet and specification booklet as well as in the FMEA.
  2. Requirements may be an integral part of FMEA. By means of methodologically clean processing (and separation), requirements and their negations can be components of the failure networks.
  3. Since not purposeful (generated data waste and fog), the "contamination" of a variety of system elements (SE) of the FMEA with requirements is to be avoided.

Note: Already the word "requirement" is problematic. In the German language, this means that an object should enter the control area. It would have to be called "demand" (this "vagueness" has occurred in almost all norms of recent decades).

Prerequisites

Functions and requirements are perceived, understood and treated differently (differentiation).

2. Procedure

Handling Functions and Requirements

1. Clarify, define and communicate the difference and separation of functions and requirements within the framework of FMEA development.

Our Suggestion:

Functions describe the transformation of input and output variables in a system with a view to fulfilling a task / achieving  a goal.

Requirements describe "quality filter = properties" for the input and output variables of a system.

 

2. FMEA development: Presentation of the requirements in an exposed system element of the system structure (name of the system element, for example: "requirements" or "requirements from the data sheet", ...)

The third level is recommended in the system structure.

  • 1st  Level: Customer system
  • 2nd Level: Analysis object
  • 3rd  Level: Assemblies and "requirements"

3. Prevent the presentation of requirements in other system elements (SE) (e.g. on the component / component level of the system structure).

4. Link the negated requirement with the second level analysis object and first level customer system.

5. Sample question formulation for:

Functions:

  • „Which Functions carry out the system element?“
  • „What does the thing do?“ 

Requirements:

  • „Which (test / test) requirements must fulfill the system?"
  • „What are the requirements of the data sheet / specification handbook?"

 

3. Examples

Handling with Functions and Requirements

 

 

4. Results

Handling Functions and Requirements

  1. Systematic processing of the requirements from the data sheets in the defect networks and the corresponding avoidance and verification measures (including the assessment of the measures)
  2. Prevent the fact that the requirements are often displayed and edited in the growth stages of the assemblies and components.
  3. Positioning of  the requirements in a level where they are verified (the level of the analysis object and not the component plane)
  4. Consistent and streamlined analysis of requirements in the FMEA