Requirements Gathering (WIP)

Purpose

Requirements gathering is the process of figuring out what we should build. It’s about finding product-market fit. Elegant, fully-tested, fully-documented software is useless if nobody wants to use it!

Requirements gathering is hard. Our startup clients may not know exactly who their users are or what they want. If they don’t know, then how can we help? There are a few ways:

• Similar medical devices have similar requirements, so we can lean into our institutional knowledge from past projects.
• We can document the requirements and ask questions to be sure they’re fully thought out. Not only is this is a worthwhile activity for most software projects, but also these documents will be submitted to the FDA in our client’s premarket submissions.
• We can suggest and run user studies to validate user needs (sometimes the FDA needs such studies too).

Although these are all good ways to help, requirements gathering is a joint activity between us engineers and the product owner. We don’t have the full business or clinical picture. This is one of the reasons why weekly progress demos and sprint planning meetings are helpful—they give our clients an opportunity to refine the requirements iteratively.

If we want to accelerate progress in the medical device industry, we need to build devices that are useful. If you want to work on devices that help patients, you should care about requirements gathering.

In this lesson we’ll discuss some best practices requirements gathering in general, as well aspects of requirements gathering that are specific to medical devices.

The Why-Spectrum

In a sense, requirements gathering is about asking “why”.

• Why are we using dcmtk? Because we need to listen for DICOM files.
• Why do we need to listen for incoming DICOM files? Because it lets us preprocess the MRIs.
• Why do we need to preprocess the MRIs? Because radiologists don’t want to wait when they open a series.

This is usually as far as we go, but we could go further:

• Why don’t radiologists want to wait? Because they want to finish their work.
• Why do radiologists want to finish their work? Because they want to help patients.
• Why do radiologists want to help patients? Because it’s their purpose.

If we keep asking why we’ll bottom out.

At each level there could be other answers: We may use dcmtk for other purposes too. Also, it doesn’t answer why we used dcmtk in particular. At a higher level, the radiologist may want to finish their work to make money or get home to their family. Therefore, the sequence of why-questions is better thought of as directed-acyclic graph than a tree with the “good” at its root.

There is a spectrum that we step up with each subsequent “why”. When we document requirements for medical devices, we divide this spectrum into different requirements levels. A simple software-only medical device may have three levels:

Level	Example
design specifications (the FDA calls these “design outputs”)	how we’re building the device
requirements (the FDA calls these “design inputs”)	what we’re building
user needs	why we’re building the device

Note that the term “requirement” can refer to all levels (as in the term requirements gathering) as well as for it’s particular level between user needs and design specifications.

It’s occasionally not clear whether a statement is a user need or a requirement. That this would occur is apparent once one recognizes that user needs and requirements lie on a spectrum. User needs are higher level and more abstract or fluffy. Try to use consistent levels of abstraction (just like you do in your code).

The goal of documenting requirements is to help us make devices safer and more effective. Overly-detailed documentation can be too complicated to be useful. (It’s like 5000-line function—you can’t keep it all in your head!) If you start to have a lot of requirements at a particular level, you may want to introduce additional levels. For example, on a larger software-and-hardware medical device we may have more levels:

Level	Example
detailed design specifications	a docstring for a function
design specifications	a project-level architectural diagram
software item requirements	granular statements about what a software component must do
software requirements	more abstract statements about a software system
system requirements	statements about what the whole device (including non-software) must do
user needs	more abstract statements about what users want

Discovery Phase

We usually start projects with a discovery phase that does the bulk of requirements gathering and provides a cost estimate to clients. Although we like agile processes, we still believe it makes sense to do a lot of requirements gathering at the beginning of projects. Hopefully most of the user needs and requirements remain fixed through out the project.

User Groups

It’s helpful to start by identify your different user groups. Different groups often have different, and possibly conflicting, needs. Writing out the groups, and possibly also their use cases and personas, can help identify their associate user needs. Similarly, knowing the user needs can help identify new requirements.

The ways in which users differ from one another are unlimited, so you should focus on user characteristics that could have a particular influence on what they need from the device, such as age, education or literacy level, sensory or physical impairments or occupational specialty.

User groups often correspond with different market segments. E.g., one of the devices we’ve worked on is used by ENTs and pediatrician. Each group had different needs and are also marketed to differently.

User Needs

TODO: fill this in

Requirements

TODO: fill this in

TODO: address these

• the use of the word “shall”
• examples of bad user needs
• examples of bad design inputs

Traceability Tables

Tracing design specifications to requirements to user needs can identify gaps. E.g., you may have a user need that isn’t being met by any requirements. You may also have some requirements that don’t map to a documented user need, thus pointing to an implicit user need you hadn’t identified previously. Medical device submissions require us to document this, usually in a traceability table.

Learning Material

Read chapters I through IV of book I of Nicomachean Ethics. Here is a pretty good translations.

Read through this tweet sequence.

Watch this short video on design controls (here are the slides and a transcript).

Read the Introduction, Section C on Design inputs, and Section D on Design outputs of the FDA’s Design Control Guidance For Medical Device Manufacturers.

Exercises