Two Lessons Learned on Requirements

On the path to helping our clients achieve success with their medical device developments, here are two lessons we have learned about requirements.

Lesson 1: Capture them

From the moment you begin discussing the details of a new product, begin describing its requirements and specifications. There are many creative ways to gather these. The key is to "set the trap" and start recording. This is a mindset and reaction. When you hear of a requirement, capture it by recording it on the fly into a document. We'll get this information into the Product Requirements Document. Over time you will have an impressive list of requirements that you can review to create clarity on the goals.

Lesson 2: Don't get distracted

It's easy to get distracted by focusing on the organization of the requirement document, the wording of requirements or going out of scope and focusing too early on the specifications. We help our clients avoid this. The goal should be to capture the requirements and refine them later. One thing to keep in mind is that there is no ideal organizational method, so don't get hung up on that. Also, specifications can remain unclear until significant development testing is conducted. Don't get too excited about defining detailed specifications before their time.

The requirements process can seem onerous, and so at PADT Medical we work closely with clients to help in every aspect of getting their idea to market, including developing requirements that enable success.

Medical Device Requirements vs. Specification

There is occasional confusion when discussing what it means to establish "requirements" for a medical device project. The word is so generic that few people agree to its meaning. One thing we have found to be helpful is to define the difference between a requirement and a specification.

We define a requirement as a medical device characteristic that would be described by the end-user or customer. It is typically a general statement of "want" about the product. We define a specification as a "metric" that measures how well that requirement is satisfied.

In an ideal world, each customer requirement would have a single measurable specification. For example, the customer might state that the medical device must be lightweight. The obvious specification (or metric) would be product weight. This is something that we can measure in the lab, compare to a competitive product and track over the course of development.

So a requirement uses customer language and a specification uses engineering language. We'll be discussing four lessons we have learned about requirements in our next posting.