Maximize Your Test System Development: Optimize Your Performance, Reliability and Usability by Starting with Good Requirements
After reading through Ralph Hutson’s blog about whether to make or buy your next test system, you may have decided you want to hire G Systems to design and build your test system. To take that step, you need to provide the test requirements; however, you may not be familiar with how to write requirements. It’s likely that you typically define the test requirements in-house as you design your test system. So, what should you consider when writing your requirements?
Your first instinct might be to ask G Systems how to write the test requirements. You would not be alone; customers frequently ask “What do I need to provide you so you can estimate the effort to complete my test system?” Since this is such a common request, I feel this is a helpful question for me to address.
Prior to delving in to details, I want to recognize this is a large topic, about which much has been written. Test requirements are addressed in a multitude of ways, such as military and industry standards, MIL-STD-499A/B/C, as well as job roles and graduate degree programs such as Systems Engineering. My goal is not to have an exhaustive discussion on the topic; it is instead to get you thinking about what to consider when writing your requirements.
The question that is perhaps the most important to ask is “What is the goal or purpose of the testing I want to perform?” You might say “I don’t know what the purpose or goal of the test system is; I was just asked by my boss or the quality department at my company to create a test and measurement system for a new product we are creating.”
In that case, to answer this question, you will need to involve all stakeholders. The stakeholders could include your customer, sales and marketing, product development team, manufacturing, and quality department. Anyone that could help you understand what must be tested and verified in order to have a successful product. The customer can tell you what is important to them in a successful product, like reliability or ease of use. Customers don’t like it when your product catches on fire or they can’t figure out how to use.
The sales and marketing team can also provide their understanding of what is important to the customer and also the vision for what the product should do. They have a front row seat to the customer. The product development team is responsible for the design and development of the product. This team knows the technical specifications they are trying to meet. They get job satisfaction knowing they created a great product. The manufacturing department is interested in creating consistent product and reducing test time. It’s all about how fast can they get the product out the door while still making great product. The quality department can provide any industry standards or company standards that must be met by the product. This gives your product great street credentials.
The answer to the first question will most likely lead to the next question: “At what stage of the product life cycle will this test system be used?” Are you trying to create the Holy Grail, the test system to end all test systems? Or do you need a test system to help the product development team verify that their specifications are met? Are you trying to create a test system to help manufacturing verify the product they are building is consistent? Does your industry require that a certain standard be met by the product? Do you need a test system for verifying the product is working properly while in the field or after it has been repaired?
At this point you may be thinking, “You just listed a bunch of questions and didn’t really answer the original question.” That is a fair statement. Let me take the example of a manufacturing test system for an electronic assembly. Below is a list of some of the test requirements you might need to provide G Systems. (I would like to thank Ralph Hutson of “Make vs. Buy” blog fame for providing this list.)
- Complete physical interface requirement
- Quantity
- Dimensions
- Connector type
- Insertions lifetime
- Complete electrical interface specifications
- Source impedance
- Load impedance requirements
- Logic families
- Analog ranges
- Hazardous voltages
- Bandwidth/clock speeds
- Stimulus definitions
- Measurement requirements
- Steps necessary to insure UUT meets its raison d’être
- Subsection(s) test requirements
- Top level test requirements
- Inter-component dependencies
- Test time or throughput requirements
- Test cost limits or budgets
- Expected test lifetime
- Maintainability requirements
- Reparability requirements
- Duplicable requirements
- Test systems’ correlation requirements
Another important, but sometimes overlooked, topic to consider is the operator of the test system. For example, is the operator an engineer on the development team or an assembler in manufacturing? An engineer might be more interested in the test system allowing for low-level diagnostics. Engineers love to get their hands dirty and really dig into a problem. An assembler might be more interested in a simple pass or fail. Does the product work or not? This will drive your requirements and also the design of the test system.
The last topic I would like to address is what you plan to do with the information you acquire from the test system. The point of the test is to gain information that will then enable your company to decide how to improve the product or decide whether you are building quality product. There is no point in performing a test if it doesn’t tell you anything of value or it takes a long time to make a determination from the test results. So you must think about what data you want to collect from the test system, how the end user will get that data, and in what form the data will be presented. You don’t want your engineers spending all day just trying to decide whether or not the specifications have been met. They won’t have any time to actually build the product, which is their main job.
In summary, when creating test requirements you need to consider the purpose of the test, where it will be used, who will run the test, and what you will do with the test results. I hope you found this helpful in defining your test requirements. As always feel free to contact G Systems if you would like to discuss your test requirements. We look forward to discussing your requirements and potentially working with you in the future.
