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.
System requirements can be defined as follows:
System requirements are clearly articulated statements of what a system must be able to do in order to satisfy stakeholder needs.
In addition to the stakeholder requirements, the system requirements as technical requirements form the second type of requirement.
The article on general requirements provides a taxonomy of all requirement types.
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.
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.
The term “system requirements specification” is often called system requirements or system specifications. However, the terms are not congruent:
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.
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:
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.
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 |
To express system requirements or system specifications, sentence templates such as the following are recommended:
[<requirement|condition>] the system [< enable | prohibit>] [not].
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.
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.
The manufacturer must check whether the product fulfills the requirements placed on it. This is a verification (see Fig. 1), not a validation activity.
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).
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.
What is the difference between verification and validation, and how are these terms defined? Even standards and regulations use the terms incorrectly or misleadingly. This article 1. Verification a) Definition This definition does not explain what type of “requirements” need to be confirmed by verification. Limiting these requirements to product or component requirements is recommended to avoid…
DetailsThe V-model is a development process model that was originally used for government projects (e.g., armaments). To this day, it is still anchored in many people’s minds and in standards for projects in regulated environments (e.g., medical technology, banks). This leads to disputes in teams that prefer agile development processes. This article helps to resolve…
DetailsLaws and standards formulate requirements on how medical device manufacturers must define and document the development process. Notified bodies check these requirements during audits. This article on the development process provides tips on how to design the process and how to align it with other processes, such as the risk management process. 1. Development process:…
DetailsMedical devices must comply with the legal requirements for functional safety. Unfortunately, the relevant standards and laws for medical devices do not define or use the term “functional safety.” This article provides clarity. 1. Functional safety: The background a) Who has to deal with it? The following roles must understand the concepts of functional safety:…
DetailsIEC 62366-1 uses the concept of (hazard-related) use scenario. The FDA uses the concept of critical (user) tasks. In development, one works with use cases and user stories. This diversity of terms makes a common understanding difficult. However, this is necessary to create consistent and legally compliant usability files and to avoid regulatory problems. This…
DetailsIEC 60601-1 defines a PESS, a Programmable Electronic Subsystem, as a system based on one or more central processing units, including their software and interfaces. The standard does not reveal what it means by system; in this context, it is a medical device component. For this, IEC 60601-1 sets out specific requirements for the PESS.…
Details