Why Aren’t the Requirements Done?

Writing and managing requirements for new product development is challenging and multi-faceted

Introduction

Defining the product requirements is central to developing a new medical device and complying with design controls. Unfortunately, in my experience consulting on dozens of medical device development projects, I find over and over again that project teams struggle to write their requirements.  And those teams are plagued with the repeated question of “Why aren’t the requirements done?” 

Short answer–it’s difficult to write good requirements for an innovative new product and there are a lot of misunderstandings about requirements that cause confusion and delays.

The slightly longer answer–writing new product requirements is a little like packing your bags for a vacation around the world. You want to include everything necessary but nothing extra. Now imagine you don’t know yet where you’re going, for how long, nor what the weather will be like with any certainty. That’s the uncertainties of new product development. And people wonder why you aren’t done packing…

This blog post aims to provide development teams with a clear understanding of what a product requirements document should encompass and some basics in creating and managing your requirements throughout development. 

DEFINITION  

Requirements don’t describe the design of a new product. They control the design by describing what the design must fulfill and by driving testing of the new design.  When teams try to explain a new design by writing elaborately worded requirements, they often end up with poor requirements and a poor explanation of product function.  It’s far better to use separate means (user workflows, UI mockups, mechanical models, etc.) to explain how a new product will work and leave the requirements to perform their primary function as controls of the design.

Most importantly for early stage product development: requirements should not be treated as commandments to be obeyed by the design engineers. On the contrary, it’s better to treat them initially as a series of questions that need to be answered during development.  Liberal usage of TBDs and placeholder values in the initial revision of the requirements documents is not lazy. It’s a proven method to point the team toward parameters that need more analysis and testing and to allow the flexibility to rapidly iterate towards an optimal design.

Product Requirements Model 

Below is a simple diagram of medical device product requirements that I’ve used with product development teams, outlining the four main areas that drive the requirements. If your team is struggling with defining what should be included in a requirements document, these are the categories of inputs you want to make sure are fully evaluated. 

1. VOC/Voice of Customer = all the amazing features and performances that will be marketed to customers
2. VOB/Voice of Business = what’s needed to make the new product profitable, things like manufacturability, serviceability, interoperability, etc.
3. Risk Analysis = safety features and everything the product must absolutely NOT do
4. Regulations and Standards = the very particular things a product must do or not do as directed by regulatory agencies

Keeping these 4 areas in mind as you proceed in product development ensures that the requirements are comprehensive and there aren’t any surprises late in development.  And don’t forget that product packaging and labeling are part of the product and need to be included in these product requirements.

In addition to the above model, there are three key steps to good requirements writing and management. 

STEP 1: DON’T FREEZE! 

Freezing requirements too early forces development teams to make hasty decisions based on incomplete knowledge that may bypass further research and learning. These poor decisions then have the illusion of being final and can end up dictating the rest of the development process.

Instead, as previously stated, treat the content of requirements documents initially as a series of questions that must be answered during development, and that reflect the team’s evolving understanding of the new product and its applications.  These unfinished requirements will drive further research, analysis, and testing work and will be able to evolve as the team’s knowledge evolves.  Some companies’ quality systems will require the requirements to be released much earlier. That’s where the TBDs and placeholder values come in handy. 

To recap: DON’T FREEZE your requirements early. They are changeable and should evolve as the team’s knowledge of the product grows.

STEP 2: JOIN FORCES

Good requirements reflect cross-functional knowledge about a new product and writing them is most definitely a team effort.  A principle of good project management is to assign a single owner responsible for each deliverable, including the product requirements document(s).  However, that owner of the product requirements should not be expected to write them alone.

For the requirements document of a new intravascular catheter, for example, the team would need detailed knowledge about the mechanical constraints, the materials and components, coatings, sterile packaging, manufacturing processes, as well as the medical procedure. No individual can be expected to be an expert in all those areas of knowledge. They may be in charge of collecting and managing all the requirements information, but they’ll need multiple experts to provide all the knowledge to write and finalize the requirements. 

And remember, going back and changing the requirements document is not just okay, it’s strongly encouraged as the development team learns more about the product and its application.

STEP 3: HANG IN THERE

Cue the slow crescendo of motivational music. Good product requirements are involved and complicated and difficult to write, but they are well worth the effort. Formal requirements documents are integral to the development process and will be crucial for long term support of production.  So poorly written requirements seriously hinder all subsequent stages of development, and eventually production and supply chain management.

Align the Triples

Product requirements are central to medical device design controls.  The simple diagram below shows the close relationship of requirements to design and to testing (and to risk analysis where risk controls are represented by requirements).  Product development can be represented by dozens of these “triples” of requirement-design-test (or 100’s or 1000’s for more complex devices).  

Traditionally, we think of writing requirements first then designing the product then testing the design against the requirements.  But product development is complex and doesn’t always follow that neat, linear script.  Information can flow in both directions in this diagram.  A design engineer may conclude that a requirement is wrong and needs to be changed.  Likewise, a test engineer may find flaws in a requirement as well as flaws in a new design.  In Test Driven Development (TDD) the tests are written first followed by the requirements and design (counterintuitive but an effective method for software development).  Given this model of triples, completing V&V means bringing all 3 elements in each triple into alignment (adjusting one or more to make them align).  

Agile-lean methods of product development embrace this evolution of requirements, enabling a smooth alignment of requirements-design-test triples.  Traditional waterfall methods make it difficult to modify requirements once they’ve been approved.  Does your company’s quality system support or hinder the alignment of these three elements?

What About Software Requirements?

If your medical device contains software then you need to define a separate set of software requirements describing the functions and features of the software.  These software requirements are considered subservient to top-level product requirements and need to be traceable to them (i.e., show which product functions are implemented in software).  Even if your medical device is all software (Software as a Medical Device or SaMD), you’ll want to define top-level requirements above the software requirements since the FDA software guidance and the IEC 62304 software standard are written around this framework of software requirements underneath top-level requirements.

In a future blog post I’ll be writing more about managing software requirements in the context of systems engineering for complex capital equipment.  Meanwhile, check out the link below for more information on writing good software requirements.

Concluding Notes

Writing and managing requirements is a big, complex topic (see links below).  In addition to the notes above, here are a few more tips to help your team on the right path to good requirements:

• Clarity in writing requirements is always important; you’re not writing great literature but you do need to make sure that all the requirements are written clearly to unambiguously communicate the intent with all stakeholders
• Your quality system needs to include a process to address ambiguous, conflicting, and missing requirements (for compliance and for the sanity of your development team)
• Requirements are hard to write and easy to criticize; keep that in mind during the inevitable arguments about them and make sure your team has effective methods to settle arguments and finalize the requirements (what I call reaching a “reluctant consensus”)

And finally, are you still managing requirements in an Excel spreadsheet or Word document?  You should look into how a modern requirements management tool can save time in V&V and serve as a robust collaboration tool for your distributed project team and partners.

Resources for Understanding and Improving Requirements Management

There’s lots more to know about writing good requirements.  The links below provide more in-depth information on this topic.

For an excellent discussion of what to do and not do in writing requirements, take a look at these 4 blog posts on ‘Elements of Requirements Style’ by Karl Wiegers (from the Jama Software blog):

https://www.jamasoftware.com/blog/elements-of-requirements-style-part-1/

https://www.jamasoftware.com/blog/elements-of-requirements-style-part-2/

https://www.jamasoftware.com/blog/elements-of-requirements-style-part-3/

https://www.jamasoftware.com/blog/elements-of-requirements-style-part-4/

Or download Karl’s whitepaper which combines the 4 blog posts: Writing High Quality Requirements

Also on Medium:  https://medium.com/swlh/elements-of-requirements-style-b6b0e92c1b13 

EARS is a simple, practical approach to making requirements more readable: https://alistairmavin.com/ears/

For a good summary of what to consider in writing software requirements, take a look at this blog post by Frances Cohen of Promenade Software:

https://promenadesoftware.com/blog/writing-good-software-requirements