System requirements are technical requirements that serve as specifications for development. The system requirements are legally required and are described in a “system requirements specification.”

Content

This page gives you a quick overview of the system requirements and provides links to further articles.

  1. Basics
  2. Regulatory requirements
  3. Specifying system requirements
  4. Checking system requirements
  5. Support

1. Basics

a) Definition

System requirements can be defined as follows:

Definition: System requirements

System requirements are clearly articulated statements of what a system must be able to do in order to satisfy stakeholder needs.

Source

In addition to the stakeholder requirements, the system requirements as technical requirements form the second type of requirement.

Further information

The article on general requirements provides a taxonomy of all requirement types.

b) System requirements in the development process

Regardless of the development process (i.e., not only in the V-model but also in agile development), the system requirements are derived from the stakeholder requirements.

Eliciting system requirements is an activity in the development process

Fig. 1: The system requirements follow the stakeholder requirements during development and serve as input for development.

The “system requirements” serve as design input for development. Based on this, development designs the device or system, usually in the form of a system architecture.

The system requirements can also form the basis if development is outsourced to an engineering service provider.

c) Differentiation: system requirements and system specification

The term “system requirements specification” is often called system requirements or system specifications. However, the terms are not congruent:

  • System specifications specify how the system should behave from a black box perspective, i.e., via its interfaces (e.g., via the GUI or data interfaces). You can read more about this below.
  • The system requirements are requirements for the system “under the hood.” One example is the requirement that the system should be able to store data (in a database). The requirement for a database would already be a restriction of the solution space.
Tip

In most cases, systems can be specified sufficiently as a black box so that the system requirements become obsolete or coincide with the system specification, depending on the point of view. Standards such as IEC 62304 do not differentiate between software requirements and software specifications.

2. Regulatory requirements

Manufacturers must determine the system requirements, document them, check them for completeness and correctness, and ensure they are implemented.

These requirements can be found, for example, in the following specifications:

  • ISO 13485: in Chapter 7.3.3 (“Design and development inputs”)
  • IEC 60601-1: in Chapter 14.7 (PESS “Requirements specification”). The standard also determines many system requirements.
  • MDR respectively IVDR: in Annex II, Section 1.1, 3. and 5.
Note!

Many regulatory requirements do not distinguish precisely between the different types of requirements. In most cases, however, they at least separate the stakeholder requirements and the technical requirements.

3. Specifying system requirements

a) Black box model

The black box is recommended as a mental model to specify the system requirements consistently and completely. A black box has external (hardware) interfaces that can be used to specify the system:

Interface type Examples Specification (examples)
User Interface (UI) Software screens, touch panels, switches Mockups, prototypes based on use scenarios and user requirements
Data interfaces APIs, bus systems, web services, and other “ethernet interfaces” Definition of all interoperability levels, e.g., protocols, formats, and semantic standards
Mechanical interfaces Enclosure, handles, fastenings Drawings, CAD
Electrical interfaces Mains current Number and geometry of the cables, voltage and permitted fluctuations, capacitance of the system or phase shifts of current and voltage, expected currents, behavior in the event of a short circuit
Connection of liquids Water connection Mechanical form factor, e.g., of the hose and the thread, expected pressure range, minimum and maximum flow velocity, quality or purity of the water

b) Wording

Wording template

To express system requirements or system specifications, sentence templates such as the following are recommended:

[<requirement|condition>] the system [< enable | prohibit>] [not].

Examples

  • 30 seconds after starting, the system must show the status on the display.
  • If the field with the patient name is not filled in, the system must display a pop-up dialog with the text ‘You must first fill in the patient name’ when the save button is pressed.
  • If the #CD13 flag is not set via the CAN bus, the system must switch off the motor via PIN13.

c) Verifying the system requirements specification

Manufacturers must verify the system requirements specification, i.e., to check whether the requirements are complete, correct, precise, consistent, and testable.

The formulation template and the avoidance of “weak words” help with this. These “softening words” are strong indications of imprecise requirements documents.

Examples and tips

These include words such as sufficient, almost, circa, even, rather, easy, almost, barely, enough, little, good, often, any, hardly, small, easy, sometimes, more, usually, almost, more often, very, quickly, already, nice, other, various, different, much, numerous, first, etc.

These words can be found quickly and reliably using a tool.

Inspecting system requirements should not only include compliance with the wording guideline. Instead, it is also essential to be able to trace these back to stakeholder requirements.

4. Checking system requirements

The manufacturer must check whether the product fulfills the requirements placed on it. This is a verification (see Fig. 1), not a validation activity.

Further information

This article on verification and validation will help you to distinguish between the two.

There are many ways to verify the system requirements, e.g., through inspections and tests where the test cases are derived using black box test procedures. Test laboratories are recommended for some tests (e.g., electrical safety, EMC, and biocompatibility).

5. Support

Do you still have questions about system requirements? You will get answers in our free micro-consulting.

In the IEC 60601-1 seminar, you will learn how to specify the requirements for medical electrical equipment.

You can ensure that your devices meet the regulatory requirements through electrical safety and EMC tests, biocompatibility tests, and IT security tests.

Contact us here if you would like support in determining and verifying all relevant system requirements as quickly, efficiently, and in compliance with the law as possible. This will ensure your devices are safe and can be brought to market quickly.