Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Handling nonfunctional requirements in DFMEA

Jimmy123

Involved In Discussions
#1
How do you handle requirements in DFMEA? For example there is a non- functional requirement like the weight of a bicycle. Do you write the the 30 kg on bicycle Level and 2 kg for each wheel and 5 kg for the frame etc. ? Or another requirement like corrosion resistent, do you write this requirement on each part?
 

Miner

Forum Moderator
Staff member
Admin
#2
This is a judgment call and also depends on whether you plan to perform a DFMEA at the system, subsystem and/or component levels. While you can definitely argue that you should consider these at all three levels, I think you can be practical about it and consider them at the level that makes the most sense. For example, the customer for a racing bike doesn't particularly care about the weight of individual components (unless they are purchasing them separately as an upgrade) but is very concerned about the total weight of the bike. This would make sense to consider at the system level. On the other hand, components will vary greatly in their resistance to corrosion, so this makes sense to consider at the component level. However, if the corrosion protection could be aggravated by the design of the assembly (say the assembly collects and holds corrosive elements), you may need to consider it again at the subsystem or system level.

Bottom line: Make sure you address it at least one time at the most relevant level, by also consider whether it should be done at multiple levels.
 

Ronen E

Problem Solver
Staff member
Super Moderator
#3
Excellent answer above. Additionally: I would think that Functional / Non-Functional is not that important in this context; this might indirectly affect the Severity rating assigned to the effect, which is what really matters.
 

Marc

Captain Nice
Staff member
Admin
#4
A quick "old man" rant:

Bicycle wise: I have one in my barn that I admit I haven't used in quite a few years. I'm not worried about corrosion should I decide to have the bike "restored' or rebuilt, all it really should be new tires. The last thing I would think about is the frame actually failing due to internal corrosion.

General: An Ohio "ride" at a state fair. The is sides of the ride's arms. There was no way to inspect them. Over the years the rides arms did, in fact, rust snd corrode. tFinally an arm broke, a person was killed.

DFEMA should address each of these. If, for example, the likelyhood of a bike frame failure would be anywhere near "common" or potentially a potential cause of a serious injury, it should be in the design FMEA.

Even using historical data for failure rate (this never has never happened), potential failures should, in my opinion, be part of a DFMEA. True, in the Ohio fair ride case, I can understand that the original designers didn't consider this as a potential failure mode. It surely will be now. I also read that the ride's manufacturer has recalled all of the rides to cut in an inspection port.
 

Cephissus

Involved In Discussions
#5
Using APIS I would describe the Weight as a "Product Characteristic" of the bike, which is equivalent to a Function but will show-up in the Requirements column like Function Performance Requirements

The treatment of corrosion is trickier, and we have decided normally to include this notion in the function, for example.

Transport cyclist "in specific environment conditions" or "in defined weather conditions".

This means that the subs-systems of the bicycle will need to operate in salty/wet conditions (In fact, one could argue the bicycle as a system is not corroded, only its components)
 
#6
When performing a DFMEAs, there are 18 different types of design requirements that should be considered. One of the 18 types is function. One of the most common mistakes of people performing DFMEAs make is turning the first column of the DFMEA into a BOM and listing functions for each of the BOM elements.

When properly performed, the DFMEA is a risk assessment of the adequacy of the design spec (hardware specs and/or software code) in defining the design requirements. Unless you are creating a scoped DFMEA, every design requirement should be listed in the Requirements column (first column) of the DFMEA. When done correctly, you will find out in most cases non-functional design requirements exceed functional design requirements. Unfortunately, 90%+ of all DFMEAs are not done correctly.
 
Top Bottom