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


This page provides a quick overview and links to further articles.

  1. Basics (e.g., the difference between software requirements and software specifications)
  2. Regulatory requirements
  3. Tips for specifying software requirements
  4. Possibilities for support

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:

Definition:  Requirement

“need or expectation that is stated, generally implied or obligatory.”

Source: ISO 9000:2015 (3.6.4)

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

The specifications of IEC 62304 in Chapter 5.2 are formulated suboptimally. The standard confuses the various aspects of ISO 25010, on which it is based. It confuses stakeholder and software requirements, as well as software requirements and requirements for the software architecture.

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
Additional Tip

Benefit from the templates in the Medical Device University. These templates will save you much time when structuring and documenting your software 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

4. Support

Benefit from the support of the Johner Institute:

  • Do you still have questions about software development? Then, take advantage of the free micro-consulting.
  • With our Medical Device University, you will learn step-by-step how to create a lean and IEC 62304-compliant “software file” using video training. A complete set of templates takes a lot of work off your hands.

Contact us right away so that we can discuss the next steps. This will ensure that the “approval” is a success and that your software or device is quickly launched on the market.