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


Requirement Management and FMEA

How they work together!

1. Aims & Prerequisites

Prerequisite validation and optimization with the support of FMEA

The use of an FMEA at a later point in time creates additional costs for test case validation and can lead to subsequent changes in requirements and thus to changes in the development product.

We therefore promote the following goals:

  1. Creation of the FMEA parallel to the requirements process (AM).
  2. Integration of FMEA's avoidance measures into requirements management.
  3. Integration of  the  detection  measurements of  the FMEA into the creation of test cases.

2. Conventional procedure

for the creation of a FMEA


  • FMEA detection measures are not included in test cases..
  • Avoidance measures of the FMEA are not used to refinement of requirements.
  • Severe faults / risks must be controlled by means of elaborate change management.

3. Procedure

Integration of the FMEA into the requirements process

Requirements that have a functional character are converted into functions.

The structural and functional analysis of the FMEA is established. With that care must be taken that the functions are matched with existing requirements.

According to the approach of the FMEA to VDA, the malfunctions are now derived. The malfunctions and their causes are used to develop preventive and discoverative measures.

Avoidance measures may include requirements that are either addressed to the product or to the process. These new requirements complete the Data Sheet or Specification booklet.

Detection measures are often test cases or can be derived from them. These complete the test cases for the product.

The figure below (fig. 2) shows the FMEA as part of the requirements development. The FMEA serves to verify a requirement set.

With regard to the development process, the optimal temporal progress with regard to the development of an FMEA in the product development is shown in the picture bellow (fig. 3).

4. Applications and Examples

We take a crankshaft. A possible requirement of a crankshaft could be "The crankshaft must be able to convert the connecting rod forces to a moment of yyy Nm". From this, one can derive the function "translatory forces transformed into torque".

A suitable possible overriding (parent) requirement of the engine could be "The engine must be able to provide a moment of yyy Nm. From this, the "generate torque" function can be derived.

With regards to the vehicle, a suitable overriding requirement would be "The vehicle must be capable of approaching a gradient of 30% smoothly." Transferring this function to a function could be "noiseless".

This depicted in a FMEA gives the following structure:


Avoidance measures

An avoidance measure such as "Ensure Material Requirements (Strength, Purity)" is again a requirement for the crankshaft, which must be checked and returned to the load book.


Detection Measures

A test case such as "Torsion / bending test" can be carried out from a discovery measure such as "Testing the material of the crankshaft".

Test cases which overlying systems (as here motor or vehicle) are to be tested and to adjust if necessary

5. Conclusion

The FMEA is not a tool for  requirement development tool. However, due to clear parallels, the FMEA can validate a top-down approach, refine requirements and assist in the creation of test cases.

It is especially important here that requirements management works hand-in-hand with FMEA creation. The disadvantage of a slightly higher effort is a complete consistency of the requirement, validated by the expert team, as well as a derivation of test cases from discovery measures. Error in the

Loads can thus be identified and test cases completed.