Customers of your product would like the particular one they have to work. To work over time.
If a product meets the customer’s expectation by working as long or longer than they expected it to do so, then they may consider your product reliable.
We use reliability goals to discuss the customer’s reliability expectations. It is the establishment of requirements that converts the customer expectations to development and production obligations.
Is a Goal the Same as a Requirement?
In short, no.
Goals provide an intention, a direction, an idea, a target.
Requirements provide an obligation, a necessity, a stipulation.
Goals and objectives define concepts that provide insights and may or may not be measured or measurable. Make it reliable is a weak goal and left wide open for a range of interpretation.
The requirement to create a product that is 3 cm long may include guidance on tolerances, yet the result is measured, checked, verified, and is 3 cm long. A reliability requirement of 98% survive 2 years of use by our industrial customers is measurable (albeit difficult).
A requirement has teeth. If we don’t meet the requirement we have failed, or have to change the requirement.
Requirements are firm(er) and provide a steady reference point of information across the organization. A reliability goal may provide a surrogate value if a requirement doesn’t exist. A reliability requirement provides a point to build contracts, marketing plans, and financial forecasts.
In a medical device organization I worked with years ago, the product requirements document included small tags numbering the requirements. Length, pressure, color, and close to 350 different specific element of the document included a requirements tag.
The Quality Department had the assignment to measure each tagged requirement and to verify the design met each requirements.
The reliability objective elements did not include such tags. When I asked why, the explanation include the inability (unwieldiness?) to measure reliability.
Allowing a goal to remained ‘soft’ and unmeasured essentially negates the need to consider the reliability during the design or production process. While everyone in the organization agreed reliability was critical to the success of the product, they didn’t have a way to determine if the design met the goal or not.
Breaking Down Goals and Converting to Requirements
A product reliability goal is for the product as an entirety. It’s a system goal.
For many products, if one element of the product fails the entire product fails. If the power supply on your desktop fails, you are unable to use your computer for much other than collecting dust.
Recalling the basic series system reliability block diagram models, the reliability of the elements within a product should have a higher reliability performance than the system as a whole.
Basic modeling and apportionment permits the allocation of reliability at the system level to the various elements within the system. You can determine the specific reliability expectation for performance for the power supply.
The process to change a goal to a requirement is as simple as removing the word goal and inserting requirement. Tag the reliability objective as an obligation.
This means you are going to measure reliability as you would measure length of the case for their respective requirements.
Breaking down the requirements allows your team to stipulate reliability requirements to suppliers. For example if the system reliability requirement is 95% over 5 years, you may provide the power supply vendor the requirement of 99% reliable over 5 years, plus the local environmental and use conditions to round out the requirement using a complete reliability statement.
Testing and Requirements and Goals
Listing a set of environmental or life tests is not the same as setting reliability requirements. It is a list of tests that may or may not provide the measurement of reliability your require to verify the design’s ability to meet the requirement.
Set the requirements, allocate the requirements to the key elements of your product, then sort out how to measure reliability.
Define reliability related testing to focus on discovering failure mechanisms, or to estimate the durability (lifetime or time to failure) of the design for specific failure mechanisms.
Year ago I was on a team considering using a new type of solder joint design. The question we faced given a firm reliability requirement, was, will the new solder joints survive long enough to not affect the component and system reliability requirements?
Thus we designed a solder joint accelerated life test focused on answering that question. The same test was not informative for high temperature failure mechanisms, or metal migration mechanisms within the silicon based devices, it only helped us to understand the solder cracking failure mechanisms time to failure distribution.
Sure, some testing is to provide a guard for major unsuspected defects in a design, yet these tests (7 units at high temperature for 100 hours) does little to evaluate the time to failure information you need to measure reliability. These ‘check’ type tests are good at finding major issues (50% of all units will fail within one month of use). They are not good to check if you met your reliability requirements or not.
Summary
Goals are nice. Requirements are better, if and only if, you properly measure the product’s ability to meet the requirement.
Changing a reliability goal into a requirement is really easy, yet often hard to fully implement. Measuring reliability well does take some time, resources, and skill. The investment to set and measure reliability requirements translates a wish into a way of designing product that meet your customer’s reliability expectations.
Do you use goal or requirements and how’s that working for you? Leave a comment, share your experience in the comments section below.
Leave a Reply