Anforderungen für sicherheitskritische und regulierte Systeme

2. September 2026· 9 Min. Lesezeit

In den meisten Projekten sind „verifizierbar“ und „nachverfolgbar“ Eigenschaften, die man anstrebt. In einem sicherheitskritischen oder regulierten System hören sie auf, Adjektive zu sein, und werden zu rechtlichen Anforderungen. Die Spezifikation ist kein Arbeitsdokument mehr — sie ist ein Beweismittel, und eine fehlende Nachverfolgbarkeits-Verknüpfung ist ein Befund, keine Stilfrage.

Dieser Beitrag handelt davon, was diese Verschiebung für das Schreiben von Anforderungen bedeutet und was die großen Normen tatsächlich von ihnen verlangen.

Warum Regulierung die Spezifikation verändert

Ein nicht reguliertes Produkt kann mit einer undokumentierten Entscheidung ausgeliefert werden, und niemand wird je fragen. Ein reguliertes Produkt wird geprüft, und der Prüfer stellt zu jeder Behauptung eine Frage: Zeigen Sie mir die Anforderung und den Nachweis, dass sie erfüllt wurde.

Diese Frage macht die Spezifikation zum Rückgrat des gesamten Projekts. Ist die Spur von der Anforderung über den Entwurf zum Code bis zum Test an irgendeiner Stelle unterbrochen, scheitert das Audit — selbst wenn das Produkt selbst perfekt funktioniert.

Die Normen, kurz

IEC 62304 — Software für Medizinprodukte. Stuft Software nach Risiko ein (A/B/C) und verlangt dokumentierte Anforderungen mit Nachverfolgbarkeit zu Entwurf und Verifikation — strenger für höhere Klassen.
ISO 26262 — Funktionale Sicherheit im Automobil. Vergibt ASIL-Stufen (A–D) und verlangt Sicherheitsziele, die in Sicherheitsanforderungen zerlegt werden — jede mit Entwurf und Tests verknüpft.
DO-178C — Software für Luftfahrzeuge. Definiert Design Assurance Levels (DAL A–E) und verlangt Vorwärts- und Rückwärts-Nachverfolgbarkeit samt Verifikation mit Überdeckungsanalyse.
IEC 61508 — die übergeordnete Norm der funktionalen Sicherheit für elektrische/elektronische Systeme, die die anderen spezialisieren.
In der Energiespeicherung gilt dieselbe Disziplin über IEC 62619 (Zellsicherheit), UL 9540 (Energiespeichersysteme) und NFPA 855 (Installation) — wo eine Sicherheitsanforderung ohne Nachweis eine Gefahr ist, keine Formalität.

Was die Normen tatsächlich verlangen

Anforderungen, die geschrieben, geprüft und unter Änderungskontrolle stehen — kein lebendes Wiki, das jeder editieren kann.
Vorwärts-Nachverfolgbarkeit — jede Anforderung ist mit Entwurf, Code und Tests verknüpft, die sie erfüllen.
Rückwärts-Nachverfolgbarkeit — jede Codezeile und jeder Test verweist auf eine Anforderung, sodass nichts existiert, was nicht verlangt wurde.
Verifikation mit Nachweis — ein Testprotokoll, keine Behauptung, das belegt, dass jede Anforderung erfüllt ist.
Risikogetriebene Strenge — je höher die Sicherheitsklasse (ASIL, DAL oder IEC-62304-Klasse), desto mehr Nachweise müssen Sie erbringen.
Änderungskontrolle als Disziplin — eine Änderung an einer Anforderung ist eine Änderung am Sicherheitsnachweis und muss erneut verifiziert werden.

Nachverfolgbarkeit ist die tragende Anforderung

In diesen Systemen ist die Nachverfolgbarkeitsmatrix kein Liefergegenstand, den man am Ende erstellt. Sie ist die Struktur, die den Sicherheitsnachweis zusammenhält, und sie muss kontinuierlich gepflegt werden — denn eine Anforderung, die sich nicht nachverfolgen lässt, ist aus Sicht des Prüfers eine Anforderung, die nicht existiert.

Das ist der größte Unterschied zwischen dem Schreiben von Anforderungen für eine App und für ein zertifiziertes System: In der App kostet eine vergessene Verknüpfung einen Fehler. Im zertifizierten System kostet sie die Zertifizierung.

Was das in der Praxis bedeutet

Schreiben Sie Anforderungen, auf die Sie zeigen können — singulär, eindeutig und jede mit eindeutiger Kennung.
Pflegen Sie die Spur kontinuierlich, statt sie zu rekonstruieren — sonst baut das Audit sie Ihnen mühsam wieder auf.
Behandeln Sie jede Änderung als kontrolliertes Ereignis — Auswirkung bewerten, erneut verifizieren und an der Anforderung dokumentieren.
Bewahren Sie die Nachweise auf — das Testprotokoll gehört ebenso zur Spezifikation wie der Satz.

In einem regulierten System ist die Spezifikation keine Dokumentation dessen, was Sie gebaut haben. Sie ist der Nachweis dessen, was Sie versprochen haben — und der Prüfer liest sie wie einen Vertrag, weil sie genau das ist.