Inhaltsverzeichnis
Das Wichtigste vorab
Was unterscheidet URS, FS und DS bei der Computersystemvalidierung?
Die URS beschreibt, was der Anwender für den vorgesehenen Prozess benötigt. Die FS erläutert, wie Funktionen dieses Bedürfnis erfüllen. Die DS beschreibt die erforderliche technische Auslegung. Die Bezeichnungen und Dokumentgrenzen dürfen zum Projekt passen; entscheidend sind eindeutige Anforderungen, nachvollziehbare Umsetzung und geeignete Nachweise. Drei getrennte Dokumente sind nicht für jedes System automatisch erforderlich.
Drei Ebenen, drei unterschiedliche Fragen
Eine User Requirements Specification beantwortet die Frage: Welches Ergebnis muss das System im vorgesehenen Betrieb ermöglichen? Eine Functional Specification beschreibt das funktionale Verhalten einschließlich erlaubter Zustände und Reaktionen. Eine Design Specification legt technische Entscheidungen fest, beispielsweise Datenmodell, Schnittstellenvertrag oder kundenspezifische Implementierung. Die Abkürzungen sind verbreitet, ihre konkrete Verwendung muss im Qualitätsmanagementsystem verständlich definiert sein.
Verwechseln Sie die Dokumentnamen nicht mit dem Nachweis. Annex 11 verlangt unter anderem dokumentierte Anwenderanforderungen auf Basis von Risiko und GMP-Auswirkung sowie deren Nachverfolgbarkeit im Lebenszyklus. Daraus folgt keine allgemeine Verpflichtung zu drei gleich großen Dateien. Bei Standardsoftware können Lieferantendokumentation und eine kontrollierte Konfigurationsbeschreibung wesentliche Teile abdecken. Bei eigener Software werden technische Festlegungen umfangreicher. Entscheidend ist, ob die Beteiligten denselben Einsatzzweck, dieselben Grenzen und dieselben Akzeptanzkriterien verstehen.
Was in eine gute URS gehört
Beschreiben Sie zuerst Prozess, Nutzer, relevante Daten und Grenzen. „Das System muss GxP-konform sein“ beschreibt ein Ziel, aber noch kein prüfbares Verhalten. Besser: „Eine gesperrte Charge darf im definierten Versandprozess nicht für eine Auslieferung bestätigt werden.“ Ergänzen Sie, wer den Status setzen darf, welche Schnittstellen betroffen sind und wie Abweichungen bearbeitet werden. Damit erhält die Anforderung fachlichen Inhalt.
Jede Anforderung braucht eine eindeutige Kennung, eine verständliche Aussage und eine begründbare Prüfmöglichkeit. Trennen Sie wesentliche Anforderungen von Komfortwünschen, ohne Prozessrisiken hinter einer niedrigen Priorität zu verstecken. Auch Betrieb, Wiederherstellung, Recherche, Berechtigungen und Archivzugriff können Anwenderanforderungen sein. Halten Sie Annahmen fest: Welche Daten kommen aus einem anderen System, und welcher Fachbereich verantwortet ihre Qualität? Sonst beschreibt die URS einen vermeintlich geschlossenen Prozess, obwohl entscheidende Schritte außerhalb liegen.
Quellen: [1]
Wie die FS aus Anforderungen ausführbares Verhalten macht
Die funktionale Beschreibung erklärt Abläufe, Zustände und Ausnahmen. Für die Chargensperre bedeutet das: Wann wird der Status geprüft? Welche Rückmeldung sieht der Anwender? Was geschieht bei einer zeitgleichen Statusänderung oder einer nicht erreichbaren Schnittstelle? Eine Beschreibung nur des erfolgreichen Standardfalls lässt die fachlich entscheidenden Fehlerpfade offen. Die FS sollte deshalb nicht lediglich die URS mit anderen Verben wiederholen.
Sie kann auf eine geeignete Standardfunktionsbeschreibung verweisen und die kundenspezifischen Einstellungen ergänzen. Der Verweis braucht Produktstand und eindeutigen Abschnitt. „Siehe Herstellerhandbuch“ ist bei mehreren Versionen und zahlreichen Modulen zu ungenau. Prüfen Sie außerdem Abweichungen zwischen dokumentierter Standardfunktion und Ihrem tatsächlichen Prozess. Wenn der Standard nur bei der Auftragserfassung prüft, Ihr Prozess aber eine erneute Kontrolle vor dem Versand verlangt, bleibt diese Differenz eine bewusst zu lösende Anforderung.
Quellen: [1]
Wann eine DS zusätzliche Klarheit schafft
Technische Details gehören dorthin, wo sie eine Umsetzung oder spätere Änderung nachvollziehbar machen. Bei einer selbst entwickelten Schnittstelle können dies Feldzuordnung, Datentyp, Statuscodes, Wiederholungslogik und Fehlerablage sein. Bei einer konfigurierten Standardanwendung kann eine freigegebene Parameterliste genügen, ergänzt um relevante Erweiterungen. Eine DS soll den tatsächlichen Aufbau erklären; sie muss keine intern unzugänglichen Entwicklungsdetails eines SaaS-Herstellers nachbilden.
Die Tiefe richtet sich nach Komplexität, Neuheit, Lieferantennachweisen und Risiko. Eine technische Beschreibung wird besonders wichtig, wenn mehrere Teams Verantwortung teilen oder Änderungen unvorhergesehene Auswirkungen haben können. Dokumentieren Sie beispielsweise, welche Komponente den Chargenstatus verbindlich liefert. Ein Diagramm mit einem Pfeil „ERP an Lager“ genügt dafür nicht. Erforderlich sind die relevanten Daten, die fachliche Interpretation und das Verhalten bei veralteten oder widersprüchlichen Informationen.
Quellen: [1]
Durchgängiges Beispiel: eine gesperrte Charge
Das folgende Beispiel ist konstruiert. Ein ERP übermittelt den Chargenstatus an eine Lageranwendung. URS-017 verlangt, dass gesperrte Chargen nicht versendet werden. Die FS beschreibt die Prüfung vor der Versandbestätigung und die Behandlung nicht verfügbarer Statusinformationen. Die DS dokumentiert Datenquelle, Statusmapping und technische Behandlung eines fehlgeschlagenen Aufrufs. Die Testfälle prüfen diese Aussagen mit bekannten Ausgangsdaten.
Die fachliche Entscheidung lautet im Beispiel: Bei unbekanntem oder veraltetem Status wird die Versandbestätigung zurückgestellt und ein benannter Verantwortlicher informiert. Das ist eine eigene Prozessregel, keine allgemeine Vorschrift für jede Schnittstelle. Sie muss technisch umsetzbar, geschult und getestet sein. Ein positiver Test mit einer freigegebenen Charge reicht dafür nicht. Prüfen Sie auch Statuswechsel während des Vorgangs, einen wiederholten Aufruf und den Unterschied zwischen technischer Übertragung und fachlicher Annahme.
| Ebene | Beispielhafte Festlegung | Passender Nachweis |
|---|---|---|
| URS-017 | Gesperrte Charge nicht versenden | Versandversuch mit gesperrter Charge |
| FS-017a | Prüfung vor Versandbestätigung | Ablauf und maßgeblicher Prüfzeitpunkt |
| FS-017b | Unbekannten Status zurückstellen | Ausfall- und Fehlerfall |
| DS-017a | Zuordnung der Quellstatuswerte | Mapping gegen Referenzdaten |
| DS-017b | Veraltete Antwort erkennen | Grenzfall zur vereinbarten Aktualität |
| Betrieb | Ausnahme verantwortlich bearbeiten | Bearbeitung einschließlich erneuter Prüfung |
Quellen: [1]
Traceability ohne dreifache Dokumentation
Verknüpfen Sie Anforderung, Umsetzung, Risiko und Test dort, wo die Beziehung entsteht. Eine kleine Zuordnungstabelle kann ausreichen. Bei größeren Projekten unterstützt ein geeignetes Werkzeug die Pflege. Entscheidend ist, dass ein Prüfer von einer kritischen Anforderung zu den relevanten Ergebnissen gelangt und eine Änderung in Gegenrichtung bewerten kann. Die Zahl ausgefüllter Tabellenzellen sagt wenig über diese Nutzbarkeit aus.
Eine Anforderung kann mehrere Funktionen und Tests benötigen. Umgekehrt kann ein Prozessnachweis mehrere Anforderungen abdecken. Erzwingen Sie keine künstliche Eins-zu-eins-Beziehung. Begründen Sie jedoch, wenn eine Anforderung ausschließlich durch Dokumentenprüfung oder übernommene Lieferantentests belegt wird. Offene Abdeckungen bleiben sichtbar. Kopierte Texte in URS, FS und DS erhöhen sonst den Pflegeaufwand und erzeugen Widersprüche, sobald nur eine der drei Fassungen angepasst wird.
Quellen: [1]
Standardsoftware, SaaS und Eigenentwicklung passend behandeln
Bei SaaS bleiben kundenspezifischer Verwendungszweck, Konfiguration und Schnittstellen Prüfgegenstand. Der Anbieter verantwortet seine Entwicklungs- und Betriebsleistungen im vereinbarten Umfang; der regulierte Anwender bewertet die Eignung für seinen Prozess. Lieferantennachweise werden auf Aktualität, Umfang und Übertragbarkeit geprüft. Fehlender Quellcodezugriff rechtfertigt keine erfundenen Designinformationen. Beschreiben Sie stattdessen die zugängliche Architektur und die bewerteten Grenzen.
Bei Eigenentwicklungen müssen Anforderungen und technische Auslegung enger miteinander verbunden werden. Auch ein agiles Projekt braucht kontrollierte Entscheidungen, nachvollziehbare Änderungen und geeignete Nachweise. Die Spezifikation darf schrittweise entstehen, sofern der freigegebene Stand und seine Prüfung erkennbar bleiben. Eine starre Dokumentabfolge ist ebenso wenig ein Qualitätsmerkmal wie ein ungeprüftes Backlog. Legen Sie im Plan fest, welche Informationen vor Implementierung, vor Test und vor Nutzung verbindlich sein müssen.
Quellen: [1]
Prüfliste für den nächsten Spezifikationsreview
Nehmen Sie eine kritische Anforderung und verfolgen Sie sie vollständig durch das Projekt. Versteht der Fachbereich die Aussage? Ist die Umsetzung eindeutig zugeordnet? Sind negative Fälle und Betriebsbedingungen berücksichtigt? Kann ein unabhängiger Tester das erwartete Ergebnis vor der Ausführung bestimmen? Wo diese Fragen unbeantwortet bleiben, hilft mehr Text selten. Dort fehlt eine Entscheidung, eine Abgrenzung oder ein überprüfbarer Zusammenhang.
Zum Abschluss sollten offene Punkte einen Verantwortlichen und einen Termin haben. Änderungen an bereits freigegebenen Anforderungen werden mit ihren Auswirkungen auf Konfiguration, Testdaten, Schulung und bestehende Nachweise bewertet. Bewahren Sie den historisch geprüften Stand. Eine nachträglich überarbeitete URS darf nicht so erscheinen, als sei genau diese Fassung schon ursprünglich getestet worden. Ein schlankes, gepflegtes Spezifikationspaket liefert mehr Orientierung als drei umfangreiche Dokumente ohne belastbare Verbindung.
Häufige Fragen zu URS, FS und DS
Sind URS, FS und DS immer drei separate Pflichtdokumente?
Nein. Dokumentstruktur und Bezeichnungen müssen zum System und Qualitätssystem passen. Die notwendigen Informationen und ihre Nachverfolgbarkeit bleiben erforderlich. Bei Standardsoftware können geeignete Lieferantendokumentation und Konfigurationsnachweise Teile abdecken. Eine Zusammenlegung darf Verantwortlichkeiten, geprüfte Stände und Akzeptanzkriterien nicht unklar machen.
Quellen: [1]
Ist die URS dasselbe wie ein Lastenheft?
Es gibt Überschneidungen. Ein Lastenheft kann kaufmännische und technische Wünsche umfassen; eine URS für die Validierung beschreibt insbesondere den vorgesehenen Einsatz und prüfbare Anforderungen. Klären Sie die Begriffe im Projekt. Der Titel allein belegt weder Vollständigkeit noch Eignung.
Wer schreibt die FS: Kunde oder Lieferant?
Das hängt vom Vertrag und der Umsetzung ab. Häufig beschreibt der Lieferant das funktionale Verhalten, während der Anwender es gegen seine Anforderungen bewertet. Kundenspezifische Konfigurationen benötigen klare Verantwortliche. Eine Lieferantenunterschrift ersetzt nicht die fachliche Prüfung der Prozessabdeckung durch den Anwender.
Braucht Standardsoftware eine selbst geschriebene DS?
Nicht automatisch. Prüfen Sie vorhandene technische Unterlagen und dokumentieren Sie relevante Konfigurationen, Erweiterungen und Schnittstellen. Stellen Sie keine unzugänglichen Herstellerdetails nach. Wenn das tatsächliche Verhalten ohne zusätzliche technische Beschreibung nicht verständlich wird, ergänzen Sie diese gezielt und kontrolliert.
Können Tests die fehlende Spezifikation ersetzen?
Tests benötigen ein begründetes erwartetes Ergebnis. Ohne klare Anforderungen besteht die Gefahr, lediglich beobachtetes Verhalten als richtig zu bestätigen. Vorhandene Testfälle können helfen, Spezifikationslücken zu erkennen. Die fachliche Regel muss dennoch nachvollziehbar festgelegt und vor der abschließenden Bewertung kontrolliert sein.
Quellen: [1]
Wie detailliert sollte eine URS sein?
So detailliert, dass kritische Anforderungen eindeutig umsetzbar und überprüfbar sind. Beschreiben Sie Ergebnis, relevante Bedingungen und Grenzen. Vermeiden Sie unnötige Implementierungsdetails auf Anwenderebene. Bei komplexen Funktionen ergänzen Sie verständliche Beispiele und verweisen kontrolliert auf funktionale oder technische Festlegungen.
Quellen & fachlicher Stand
Stand: 14. Oktober 2026. Regulatorische Einordnung und Herstellerfunktionen sind getrennt belegt. Beispiele, Testmatrizen und Vorlagen sind eigene Arbeitshilfen; sie werden für den tatsächlichen Einsatzzweck angepasst.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
- Europäische Kommission: EU-GMP Annex 15, Qualification and Validation (2015)
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Wie wir Sie dabei unterstützen
Daniel Herrmann Consulting verbindet die fachliche Bewertung mit der Arbeit am konkreten System. Im Erstgespräch klären wir Ihren Einsatzzweck, vorhandene Nachweise und den nächsten sinnvollen Schritt.
- IT-GxP-Coaching →
Ihr Team bei Entscheidungen und Nachweisen begleiten und das Wissen im Betrieb verankern.