How to Define Product Requirements for Medical Devices

Product requirements are statements that unambiguously define the expected function, behavior, and performance of certain features within a product. A product requirements document is a collection of the many requirements that will define the expected behavior for an entire product.

Thinking through and writing out the expected functions of a product puts Simbex clients, sales, marketing, project management and Simbex engineering all on the same page designing and documenting the same end product. The requirements document becomes the link between the product owners with the high level vision for the product and the engineering team making minute technical decisions. This foundation of product expectations between all stakeholders is crucial for a smooth development effort.

Establishing this agreement of the product’s expected behavior is the greatest value of the requirements document, but the requirements also serve as an input to testing and regulatory compliance. A well thought out requirements list becomes a high-level product verification test plan. Test teams can simply run down the requirements list and test each function using the acceptance criteria defined in the requirement to indicate a pass/fail. The requirements document is the start to a test-driven design approach. A well-established requirements document is also the gold standard for design input as required by FDA medical device development design controls.

This article discusses Simbex’s methods for developing requirements with our clients, but many of these techniques can be applied to an organization that has internal product sales, marketing, and engineering. In this case the engineering team works directly with the sales and marketing team to develop the requirements.

Typically, the team writing the product requirements has a market requirements document to reference. This is a high-level document that very broadly describes the market need and overall goals for the end product without any technical detail. The product requirements describe the technical functions needed to meet the market requirements. The process of translating the market requirements into product requirements is a back and forth between engineering and the client or sales team – the requirements gathering process. Here are some tricks that can help engineers get down into the nuts and bolts with the client and really figure out what is being asked of the engineering team.

• Ask many questions
  • Ask “The 5 Whys” – a technique to gradually get to a very specific answer
  • Ask the same questions to people in different roles; engineer, marketing, etc. – Expect to get different answers from each, so be prepared to have the client talk internally to make a final determination if necessary.
  • Utilize a common list of questions or a questionnaire that is generated by numerous functions in your company (software, quality, mechanical, electrical, etc.) so that specific questions are not overlooked.
• Focus on business requirements and product features. This can help tease out additional requirements.
• Have multiple people take notes and compare those notes after each requirements gathering session.
• Perform a brainstorming session – Brainstorming with the client as part of the requirements gathering process can expand everyone’s mind and highlight requirements that someone may have forgotten about.
• If there are potentially unattainable or stretch goal requirements, work with client to prioritize
  • Which requirements are “must haves”, which are “should haves”, and which are “nice to haves”?

In parallel with gathering requirements from the client, the engineering team writes the requirements in a common language that allows engineers at all levels as well as future engineers on the project to easily understand the expected behavior of the product. The common language is that each requirement describes a specific function with specific acceptance criteria and a specific priority qualifier without dictating a design solution. A requirement or set of requirements should be performance specific so that an engineer can design a solution without further clarification and allows design freedom. This format sets up a test-driven design mentality as each product feature can be easily tested using the performance requirement as the acceptance criteria. Here is an example of a well written requirement:

“Device must tilt a 200 pound user to 45 degree incline within 10 seconds”

This requirement alone is not specific enough to design an entire tiling device, but it does describe the function needed – tilting a user to 45 degrees. It gives specific criteria for the function – 200 pound user within 10 seconds. It also gives a “Must” priority qualifier. This requirement has no ambiguity and can be tested. The requirement does not prescribe a design solution though. The design engineer can choose from a variety of motors or actuators and a variety of different mechanical linkages to optimize the implementation of this product feature.

An example of this same requirement that prescribes a design solution:

“Device must use toggle linkage with XXX brand motor to tilt 200 pound user 45 degrees”

The original function actually required by the end customer is obscured in this requirement and the engineer is locked into a very specific design solution which may not be the optimal way to solve this problem. Phrasing the requirement this way may ultimately require more work from the engineer, either in implementing this specific motor or adjusting the requirement during the design phase. Over-defining up front is an easy way to design in unnecessary cost. This level of design detail is important to capture but should go into an engineering specification document – the document that describes the exact implementation of the product requirements.

Documenting requirements, including product description, goals, design constraints and technical performance requirements, can be challenging. The requirements are usually grouped into various categories such as regulatory or environmental. Some try to capture all the requirements with text in a

traditional outline format with numbered headings and subparagraphs. These documents can be wordy and hard to read. Others create tables for organizing requirements in a matrix style. This “trace matrix” style can be beneficial to tracking important information such as the source of requirement, the acceptance criteria and reference to verification methods or tests performed. Further, software systems exist to help track and manage requirements using direct links between requirement and verification test. Simbex uses a blend of these styles by incorporating product summary in text form, trace matrix to ensure traceability to test driven requirements and software management.

The below figures are examples of the three different requirements formatting styles mentioned above with good and not so good examples of written requirements.

At Simbex, technical leads – often systems engineers – have the requirements engineering expertise. Systems engineers have the unique position of being customer facing and having a solid understanding of customer needs but also understanding the fundamentals of the underlying technology going into the products. This is the balance needed for developing realistic product requirements that will allow the product to achieve the market requirements. Many product functions will require deep technical expertise beyond the knowledge base of the systems engineers. The interdisciplinary communication skills of the systems engineers are heavily relied upon here to connect the engineering disciplines together and coordinate a cohesive requirements document.

Requirements document development should be viewed as an iterative process just like the engineering work that will bring the required features alive. It is important to have a detailed requirements document at the start of a project to avoid feature and scope creep but it is reasonable to expect change in some requirements during the development cycle. Technical feasibility changes, engineers get creative and have new ideas, sales finally delivers that quantity forecast they have been promising, no one thought about a noise level requirement – these are all normal development changes that affect the requirements. Just like mechanical drawings, software releases, and BOMs, the requirements document should be updated often enough (with revision control of course!) to represent the most recent changes in development.

Requirements documents are too often viewed as bulky, monolithic, immovable documents where change should be avoided at all costs. In reality, as development progresses, requirements often evolve slowly. If the input documents are not updated along the way, the requirements document will end up being out of date, leading to delays and added cost come verification time. The key to keeping the requirements updated is to have an owner of the document – At Simbex, the system engineers and technical leads take on this role.

The goal for the product requirements document is to detail out specific performance features and functions a product must meet in order to be successful and meet customer needs. This detailed, cohesive list keeps both the product development and test teams aligned and moving towards the same goal. Simbex will guide our clients through the process of developing a solid requirements document to lay the foundation for a great product.