23 Jul Best Practices for a Product Requirements Set
After many years of product development and the numbers and accolades to prove it – we’ve put together a concise list of a few best practices for developing a solid product requirements set. A product requirements set is the backbone of a successful product development effort – it affects function, performance, reliability, verification scope, and ultimately, schedule and budget, so it is important that all stakeholders participate in preparing and reviewing the document at the outset of the project. Marketing, Sales, Engineering, and Management all need to be a part of the conversation.
What makes something a requirement? “Requirement” can be a squishy term but a true product requirement is critical to developing a product that meets user needs while factoring in safety and regulatory constraints. When writing or reviewing requirements, it’s a good litmus test to consider: Will the end product suffer if we do not have this requirement? If a requirement will not add value it should not be included in the product requirements; doing so only increases the documentation burden and introduces unnecessary verification testing. If a requirement is important to a product’s success, but exceedingly difficult to meet, the engineering team should assess feasibility early in the project and work with marketing to ensure the right target is defined. Communication is critical for generating a solid requirements set.
Keep these tips in mind when developing a requirements set:
- Ensure that your requirements can be objectively verified. Avoid subjective language.Consider what is objectively verifiable – if you can’t verify it, the requirement might force you to perform time consuming validation testing, or even change the requirement late in the design project to make it testable. Words like “easily” and “comfortably” are subjective. Use specific measurements or functional descriptions in order to provide clear definition. This is the first principle in creating easily verifiable requirements.
- Allow several implementations and do not over-constrain the design unnecessarily.Provide designers the freedom to solve the actual problem at hand. Only prescribe specific implementations when absolutely necessary. As engineers, we often focus on the how rather than the what. Should we use a motor? Will it have lasers and jet boosters? We should make sure it’s got active water cooling to protect against overheating! …well, first let’s identify what it is the thing needs to do.
- If it is important (or possible) for a particular requirement to be focused then make it focused. Sometimes, if the requirement can be narrow in scope, then it will reduce the test population or scenarios that need to be verified.
- Bad: “The adapter shall support 50mL vials.” (Great, we need to test every 50ml vial!)
- Better: “The adapter shall support standard 50mL vials with a 25mm neck as defined in ISO 8362-1:2009.”
- ..if it is not important for the requirement to be specific then do not make it specific. This can save you a lot of verification effort. For example, it could be the difference between needing calibrated equipment to take a large sample of measurements vs. a quick visual inspection. Sometimes design details are best left out of the product requirements document.
- Bad: “The display shall be on the front face of the device at a 16° angle and 4″ up from the table.” (Now I need a calibrated protractor and ruler!)
- Better: “The display shall be on the front face of the device.” (Objectively verifiable, no problem. Details are left to the design team.)
- If the requirement already exists in an applicable standard, then simply reference the standard (in most cases). For example, if you state that the device must comply with IEC 61326, then by default it will be tested to survive +/-8kV air discharge. You do not need a separate requirement for this or the numerous other requirements in the standard. If you have a unique device that must exceed the standard, for example +/-20kV ESD (ouch!) then you do need a separate requirement. The beauty of just referencing standards is that there are test labs across the country who are certified to test requirements in the standards should you choose to go in that direction. In other words, the test protocol is already written and a professional test resource is available to help. In cases where the standard is ambiguous, you need to include requirements to clarify how the standard should be interpreted. For example, you might say that the device shall operate at altitudes up to 2500m, which will tell the test lab to use acceptance criteria based on that elevation.
- Other tips:
- Avoid ambiguous verbs like “have” or “include.” Instead, answer the question of why the device has a certain component, or what the component does.
- Provide rationale with the requirement using italicized text. The intent and rationale of the requirement is useful to aid interpretation, add this in to clarify why a certain measurement is identified or the purpose of an added feature.
There are many aspects to creating a solid requirements set. Be thoughtful in your wording and thorough in your research. Follow best practices for gathering requirements. Solicit input from end users, understand the market needs, review regulatory standards, and leverage other best practices that would help to guide the development of a finished product.
Want to work with us on your project? Contact us at TalkToUs@keytechinc.com to have us review your requirements set.
He received a BSEE from the University of Maine and an MSEE from the University of Maryland with a concentration in microelectronics. He is also a registered professional engineer. Outside of Key Tech, Jake and his wife stay busy chasing around their two young children.
Latest posts by Jake Cowperthwaite (see all)
- Best Practices for a Product Requirements Set - July 23, 2018
- Thinking About Testing in Product Development - January 6, 2016
- Portable Electronics and the Wicked Witch of the West - August 31, 2012