Die Systemanforderungen (engl.: System Requirements) sind technische Anforderungen, die als Vorgabe für die Entwicklung dienen. Die Systemanforderungen sind gesetzlich gefordert und werden in einer „System Requirements Specification“ beschrieben.

Inhalt

Diese Seite verschafft Ihnen einen schnellen Überblick über die Systemanforderungen und hilft mit Links auf weiterführende Fachartikel.

  1. Grundlagen
  2. Regulatorische Anforderungen
  3. Systemanforderungen spezifizieren
  4. Systemanforderungen prüfen
  5. Unterstützung

1. Grundlagen

a) Definition

Systemanforderungen lassen sich wie folgt definieren:

Definition: Systemanforderungen

Systemanforderungen sind klar formulierte Aussagen darüber, was ein System können muss, um die Bedürfnisse der Beteiligten (Stakeholder-Anforderungen) zu erfüllen.

Neben den Stakeholder-Anforderungen bilden die Systemanforderungen als technische Anforderungen den zweiten Anforderungstyp.
Weiterführende Informationen

Eine Taxonomie aller Anforderungstypen liefert der Artikel über die Anforderungen im Allgemeinen.

b) Systemanforderungen im Entwicklungsprozess

Unabhängig vom Entwicklungsprozess (also nicht nur beim V-Modell, sondern auch bei der agilen Entwicklung) ergeben sich die Systemanforderungen aus den Stakeholder-Anforderungen.

Das Erheben der Systemanforderungen - System-Requirements - ist eine Aktivität im Entwicklungsprozess

Abb. 1: Die Systemanforderungen (System Requirements) folgen in der Entwicklung den Stakeholder-Anforderungen und dienen als Input für die Entwicklung.

Die „System Requirements“ dienen der Entwicklung als Design Input. Auf dieser entwirft die Entwicklung das Produkt bzw. System, üblicherweise in Form einer Systemarchitektur.

Die Systemanforderungen können auch die Basis bilden, wenn eine Entwicklung an einen Engineering-Dienstleister ausgelagert wird.

c) Abgrenzung: Systemanforderungen und Systemspezifikation

Der englische Begriff „System Requirements Specification“ wird oft als Systemanforderungsspezifikation oder kurz Systemspezifikation übersetzt. Allerdings sind die Begriffe nicht deckungsgleich:

  • Eine Systemspezifikation spezifiziert, wie sich das System aus Blackbox-Sicht, d. h. über seine Schnittstellen (z. B. über die GUI oder Datenschnittstellen), verhalten soll. Mehr dazu lesen Sie weiter unten.
  • Die Systemanforderungen sind Anforderungen an das System auch „unter der Haube“. Ein Beispiel ist die Forderung, dass das System Daten (in einer Datenbank) speichern können soll. Dabei wäre die Forderung nach einer Datenbank bereits eine Einschränkung des Lösungsraums.
Tipp

In den meisten Fällen lassen sich Systeme ausreichend vollständig als Blackbox spezifizieren, sodass die Systemanforderungen damit je nach Sichtweise obsolet werden oder mit der Systemspezifikation zusammenfallen. Normen wie die IEC 62304 unterscheiden Software-Anforderungen und Software-Spezifikation nicht.

2. Regulatorische Anforderungen

Hersteller sind verpflichtet, die Systemanforderungen zu bestimmen, zu dokumentieren, auf Vollständigkeit und Korrektheit zu prüfen und deren Umsetzung sicherzustellen.

Diese Forderungen finden sich beispielsweise in folgenden Vorgaben:

  • ISO 13485: in Kapitel 7.3.3 („Entwicklungseingaben“)
  • IEC 60601-1: in Kapitel 14.7 (PESS „Anforderungsspezifikation“). Die Norm legt zudem viele Systemanforderungen fest.
  • MDR: in Anhang II, Abschnitt 1.1, 3. und 5.
Hinweis!

Viele regulatorische Vorgaben unterscheiden die verschiedenen Anforderungstypen nicht präzise. Sie trennen aber in den meisten Fällen zumindest die Stakeholder-Anforderungen und die technischen Anforderungen.

3. Systemanforderungen spezifizieren

a) Blackbox-Modell

Um die Systemanforderungen konsistent und vollständig zu spezifizieren, empfiehlt sich die Blackbox als mentales Modell. Eine Blackbox verfügt über externe (Hardware-)Schnittstellen, über die sich das System spezifizieren lässt:

Schnittstellentyp Beispiele Spezifikation (Beispiele)
Benutzerschnittstelle (UI) Software-Screens, Touchpanels, Schalter Mockups, Prototypen, die sich auf Basis von Use Scenarios und Nutzungsanforderungen ergeben
Datenschnittstellen APIs, Bus-Systeme, Webservices und andere „Ethernet-Schnittstellen“ Festlegung aller Interoperabilitätsebenen, z. B. der Protokolle, Formate und semantischen Standards
Mechanische Schnittstellen Gehäuse, Griffe, Befestigungen Zeichnungen, CAD
Elektrische Schnittstellen Netzstrom Anzahl und Geometrie der Kabel, Spannung und erlaubte Schwankungen, Kapazität des Systems bzw. Phasenverschiebungen von Strom und Spannung, erwartete Stromstärken, Verhalten bei Kurzschluss
Anschluss von Flüssigkeiten Wasseranschluss Mechanischer Formfaktor z. B. des Schlauchs und des Gewindes, erwarteter Druckbereich, minimale und maximale Flussgeschwindigkeit, Güte bzw. Reinheit des Wassers

b) Formulierung

Formulierungsschablone

Um Systemanforderungen bzw. Systemspezifikationen auszudrücken, empfehlen sich Satzschablonen wie die folgende:

[<Voraussetzung|Bedingung>] das System [< ermöglichen | untersagen>] [nicht].

Beispiele

  • 30 Sekunden nach dem Start muss das System auf dem Display den Status anzeigen.
  • Wenn das Feld mit dem Patientennamen nicht ausgefüllt ist, muss das System beim Drücken des Speichern-Buttons einen Popup-Dialog mit dem Text ‚Sie müssen zuerst den Patientennamen ausfüllen’ anzeigen.
  • Wenn über den CAN-Bus das Flag #CD13 nicht gesetzt ist, muss das System den Motor über PIN13 ausschalten.

c) System Requirements Specification verifizieren

Hersteller sind verpflichtet, die System Requirements Specification zu verifizieren, also zu prüfen, ob die Anforderungen vollständig, korrekt, präzise, widerspruchsfrei und testbar sind.

Dabei hilft die Formulierungsschablone sowie die Vermeidung von „weak words“. Diese „Weichmacher-Wörter“ sind starke Hinweise auf unpräzise Anforderungsdokumente.

Beispiele und Tipp

Dazu zählen Wörter wie ausreichend, beinahe, circa, eben, eher, einfach, fast, gar, genug, gering, gut, häufig, irgend*, kaum, klein, leicht, manchmal, mehr, meist, nahezu, öfter, sehr, schnell, schon, schön, sonstige, übrige, verschieden, viel, zahlreich, zunächst usw.

Diese Wörter lassen sich mit einem Werkzeug schnell und zuverlässig finden.

Die Prüfung von Systemanforderungen sollte nicht nur die Einhaltung der Formulierungsrichtlinie umfassen. Vielmehr ist es auch wichtig, diese auf Stakeholder-Anforderungen zurückführen zu können.

4. Systemanforderungen prüfen

Ob das Produkt die an es gestellten Anforderungen tatsächlich erfüllt, muss der Hersteller prüfen. Dies ist eine Verifizierung (s. Abb. 1), keine Validierungsaktivität.

Weiterführende Informationen

Dieser Artikel über die Verifizierung und Validierung hilft Ihnen, beides zu unterscheiden.

Es gibt viele Formen, um die Systemanforderungen zu verifizieren, z. B. durch Inspektionen und Tests, bei denen die Testfälle mit Blackbox-Testverfahren abgeleitet werden. Für einen Teil der Tests empfehlen sich Prüflabore (z. B. für die elektrische Sicherheit, EMV und Biokompatibilität).

5. Unterstützung

Haben Sie noch Fragen zu den Systemanforderungen? Antworten erhalten Sie in unserem kostenlosen Micro-Consulting.

Im Seminar zur IEC 60601-1 lernen Sie, die Anforderungen an medizinische elektrische Geräte zu spezifizieren.

Durch Prüfungen der elektrischen Sicherheit und EMV, durch Prüfungen der Biokompatibilität sowie durch IT-Security-Tests stellen Sie sicher, dass Ihre Produkte den regulatorischen Anforderungen genügen.

Melden Sie sich gleich hier, wenn Sie Unterstützung wünschen, um möglichst schnell, einfach und gesetzeskonform alle relevanten Systemanforderungen zu erheben und nachzuweisen. Denn damit werden Ihre Produkte sicher und kommen schnell in den Markt.


FDA Guidance ‚Interoperable Medical Devices‘

Die FDA hat das Guidance Dokument ‚Interoperable Medical Devices‘ am 6. September 2017 veröffentlicht. Die US-Behörde möchte damit der Tatsache Rechnung tragen, dass einerseits die Interoperabilität von Medizinprodukten immer wichtiger für die Gesundheitsversorgung wird. Andererseits führen Probleme mit mangelnder Interoperabilität immer häufiger zu Risiken. Dieser Beitrag verschafft Ihnen einen schnellen Überblick über die Anforderungen der FDA…

Weiterlesen

Design Input: Was Sie nicht vergessen sollten

Unter „Design Input“ versteht man die Entwicklungsvorgaben, an die nicht nur die FDA konkrete Forderungen stellt. Dieser Artikel beschreibt, welche Inhalte Ihr Design Input enthalten sollte. Sie erfahren, wie das Risikomanagement mit dem Design Input zusammenspielt.  Inhaltsübersicht Definition „Design Input“ » Regulatorische Anorderungen » Inhalte des Design Inputs » Risikoanalyse als Design Input »

Weiterlesen

PESS: Programmierbare elektronische Subsysteme

Die IEC 60601-1 definiert ein PESS, ein programmierbares elektronisches Subsystem, als System, das auf einer oder mehreren zentralen Prozessoreinheiten beruht, einschließlich deren Software und Schnittstellen. Die Norm verrät nicht, was sie unter System versteht, es ist in diesem Kontext eine Komponente des Medizinprodukts. Dafür stellt die IEC 60601-1 konkrete Anforderungen an die PESS.

Weiterlesen

Hardware-Schnittstellen testbar und normenkonform spezifizieren

Medizingeräte verfügen über zahlreiche Hardware-Schnittstellen. Diese sollten Hersteller genau dokumentieren, um das Produkt ohne unnötige Nachbesserungen entwickeln, Testfälle ableiten und regulatorische Forderungen erfüllen zu können. Dieser Beitrag gibt Tipps, wie es Ihnen gelingen wird, die Hardware-Schnittstellen Ihrer Medizinprodukte schnell und präzise zu spezifizieren.

Weiterlesen