The Essential Guide to Understanding Needs and Requirements in Medical Device Development

Success of medical device development relies heavily on properly defining needs and requirements. Unclear distinction between these concepts can lead to serious issues with product development, regulatory compliance, and ultimately patient safety. In this post, we'll explore how to create well-formed needs and requirements specifically for medical devices.

A quick sidebar: The industry uses a variety or terms when it comes to these concepts. For the purpose of this discussion, we'll use INCOSE terminology. Therefore, the terms User Needs, Customer Requirements, or expectations refer simply to Needs. Design Inputs, System Requirements, or any derived statements refer to Requirements.

The Fundamental Distinction: Needs vs. Requirements

In medical device development:

Needs represent stakeholder expectations expressed from their perspective:

• "The physicians need the insulin pump to allow single-handed operation during procedures"

  
  

Requirements represent what the system must do to fulfill those needs:

• "The insulin pump shall allow operation with one hand while maintaining accuracy within ±2%"

  
  

The VANS Framework for Evaluating Requirements

When developing requirements for medical devices, use the VANS framework to ensure quality:

V - Verifiable/ Validatable

Every need or requirement must be testable through inspection, analysis, demonstration, or test. You should be able to determine whether the requirement has been met.

Example:

• Poor: "The device shall be comfortable to hold"

• Better: "The device shall weigh less than 250g and have a grip circumference between 10-15cm"

  
  

A - Achievable

Requirements must be technically and economically feasible within your constraints (cost, schedule, technology).

Example:

• Poor: "The device shall have 100% reliability" (impossible to verify)

• Better: "The device shall have a Mean Time Between Failures (MTBF) of at least 5,000 hours"

  
  

N - Necessary

Each requirement must be essential for satisfying the stakeholder needs. This is where many teams falter by including requirements that don't directly fulfill a need.

The Necessity Challenge: Teams have a tendency to include "nice-to-have" features in their requirements because they skip the critical step of evaluating if each requirement is truly needed to satisfy the stakeholder needs. This creates complexity, cost, and potential conflicts.

How to Evaluate Necessity:

1. For each requirement, identify the specific need(s) it addresses

2. Challenge every requirement with: "If we removed this requirement, would any stakeholder need go unfulfilled?"

3. Conduct requirement elimination sessions where the team actively tries to remove requirements

4. Document the rationale that connects each requirement to a specific need

   
   

Example:

• Need: "Surgeons need to operate the device while maintaining a sterile field"

• Unnecessary Requirement: "The device shall have a touchscreen interface"

  (This doesn't directly fulfill the need - there could be other ways to operate while maintaining sterility)

• Necessary Requirement: "The device shall be operable through a barrier drape of up to 0.1mm thickness"

  (This directly addresses the sterile field need)

  
  

S - Sufficient

The complete set of requirements must fully address all stakeholder needs. This requires careful analysis to ensure nothing critical has been missed.

The Sufficiency Challenge: Teams must assess whether the collective requirements will completely satisfy each need, leaving no gaps or unaddressed aspects.

How to Evaluate Sufficiency:

1. Map each need to the complete set of requirements that address it

2. Conduct gap analysis to identify needs not fully addressed by requirements

3. Use scenarios and use cases to test whether the requirements cover all anticipated usage situations

4. Perform risk assessments to identify potential needs that might be missed

   
   

Example:

• Need: "Patients need to self-administer medication accurately in low-light conditions"

• Insufficient Requirements Set: "The device shall display dosage information" and "The device shall be usable with one hand"

• Sufficient Requirements Set: "The device shall display dosage information with minimum contrast ratio of 7:1", "The device shall operate with one hand", "The display shall be readable in ambient light conditions of 5-500 lux", and "The device shall provide tactile feedback upon successful dose delivery"

  
  

Practical Implementation Tips

• Conduct formal necessity reviews where each requirement must be defended

• Evaluate sufficiency through comprehensive requirements analysis sessions

• Document rationale for each requirement to help future teams understand why it exists

• Map requirements to specific verification methods early in development

  
  

Conclusion

The VANS framework provides a powerful approach for evaluating medical device requirements, with particular attention needed on Necessary and Sufficient characteristics. By rigorously applying these principles, development teams can avoid the common pitfalls of unnecessary complexity while ensuring all stakeholder needs are fully addressed—ultimately leading to safer, more effective products for patients.

If you find yourself struggling to make distinctions between needs, requirements, verification, and validation—or how to derive design inputs from needs, reach out to me for assistance. I can help ensure that your needs and requirements fit the VANS criteria. By working together, we can guarantee that your medical device projects succeed and meet stakeholder expectations while ensuring patient safety.