Functions and Requirements in FMEA

Against the mixing of functions and in

1. Purpose (Why?)
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:

Functions and requirements remain "galvanically" separated in the data sheet and specification booklet as well as in the FMEA.
Requirements may be an integral part ofFMEA. By means of methodologically clean processing (and separation), requirements and their negations can be components of the failure networks.
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 "" 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 (How?)
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.

Fig. 1 Model for "Functions" and "Requirements" (Source: Dietz Consultants)

Fig. 2 "Making coffee" process with requirements (source: Dietz Consultants)

2. FMEA development: Presentation of the requirements in an exposed system[/to oltip]element of the system structure (name of the system[/to oltip]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[/to oltip]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?"

Examples
Handling with Functions and Requirements

Fig. 3: System structure with SE "requirements" (source: Dietz Consultants)

[p][img="functions/4.jpg"]Fig. 4: Fault network with integrated negated [tooltip={"url":"https:\/\/www.dietz-consultants.com\/en\/glossar\/anforderungsmanagement","getter":"https:\/\/www.dietz-consultants.com\/en\/include\/ajax\/glossary.php?id=321"}]requirements (source: Dietz Consultants)[/img][/p]

3. Result

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)
Prevent the fact that the requirements are often displayed and edited in the growth stages of the assemblies and components.
Positioning of the requirements in a level where they are verified (the level of the analysis object and not the component plane)
Consistent and streamlined analysis of requirements in the FMEA