Design Inputs: FAQs and Examples

by J. David Giese on April 27, 2022

Introduction 🔗

Medical device design begins with design inputs. The FDA says developing your design inputs is “the single most important design control activity,” yet writing good design inputs is difficult. This article presents Innolitics’ answers questions our clients frequently ask us about design inputs and analyzes a number of poorly written example requirements.

Innolitics specializes in Software as a Medical Device (SaMD). Many of the examples are software-related, but the principles apply to all medical devices.

Reach out if you have questions or comments. If you need help writing or verifying your design inputs, or if you’re looking to outsource your medical device software development or regulatory affairs activities, we’ll be happy to help get your device on the market as quickly as possible.

Frequently Asked Questions 🔗

What is the difference between a design input and a requirement? 🔗

These terms are used interchangeably in practice. If we were to distinguish the two, we would say:

Thus, most of your design inputs will be requirements.

The regulations use the phrases “design inputs,” “requirements,” “design requirements,” and “design input requirements” without clearly distinguishing them—although they don’t use them interchangeably.

The IEC 62304 standard, Medical device software – Software life cycle processes, doesn’t use the design input term. It uses the term requirement, but without defining it. It also distinguishes between software requirements and system requirements. (See section 5.1 in particular.)

The ISO 13485 standard, Medical devices — Quality management systems — Requirements for regulatory purposes, also does not define the term requirement. However, it does refer to “design and development inputs,” though in general it uses the term requirement.

What is the difference between a requirement and a user need? 🔗

User needs are general statements of, well, what your users need! We typically write them as noun-phrases that start with with the word “To,” e.g., “To understand how the AI algorithm arrived at its recommendation…” Sometimes even an individual word is sufficient, e.g., “Portability.” Unlike requirements, such needs should be written in language that is understandable to users (user needs are similar to marketing claims in this sense).

Unlike requirements, which cannot contradict one another, user needs can be somewhat contradictory. Often the needs of one user group are in tension with the needs of another.

If you can’t express a user need in language that would make sense to a user group, then it might actually be a requirement. You can get back to the user need by asking, ‘Why is this a requirement?’ Usually this question takes you up a level of abstraction, such that you can then identify the generic user need that that requirement is meeting.

You must trace each system requirement to at least one user need.

What is the difference between a system requirement and a software requirement? 🔗

For all but the simplest devices, it’s useful to organize your requirements into a hierarchy of increasingly specific requirements. System requirements, aka product requirements, are the top-level requirements. The next level of requirements are typically split into various subsystems, each with their own requirements. Thus, the software subsystems have software requirements.

The IEC 62304 standard, the 2002 Software Validation Guidance, and the 2021 Draft Software Guidance, require that software requirements be traced to their originating system requirements, much like system requirements are traced to their originating user needs.

System requirements are often presented in a System Requirements Specification (SyRS) or Product Requirements Document (PRD). The lower-level requirements are often written by disparate team members and are presented to the FDA in separate documents. Software requirements are presented in a Software Requirements Specification (SRS). Hardware subsystems can be presented separately, too.

If your device only contains software, then your software requirements are the system requirements.

Why is it important to trace system requirements to user needs? 🔗

Tracing user needs to requirements can help you identify undocumented requirements and user needs.

As you write requirements, you might realize that some user needs are actually better placed with the requirements. Typically there are more requirements than there are user needs.

How many requirements do we need? 🔗

It’s possible to err by having too few or too many. Here are a few heuristics:

Sometimes, especially if you’re writing them for software that’s already been built, it’s easy to write requirements to prescribe a particular design. Good requirements don’t describe the design; rather, they describe the constraints the design has to fulfill.

Occasionally there might be a business reason why a particular design must be used. In this case, it makes sense to “pin part of the design down” with requirements instead of letting engineers dream up their own design. However, this should be avoided whenever possible.

How big should your requirements be? 🔗

Requirements need to be stated in terms that permit the establishment of test criteria and performance of tests to determine whether the criteria have been met. Thus, it’s usually convenient to split the requirements into small statements, each having a unique identifier that can be traced to a verification procedure. There is no regulatory reason why you couldn’t include several statements under a single identifier, but doing so will make verification more error-prone.

For example, REQ-10 has 15 statements within it; how will you know every one has been verified? You’ll need to check that your verification procedure covers each of them. But if you had split out REQ-10 into REQ-10.1, REQ-10.2, … , REQ-10.15, your traceability table would ensure your verification procedure is comprehensive.

Why can’t requirements prescribe a design? 🔗

There are a few reasons why requirements should say what is required and not how each should be met.

First, you’ll need a lot more requirements; these will make your verification more expensive. Also, a lot of verification steps won’t be especially useful since you’ll be checking secondary design choices rather than fundamental requirements the design must meet.

Second, it’ll be more costly to update the software if the desired design changes. Your requirements and verification procedures will be tied to a particular design, rather than to the requirements that design must fulfill.

For example, you could have a requirement that says:

REQ-1: The software must use Yocto to generate its operating system image.

This requirement could be verified by inspection, but it’s a bad requirement for a couple of reasons. It specifies using a particular tool, Yocto, to generate the OS image. Why Yocto? Probably because we want the images to be small and for the device to boot quickly.

But it would be better to replace this requirement with:

REQ-2: The software must boot in less than 30 seconds.

REQ-3: The OS image must be smaller than 200 MB.

These verifications will be easier and more useful. Note that REQ-1 could be met while REQ-2 and REQ-3 are not. And you’ll need to update REQ-1 if you ever switch from Yocto to a better tool. Had you used REQ-2 and REQ-3, you wouldn’t need to update your requirements or your verification procedures.

How should requirements be worded? 🔗

Typically requirements follow the form “THING must HAVE PROPERTY” or “UNDER CONDITION, THING must HAVE PROPERTY.”

Conventionally, the word “shall” has been used to denote requirements. However, we suggest using the word “must” instead of “shall.” “Shall” is ambiguous, and rarely occurs in everyday conversation. The legal community is moving to a strong preference for “must” as the clearest way to express a requirement or obligation. So states the Plain Writing Act of 2010.

(For a good discussion of “shall” and “must”, see lawyer, lexicographer, and teacher Bryan Garner’sA Dictionary of Modern Legal Usage(2d ed. 1995), pages 939-942.)

How should requirements be organized? 🔗

There are a variety of ways to organize software requirements. The best way depends on the tools you’re using. Regardless of the tool you use to collect and trace your requirements, your SRS must be “well-organized, easily navigable, and readable with the labeling and/or grouping of requirements by function” (per the 2022 Draft Software Guidance).

At Innolitics, we use a few tools to organize requirements. If we’re working with a cross-functional team, we’ll typically use Notion and its relationship properties to handle traceability. If most or all of the work is done by software engineers, we’ll often use our Regulatory Documentation Manager (RDM).

Within the broader spectrum of system requirements, it can also be helpful to organize them into a hierarchy. This can be implied in the requirement ID structure, e.g., REQ-1.2.3. Thus, you might have a layout that resembles this:

1 Functional Requirements
1.1 User System
1.1.1 After initial booting, the system must permit the creation of an admin users.
1.1.2 An admin user must be able to reset other users’ passwords.
2 Performance Requirements
2.1 The software must boot in under 30 seconds.

Only leaf nodes (e.g., 1.1.1, 1.1.2, and 2.1) are requirements. Other nodes are used to organize requirements by type (e.g., 1 and 2) and subsystems (1.1). As the system grows, you might want to introduce additional levels into the tree.

Do you recommend any tools for doing handling traceability of requirements? 🔗

This is a large topic that we hope to write about more in the future.

If you’re not sure where to start, Notion is a great place. Email us if you’d like a template.

Why does each requirement need a unique ID? 🔗

Requirements will be listed in documents submitted to the FDA. A unique ID is needed so each requirement can be referenced from other documents (including, possibly, FDA reviewer correspondence).

Can I use GitHub Issues (or Jira Issues, et al.) as requirements? 🔗

The 2022 Draft Software Guidance says:

FDA acknowledges that modern development practices may employ incremental or evolutionary software development practices. Additional forms of software requirements might be included in the submission, such as well elaborated stories, use cases, textual descriptions, screen mockups, and control flows.

Thus, the FDA is likely OK with you using GitHub issues so long as each one is uniquely identifiable, unambiguous, verifiable, and doesn’t contradict other issues. However, we generally recommend against using user stories to track your requirements.

Doing so introduces a few difficulties. First, you would need a way to address changing user stories. Say you just use a simple issue tracking system and close out issues once they’re complete. Now if requirements in Issue 403 are partially overridden by Issue 892, which are the correct requirements to include in the next regulatory submission? This can get difficult. Issue trackers tend to track changes, while the SRS needs to be a complete, unambiguous, and non-contradictory list of current requirements.

How do user interface mockups relate to software requirements? 🔗

The 2022 Draft Software Guidance says:

FDA acknowledges that modern development practices may employ incremental or evolutionary software development practices. Additional forms of software requirements might be included in the submission, such as well elaborated stories, use cases, textual descriptions, screen mockups, and control flows.

Thus, it’s fine to include user interface mockups with your other requirements.

Usually your software won’t look exactly like the user interface mockups. Thus, if mockups are included in your requirements, corresponding verification procedures must indicate how much the software can vary from the mockups.

Sometimes, if the precise design of the mockups isn’t really “required,” it might be better to treat UI mockups as if they’re design outputs rather than design inputs. Both approaches are valid; it really depends on whether it’s important to verify that the UI matches a particular design or if the suggested UI isn’t that important.

How do you verify your requirements are correct? 🔗

First, individually look at each requirement and ask whether it’s:

Examples of these are presented at the end of this article.

You can test if a requirement is verifiable by writing a verification procedure. Ambiguous, unrealistic, or negative requirements won’t be verifiable.

You can test if it’s necessary by asking: “What is the worst that could happen if we take this away?”

You can identify overly prescriptive requirements by asking why it’s stated the way it is. If another design would be OK, then you probably need to move the requirement up a level.

You can assess if a requirement is too large by determining if you can split it up into smaller, independently verifiable parts.

Second, you need to consider the requirements collectively:

How do you identify missing requirements? 🔗

Identifying missing requirements is often more difficult than identifying issues with an existing requirement. Here are a few sources of inspiration when identifying missing requirements:

User needs – Does each of your user needs have an associated system requirement? Can you think of related functionality associated with a user need that isn’t covered? (A similar analysis can be done when tracing software requirements to system requirements.)

Design outputs – Although it’s beneficial to try to write your design inputs before performing the design procedure that produces design outputs, the reality is that design is a cyclical process.

As you begin working you’ll identify new design inputs. Thus, you can identify missing requirements by looking through your design (or a prototype) and looking for areas that don’t have originating requirements.

Risk Management – Risk control measures should trace to requirements. You should probably search the MAUDE database and similar sources (i.e., Total Product Life Cycle) to identify adverse events that have occurred in your device’s product code. Such events can be used to understand the types of risks your device might have.

Standards and guidance documents – The FDA publishes a variety of guidance documents for differing device types. These documents often include requirements, written by experts, that you might not have thought of on your own.

Standards might play a similar role.

Past products or competitor products – Look through past projects or competitors’ websites.

Do you have any advice for identifying missing software requirements? 🔗

Here are a few lists of requirement types:

The 2022 Draft Cybersecurity Guidance includes a list of cybersecurity controls, many of which will result in software requirements.

Annex C of AAMI TIR57:2016, Principles for medical device security—Risk management, also has some good questions for generating cybersecurity-related requirements.

The Software Validation Guidance provides a list of software requirement areas to cover.

The IEC 62304 standard requires you to cover these areas:

  1. functional and capability requirements
    • performance (e.g., purpose of software, timing requirements),
    • physical characteristics (e.g., code language, platform, operating system),
    • computing environment (e.g., hardware, memory size, processing unit, time zone, network infrastructure) under which the software is to perform, and
    • need for compatibility with upgrades or multiple SOUP or other device versions.
  2. Software system inputs and outputs
    • data characteristics (e.g., numerical, alphanumeric, format)
    • ranges,
    • limits, and
    • defaults.
  3. interfaces between the software system and other systems
  4. software-driven alarms, warnings, and operator messages
  5. security requirements
    • those related to the compromise of sensitive information,
    • authentication,
    • authorization,
    • audit trail, and
    • communication integrity,
    • system security/malware protection.
  6. user interface requirements implemented by software
    • support for manual operations,
    • human-equipment interactions,
    • constraints on personnel, and
    • areas needing concentrated human attention.
  7. data definition and database requirements
    • form;
    • fit;
    • function.
  8. installation and acceptance requirements of the delivered medical device software at the operation and maintenance site or sites
  9. requirements related to methods of operation and maintenance
  10. requirements related to IT-network aspects:
    • networked alarms, warnings, and operator messages;
    • network protocols;
    • handling of unavailability of network services.
  11. user maintenance requirements
  12. regulatory requirements.

Who should write software requirements? 🔗

Often business analysts or project managers (PMs) will write the system requirements. It can be difficult, however, for non-engineers to write the lower level requirements.

Since engineers are often very involved with design and verification steps, it’s helpful for them to be able to write requirements.

That being said, gathering and documenting software requirements requires a different skill than software development and in our experience, many engineers aren’t interested in learning how to do it well.

Can you recommend other resources on this subject? 🔗

Yes! Ivy Hook’s concise article, Writing Good Requirements, is quite useful.

We also suggest reading chapter 21 of David A. Vogel’s, Medical Device Software: Verification, Validation, and Compliance.

Finally, although it’s not written for medical devices and it can be long-winded and fluffy in places, Suzanne Robertson and James Robertson’s book, Mastering the Requirements Process, 3rd Edition, has a lot of useful content.

Examples 🔗

Unverifiable Requirements 🔗

The system must allow the user to install upgrades, depending on user role.

This couldn’t be verified unless one knew which user roles can install upgrades. Thus, it should be rewritten: “The software must allow ‘Admin’ and ‘IT’ users to install upgrades.”

The system must support multi-touch gestures on all pages.

Unless “multi-touch gestures” is defined more precisely somewhere else in the SRS, this requirement is too vague to be verified. Which multi-touch gestures need to be supported? What will they do? It needs to be split into smaller, verifiable, requirements or “multi-touch gestures” needs to get a precise definition.

The system must be able to send email messages to users.

Without knowing when emails should be sent to users, it’s not clear how you would verify this requirement. This can be solved by making the requirement more specific: “The software must send emails to the ordering physician when the test completes.”

The system must be developed to be in compliance with FDA guidance requirements.

The FDA has a lot of guidance documents. Some, such as its “General Principles of Software Validation and Content of Premarket Submissions for Device Software Functions, provide guidance about how software should be developed. Others, such as the now outdated 2018 Cybersecurity Guidance, include requirements the software must fulfill, e.g., a user login system, encryption in transit, et al. The former guidance documents should not be listed as requirements because they don’t define what the software must do. The latter guidance documents might be valid.

Even if we assume this requirement as written, it only includes the latter group of guidance—it’s still too big and vague to verify. It should probably be removed or turned into a user need with several specific requirements tracing back to it from the relevant guidance documents.

The system must not allow unauthorized users to log in.

This example was taken from Annex C of AAMI TIR57:2016, Principles for medical device security—Risk management. It states that this requirement isn’t verifiable, since it requires “proving that the system will never allow a particular event, under any conditions.” It then suggests rewording the requirement as follows: “The system must reject unauthorized users.”

I don’t think this is a good argument. Verification doesn’t always need to prove, without any room for error, that the requirement is fully met. At some point you need to stop testing and ship the device so it can begin benefiting patients. Rewording the requirement doesn’t change this. The two requirements are logically equivalent. Any time one requirement fails, the other also fails.

One might suggest rewording this requirement again: “The system must allow users with valid passwords to log in.” This third version could be verified by attempting to log in with an invalid password and a valid password. However, even in this case you don’t know that every password will always let the user log in. Furthermore, presumably you still don’t want users without valid passwords to login too! Thus, the real problem isn’t that a negative requirement is used, but that cybersecurity requirements are difficult to verify with certainty.

Unnecessary Requirements 🔗

The system must be developed in compliance with FDA 21 CFR 820.30.

This is not a valid requirement because 21 CFR 820.30, or the design controls regulation, applies to the design process that was used to develop the software. Thus, it is not really a requirement of the software itself.

The system must include a Patient Home Page.

This requirement is unnecessary. There are almost certainly other requirements that indicate that functionality will be present on the Patient Home Page. For example, “The Patient Home Page must list all of the tests the patient has completed.” This requirement implies that the Patient Home Page exists.

The header bar must show the user’s email address and username when they hover over their profile picture.

It depends on additional context, but this requirement does not seem very important. If there’s no verification test for this feature and somehow it breaks, it’s probably fine. Furthermore, it’s the sort of feature that’s unlikely to break. Thus, it can probably be removed.

Not every aspect of the software’s functionality can or should be listed as requirements. To do this would require, more or less, that you write an SRS that is as detailed as the source code itself. Thus, requirements should be reserved for things that need to be verified.

The system is not to provide an instruction video.

Although this might be a useful assumption for the design team, it doesn’t state anything that’s required and thus is not a requirement.

Negative requirements like this are useful, so we often write them alongside our requirements and then filter them out before we generate documents for the FDA.

Prescriptive Requirements 🔗

1. On the test history table, each test must be editable, by clicking on the ‘edit’ icon.

2. Once a test is edited, there must be options to ‘save’ the entry and ‘close’ the window.

These two requirements are likely too specific and may constraint the designs available to the engineers implementing the requirements. Furthermore, if the design changes, the requirements will also need to change. It would likely be better to combine these into a single requirement that says: “The Test History Table must provide a mechanism to edit each test in it.” It would also be good to clarify what it means for the results to be editable.

Large Requirements 🔗

The software must give the short intake questionnaire if (a) the patient has completed the long questionnaire twice in the last six months, (b) the patient has donated twice in the last year, and (c) the patient has passed a physical exam in the last year, otherwise give the full intake questionnaire.

Not only would this requirement be easier to read if it was split up, but it also would ensure no side cases were missed during verification. As it is now, the verification will need to be sure to test at least four cases:

One could argue whether or not the other permutations are necessary—you can’t ever test everything!

If you split up the compound requirement you’ll ensure that each case is covered during verification (because your traceability analysis will identify any requirements without verification procedures).

Splitting up the requirement is tricky, since the logic is intertwined. Here’s one way to do it:

  1. The software must give the short intake questionnaire if all of the short intake questionnaire conditions are met, otherwise it will give the long intake questionnaire.
  2. The software must check that the patient has completed the long questionnaire twice in the last six months as a condition to taking the short intake questionnaire.
  3. The software must check that the patient has donated twice in the last year as a condition to taking the short intake questionnaire.
  4. The software must check that the patient has passed a physical exam in the last year as a condition to taking the short intake questionnaire.

To prevent these granular requirements from being too tightly coupled together we must duplicate some of their content. This might be a reason to place them under a shared node in the requirements tree, thus coupling them together. Depending on how you present your requirements, you might also be able to pull some of the duplication up into the parent node of these shared items. For example:

1 Functional Requirements:
1.3 The questionnaire selection algorithm
1.3.4 must give the short intake questionnaire, unless the patient meets the following condition (in which case it will give the full intake questionnaire): They have completed the long questionnaire twice in the last six months. They have donated twice in the last six months. They have passed a physical exam in the last year.

Get Medtech Software Tips

Subscribe using RSS

How frequently are they sent?

We send out tips about once a month.

What will I read?

Articles about software development, AI, signal and image processing, medical regulations, and other topics of interest to professionals in the medical device software industry.

You may view previous articles here.

Who creates the content?

The Innolitics team, and experts we collaborate with, write all of our articles.

Want to know more?

Contact us.