Inhaltsverzeichnis
Das Wichtigste vorab
Was macht eine gute URS für ein GxP-System aus?
Eine gute URS beschreibt den vorgesehenen Gebrauch und das benötigte fachliche Ergebnis so eindeutig, dass seine Erfüllung beurteilt werden kann. Sie benennt relevante Bedingungen, Rollen, Daten und Grenzen und trennt Anforderungen von gewählten technischen Lösungen. Risikobedeutung und GMP-Auswirkung bestimmen die angemessene Tiefe. Akzeptanzkriterien müssen prüfbar sein; sie müssen nicht immer einen Zahlenwert enthalten.
- Beginnen Sie mit Prozess und Entscheidung, nicht mit einem Produktkatalog.
- Beschreiben Sie erlaubtes Verhalten und relevante unerlaubte Ergebnisse.
- Trennen Sie fachliches Soll, begründete Randbedingungen und technische Umsetzung.
- Halten Sie Anforderungen identifizierbar, abgestimmt und über Änderungen hinweg nachvollziehbar.
1. Festlegen, wofür die URS gebraucht wird
Die URS beschreibt aus Anwendersicht, was ein System für einen bestimmten Gebrauch leisten soll. Sie dient damit als gemeinsame Grundlage für Auswahl, Konfiguration, Umsetzung und Nachweise. Eine gute Anforderung hilft schon vor dem Test: Anbieter können Verständnisfragen stellen, Fachbereiche widersprüchliche Wünsche erkennen und Verantwortliche den tatsächlich benötigten Umfang abgrenzen.
Der regulatorische Beispielrahmen dieses Beitrags ist Humanarzneimittel-GMP. Annex 11 beschreibt Anwenderanforderungen auf Basis dokumentierter Risiken und GMP-Auswirkungen sowie ihre Nachvollziehbarkeit über den Lebenszyklus. Annex 15 behandelt URS beziehungsweise funktionale Spezifikationen im Qualifizierungs- und Validierungskontext. Beide sind GMP-Leitlinien; daraus folgt kein für alle Branchen und Systeme identisches Formular.
Für andere GxP-Bereiche oder einen zusätzlichen US-Bezug bestimmen Sie zunächst die einschlägigen Anforderungen. Ein universeller Textbaustein „alle gesetzlichen Vorgaben erfüllen“ ersetzt diese Arbeit nicht. Die hier gezeigten Tabellen sind eigene praktische Hilfen zum Schreiben und Abstimmen. Sie sind weder eine amtliche Vorlage noch eine vollständige URS für ein bestimmtes Produkt.
2. Vom Prozessbedarf zur Systemgrenze kommen
Beschreiben Sie zuerst den Prozess in wenigen verständlichen Schritten. Welche Information entsteht, wer bearbeitet sie und welche Entscheidung hängt von ihr ab? Nennen Sie Anfang und Ende des betrachteten Ablaufs. Dadurch lässt sich unterscheiden, was das System leisten soll und welche organisatorischen Tätigkeiten daneben bestehen bleiben. Eine Softwareanforderung sollte keine ungeklärte Prozessentscheidung verdecken.
Bei einer Ergebnisübertragung beginnt der betrachtete Ablauf beispielsweise mit einem zur Übermittlung bestimmten Laborergebnis und endet mit dessen eindeutigem Verarbeitungsstatus im Zielsystem. Die fachliche Bewertung des Ergebnisses kann vorgelagert sein. Eine rechtliche Chargenzertifizierung ist dadurch noch nicht beschrieben. Diese Grenze verhindert, dass ein Schnittstellenprojekt unbeabsichtigt als vollständige Abbildung des Qualitätsprozesses behandelt wird.
Halten Sie bewusste Ausschlüsse samt relevanten Abhängigkeiten fest. Wenn eine Archivfunktion außerhalb des Projekts liegt, aber später für die Aufbewahrung benötigt wird, gehört diese Abhängigkeit trotzdem in die Betrachtung. Bestehende Prozessbeschreibungen und Systemübersichten können dafür genutzt werden. Sie müssen nicht jede Hintergrundinformation vollständig in die URS kopieren.
Quellen: [2]
3. Fachliche Quellen, Rollen und Daten klären
Sammeln Sie die Grundlage jeder wichtigen Anforderung: freigegebene Arbeitsweise, anwendbare Vorgabe, bekannter Prozessfehler oder begründeter neuer Bedarf. Kennzeichnen Sie offene Annahmen. Eine persönliche Vorliebe für eine Bildschirmansicht sollte nicht denselben Stellenwert erhalten wie eine Kontrolle gegen falsche Ergebniszuordnung. Das erleichtert später Entscheidungen bei Zielkonflikten.
Lassen Sie Prozessverantwortliche die fachliche Bedeutung von Daten erklären. Eine Zahl ohne Einheit, eine Probenkennung ohne Kontext oder ein Status ohne festgelegte Bedeutung kann beim Empfänger anders verstanden werden. IT ergänzt Datenwege, Identitäten und technische Abhängigkeiten. QA unterstützt die Einordnung des Regelbereichs und den geregelten Umgang mit Anforderungen und Nachweisen.
Prüfen Sie dabei, wer Informationen erzeugt, ändert, bestätigt und verwendet. Die erforderlichen Berechtigungen ergeben sich aus diesen Aufgaben. Schreiben Sie keine pauschale Liste möglicher Rollen ab. Besser ist ein nachvollziehbarer Bezug zwischen Handlung, zuständiger Rolle und fachlicher Folge. Annex 11 betont die Zusammenarbeit der relevanten Verantwortlichen; die konkrete Aufgabenverteilung gestalten Sie für Ihr System.
4. Fachliches Soll und technische Lösung auseinanderhalten
„Nur die für diesen Vorgang berechtigte Rolle darf den Status ändern“ beschreibt ein fachliches Soll. „Ein blauer Knopf ruft eine bestimmte Datenbankprozedur auf“ beschreibt eine Lösung. Wenn Sie zu früh eine Lösung festschreiben, kann eine gleichwertige Produktfunktion unnötig ausgeschlossen werden. Umgekehrt ist eine technisch klingende Vorgabe nicht automatisch falsch: Eine verbindliche Schnittstelle oder vorgegebene Infrastruktur kann eine begründete Randbedingung sein.
Kennzeichnen Sie solche Randbedingungen und ihren Ursprung. Dann bleibt erkennbar, welche Entscheidung bereits getroffen wurde und wo ein Anbieter Gestaltungsspielraum hat. In einer funktionalen oder technischen Spezifikation kann anschließend beschrieben werden, wie das gewählte System die Anforderung erfüllt. Dokumente dürfen je nach Umfang zusammengeführt sein, solange diese unterschiedlichen Aussagen verständlich bleiben.
Stellen Sie im Review zwei getrennte Fragen: Brauchen wir dieses Ergebnis? Und ist die vorgeschlagene Umsetzung dafür geeignet? Wird beispielsweise eine bestimmte Protokollierung verlangt, sollten Anlass, benötigte Information und Verwendung geklärt sein, bevor ein bestimmtes Protokollformat vorgegeben wird. Eine pauschale Produkt- oder GAMP-Kategorie beantwortet diese Fragen nicht.
5. Unklare Wünsche in prüfbare Kriterien übersetzen
Ein brauchbares Kriterium verbindet Voraussetzung, Handlung und erwartete Beobachtung. Ergänzen Sie relevante Rollen und Daten, wenn sie das Ergebnis beeinflussen. Fragen Sie anschließend eine fachkundige Person, die den Text nicht geschrieben hat: Könnten Sie damit entscheiden, ob die Anforderung erfüllt ist? Wenn mehrere gegensätzliche Ergebnisse noch als Erfolg gelten könnten, fehlt meist eine Präzisierung.
Prüfbarkeit bedeutet nicht, überall Zahlen einzusetzen. Eine unzulässige Statusänderung muss beispielsweise verhindert werden; dafür ist keine künstliche Prozentzahl nötig. Bei fachlich relevanten Zeitgrenzen oder Messbereichen können dagegen quantitative Kriterien erforderlich sein. Deren Werte werden aus dem konkreten Prozess begründet, nicht aus einer Mustervorlage übernommen.
| Unklare Formulierung | Prüfbarer formuliert | Kommentar zur Anwendung |
|---|---|---|
| Das System muss sicher sein. | Eine Rolle ohne Änderungsberechtigung darf den festgelegten Ergebnisstatus nicht ändern. | Benennen Sie Status, Rolle und die für den Gebrauch relevanten Zugriffswege. |
| Daten müssen korrekt übertragen werden. | Auftragskennung, Ergebniswert und Einheit müssen dem richtigen Zielauftrag ohne Bedeutungsänderung zugeordnet werden. | Erlaubte Umrechnungen und Formate separat festlegen. |
| Die Schnittstelle muss schnell sein. | Die vereinbarte Rückmeldung muss innerhalb des aus dem Prozess abgeleiteten Zeitfensters vorliegen. | Noch kein fertiges Kriterium: Zeitfenster und Prüfbedingungen vor Freigabe konkretisieren. |
| Doppelte Daten sind zu vermeiden. | Eine erneut eingehende Nachricht mit gleicher Kennung und gleichem Inhalt darf keinen zweiten Ergebnisdatensatz erzeugen. | Geänderten Inhalt mit gleicher Kennung als eigenen Konfliktfall behandeln. |
| Fehler müssen angezeigt werden. | Eine zurückgewiesene Übertragung muss für die zuständige Rolle dem Auftrag zuordenbar sein und darf nicht als erfolgreich erscheinen. | Festlegen, wo die Rolle dies erkennt und welches weitere Vorgehen gilt. |
6. Prüftiefe und relevante Fehlerfälle begründen
Beurteilen Sie, welche Folgen eine nicht erfüllte Anforderung haben kann. Eine falsche Ergebniszuordnung verdient möglicherweise mehr Aufmerksamkeit als eine ungünstige Spaltenbreite. Berücksichtigen Sie dabei den tatsächlichen Prozess, vorhandene Kontrollen und bestehende Unsicherheit. ICH Q9(R1) beschreibt einen verhältnismäßigen Umgang mit Qualitätsrisiken; es schreibt nicht für jede URS eine bestimmte Rechenmethode vor.
Leiten Sie aus bedeutsamen Fehlermöglichkeiten gezielte Kriterien ab. Was geschieht bei unbekannter Kennung, unzulässiger Einheit, widersprüchlichem Inhalt oder nicht berechtigter Handlung? Ein positives Beispiel allein zeigt oft nicht, ob der Prozess bei solchen Bedingungen beherrscht bleibt. Gleichzeitig müssen Sie nicht jede denkbare Fehlbedienung als eigene URS-Zeile aufnehmen.
Trennen Sie die Anforderung vom ausführlichen Testskript. Die URS benennt das benötigte Verhalten und hinreichend klare Kriterien. Einzelne Eingabewerte, Klickfolgen und Nachweisformen können anschließend im passenden Test beschrieben werden. Die Verbindung bleibt nachvollziehbar. So entsteht eine Grundlage für risikobasierte Tests, ohne dass die URS zu einer ungeordneten Sammlung von Testschritten wird.
7. Ein konstruiertes Beispiel fachlich durchdenken
Das folgende Beispiel ist vollständig konstruiert; es beschreibt weder einen Kundenfall noch eine bestimmte Softwarefunktion. Eine Laboranwendung soll einen ausgewählten Ergebniswert an ein ERP übermitteln. Der Zielauftrag P-104 existiert bereits. Die Nachricht N-17 enthält einen Ergebniswert von 12,5 mg/l. Für den betrachteten Ablauf ist keine Einheitenumrechnung vorgesehen. Auftrag und Nachricht sind absichtlich frei erfundene Kennungen.
Die ursprüngliche Anforderung lautet: „Das ERP soll Laborergebnisse automatisch übernehmen.“ Das lässt offen, wie der Auftrag zugeordnet wird, welche Einheiten erlaubt sind, was bei einer Wiederholung passiert und wer Fehler bearbeitet. Das Team ergänzt deshalb vier getrennte Anforderungen. Es legt außerdem fest, dass die Übermittlung keine eigenständige fachliche Bewertung oder Chargenzertifizierung ersetzt.
Vor der Auswahl einer technischen Lösung werden die erwarteten Ergebnisse abgestimmt: Der Wert gehört genau zu P-104; seine Einheit bleibt mg/l; eine identische Wiederholung erzeugt keinen weiteren Ergebnisdatensatz; eine Nachricht mit unbekanntem Auftrag wird erkennbar zurückgewiesen. Ob der Anbieter dafür eine Standardfunktion, Konfiguration oder Erweiterung nutzt, wird anschließend im Design bewertet. Diese Trennung macht Angebote und Nachweise vergleichbar.
Quellen: [2]
8. Anforderungen und konkrete Sollprüfungen verbinden
Die folgende Tabelle formuliert einen Ausschnitt der Beispiel-URS, keine vollständige Spezifikation. Alle Testhandlungen sind Vorschläge, keine ausgeführten Prüfungen. Sie veranschaulichen, wie die Kriterien eine spätere Beurteilung ermöglichen. Bei der Umsetzung wären zusätzlich der tatsächliche Systemstand, Rollen, Datenfluss und weitere relevante Risiken zu berücksichtigen.
Beginnen Sie im Beispiel mit einer gültigen Nachricht und vergleichen Sie Quelle und Ziel. Senden Sie danach denselben Inhalt erneut. Verändern Sie anschließend bei gleicher Nachrichtenkennung den Ergebniswert: Dieser Konflikt darf nach der hier angenommenen Fachregel nicht still überschreiben. Zuletzt verwenden Sie eine unbekannte Auftragskennung. Für jeden Schritt werden die erwartete Beobachtung und der zulässige Ausgang vorher festgehalten.
Scheitert eine vorgeschlagene Lösung an einem Kriterium, ändern Sie nicht still die Erwartung. Klären Sie, ob ein Umsetzungsfehler, eine unpassende Lösung oder eine sachlich zu revidierende Anforderung vorliegt. Eine begründete Änderung bleibt möglich, muss aber samt betroffener Nachweise nachvollziehbar sein.
| Kennung | Fachliche Anforderung und Kriterium | Illustrative Prüfung |
|---|---|---|
| U-01 | Ergebnisse werden nur einem eindeutig identifizierten vorhandenen Auftrag zugeordnet; unbekannte Kennungen erzeugen keine automatische Ersatzzuordnung. | P-104 verwenden, anschließend eine unbekannte Kennung senden; Zuordnung beziehungsweise Zurückweisung beurteilen. |
| U-02 | Ergebniswert und Einheit behalten ihre Bedeutung; nicht vereinbarte Einheiten werden in diesem Ablauf nicht still umgedeutet. | 12,5 mg/l vergleichen; anschließend eine nicht zugelassene Einheit senden und den definierten Fehlerweg prüfen. |
| U-03 | Gleiche Nachricht mit gleichem Inhalt erzeugt keinen zweiten Ergebnisdatensatz; gleicher Schlüssel mit geändertem Inhalt wird als Konflikt behandelt. | Identische Wiederholung und danach geänderten Wert bei gleicher Nachrichtenkennung getrennt prüfen. |
| U-04 | Die zuständige Rolle erkennt zurückgewiesene Übertragungen mit Auftragsbezug; ihr Status darf nicht Erfolg signalisieren. | Zurückweisung erzeugen und sichtbare Zuordnung, Status und geregelte Bearbeitungsmöglichkeit prüfen. |
9. Review, Version und Nachvollziehbarkeit organisieren
Lassen Sie die URS von den Personen beurteilen, die das fachliche Soll, seine Risiken und die technische Machbarkeit verstehen. Prüfen Sie widersprüchliche Kriterien, unerklärte Abkürzungen, offene Annahmen und nicht zugeordnete Zuständigkeiten. Ein Dokument kann sprachlich sauber wirken und dennoch zwei unvereinbare Prozessregeln enthalten. Das Review soll solche Unterschiede sichtbar machen, bevor sie in Konfiguration oder Tests übergehen.
Halten Sie Anforderungen eindeutig identifizierbar und ihren aktuellen Stand erkennbar. Verknüpfen Sie Änderungen mit der betroffenen Umsetzung und den Nachweisen. Das kann in einer passenden Tabelle oder einem geeigneten System erfolgen; ein bestimmtes Werkzeug ist nicht vorgeschrieben. Die URS bleibt eine fachliche Referenz, statt nach Beschaffung des Produkts bedeutungslos zu werden.
Auch ein bestehendes System ohne frühere URS braucht eine geklärte heutige Anforderungsbasis. Die EMA behandelt diesen Fall ausdrücklich. Dokumentieren Sie den gegenwärtigen Sollgebrauch und bewerten Sie die vorhandenen Nachweise dazu. Datieren Sie Unterlagen nicht rückwirkend und erklären Sie heutige Anforderungen nicht zum Beleg früherer Kontrollen. Die weitere Bearbeitung historischer Lücken ist ein eigener Arbeitsschritt.
10. Den Start für ein KMU konkret vorbereiten
Stellen Sie für den ersten Termin einen abgegrenzten Prozess, vorhandene Arbeitsanweisungen, bekannte Fehler oder Schwierigkeiten und eine Übersicht der beteiligten Systeme bereit. Bringen Sie auch offene Entscheidungen mit. Ein noch unbekanntes Produkt hindert Sie nicht daran, den fachlichen Bedarf zu beschreiben. Einzelne technische Randbedingungen können später ergänzt werden, sobald sie begründet feststehen.
Der Aufwand wird durch Prozessklarheit, Schnittstellen, unterschiedliche Standortregeln, Datenbedeutung und die Zahl ungeklärter Entscheidungen geprägt. Dokumentlänge ist dafür ein schwacher Maßstab. Bearbeiten Sie zunächst einen wichtigen Ablauf vollständig und stimmen Sie Schreibweise sowie Detailtiefe gemeinsam ab. Das schafft eine brauchbare Grundlage, bevor mehrere Personen parallel Anforderungen formulieren.
- Vorgesehener Gebrauch, Regelbereich und Systemgrenze benannt.
- Fachliche Quelle und zuständige Rolle je wichtiger Anforderung erkennbar.
- Benötigtes Ergebnis von technischer Lösung und Randbedingung getrennt.
- Akzeptanzkriterien unter definierten Bedingungen beurteilbar.
- Relevante Fehlerszenarien und bestehende Kontrollen berücksichtigt.
- Offene Werte und Entscheidungen sichtbar; vor verbindlicher Nutzung geklärt.
- Review, Version und Verknüpfung mit späteren Nachweisen geregelt.
Häufige Fragen zu URS schreiben
Wie unterscheidet sich eine URS von einer funktionalen Spezifikation?
Die URS beschreibt den benötigten Gebrauch und das fachliche Ergebnis aus Anwendersicht. Eine funktionale Spezifikation beschreibt näher, wie die gewählte Lösung dieses Soll erfüllt. Begründete technische Randbedingungen können bereits in der URS stehen. Entscheidend ist die erkennbare Funktion der Aussage; je nach Projekt dürfen Inhalte sinnvoll zusammengeführt werden, ohne die fachliche Anforderung in technischen Details zu verlieren.
Muss jedes Akzeptanzkriterium eine Zahl enthalten?
Nein. „Eine nicht berechtigte Rolle kann diesen Status nicht ändern“ ist grundsätzlich beurteilbar, wenn Rolle, Status und Bedingungen geklärt sind. Für Zeitgrenzen, Messbereiche oder Belastungen können Zahlen dagegen wesentlich sein. Verwenden Sie dann aus dem Prozess begründete Werte und definierte Prüfbedingungen. Eine frei erfundene Prozentzahl macht eine unklare Anforderung nicht automatisch belastbarer.
Brauchen wir eine URS auch bei unveränderter Standardsoftware?
Der vorgesehene Gebrauch und die benötigten Funktionen müssen auch bei einem bestehenden Produkt verständlich sein. Sie müssen dafür keinen vollständigen Herstellerkatalog abschreiben. Beschreiben Sie relevante Anforderungen und prüfen Sie, wie das Produkt sie abdeckt. Gute Lieferantendokumentation kann dabei helfen. Ein bekannter Produktname allein sagt jedoch nicht, ob Ihre Rollen, Daten und Abläufe passend unterstützt werden.
Quellen: [2]
Dürfen wir Anforderungen des Lieferanten als Ausgangspunkt verwenden?
Ja, wenn Sie sie auf Ihren Gebrauch prüfen und erforderlichenfalls anpassen. Eine Herstellerliste kann Funktionen verständlich machen und offene Fragen aufdecken. Sie ist aber nicht automatisch Ihre abgestimmte Anforderungsbasis. Kennzeichnen Sie passende Übernahmen, begründen Sie relevante Ergänzungen und entfernen Sie für den beschriebenen Umfang unpassende Vorgaben aus der verbindlichen Auswahl. Bewahren Sie die Herkunft nachvollziehbar auf.
Wer muss an der URS mitarbeiten und sie freigeben?
Der Fachbereich muss das benötigte Ergebnis vertreten; Systemverantwortlicher beziehungsweise IT klären Abhängigkeiten und Machbarkeit; QA unterstützt die regulatorische Einordnung und den geregelten Dokumentationsweg. Wer formal genehmigt, ergibt sich aus Zuständigkeiten und Ihrem Qualitätsmanagementsystem. Eine universelle Zahl von Unterschriften ist daraus nicht abzuleiten. Fehlende fachliche Entscheidungen lassen sich durch zusätzliche Signaturen nicht ersetzen.
Müssen wir jede verfügbare Softwarefunktion beschreiben?
Die URS sollte Ihren vorgesehenen Gebrauch abbilden. Unbenutzte Funktionen müssen nicht allein wegen ihrer Existenz zu eigenen Anforderungen werden. Prüfen Sie aber relevante Abhängigkeiten: Eine übergreifende Berechtigungsfunktion kann den genutzten Ablauf beeinflussen, auch wenn sie kein eigener Geschäftsprozess ist. Begründen Sie den Umfang und die angemessene Detailtiefe anhand von Auswirkungen, Risiken und Systemzusammenhängen.
Wie gehen wir mit einem alten System ohne ursprüngliche URS um?
Ermitteln Sie die heute benötigten Funktionen und den tatsächlich vorgesehenen Gebrauch und stellen Sie eine aktuelle Anforderungsbasis her. Vergleichen Sie diese mit verfügbaren Nachweisen und offenem Risiko. Die EMA beschreibt das Vorgehen für bestehende Systeme ohne damalige URS. Eine heutige Dokumentation darf dabei weder zurückdatiert werden noch eine nicht belegte historische Prüfung vortäuschen.
Was tun wir mit noch ungeklärten Werten oder Prozessregeln?
Markieren Sie sie ausdrücklich und ordnen Sie Verantwortliche sowie einen Klärungszeitpunkt zu. Ein Entwurf darf offene Punkte enthalten. Bevor eine Anforderung verbindlich für Auswahl, Umsetzung oder Akzeptanz verwendet wird, müssen die dafür entscheidenden Kriterien ausreichend geklärt sein. Im Zeitbeispiel der Tabelle fehlt deshalb bewusst noch der konkret begründete Grenzwert; die Formulierung allein ist nicht abnahmefähig.
Darf eine Anforderung nach Beginn der Tests geändert werden?
Eine sachlich begründete Änderung ist möglich, sollte aber kontrolliert erfolgen. Beschreiben Sie Anlass, betroffene Kriterien, Umsetzungsfolgen und notwendige Anpassungen der Nachweise. Ein fehlgeschlagener Test darf nicht allein durch nachträgliche Umformulierung zum Erfolg erklärt werden. Unterscheiden Sie einen Implementierungsfehler von einem tatsächlich revidierten fachlichen Bedarf und halten Sie diese Entscheidung nachvollziehbar fest.
Was müssen wir bereitstellen, und wie lässt sich der Aufwand abschätzen?
Beginnen Sie mit Prozessablauf, relevanten Arbeitsanweisungen, Rollen, Datenwegen und bekannten offenen Entscheidungen. Der Aufwand hängt vor allem davon ab, wie viel fachliches Soll erst geklärt werden muss und wie viele Abhängigkeiten bestehen. Ein gemeinsam ausgearbeiteter wichtiger Ablauf zeigt die benötigte Tiefe. Eine feste Seitenzahl oder pauschale Dauer ist dafür kein verlässlicher Ersatz.
Quellen & fachlicher Stand
Quellen am 6. Oktober 2026 geöffnet. Der regulatorische Beispielrahmen ist Humanarzneimittel-GMP. Annex 11, Annex 15 und Kapitel 4 werden in den aktuell verlinkten Fassungen verwendet; Entwürfe werden nicht als zusätzliche Pflichten ausgegeben. Tabellen, Formulierungen und Schnittstellenszenario sind eigene illustrative Arbeitshilfen und keine ausgeführten Produkttests.
- Europäische Kommission: EudraLex Volume 4, aktuelle Übersicht der GMP-Leitlinien
- EU-GMP Annex 11: Computerised Systems, Revision Januar 2011
- EU-GMP Annex 15: Qualification and Validation, Revision 2015
- EU-GMP Kapitel 4: Documentation, Revision Januar 2011
- EMA: GMP/GDP Questions and answers, Abschnitt Annex 11, Fragen 5 und 6
- ICH Q9(R1): Quality Risk Management, europäische Step-5-Fassung 2023
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Aus Prozesswissen eine verwendbare URS machen
Daniel Herrmann Consulting unterstützt Sie dabei, fachliche Anforderungen abzugrenzen, Kriterien zu schärfen und die Verbindung zu Umsetzung und Nachweisen nachvollziehbar aufzubauen.
- IT-GxP-Audit →
Bestehende Anforderungen auf Unklarheiten, Lücken und fehlende Nachvollziehbarkeit prüfen.
- IT-GxP-Consulting →
URS, Akzeptanzkriterien und passende Nachweisstruktur gemeinsam ausarbeiten.