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.


Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen Die Vorstellungen darüber, was Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma. Das liegt u. a. daran, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden. Vielmehr unterscheiden sie sich in der Granularität und dem Detailgrad. Schon aus regulatorischer Sicht sollten Sie…

Weiterlesen

V-Modell: Die 5 häufigsten Probleme vermeiden

Das V-Modell ist ein Entwicklungsprozessmodell, das ursprünglich bei staatlichen Projekten (u. a. Rüstung) zur Anwendung kam. Bis heute ist es bei Projekten im regulierten Umfeld (z. B. Medizintechnik, Banken) in vielen Köpfen und Normen verankert. Das führt zu Konflikten in Teams, die agile Entwicklungsprozesse bevorzugen. Dieser Artikel hilft, diesen Widerspruch aufzulösen. Sie erfahren, wie Sie…

Weiterlesen
Funktionale Anforderungen und nicht-funktionale Anforderungen unterscheidet die ISO 9126

Funktionale Anforderungen versus nicht-funktionale Anforderungen

Viele Lastenhefte und Pflichtenhefte unterscheiden funktionale Anforderungen und nicht-funktionale Anforderungen. Funktionale Anforderungen sind Anforderungen mit Bezug zur Zweckbestimmung des Produkts. Zu den nicht-funktionale Anforderungen zählen Anforderungen wie die Zuverlässigkeit und das Zeitverhalten. Dieser Artikel hilft mit Beispielen, beide Anforderungstypen zu unterscheiden, und erläutert die Auswirkung auf deren Dokumentation.

Weiterlesen

Use Scenario – User Story – User Task: Endlich durchblicken

Die IEC 62366-1 nutzt das Konzept (Hazard-Related) Use Scenario, auf deutsch „(gefährdungsbezogenes) Benutzungsszenario“. Die FDA kennt die Critical (User) Tasks. In der Entwicklung arbeitet man mit Use Cases und User Stories. Diese Begriffsvielfalt erschwert ein gemeinsames Verständnis. Das aber ist notwendig, um konsistente und gesetzeskonforme Gebrauchstauglichkeitsakten zu erstellen und regulatorische Probleme zu vermeiden. Dieser Artikel…

Weiterlesen

‚Personas‘: die 5 häufigsten Fehler vermeiden

Viele Firmen verwenden Personas als Methode im Usability und Requirements Engineering. Eine Persona ist eine fiktive Person, die als repräsentativer Vertreter einer Gruppe dient, typischerweise einer Gruppe potenzieller Benutzer eines Systems. Besonders in der agilen Software-Entwicklung sowie bei Marketing- und Design-Agenturen sind Personas beliebt. Doch die Methode wird häufig missverstanden und birgt Risiken, die den meisten…

Weiterlesen