Documenting software requirements in accordance with IEC 62304

Medical device manufacturers must specify and document the software requirements , regardless of the safety class of this software.

1. Basics

a) Objectives

A Software Requirements Specification (SRS) is intended to provide the software development team with the information they need to develop the software with as few queries as possible.

b) Definition

Neither IEC 62304 nor the FDA define the term “software requirements.”

The definition of the term “requirement” in ISO 9000:2015 is only of limited use:

But examples help to understand the term software requirements:

For example, a Software Requirements Specification (SRS) should describe,

• which data the software must read in, receive, or process,
• which outputs it generates in which form and how quickly,
• how it must process the data,
• what the graphical interface should look like and how it should behave when interacting with users and
• in which technical environment (e.g., hardware) the software must be able to run.

b) Differentiation between software requirements and software specifications

The two terms are not identical. Software requirements describe the requirements in general. Software specifications specify how these requirements are to be implemented. Here are some examples to illustrate this:

Software requirement	Software specification
The software system / software must display the patient name.	The system displays the patient name in 18-point Arial 20 pixels from the right edge of the screen (according to mockup screen X).
The software must be able to send the data to connected neighboring systems via HL7.	As soon as a new patient is recorded, the system sends an HL7-V2.6 ADT-A01 message via the data interface X, whereby the system is entered as the “HIS” in the MSH segment as the sending system.
The software must store the data internally with 1024-bit encryption.	—

We recommend creating a software specification because the inspections (e.g., tests) require precise specifications.

2. Regulatory requirements

a) Europe

EU regulations

Although the MDR and IVDR do not explicitly require a software requirement specification, they do require software verification. Verification is only possible if there is a specification against which the manufacturer can verify. This is exactly what a software specification or software requirement is.

IEC 62304

IEC 62304 requires manufacturers to specify the software requirements in chapter 5.2 and to verify this specification (see tips below).

The requirements for the software must concern, for example

• inputs and outputs, e.g., the user interface
• technical environment, such as hardware
• IT security

b) USA

The FDA acknowledges IEC 62304 as a “recognized standard”. However, the authority formulates the most relevant requirements for software requirements in its guidance document on software validation.

The guidance document Content of the premarket submission specifies which documents manufacturers must submit. The FDA also sets out requirements for the Software Requirements Specification.

3. Four tips for software requirements

Tip 1: Benefit from the black box model

The Johner Institute recommends specifying software as a black box, i.e., via its external interfaces.

Interface type	Elements of the SRS
User Interface (UI)	Specification of the static appearance of the UI, e.g., with mockups and style guides Description of the dynamic behavior, e.g., with interactive mockups and prototypes or with the help of diagrams for the “screen flow”
Data interfaces	Description of all four levels of the interoperability model Specification of “non-functional” aspects such as time behavior and handling of faulty inputs (fault tolerance)
Interface to the runtime environment	Specification of all permitted combinations of hardware (CPU, I/O, hard disk, RAM, screen sizes and resolutions, etc.) and software (operating system, browser types and versions, firewalls, etc.)

Manufacturers can even structure the Software Requirements Specification according to this breakdown (see tip 3).

Tip 2: Use ISO 25010

ISO 25010 offers a very helpful taxonomy of the quality characteristics of software. It can be used as a checklist to review the completeness of the requirements. This method is particularly effective when combined with the interface types (see tip 1).

Example of a question that arises from this:

„Has it been defined for the user interface how quickly it must respond to user input?“

Tip 3: Do not adopt the structure of IEC or ISO

Neither the structure of chapter 5.2 of IEC 62304 nor the structure of ISO 25010 is recommended as a chapter structure for the Software Requirements Specification.

The following chapter structure is more helpful:

1. Meta information
2. User interface
3. Data interfaces
4. Runtime environment
5. Requirements for further development phases
6. Other requirements

Tip 4: Specify as concisely as possible

An SRS should be as short as possible but as detailed as necessary.

• Do not repeat the intended purpose in the SRS
• Only reference the list of abbreviations and do not repeat them
• No long meta-information (e.g., about the objectives of the SRS)
• Instead of long lists of requirements for what a UI should look like, it is better to provide a link to a versioned mock-up
• Images and diagrams instead of lots of text