Requirement Management and FMEA

1. Objective (Why?)
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. Procedure (How?)
Conventional procedure for the creation of a FMEA:
Disadvantages:

• 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.

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 measuresmay include requirements that are either addressed to the product or to the process. These new requirements complete the Data Sheet or Specification booklet.
Detection measuresare 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).

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.

3. 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.