Just as the Design and Development Plan (DDP) needs to be a written and reviewed document, the design and development inputs also need to be controlled documents.
The reality is the input documents are often being created simultaneously with the DDP, but before we dive into the input documents let’s backup and discuss the URS, or customer related processes again (See Chapter 7.2)
Customer Experience
The URS should focus on the customer experience.
It’s not a list of requirements, but a list of what the user wants or desires and should avoid including solutions, unless that solution is truly required.
It should answer the question of what the user experiences and what the user would want to achieve by using the product.
The user needs may include both the patient as a user and an operator perspective.
Design Input Requirements
Once the user needs have been defined, it’s typically up to design engineers to translate the user needs into the design input requirements.
While this is the job of the design engineers there should be input by other key personnel, including representatives from production, service, marketing, and others as needed.
It is extremely common for incorrect assumptions to be made, so care should be taken to remove any ambiguity.
Avoid Design Solutions
Typically, it is best to avoid design solutions as part of the input requirements, although there are scenario’s where part of a design solution may be included if it is truly required by the design.
As a simple example, a user requirement might be listed as, “the device must have a foot switch to activate operation”.
Rather than specify the foot switch, it would be better to state, “the device must have the ability to be activated with hands-free operation”.
The first scenario requires a foot switch, while the second scenario allows the engineers to offer a variety of solutions, such as, motion activation, or voice recognition.