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.
- Grundlagen
- Regulatorische Anforderungen
- Systemanforderungen spezifizieren
- Systemanforderungen prüfen
- 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.
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.
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.
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).
