Im regulierten Umfeld genügt es nicht, dass etwas funktioniert. Es muss belegbar sein, dass es funktioniert — und warum es so gebaut wurde.
Eine Anforderung im regulierten Umfeld unterscheidet sich von einer normalen Anforderung nicht durch mehr Detail, sondern durch eine zusätzliche Eigenschaft: Sie muss bis zu ihrer Quelle und bis zu ihrem Nachweis verfolgbar sein. Vorgabe, Anforderung, Umsetzung, Testfall und Prüfergebnis müssen als Kette lesbar sein — auch Monate später und auch von Menschen, die nicht dabei waren.
Wer diese Kette erst am Ende herstellt, baut sie rekonstruierend nach. Das ist teuer, lückenhaft und der häufigste Grund dafür, dass Prüfungen unangenehm werden.
In den meisten Vorhaben ist die Abnahme der Moment, in dem der Fachbereich bestätigt, dass sich das System wie gewünscht verhält. Im regulierten Umfeld kommt eine zweite Frage hinzu, die zeitlich viel später gestellt wird und von jemand anderem: Woraus ergab sich diese Ausgestaltung, wer hat sie entschieden, und wie wurde geprüft, dass sie eingehalten ist?
Diese zweite Frage verändert die Arbeitsweise. Entscheidungen müssen nicht nur getroffen, sondern begründet dokumentiert werden. Bewusste Abweichungen von einer Vorgabe sind zulässig, aber sie brauchen eine festgehaltene Begründung und eine benannte Person. Und Prüfungen brauchen ein Ergebnis, das man vorzeigen kann — nicht die Erinnerung daran, dass getestet wurde.
Der praktische Effekt: Was in einem unregulierten Vorhaben als Bürokratie erscheint, ist hier Teil des Produkts. Die Dokumentation ist kein Nebenprodukt der Umsetzung, sondern ein Ergebnis, für das Aufwand geplant wird.
Fünf Glieder. Jedes Glied verweist nachprüfbar auf das vorige. Bricht ein Glied, ist der Nachweis unterbrochen.
Welche Regelung, welcher Absatz, welche interne Richtlinie, welche Aufsichtsanforderung? Ein Verweis auf „regulatorische Anforderungen“ ist keine Quelle. Ohne eindeutige Quelle lässt sich später nicht prüfen, ob die Umsetzung sie trifft.
Vorgaben sind selten eindeutig. Die fachliche Auslegung — was heißt die Vorgabe für unseren Prozess? — ist eine Entscheidung mit Begründung und Namen. Dieses Glied wird am häufigsten übersprungen und fehlt später am schmerzlichsten.
Aus der Auslegung wird eine Anforderung, die ein Entwickler umsetzen und ein Tester prüfen kann. Kennzeichen einer prüfbaren Anforderung: Sie enthält eine beobachtbare Wirkung und mindestens einen Fall, in dem sie verletzt wäre.
Zu jeder Anforderung mindestens ein Testfall, der ihre Verletzung erkennen würde — nicht nur ihren Erfolg bestätigt. Das Ergebnis wird mit Datum und Umgebung festgehalten, auch wenn es negativ ist.
Die fachliche Bestätigung mit Name, Datum und Bezug auf die geprüften Anforderungen. Eine Zustimmung im Gespräch ist kein Nachweis, auch wenn sie ehrlich gemeint war.
Der häufigste Mangel an Anforderungen ist nicht fehlendes Detail, sondern fehlende Prüfbarkeit. Formulierungen wie „das System soll benutzerfreundlich reagieren“ oder „Daten werden zeitnah aktualisiert“ sind nicht falsch, aber nicht prüfbar — und damit nicht abnahmefähig. Nützliche Gegenprobe sind vier Fragen:
In agil arbeitenden Organisationen entsteht regelmäßig eine Lücke zwischen dem Product Owner, der Priorität und Nutzen verantwortet, und der Entwicklung, die Umsetzbarkeit beurteilt. Im regulierten Umfeld ist diese Lücke besonders teuer, weil dort die Nachweisführung sitzt: Wer schreibt die Auslegung auf? Wer stellt sicher, dass zu jeder Anforderung ein prüfender Testfall existiert? Wer merkt, dass eine Umsetzung fachlich funktioniert, aber die Vorgabe nicht mehr trifft?
Diese Aufgabe kann der Product Owner übernehmen, wenn er die fachliche Tiefe hat. In der Praxis fehlt ihm meist die Zeit. Sie kann in der Entwicklung liegen, wenn dort das regulatorische Verständnis vorhanden ist. Häufig ist es weder das eine noch das andere — und dann entsteht die Lücke, die später als Dokumentationsschuld sichtbar wird.
Praktisch bewährt hat sich, die Nachweiskette als festen Teil der Definition of Done zu führen: Eine Anforderung ist nicht fertig, wenn sie umgesetzt ist, sondern wenn Quelle, Auslegung, Testfall und Ergebnis verknüpft sind. Das klingt schwerfällig, kostet pro Anforderung wenige Minuten und ersetzt später Wochen an Rekonstruktion.
Die Regelung wird zitiert und direkt in eine technische Anforderung übersetzt. Die Zwischenentscheidung, was die Regelung für diesen Prozess bedeutet, bleibt in Köpfen. Bei Personalwechsel ist sie verloren.
Ein Testfall, der bestätigt, dass die Funktion im Normalfall arbeitet, weist nicht nach, dass die Regel eingehalten wird. Nachweiskraft entsteht durch Fälle, die eine Verletzung erkennen würden.
Nachträglich erstellte Nachweise sind aufwändiger und lückenhaft, weil Begründungen rekonstruiert werden müssen. Der Aufwand verschiebt sich nicht, er vervielfacht sich.
„Der Fachbereich war einverstanden“ ist im Konfliktfall wertlos und im Prüfungsfall kein Nachweis. Eine kurze schriftliche Bestätigung mit Bezug und Datum genügt — sie muss nur existieren.
Beschreiben Sie mir die Vorgabe, die Projektphase und die vorgesehene Rolle. Sie erhalten eine Einschätzung, wie sich Auslegung, Umsetzung und Nachweis verzahnen lassen.
Projekt besprechen