Systemanforderungen – System Requirements Specification

Systemanforderungen und Systemspezifikationen
(System Requirements Specification)

Der englische Begriff „System Requirements Specification“ wird oft als Systemanforderungen oder System-Spezifikation übersetzt. Streng genommen sind beide Begriffe aber nicht deckungsgleich:

  • Eine Systemspezifikation spezifiziert, wie sich das System aus Blckbox-Sicht d.h. über seine Schnittstellen (z.B. über die GUI oder Datenschnittstellen) verhalten soll. Mehr dazu lesen Sie weiter unten auf dieser Seite.
  • Die Systemanforderungen sind Anforderungen an das System „unter der Haube“. Ein Beispiel wäre 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.

In den allermeisten Fällen lassen sich Systeme ausreichend vollständig als Blackbox spezifizieren, so dass die Systemanforderungen damit je nach Sichtweise obsolet werden oder mit der System-Spezifikation zusammenfallen. Auch Normen wie die IEC 62304 unterscheidet Software-Anforderungen und Software-Spezifikation nicht.

Weiterführende Informationen

Häufig dokumentiert man Anforderungen in einem Lastenheft oder Pflichtenheft. Lesen Sie hier mehr, auf was Sie beim Schreiben dieser Dokumente beachten müssen.

Systemanforderungen bzw. Systemspezifikation als Blackbox-Modell beschreiben

Um System Requirements Specifications (SRS) konsistent und vollständig zu beschreiben, schlagen wir als mentales Modell die Blackbox vor. Wenn man sich ein Medizinprodukt als Blackbox vorstellt, werden die Schnittstellen, die diese zur „Außenwelt“ haben, offensichtlich:

  • Benutzer-System-Schnittstelle (UI)
  • Datenschnittstellen wie APIs, Bus-Systeme, Webservices und andere „Ethernet-Schnittstellen“
  • Mechanische Schnittstellen wie Griffe oder das Gehäuse
  • Elektrische Schnittstellen: Ein Stromanschluss lässt sich ebenfalls aus Blackbox-Sicht spezifizieren, nämlich die Anzahl und Geometrie der Kabel, die Befestigung dieser, die Spannung und erlaubte Schwankungen, Kapazität des Systems bzw. Phasenverschiebungen von Strom und Spannung, erwartete Stromstärken und Verhalten bei Kurzschluss
  • „Wasser-Schnittstellen“: in Wasseranschluss könnte beschrieben werden über den mechanischen Formfaktor z.B. des Schlauchs und des Gewindes, über den erwarteten Druckbereich, die minimale und maximale Flussgeschwindigkeit und die Güte bzw. Reinheit des Wassers
  • Weitere Schnittstellen wie „Druckluftschnittstellen“.

Black Box zur Beschreibung von System-Anforderungen (Ssytem Requirements Specifications)

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Software-Anforderungen.

Formulierungsschablone für Systemanforderungen

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

[<Voraussetzung|Bedingung>] <muss|soll> das System [< die Möglichkeit bieten|untersagen>] [nicht] .

Beispiele:

  • 30 sec 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 dem eine 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.

Diese Formulierungsschablone hilft auch, „weak words“ zu vermeiden. Diese „Weichmacher“-Wörter sind starke Hinweise auf unpräzise Anforderungsdokumente. 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, öfters, sehr, schnell, schon, schön, sonstige, übrige, verschieden, viel, zahlreich, zunächst, usw.

Diese Wörter lassen sich übringens mit einem Werkzeug schneller und zuverlässiger finden als mit einem Review.

Die Prüfung von Systemanforderungen sollte aber nicht nur die Einhaltung der Formulierungsrichtlinie umfassen. Vielmehr ist es wichtig, diese auf Stakeholder-Anforderungen oder im Falle eines Subsystem (PESS) auf die Anforderungen eines übergeordneten Systems (PEMS) zurückführen zu können.

Für IEC 62304 konforme Anforderungen an Software-Systeme sollte sie inhaltlich alle Aspekte berücksichtigen, die ich im Auditgarant vorstelle.

Software-Systemanforderungen

Wie Sie diese Schnittstellen insbesondere bei Medizinprodukten, die Software enthalten oder die standalone Software sind, gesetzeskonform (insbesondere konform mit der IEC 62304 Kapitel 5.2 zu den Software-Anforderungen) beschreiben, finden Sie auf der Seite zu den Software-Anforderungen (Software System Requirements Specification SSRS beschrieben.

PS: Wenn Sie die IEC 62304 Kapitel 5.2. untersuchen, wie Softwareanforderungen zu beschreiben sind, wird Ihnen Vieles bekannt vorkommen. Ihnen werden auch Fehler bzw. Inkonsistenzen in der Norm auffallen.

PPS: Die Blackbox-Metapher wird Ihnen sehr nützlich beim Spezifizieren von Blackbox-Tests sein.


Donnerstag 13. September 2018 von Prof. Dr. Christian Johner

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen

Die Vorstellungen darüber, was diese Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma.

Regelmäßig beobachtet das Johner Institut, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden.

Lastenheft und PflichtenheftNur in der Granularität und dem Detailgrad unterscheiden sie sich. Schon aus regulatorischer Sicht sollten Sie die Begriffe Lastenheft und Pflichtenheft gegeneinander abgrenzen.

Lastenheft und Pflichtenheft | Beitrag lesen »


Mittwoch 11. Juli 2018 von Prof. Dr. Christian Johner

Das V-Modell ist ein Entwicklungsprozessmodell, das ursprünglich für staatliche Projekte entwickelt wurde.

Das V-Modell unterscheidet sich vom Wasserfall-Modell dadurch, dass bereits während der konstruktiven Phasen (z.B. während dem Schreiben der Anforderungen oder dem Entwerfen der Architektur) die zugehörigen Tests spezifiziert werden müssen.

Das hat den Vorteil, dass unvollständige Spezifikationen frühzeitig erkannt werden, auch dadurch, dass die für das Testen verantwortlichen Personen mit eingebunden werden.

V-Modell vs. Wasserfallmodell für Hardware- und Softwareentwicklung | Beitrag lesen »


Sonntag 13. Mai 2018 von Prof. Dr. Christian Johner

Viele Lastenhefte und Pflichtenhefte unterscheiden sogenannte 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.

Funktionale Anforderungen versus nicht-funktionale Anforderungen | Beitrag lesen »


Dienstag 8. Mai 2018 von Prof. Dr. Christian Johner

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 Firmen nicht bewusst sind.

‚Personas‘: die 5 häufigsten Fehler vermeiden | Beitrag lesen »


Dienstag 26. September 2017 von Prof. Dr. Christian Johner

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 an ‚Interoperable Medical Devices‘ und gibt Tipps wie Sie diese erfüllen können.

FDA Guidance ‚Interoperable Medical Devices‘ | Beitrag lesen »


Montag 20. Februar 2017 von Prof. Dr. Christian Johner

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.

Design Input: Was Sie nicht vergessen sollten | Beitrag lesen »


Mittwoch 9. März 2016 von Prof. Dr. Christian Johner

Beim Wort „Produktmanager“ oder „Produktmanagement“ verdrehen viele Entwickler die Augen. Die Zusammenarbeit der beiden Abteilungen ist oft von Reibungsverlusten geprägt. Lesen Sie hier, weshalb dem so ist und was Sie dagegen machen können.Was macht eigentlich ein Produktmanager? Müssen die uns leidtun? | Beitrag lesen »


Freitag 5. Februar 2016 von Prof. Dr. Christian Johner

Die Uses Cases, auf Deutsch Anwendungsfälle, finden im Gegensatz zu User Stories in der agilen Entwicklung nicht mehr so viel Verwendung. Kann man mit der Modellierung von Use Cases zumindest die Forderungen der IEC 62366-1:2015 nach Benutzungsszenarien erfüllen? Sind die Begriffe Use Case und Benutzungsszenario synonym zu verstehen? Dieser Beitrag gibt Ihnen Antworten und Tipps.

Use Case und Benutzungsszenario: Synonyme? Was sagt die IEC 62366? | Beitrag lesen »


Mittwoch 12. August 2015 von Prof. Dr. Christian Johner

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.

 

PESS: Programmierbare elektronische Subsysteme | Beitrag lesen »


Mittwoch 5. August 2015 von Prof. Dr. Christian Johner

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.

Hardware-Schnittstellen testbar und normenkonform spezifizieren | Beitrag lesen »

Seite 1