Functions and Requirements in FMEA
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.
Prerequisites: Functions and requirements are perceived, understood and treated differently (differentiation).
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[/tooltip]element of the system structure (name of the system[/tooltip]element, for example: "requirements" or "requirements from the data sheet", ...) The third level is recommended in the system structure.
5. Sample question formulation for:
Functions: „Which Functions carry out the system[/tooltip]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?"
Handling with Functions and Requirements
- 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