Customer requirements basics
One of the more challenging aspects of medical device design is documentation. Documentation serves several purposes including but not limited to archival of design history, presentation of work to notified bodies, customer facing materials, and others. Just like your product you want to understand the purpose that these documents serve and the needs of the user who will be reviewing them.
Today I want to focus on a specific document that can be more difficult to create than you might think. The customer requirement document, sometimes called a product requirement document.
Per the FDA one of the key documents in a submission is the customer requirements document. This shows the FDA that you have done your homework in understanding the needs of any and all customers that will use your product. It sets the stage for your design work and is the foundation for your technical specifications.
Here are some of my suggested Customer requirements dos and don’ts:
customer requirements should represent the needs of your customers and the environment(s) that the product will be used in.
customer requirements should not dictate design but should set a framework to design within
customer requirements should be objective
customer requirements should be testable
customer requirements should NOT include items that are not required for the base use of your product
customer requirements should encompass any items that need to be validated for intended use of your product
Let’s dive in a bit more on each of these:
1. customer requirements should represent the needs of your customers and the environment(s) that the product will be used in
This one may seem obvious as it is the definition of the customer requirements document. In order to design a new product, you need to do the work to understand the customer, the environment, and the business path of your product. I recommend doing a thorough workflow assessment as it sets the foundation for your design work and many of the documents you will need to create. If you would like to learn more about a workflow assessment please reach out! It is one of my favorite methods to teach.
2. customer requirements should not dictate design but should set a framework to design within
If you tell the engineering team exactly what to build then creative solutions and innovation can be lost. Customer requirements should capture the need of the user in just enough detail to frame the design but not over constrain it.
For example, if you are designing a new innovative smart car one of your requirements may be “The customer must be to take control of the care at anytime”. An example of over-constraining this requirement might look like, “The customer must have a red button to push to stop the car at anytime”. The requirement of “The customer must be to take control of the care at anytime” is speaking to a safety issue. How the safety issue is solved is the innovation. A red button may be the right design, but unless a red button is dictated by a standard it may be an over-constraint to the requirement.
3. customer requirements should be measurable & 4. customer requirements should be testable & 6. customer requirements should encompass any items that need to be validated for intended use of your product
These are all important ones and a good way to gauge if you have written your customer requirement correctly. One way to do this is to write your requirement and then write how you would test this requirement. If the test is too subjective, too rigorous, not testable, or does not result in testing to your intended use, then the requirement needs to be revised. These should be checked throughout the revision process of your document to insure that the intent of these is not lost.
5. customer requirements should NOT include items that are not required for the base use of your product
This one can be one of the toughest to do. Prior to developing customer requirements, typically a market and customers’ needs assessments exercise is performed. This work is summarized in what is often called a business or marketing requirements document. The business requirement document discusses not only what the customer needs but also IF a product were developed how the market would respond. In my opinion this document is critical to the business. It is the foundation of setting intended use. It is also useful for launch planning of the product as it gauges overall customer acceptance and success. It is easy to think that this business requirement document is the same as your customer requirement document, but it serves a different purpose and is read by a different audience. I would recommend that you separate the two documents.
Again as you are approaching the end of your design and unnecessary requirements may creep in. These are requirements that I call “emotional requirements”. The product must do this because I really strongly feel that it should. Watch out for these, If the requirement is not part of the baseline of your product then it may not be necessary. The key questions to ask are: Is it a true requirement of the device? Does it affect the intended use and/or safety of the device? Would you halt the submission of the device not meeting the requirement? If the answer is NO, then it is not a customer requirement.
Now this one does get a bit tricky. Because the business side may come back and say that this is a requirement to launch the product and for the overall success in the market. So, do you take the requirement out, validate and submit the product later? That depends on your strategy and launch plan. IF the addition of your feature could affect the safety, efficacy or outcome as defined by your submission then you will need to verify/validate this feature now or in the future prior to use of the feature in the field.
If you are interested in talking more about this topic contact: k2a2consulting@gmail.com
