March 20, 2025 • 14 mins
Good reliability requirements are going to drive our design decisions relating to the concept, the components, the materials, and other stuff. So, the moment to start defining reliability requirements is early in the design process. But, what makes a well-defined reliability requirement? There are five aspects it should cover: do you know what they are?
We'll describe what makes a good reliability requirement and examples of common (but not good) requirements.
Visit the podcast blog for links to reliability engineering articles and sites about "No MTBF".
DISCOVER YOUR PRODUCT DEVELOPMENT FOCUS: UNLOCK YOUR IMPACT
Take this quick quiz to cut through the 'design fog' and discover where your greatest potential lies
BI-WEEKLY EPISODES
Subscribe to this show on your favorite provider and Give us a Rating & Review to help others find us!
SELF-PACED COURSE FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Join over 300 students: Click Here.
MONTHLY DIGEST
Subscribe to the free monthly e-newsletter: newsletter.deeneyenterprises.com
Get the short version on Linked-In: Subscribe here.
About me
Dianna Deeney is a quality advocate for product development with over 25 years of experience in manufacturing. She is president of Deeney Enterprises, LLC, which helps organizations optimize their engineering processes and team perform...
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome to the Quality During Design podcast.
I'm your host, diana Deeney.
I'm reaching back into thearchive.
Four and a half years ago Ican't believe it In 2021, we
talked about five aspects ofgood reliability, goals and
requirements that are reallygoing to drive our design.
I had to revisit this topicwithin the last couple weeks and
(00:23):
thought, you know, this is agood reminder for us to have.
Every once in a while, we needto get back to basics and
understand why it is we're doingwhat we're doing, which all
leads back to our requirementsand, basically, our customers
what it is they need.
So I'm pulling back thisepisode from the archive to
reshare with you today.
(00:43):
If you're a repeat listener ofthe Quality During Design
podcast, welcome back.
If you're new to the QualityDuring Design podcast, welcome.
We talk a lot about productdevelopment and engineers
working to create new products.
Quality During Design is aphilosophy that emphasizes the
benefits of cross-functionalteam involvement in design.
(01:06):
It's also a methodology thatuses quality tools to refine
design concepts early.
So, if you're involved indesigning stuff and want or need
to know how to do it better, ifyou want to avoid surprises
during tests, design what yourcustomers really want and have
shorter design cycle, and also,if you feel like you just need
(01:27):
to do more with less and stillcreate the best, we have some
resources for you.
I invite you to visit andbookmark the website
qualityduringdesigncom.
On that website, you can accessand search through the podcast
library.
There's also additionaltraining links and other
offerings available that you canaccess for free.
If you want to stay on top ofwhat's the latest and greatest,
(01:51):
then please sign up for ourmonthly newsletter.
All of this can be done atqualityduringdesigncom Without
further delay.
I'll share this Quality, yourDesign Archive episode.
Enjoy.
Good reliability requirementsare going to drive our design
decisions relating to theconcept, the components, the
(02:13):
materials and other stuff.
So the moment to start definingreliability requirements is
early in the design process.
But what makes a well-definedreliability requirement?
There are five aspects itshould cover.
Do you know what they are?
Let's review after this briefintroduction.
Hello and welcome to QualityDuring Design, the place to use
(02:37):
quality thinking to createproducts.
Others love for less.
My name is Diana.
I'm a senior level qualityprofessional and engineer with
over 20 years of experience inmanufacturing and design.
Listen in and then join theconversation at
qualityduringdesigncom.
Today we'll describe what makesa good reliability requirement
(03:00):
In general.
One of the first steps indefining any good requirement is
characterizing our product'suse and operating needs.
This means knowing who is goingto be using our product in what
way and in what type ofenvironment.
This is one of the reasons whyI promote an early usability
engineering cycle.
This can be done in tandem witha technical assessment of any
(03:24):
new design.
Both the usability engineeringand technical assessment cycles
can be part of the conceptevaluation phase.
Think of the product's use andoperating needs in terms of the
stresses that our product isgoing to see once it's released
to market.
To see once it's released tomarket.
(03:47):
These stresses are introducedthrough the users themselves and
the environment that ourproduct is exposed to.
This could include things liketemperature and humidity.
It's knowing things like ourproduct is supposed to function
with vibration in an area withexposure to extreme temperature
cycles.
It could also be that ourproduct is cycled on and off
multiple times.
(04:08):
My car has an auto-off function.
It turns off the engine whileI'm stopped at a traffic light.
Its ignition switch is cyclingon and off multiple times during
my drives, so that switch forthe engine is going to have to
be more durable or more reliablethan my 20-year-old family van
that doesn't have that feature.
(04:30):
Is our product expected to haveroutine maintenance?
If so, then we can start todefine what type of maintenance
we're expecting, or really whatour customers could be expecting
to have to do for maintenanceof our product.
And we can consider our userstoo.
Are we designing a productwhere a user is expected to
twist, to handle on our design?
(04:51):
Is our product intended to helpusers that lack strength for
some reason Perhaps they arerecovering from a surgery or
otherwise injured or impaired orare users professional
mechanics that are used to usingmanual hand tools?
The reliability of our twistmechanism design may depend on
our user, so users may be afactor in setting the
(05:14):
reliability requirements.
Once we understand our usersand use environment and what it
is our design is supposed to do,then we can start defining good
reliability requirements.
We can start with what we knowand adjust as we move through
our design process and learnmore, but the more we can settle
(05:35):
early on, the better.
Good requirements aremeasurable.
What do good reliabilityrequirements include?
They should include fiveaspects.
Let's talk about each of these.
Measurement of time Doesn'thave to be a clock or calendar
time.
It could be cycles, distance ornumber of batches.
(05:57):
We use the measure that'sassociated with the aging of our
product.
Let's assume we're designing aproduct that gets switched on
and off, measured in cycles.
Our reliability requirementwill include a measure of on-off
cycles.
Another aspect to include inour requirement is the
(06:17):
reliability at specific pointsin time.
It may help us to think ofreliability as just one minus
the probability of failure, andit can be multi-step too,
including differentreliabilities at different
points in time.
Continuing our example of ourproduct with the reliability
measured in cycles.
(06:38):
Continuing our example of ourproduct with the reliability
measured in cycles 99%reliability is required after
600 on-off cycles of operation.
If we wanted to make this amulti-step reliability
requirement, we could add 95%reliability is required at the
end of 1,000 on-off cycles.
(06:59):
A third aspect of ourreliability requirement is a
desired confidence level.
If we don't specify aconfidence level, then we can
assume a 50% confidence level.
I've never had a team definetheir confidence level in
anything at a 50% level.
Who wants to be half confident?
We can state our desiredconfidence level as part of our
(07:22):
reliability requirement.
The confidence level that wechoose can be dependent upon
customer perception, the effecton the overall function of our
product or how serious it is ifour product doesn't work, to
name a few.
Why do we add a confidencelevel?
Because there's variation ineverything, both in how we make
(07:43):
product and how we measure it.
Setting a confidence levelaccounts for the variability
we're going to see in our testdata.
Continuing with our exampleproduct 99% reliability is
required after 600 on-off cyclesof operation with 95 percent
confidence.
(08:04):
A fourth aspect of our goodreliability requirement is a
definition of failure.
What is considered a failure orwhat is the function of the
part supposed to be?
Systems degrade, but at whatfunctional point is performance
no longer acceptable?
For our example, ourmeasurement is on-off cycles.
(08:26):
What is considered a failure?
Is it that it no longer turnson at all, or is it that it
needs to meet a specificrevolutions per minute?
Maybe our product will nolonger work at all if it doesn't
spin fast enough.
Continuing our example, ourreliability requirement has
evolved to 99%.
(08:46):
Reliability in system startupto at least 300 revolutions per
minute is required after 600on-off cycles of operation with
95% confidence.
There is one last thing we needto include.
We need to clearly state theoperating and environmental
conditions.
(09:06):
This involves more of ourusability engineering
information that we talked aboutearlier in this episode.
What are the external stressfactors?
What is our preventivemaintenance?
What is the experience level ofour products, users and
operators?
This can be added to fullydescribe our reliability
requirement.
There are some different wayswe could state this.
(09:29):
We could state it as an averagevalue of stress or a high
stress value that correspondswith most of our users.
We could use a high-low limit.
We could describe it usingprofiles of two or more stresses
, or we could describe it as adistribution.
To describe this with adistribution, we could say
(09:50):
something like when operating inan environment that follows a
normal distribution with a meanof 45 degrees C and a standard
deviation of 10 degrees C.
Building upon our example thatwe've been building on
throughout our five steps, ourfinal reliability requirement
(10:10):
could be 99%.
Reliability in system startupto at least 300 revolutions per
minute is required after 600on-off cycles of operation, with
95% confidence when operatingin an environment with a
temperature range of negative 15degrees Celsius to 40 degrees
(10:31):
Celsius.
That is a long-wordedrequirement, but it addresses
the five areas that we shouldcover when defining reliability
requirements.
Now that we've set someexpectations, what are not good
reliability requirements?
A statement like our productmust meet or exceed customer
(10:53):
expectations is not a goodreliability requirement.
Of course we want our customersto be happy, but this type of
requirement lacks any measurabletargets and doesn't at all
include any of the five aspectswe just talked about.
We need to take this very broadidea and get specific about our
product.
Maybe we'll start withunderstanding our customer
(11:16):
expectations, which we can thentranslate into numerical
measures.
Mean time to failure, mean timebefore failure or any other
variation of a mean time tosomething is not a good
reliability requirement.
This type of requirement reallybugs reliability engineers,
even though we may see itcommonly used.
(11:38):
Mean time to failure, mttf, orbetween failure is just that a
mean, an average.
Or between failure is just thata mean, an average.
We know that we can have aproduct fail at four cycles and
eight cycles and get a mean timeto failure of six cycles.
We can also have anotherproduct fail at one cycle and at
(12:00):
10 cycle and we get the samemean, six cycles.
But we wouldn't expect thesetwo different products with the
same mean time to failureperform the same in the field.
Also, for reliability engineers, using MTTF assumes a constant
failure rate as part of thespecification.
(12:20):
If we're using MTTF, then we'llneed to demonstrate or verify
through tests that the productdoes follow a constant failure
rate.
Mttf and MTBF do not adequatelydescribe the failure rate
function of a product.
On this podcast blog, I'llinclude links to articles and
websites by reliabilityengineers that beg us to stop
(12:44):
using this metric.
They also include a breakdownof the mathematics, so check
them out.
To end on an up note, we talkedabout five aspects of a good
reliability requirementMeasurement of time, reliability
at specific points in time, adesired confidence level, a
(13:05):
definition of failure and theoperating and environmental
conditions.
We can certainly start todefine these during the concept
evaluation phase, when we startboth the usability engineering
and technical assessment cyclesat the front end of our design
process.
What's today's insight toaction?
(13:26):
Take a look at yourrequirements for your new design
.
Do your reliabilityrequirements include these five
aspects?
If not, can you fill in theblanks with what you know?
If you don't know the answers,then those might be the gaps you
should start to investigate tobe able to answer.
Defining good reliabilityrequirements helps ensure that
(13:49):
your product is one that yourcustomers love, will help direct
you on the components anddesign decisions and will most
certainly help you with thetesting of your product.
Please visit this podcast blogand others at
qualityduringdesigncom.
Subscribe to the weeklynewsletter to keep in touch.
If you like this podcast orhave a suggestion for an
(14:12):
upcoming episode, let me know.
You can find me atqualityduringdesigncom on
LinkedIn or you could leave me avoicemail at 484-341-0238.
This has been a production ofDini Enterprises.
Thanks for listening.
Welcome to the Quality During Design podcast.
I'm your host, diana Deeney.
I'm reaching back into thearchive.
Four and a half years ago Ican't believe it In 2021, we
talked about five aspects ofgood reliability, goals and
requirements that are reallygoing to drive our design.
I had to revisit this topicwithin the last couple weeks and
(00:23):
thought, you know, this is agood reminder for us to have.
Every once in a while, we needto get back to basics and
understand why it is we're doingwhat we're doing, which all
leads back to our requirementsand, basically, our customers
what it is they need.
So I'm pulling back thisepisode from the archive to
reshare with you today.
(00:43):
If you're a repeat listener ofthe Quality During Design
podcast, welcome back.
If you're new to the QualityDuring Design podcast, welcome.
We talk a lot about productdevelopment and engineers
working to create new products.
Quality During Design is aphilosophy that emphasizes the
benefits of cross-functionalteam involvement in design.
(01:06):
It's also a methodology thatuses quality tools to refine
design concepts early.
So, if you're involved indesigning stuff and want or need
to know how to do it better, ifyou want to avoid surprises
during tests, design what yourcustomers really want and have
shorter design cycle, and also,if you feel like you just need
(01:27):
to do more with less and stillcreate the best, we have some
resources for you.
I invite you to visit andbookmark the website
qualityduringdesigncom.
On that website, you can accessand search through the podcast
library.
There's also additionaltraining links and other
offerings available that you canaccess for free.
If you want to stay on top ofwhat's the latest and greatest,
(01:51):
then please sign up for ourmonthly newsletter.
All of this can be done atqualityduringdesigncom Without
further delay.
I'll share this Quality, yourDesign Archive episode.
Enjoy.
Good reliability requirementsare going to drive our design
decisions relating to theconcept, the components, the
(02:13):
materials and other stuff.
So the moment to start definingreliability requirements is
early in the design process.
But what makes a well-definedreliability requirement?
There are five aspects itshould cover.
Do you know what they are?
Let's review after this briefintroduction.
Hello and welcome to QualityDuring Design, the place to use
(02:37):
quality thinking to createproducts.
Others love for less.
My name is Diana.
I'm a senior level qualityprofessional and engineer with
over 20 years of experience inmanufacturing and design.
Listen in and then join theconversation at
qualityduringdesigncom.
Today we'll describe what makesa good reliability requirement
(03:00):
In general.
One of the first steps indefining any good requirement is
characterizing our product'suse and operating needs.
This means knowing who is goingto be using our product in what
way and in what type ofenvironment.
This is one of the reasons whyI promote an early usability
engineering cycle.
This can be done in tandem witha technical assessment of any
(03:24):
new design.
Both the usability engineeringand technical assessment cycles
can be part of the conceptevaluation phase.
Think of the product's use andoperating needs in terms of the
stresses that our product isgoing to see once it's released
to market.
To see once it's released tomarket.
(03:47):
These stresses are introducedthrough the users themselves and
the environment that ourproduct is exposed to.
This could include things liketemperature and humidity.
It's knowing things like ourproduct is supposed to function
with vibration in an area withexposure to extreme temperature
cycles.
It could also be that ourproduct is cycled on and off
multiple times.
(04:08):
My car has an auto-off function.
It turns off the engine whileI'm stopped at a traffic light.
Its ignition switch is cyclingon and off multiple times during
my drives, so that switch forthe engine is going to have to
be more durable or more reliablethan my 20-year-old family van
that doesn't have that feature.
(04:30):
Is our product expected to haveroutine maintenance?
If so, then we can start todefine what type of maintenance
we're expecting, or really whatour customers could be expecting
to have to do for maintenanceof our product.
And we can consider our userstoo.
Are we designing a productwhere a user is expected to
twist, to handle on our design?
(04:51):
Is our product intended to helpusers that lack strength for
some reason Perhaps they arerecovering from a surgery or
otherwise injured or impaired orare users professional
mechanics that are used to usingmanual hand tools?
The reliability of our twistmechanism design may depend on
our user, so users may be afactor in setting the
(05:14):
reliability requirements.
Once we understand our usersand use environment and what it
is our design is supposed to do,then we can start defining good
reliability requirements.
We can start with what we knowand adjust as we move through
our design process and learnmore, but the more we can settle
(05:35):
early on, the better.
Good requirements aremeasurable.
What do good reliabilityrequirements include?
They should include fiveaspects.
Let's talk about each of these.
Measurement of time Doesn'thave to be a clock or calendar
time.
It could be cycles, distance ornumber of batches.
(05:57):
We use the measure that'sassociated with the aging of our
product.
Let's assume we're designing aproduct that gets switched on
and off, measured in cycles.
Our reliability requirementwill include a measure of on-off
cycles.
Another aspect to include inour requirement is the
(06:17):
reliability at specific pointsin time.
It may help us to think ofreliability as just one minus
the probability of failure, andit can be multi-step too,
including differentreliabilities at different
points in time.
Continuing our example of ourproduct with the reliability
measured in cycles.
(06:38):
Continuing our example of ourproduct with the reliability
measured in cycles 99%reliability is required after
600 on-off cycles of operation.
If we wanted to make this amulti-step reliability
requirement, we could add 95%reliability is required at the
end of 1,000 on-off cycles.
(06:59):
A third aspect of ourreliability requirement is a
desired confidence level.
If we don't specify aconfidence level, then we can
assume a 50% confidence level.
I've never had a team definetheir confidence level in
anything at a 50% level.
Who wants to be half confident?
We can state our desiredconfidence level as part of our
(07:22):
reliability requirement.
The confidence level that wechoose can be dependent upon
customer perception, the effecton the overall function of our
product or how serious it is ifour product doesn't work, to
name a few.
Why do we add a confidencelevel?
Because there's variation ineverything, both in how we make
(07:43):
product and how we measure it.
Setting a confidence levelaccounts for the variability
we're going to see in our testdata.
Continuing with our exampleproduct 99% reliability is
required after 600 on-off cyclesof operation with 95 percent
confidence.
(08:04):
A fourth aspect of our goodreliability requirement is a
definition of failure.
What is considered a failure orwhat is the function of the
part supposed to be?
Systems degrade, but at whatfunctional point is performance
no longer acceptable?
For our example, ourmeasurement is on-off cycles.
(08:26):
What is considered a failure?
Is it that it no longer turnson at all, or is it that it
needs to meet a specificrevolutions per minute?
Maybe our product will nolonger work at all if it doesn't
spin fast enough.
Continuing our example, ourreliability requirement has
evolved to 99%.
(08:46):
Reliability in system startupto at least 300 revolutions per
minute is required after 600on-off cycles of operation with
95% confidence.
There is one last thing we needto include.
We need to clearly state theoperating and environmental
conditions.
(09:06):
This involves more of ourusability engineering
information that we talked aboutearlier in this episode.
What are the external stressfactors?
What is our preventivemaintenance?
What is the experience level ofour products, users and
operators?
This can be added to fullydescribe our reliability
requirement.
There are some different wayswe could state this.
(09:29):
We could state it as an averagevalue of stress or a high
stress value that correspondswith most of our users.
We could use a high-low limit.
We could describe it usingprofiles of two or more stresses
, or we could describe it as adistribution.
To describe this with adistribution, we could say
(09:50):
something like when operating inan environment that follows a
normal distribution with a meanof 45 degrees C and a standard
deviation of 10 degrees C.
Building upon our example thatwe've been building on
throughout our five steps, ourfinal reliability requirement
(10:10):
could be 99%.
Reliability in system startupto at least 300 revolutions per
minute is required after 600on-off cycles of operation, with
95% confidence when operatingin an environment with a
temperature range of negative 15degrees Celsius to 40 degrees
(10:31):
Celsius.
That is a long-wordedrequirement, but it addresses
the five areas that we shouldcover when defining reliability
requirements.
Now that we've set someexpectations, what are not good
reliability requirements?
A statement like our productmust meet or exceed customer
(10:53):
expectations is not a goodreliability requirement.
Of course we want our customersto be happy, but this type of
requirement lacks any measurabletargets and doesn't at all
include any of the five aspectswe just talked about.
We need to take this very broadidea and get specific about our
product.
Maybe we'll start withunderstanding our customer
(11:16):
expectations, which we can thentranslate into numerical
measures.
Mean time to failure, mean timebefore failure or any other
variation of a mean time tosomething is not a good
reliability requirement.
This type of requirement reallybugs reliability engineers,
even though we may see itcommonly used.
(11:38):
Mean time to failure, mttf, orbetween failure is just that a
mean, an average.
Or between failure is just thata mean, an average.
We know that we can have aproduct fail at four cycles and
eight cycles and get a mean timeto failure of six cycles.
We can also have anotherproduct fail at one cycle and at
(12:00):
10 cycle and we get the samemean, six cycles.
But we wouldn't expect thesetwo different products with the
same mean time to failureperform the same in the field.
Also, for reliability engineers, using MTTF assumes a constant
failure rate as part of thespecification.
(12:20):
If we're using MTTF, then we'llneed to demonstrate or verify
through tests that the productdoes follow a constant failure
rate.
Mttf and MTBF do not adequatelydescribe the failure rate
function of a product.
On this podcast blog, I'llinclude links to articles and
websites by reliabilityengineers that beg us to stop
(12:44):
using this metric.
They also include a breakdownof the mathematics, so check
them out.
To end on an up note, we talkedabout five aspects of a good
reliability requirementMeasurement of time, reliability
at specific points in time, adesired confidence level, a
(13:05):
definition of failure and theoperating and environmental
conditions.
We can certainly start todefine these during the concept
evaluation phase, when we startboth the usability engineering
and technical assessment cyclesat the front end of our design
process.
What's today's insight toaction?
(13:26):
Take a look at yourrequirements for your new design
.
Do your reliabilityrequirements include these five
aspects?
If not, can you fill in theblanks with what you know?
If you don't know the answers,then those might be the gaps you
should start to investigate tobe able to answer.
Defining good reliabilityrequirements helps ensure that
(13:49):
your product is one that yourcustomers love, will help direct
you on the components anddesign decisions and will most
certainly help you with thetesting of your product.
Please visit this podcast blogand others at
qualityduringdesigncom.
Subscribe to the weeklynewsletter to keep in touch.
If you like this podcast orhave a suggestion for an
(14:12):
upcoming episode, let me know.
You can find me atqualityduringdesigncom on
LinkedIn or you could leave me avoicemail at 484-341-0238.
This has been a production ofDini Enterprises.
Thanks for listening.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy And Charlamagne Tha God!
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.