Quality during Design
Quality during Design is a production of Deeney Enterprises, LLC. It is a podcast for product designers, engineers, and anyone else who cares about creating high-quality products. In each episode, we explore the principles of quality design, from user-centered thinking to iterative development. We introduce frameworks to make better design decisions and reduce costly re-designs. We explore ways to co-work with cross-functional teams. We also talk to experts in the field about their experiences and insights.
Join host Dianna Deeney in using quality thinking throughout the design process to create products others love, for less. Whether you're a seasoned designer or just starting out, looking to improve your existing designs or start from scratch, Quality during Design is the podcast for you.
Quality during Design
QDD Redux: 5 Aspects of Good Reliability Goals and Requirements
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".
**BI-WEEKLY EPISODES**
Subscribe to this show on your favorite provider and Give us a Rating & Review to help others find us!
**ONLINE COURSE**
FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Join over 200 students in taking your FMEA to the next level. Click Here
**MONTHLY DIGEST**
Subscribe to the free monthly e-newsletter at www.qualityduringdesign.com.
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 performance by promoting the use of reliability and quality methods during design. She offers consulting services for managers and directors, training for engineers through the Quality During Design program, and other practical resources.
Welcome to the Quality During Design podcast. I'm your host, diana Deeney. I'm reaching back into the archive. Four and a half years ago I can't believe it In 2021, we talked about five aspects of good reliability, goals and requirements that are really going to drive our design. I had to revisit this topic within the last couple weeks and thought, you know, this is a good reminder for us to have. Every once in a while, we need to get back to basics and understand why it is we're doing what we're doing, which all leads back to our requirements and, basically, our customers what it is they need. So I'm pulling back this episode from the archive to reshare with you today. If you're a repeat listener of the Quality During Design podcast, welcome back. If you're new to the Quality During Design podcast, welcome. We talk a lot about product development and engineers working to create new products. Quality During Design is a philosophy that emphasizes the benefits of cross-functional team involvement in design. It's also a methodology that uses quality tools to refine design concepts early. So, if you're involved in designing stuff and want or need to know how to do it better, if you want to avoid surprises during tests, design what your customers really want and have shorter design cycle, and also, if you feel like you just need to do more with less and still create the best, we have some resources for you. I invite you to visit and bookmark the website qualityduringdesigncom. On that website, you can access and search through the podcast library. There's also additional training links and other offerings available that you can access for free. If you want to stay on top of what's the latest and greatest, then please sign up for our monthly newsletter. All of this can be done at qualityduringdesigncom Without further delay. I'll share this Quality, your Design Archive episode. Enjoy.
Speaker 1: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? Let's review after this brief introduction. Hello and welcome to Quality During Design, the place to use quality thinking to create products. Others love for less. My name is Diana. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join the conversation at qualityduringdesigncom. Today we'll describe what makes a good reliability requirement In general. One of the first steps in defining any good requirement is characterizing our product's use and operating needs. This means knowing who is going to be using our product in what way and in what type of environment. This is one of the reasons why I promote an early usability engineering cycle. This can be done in tandem with a technical assessment of any new design. Both the usability engineering and technical assessment cycles can be part of the concept evaluation phase.
Speaker 1:Think of the product's use and operating needs in terms of the stresses that our product is going to see once it's released to market. To see once it's released to market. These stresses are introduced through the users themselves and the environment that our product is exposed to. This could include things like temperature and humidity. It's knowing things like our product is supposed to function with vibration in an area with exposure to extreme temperature cycles. It could also be that our product is cycled on and off multiple times. My car has an auto-off function. It turns off the engine while I'm stopped at a traffic light. Its ignition switch is cycling on and off multiple times during my drives, so that switch for the engine is going to have to be more durable or more reliable than my 20-year-old family van that doesn't have that feature.
Speaker 1:Is our product expected to have routine maintenance? If so, then we can start to define what type of maintenance we're expecting, or really what our customers could be expecting to have to do for maintenance of our product. And we can consider our users too. Are we designing a product where a user is expected to twist, to handle on our design? Is our product intended to help users that lack strength for some reason Perhaps they are recovering from a surgery or otherwise injured or impaired or are users professional mechanics that are used to using manual hand tools? The reliability of our twist mechanism design may depend on our user, so users may be a factor in setting the reliability requirements. Once we understand our users and 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 know and adjust as we move through our design process and learn more, but the more we can settle early on, the better. Good requirements are measurable.
Speaker 1:What do good reliability requirements include? They should include five aspects. Let's talk about each of these. Measurement of time Doesn't have to be a clock or calendar time. It could be cycles, distance or number of batches. We use the measure that's associated with the aging of our product. Let's assume we're designing a product that gets switched on and off, measured in cycles. Our reliability requirement will include a measure of on-off cycles. Another aspect to include in our requirement is the reliability at specific points in time. It may help us to think of reliability as just one minus the probability of failure, and it can be multi-step too, including different reliabilities at different points in time. Continuing our example of our product with the reliability measured in cycles. Continuing our example of our product with the reliability measured in cycles 99% reliability is required after 600 on-off cycles of operation. If we wanted to make this a multi-step reliability requirement, we could add 95% reliability is required at the end of 1,000 on-off cycles.
Speaker 1:A third aspect of our reliability requirement is a desired confidence level. If we don't specify a confidence level, then we can assume a 50% confidence level. I've never had a team define their confidence level in anything at a 50% level. Who wants to be half confident? We can state our desired confidence level as part of our reliability requirement. The confidence level that we choose can be dependent upon customer perception, the effect on the overall function of our product or how serious it is if our product doesn't work, to name a few. Why do we add a confidence level? Because there's variation in everything, both in how we make product and how we measure it. Setting a confidence level accounts for the variability we're going to see in our test data. Continuing with our example product 99% reliability is required after 600 on-off cycles of operation with 95 percent confidence.
Speaker 1:A fourth aspect of our good reliability requirement is a definition of failure. What is considered a failure or what is the function of the part supposed to be? Systems degrade, but at what functional point is performance no longer acceptable? For our example, our measurement is on-off cycles. What is considered a failure? Is it that it no longer turns on at all, or is it that it needs to meet a specific revolutions per minute? Maybe our product will no longer work at all if it doesn't spin fast enough. Continuing our example, our reliability requirement has evolved to 99%. Reliability in system startup to at least 300 revolutions per minute is required after 600 on-off cycles of operation with 95% confidence.
Speaker 1:There is one last thing we need to include. We need to clearly state the operating and environmental conditions. This involves more of our usability engineering information that we talked about earlier in this episode. What are the external stress factors? What is our preventive maintenance? What is the experience level of our products, users and operators? This can be added to fully describe our reliability requirement. There are some different ways we could state this. We could state it as an average value of stress or a high stress value that corresponds with most of our users. We could use a high-low limit. We could describe it using profiles of two or more stresses, or we could describe it as a distribution. To describe this with a distribution, we could say something like when operating in an environment that follows a normal distribution with a mean of 45 degrees C and a standard deviation of 10 degrees C.
Speaker 1:Building upon our example that we've been building on throughout our five steps, our final reliability requirement could be 99%. Reliability in system startup to at least 300 revolutions per minute is required after 600 on-off cycles of operation, with 95% confidence when operating in an environment with a temperature range of negative 15 degrees Celsius to 40 degrees Celsius. That is a long-worded requirement, but it addresses the five areas that we should cover when defining reliability requirements. Now that we've set some expectations, what are not good reliability requirements? A statement like our product must meet or exceed customer expectations is not a good reliability requirement. Of course we want our customers to be happy, but this type of requirement lacks any measurable targets and doesn't at all include any of the five aspects we just talked about. We need to take this very broad idea and get specific about our product. Maybe we'll start with understanding our customer expectations, which we can then translate into numerical measures.
Speaker 1:Mean time to failure, mean time before failure or any other variation of a mean time to something is not a good reliability requirement. This type of requirement really bugs reliability engineers, even though we may see it commonly used. Mean time to failure, mttf, or between failure is just that a mean, an average. Or between failure is just that a mean, an average. We know that we can have a product fail at four cycles and eight cycles and get a mean time to failure of six cycles. We can also have another product fail at one cycle and at 10 cycle and we get the same mean, six cycles. But we wouldn't expect these two different products with the same mean time to failure perform the same in the field. Also, for reliability engineers, using MTTF assumes a constant failure rate as part of the specification. If we're using MTTF, then we'll need to demonstrate or verify through tests that the product does follow a constant failure rate. Mttf and MTBF do not adequately describe the failure rate function of a product. On this podcast blog, I'll include links to articles and websites by reliability engineers that beg us to stop using this metric. They also include a breakdown of the mathematics, so check them out.
Speaker 1:To end on an up note, we talked about five aspects of a good reliability requirement Measurement of time, reliability at specific points in time, a desired confidence level, a definition of failure and the operating and environmental conditions. We can certainly start to define these during the concept evaluation phase, when we start both the usability engineering and technical assessment cycles at the front end of our design process. What's today's insight to action? Take a look at your requirements for your new design. Do your reliability requirements include these five aspects? If not, can you fill in the blanks with what you know? If you don't know the answers, then those might be the gaps you should start to investigate to be able to answer. Defining good reliability requirements helps ensure that your product is one that your customers love, will help direct you on the components and design decisions and will most certainly help you with the testing of your product.
Speaker 1:Please visit this podcast blog and others at qualityduringdesigncom. Subscribe to the weekly newsletter to keep in touch. If you like this podcast or have a suggestion for an upcoming episode, let me know. You can find me at qualityduringdesigncom on LinkedIn or you could leave me a voicemail at 484-341-0238. This has been a production of Dini Enterprises. Thanks for listening.
