10 Essentials for Writing a Clear Product Requirements Document [Guide+Checklist]

We distilled the insights from our research into this one guide + checklist that we hope will help accelerate the requirements engineering phase of your medical device projects.

Sifting through medical device safety and performance requirements to create medical device requirements specifications can be an exercise of patience, but with the right preparation and approach, it can be more than just another required piece of paperwork. A well-crafted specification document can become a one-stop reference for personnel involved in the design and development process.

Over the past few years, our team has worked with dozens of systems engineers and business analysts working on ambitious medical device projects to create the ultimate list of tips on how to write product requirements documents that are a dream to author and use. 

This article was originally published on the QRA Team Blog and can be viewed by clicking here.

It has become clear to us that the most devastating project errors and delays begin in the requirements authoring stage. Moreover, agreement on requirements engineering best practices can be a fierce debate. Therefore, we distilled the insights from our research into this one guide + checklist that we hope will help accelerate the requirements engineering phase of your medical device projects.

FREE eBOOK + CHECKLIST PDF: Click here to download the free eBook PDF of this guide AND printable checklist.

1. Ensure each requirement is specific

Broad requirements are weak and difficult to verify. One way to make sure that your requirements are specific is to eliminate the use of inherently weak words such as user-friendly, reliable, capable, etc. These words are vague and do not tell the user what is being measured (see Tip #2). Your medical device requirements specifications should be able to stand-alone without supplementary information to explain what “user-friendly” or other broad terms mean.

“The device must be user-friendly” – This is a weak requirement that leaves many questions unanswered. How is “user-friendly” defined? Who are the users? Is this talking about the user-interface, ergonomics, or other features that the user interacts with?

Instead, this requirement should be broken down into a series of small, objective requirements.

2. Define requirements in measurable terms

When writing a medical device essential requirements checklist, it is important to keep in mind that you must be able to demonstrate how the requirement is met. If you cannot quickly come up with an objective way to show that the requirement has been met, it probably needs to be rewritten. Requirements should be written so that they contain a clearly measurable objective. A person unfamiliar with the product or process should be able to come in and verify requirements are met through a review of documentation.

Remember, if it isn’t documented then it didn’t happen!

3. Use imperatives such as “shall” or “must” properly and consistently

Anyone that works in the Quality or Regulatory side of medical device is well-versed in reading standards and regulatory requirements like ISO 13485 closely for shall and should statements. Your requirements document should not require a close reading to determine intent.

4. Enforce consistency of terminology and prohibit industry or company jargon

Sticking with consistent terminology makes it easier to search through requirements quickly and minimizes the risk of incorrect interpretation. It may be helpful to include a definitions or glossary section to the requirements document if conflicting terminology is a consistent concern or the requirements document will be used by personnel that may be downstream in the process and use different terminology.

This also includes consistently referring to acronyms or abbreviations. Acronyms are only useful when they are standardized and understood by all document users. Your medical device requirements specification needs to be easily understood by all personnel that may work with it.

5. Prohibit passive voice

Requirements are living documents for a product that needs to actively meet the general safety and performance requirements continuously. The requirement statements should be written in a consistent voice that reflects the active nature of the requirement.

This suggests that this flow rate is an upper limit test and only needs to happen once.

This is better, but still sounds like an upper limit that the device won’t necessarily hit.

This is clear and concise. Every unit of the device must withstand the flow rate.

6. Avoid duplicate or contradictory requirements

Requirements for regulatory agencies often overlap completely or significantly. It is important to decide on a strategy for addressing this issue early on when developing requirements. Will you list the requirement under a section for each regulator or will you lump all regulatory requirements into one section to avoid duplication? Further, regulatory requirements and functional or material requirements may overlap as well.

Depending on the structure of your template it may be easier to list the requirement as both a functional and a regulatory requirement or list all applicable regulations as a source of the requirement.

7. Keep risk in mind

Assessing risk continues to be a focus for regulatory agencies. The latest revision of ISO 13485 expanded risk assessment to the entire quality system and the new MDR 2017/745 regulations also put more emphasis on risk assessment. Working on risk assessment in conjunction with requirements is one way of mitigating risk before it getting further down the development pipeline.

Is there a process that is user-dependent and high-risk? Can a requirement be written to mitigate that risk through design?

8. Perform cross-functional design reviews to assess your requirements before implementation

The requirements document should be reviewed within your Design Controls process and the review documented accordingly. The design review requirements outlined in ISO 13485 require that personnel involved in the design stage attend the design review. Since the requirement document will be covering overall requirements there should be representatives present from all potentially affected departments. Getting input from a cross-functional team can minimize hiccups down the line when requirements are being reviewed by areas that may not have seen the requirements document before.

9. Maintain an audit trail of requirements improvements for your ISO 13485 Compliant Quality Management System (QMS)

As the project advances through development it is likely that new requirements will be added and existing requirements will be improved upon. A change control system should be in place to capture these changes. An audit trail should be maintained for all changes to requirements to ensure that the methods and reason for the changes are available for regulatory inspection.

Documenting clear reasons for the requirement change can be helpful later in the development process and can potentially reduce iterations in the development process.

10. Revisit your requirements

Once the device hits the market the requirements work is not done, especially as regulatory bodies put increasing scrutiny on clinical follow-up and risk assessment. Your device requirements are subject to change. As new information about the device is acquired through clinical trials, post-market clinical follow-up, through user experiences, and other pathways, the requirements will need to change.

This may not mean changing your requirements document for the current version of your device, but it may mean creating a new, draft medical device requirements specification that reflects this new information. This may later be used to develop a new version of the device or an alternative device to meet customer needs.

Bonus – Simple Med Device Requirement formula:

The (component) must (verb) (challenge criteria/requirement) as measured by (evidence/test).

The (component) must (verb) (challenge criteria/requirement) as (measured/verified/indicated/etc.) by (evidence/test). 

FREE eBOOK + CHECKLIST PDF: Click here to download the free eBook PDF of this guide AND printable checklist.

Conclusion

It is possible to make a requirements document that is a helpful, easy to use tool. Following these tips can help ensure you are incorporating risk assessment, meeting design controls requirements, and creating a document that will easily stand-up to a regulatory inspection. The key takeaway from this tip sheet should be that a little bit of planning and consistency in the beginning of the requirements process will save time and effort in the longer term.

Looking for a design control solution to help you bring safer medical devices to market faster with less risk?  Click here to take a quick tour of Greenlight Guru's Medical Device QMS software →