29 Aug. Requirements Engineering im GxP-Umfeld – warum gute Anforderungen Gold wert sind

Posted at 07:09h in Qualitätsmanagement by

Eigentlich wissen wir es alle: die Spezifikation, vor allem die User Requirement Specification (URS), ist die Basis jedes validierten Systems. Ohne sie kann kein Projektleiter, kein Tester und erst recht kein Auditor nachvollziehen, was das System leisten soll.

Und doch passiert es in Projekten immer wieder: Die Spezifikationen liegen vor, das System ist installiert,  und beim Schreiben und Durchführen der Tests merkt man plötzlich –

  • manche Anforderungen lassen sich nicht testen,
  • andere ergeben keinen Sinn,
  • und manche Funktionen fehlen komplett in der Spezifikation.

Folglich heißt es: Verantwortliche zusammensammeln, Experten befragen und alles neu abstimmen. Die Spezifikation muss überarbeitet werden – während der Projektplan schon knirscht. Die Stimmung: genervt, gestresst, angespannt und QA (bzw. Compliance) sind schuld!

Die Frage liegt auf der Hand: Wie konnte das passieren, obwohl wir alle wissen, wie wichtig eine gute Basis ist?

Warum Vorlagen / Templates uns nicht retten

Gerade im GxP-Bereich mangelt es nicht an Vorlagen. Für nahezu alles gibt es eine Vorlage – auch für die URS. Dort finden sich Abschnitte zu IT-Security, Electronic Records and Electronic Signatures (21 CFR Part 11), Data Integrity, Audit Trail und vielen weiteren regulatorischen Anforderungen.

Das Problem: Diese Vorlagen helfen uns selten dabei, die eigentlichen, systemspezifischen Anforderungen zu formulieren. Genau das, was das System leisten und was später über Tests nachgewiesen werden soll.

Wie schreibe ich eine Anforderung so, dass sie präzise und überprüfbar ist?
Wie dokumentiere ich eine Anforderung, damit IT, QA, System-, Prozesseigner, Fachexperten und Lieferanten dasselbe Bild vom System haben?

Dafür gibt es kaum eine Anleitung – und noch seltener eine Schulung. Vorlagen werden brav ausgefüllt, aber die entscheidenden Stellen bleiben schwammig. Die Quittung kommt später im Projekt: Verzögerungen, Nacharbeiten, Stress und unnötige Kosten.

Requirements Engineering – der unsichtbare Held

Genau hier setzt Requirements Engineering (RE) an. RE verfolgt einen systematischen und methodischen Ansatz:

  • Stakeholder gezielt einbinden
  • Anforderungen erheben, hinterfragen und präzisieren
  • Dokumentation so gestalten, dass sie für alle eindeutig und nachvollziehbar bleibt

Bei uns gab es hierzu eine interne Schulung. Wir orientierten uns dabei amFoundation Level zum Certified Professional for Requirements Engineering (CPRE, vom IREB). Diese international anerkannte Zertifizierung beschreibt, wie Anforderungen ermittelt, dokumentiert, geprüft und über den gesamten Projektverlauf gemanagt werden.

Kurz gesagt: Requirements Engineering ist die Kunst, aus diffusen Wünschen präzise, vollständige und überprüfbare Anforderungen zu machen. Oder einfacher: Wir sorgen dafür, dass am Ende alle das Gleiche meinen, wenn sie über „das System“ sprechen.

Das Zauberwort: Gemeinsames Verständnis

Von den neun Grundprinzipien des RE ist für uns als CSV-Experten eines das wichtigste: Gemeinsames Verständnis.

Im GxP-regulierten Umfeld ist Validierung kein bürokratischer Akt, sondern der dokumentierte Nachweis, dass ein System zuverlässig und konform arbeitet. Das gelingt nur, wenn alle Beteiligten – IT, QA, System-, Prozesseigner, Fachexperten, Lieferanten – dasselbe Bild davon haben, was das System ist und was es leisten soll.

Wenn dieses Verständnis fehlt, passiert genau das, was wir alle schon erlebt haben:

  • Anforderungen widersprechen sich,
  • Tests prüfen nicht das Richtige / Wichtige,
  • Funktionen werden genutzt, die nicht spezifiziert und / oder getestet wurden.

Manchmal hört man dann: „Das muss man doch nicht so genau aufschreiben.“
Ja, aber wo stehen die Details dann drin, wenn nicht hier?
Oder: „Jeder weiß jetzt, was damit gemeint ist.“
Ja, aber steht das auch genauso da, so dass jeder in 4 Wochen auch noch weiß, was damit gemeint war?
Und nein: Auch die besten Vorlagen ersetzen nicht die aktiven Diskussionen um zu einem gemeinsamen Verständnis zu gelangen.

Wie Anforderungen aussehen

Am häufigsten begegnen uns natürlich-sprachige Anforderungen. Sie sind leicht zu verstehen – aber auch anfällig für Mehrdeutigkeit.

Ein Beispiel:

  • Bedürfnis: „Ich brauche eine Kaffeemaschine, die mir morgens schnell guten Kaffee macht.“
  • Erste (schwache) Anforderung: „Die Kaffeemaschine soll guten, frischen Kaffee machen und einfach zu bedienen sein.“
  • Finale (gute) Anforderungen nach Diskussionen und Rückfragen:
    • „Die Kaffeemaschine soll dem Benutzer Kaffee aus frisch gemahlenen Bohnen zubereiten.“
    • „Die Kaffeemaschine soll in weniger als 30 Sekunden eine Tasse Kaffee zubereiten.“
    • „Die Kaffeemaschine soll es dem Benutzer ermöglichen, mit maximal zwei Eingaben eine Kaffeezubereitung auszuwählen.“

Der Unterschied ist offensichtlich: präzise, messbar, nachvollziehbar.

Hilfreich sind ein paar einfache Dokumentationsrichtlinien:

  • kurze, klare Sätze,
  • nur eine Anforderung pro Satz,
  • einheitliche Terminologie,
  • vage Begriffe wie „immer“, „schnell“ oder „einfach“ vermeiden.

So simpel das klingt – schon damit lassen sich viele Missverständnisse vermeiden.

Was eine gute Anforderung ausmacht

Lesbar allein genügt nicht. Eine gute Anforderung muss Qualitätskriterien erfüllen:

  • Adäquat: Sie beschreibt echte, abgestimmte Bedürfnisse.
  • Eindeutig: Alle interpretieren sie gleich.
  • Vollständig: Nichts Wesentliches fehlt.
  • Überprüfbar: Ob sie erfüllt ist (Stichwort: Akzeptanzkriterium), lässt sich testen.

Für das ganze Spezifikationsdokument kommen noch weitere Kriterien wie Konsistenz, Nachvollziehbarkeit und Modifizierbarkeit hinzu. Gerade im CSV-Umfeld zahlt sich das aus: Anforderungen lassen sich leichter prüfen, Tests klar ableiten und Änderungen ohne Chaos nachführen!

Fazit – kleine Schritte, große Wirkung

Als externe CSV-Experten stehen wir oft vor der Frage: Soll ich selbst Anforderungen schreiben oder nur ein kurzes Review machen? Die Antwort hängt vom Projekt ab. Aber unsere Erfahrung zeigt: Schon mit gezieltem Nachfragen, einheitlicher Terminologie und kleinen Verbesserungen in der Dokumentation lassen sich viele Stolperfallen vermeiden.

Requirements Engineering klingt manchmal trocken. In der Praxis ist es aber der Schlüssel dazu, Systeme im GxP-Umfeld schneller, günstiger und sicherer zu validieren – und auch nach Go-Live noch gute Stimmung im Projektteam aufrecht zu erhalten.

Autorin: Melanie Witt