When functions are confused with requirements, trouble looms. A different strategy is needed.
There is one problem that I encounter over and over again in my work with FMEA facilitators that can cause any FMEA to fail:
If requirements are treated like functions in the FMEA context, the FMEA becomes overloaded with nonsensical content and technically incorrect. The sheer amount of this type of FMEA content usually leads to the analysis not being completed.
Why?
Functions are decomposable and must be linked to function nets in the FMEA. Physically correct cause-fault sequence relationships arise from negated function nets.
Example with ballpoint pen: On the top level is the function “Convert hand movement to type image”.
If this function is decomposed, we could typically look at the ballpoint pen refill and identify the “Save ink” function. In this way, we can also assign functions and product features to the ball (the ballpoint refill).
The functional networks developed in this way are converted into failure networks by means of “negations”. These form the basis for the risk assessments of the FMEA.
What happens when requirements take the place of functions?
If you use (additional) requirements instead of functions and proceed as described, the results are not target-oriented.
In the case of the ballpoint pen example, this could look like this:
Requirement: Ballpoint pen: “Writing performance > 5000 meters”.
If this requirement is now decomposed, there is a risk that the ballpoint pen refill and the ball will receive the same requirement (loop-through effects).
- Ballpoint pen: “Writing performance > 5000 meters”.
- Refill: “Writing performance > 5000 meters”.
- Ball: “Writing performance > 5000 meters”.
This “looping through” means that in the case of failure network formation, the cause is failure to meet the requirement, the type of fault is also failure to meet the requirement, the consequence is also failure to meet the requirement.
- Cause due to ball: Writing performance < 5000 meters
- Failure type refill: Writing performance < 5000 meters
- Consequence for ballpoint pen: Writing performance < 5000 meters.
Analysis objects usually have hundreds of requirements. There is a great risk that FMEA dies the “death of fatigue” due to the “senselessness” of the described procedure and the false impression is created that FMEA is always something very time-consuming.
It is the responsibility of the FMEA method expert to guide the expert team unerringly through these shoals.
The solution is multi-stage:
Functions vs. requirements thought model: “Requirements limit / specify functions”
- Outline requirements at the top level of the system structure corresponding to the functions. In our example with ballpoint pen: “Convert motion into typeface for writing performance of > 5000 meters”.
- Potential malfunctions (negated functions and requirements):
a. Do not convert motion into type image (digital negation)
b. Convert motion to typeface at writing power < 5000 meters (thus creating realistic failure effects) - Do not decompose / “loop through” these top level requirements
- These requirements thus serve to specify the malfunctions. In doing so, requirements limit/specify functions.
Other rules for success:
Requirements that describe test cases must be immediately removed from the FMEA process of functional analysis. These show up in the FMEA as a discovery measure!
Example in the context of corrosion: “Pass salt spray test”.
We also provide this information for you in an explanatory video:
The “right” handling of requirements and functions is an essential factor for the efficiency and effectiveness of FMEA and therefore part of my opening presentation at our 18th Osnabrück FMEA Forum (Hybrid) on February 15 and 16, 2023.
If you’d like to learn more, check out our events page: https://www.dietz-academy.com/en/congress/18-osnabruecker-fmea-forum-15-02-23