Prüfplanung, wenn die Anforderung
schon in DOORS steht

DOORS führt die Anforderungen. Das bleibt so.

DOORS ist das führende System für die Anforderungen, und das aus gutem Grund. Module, Verknüpfungen, Baselines, Historie, Zugriffsrechte: das Werkzeug kann das, und es sitzt seit Jahren. Wer ein solches Projekt führt, hat die Struktur nicht aus Nachlässigkeit so gebaut. Sie ist gewachsen, weil das Fahrzeug, die Varianten und die Änderungsanträge gewachsen sind. Cevelar ersetzt das nicht. Es setzt dort an, wo aus einer geänderten Pflicht ein Prüfplan werden muss, und gibt den Bestand über ReqIF und CSV zurück.

Eine verdächtige Verknüpfung ist eine korrekte Meldung. Sie sagt, dass etwas betroffen ist. In einem gewachsenen Modul sind das viele Meldungen. Sie werden abgearbeitet oder sie bleiben stehen. Steuern tun sie die Prüfplanung selten, weil die nächste Frage nicht im Modul liegt: welche der schon geführten Prüfungen noch gilt.

Was die Suspect Links nicht entscheiden

Die Prüfmethode an der Anforderung ist in DOORS ein Attribut. Aufwand, Dauer und welche Ressource gebunden wird, stehen daneben, meist in einer eigenen Liste. Der geführte Nachweis — gegen welche Fassung, unter welchen Randbedingungen — ist kein Objekt im Werkzeug. Ob er nach einem Change Request weiterträgt, ist eine Bewertung, keine Ableitung. Wiederverwendung über Fahrzeugprojekte hinweg ist dasselbe in größerem Maßstab: eine manuelle Einschätzung, die jemand mit dem alten Bericht und dem neuen Lastenheft nebeneinander vornimmt.

Cevelar führt Prüfmethode und Aufwand an der Pflicht selbst, nicht als Nebenliste. Suspect Links markieren den Eingang. Sie sagen nicht, welcher Prüfstand noch gilt, welcher Fahrzeugversuch neu muss, und welche Belegung sich daraus verschiebt. Genau das ist die Lücke zwischen Anforderungsverwaltung und Prüfplanung.

Change Request 19 an der Türsteuerung

Eine Türsteuerung, SIL 2. Die Pflicht SYS-0218 verlangt die Freigabe erst unterhalb einer Geschwindigkeitsschwelle. Nachgewiesen ist sie über Prüfstand und Fahrzeugversuch, geführt gegen 5 km/h, Lastenheft Rev. C. Alle Angaben in diesem Abschnitt sind Demo-Daten.

Der Betreiber schickt Change Request 19. Die Schwelle wird 3 km/h. In DOORS werden die Verknüpfungen von SYS-0218 verdächtig. Das ist die richtige Meldung. Sie endet dort. Sie sagt nicht, ob der Prüfstandsbericht aus V&V-0312 weiterverwendet werden kann, ob der Fahrzeugversuch neu aufgesetzt werden muss, oder ob nur die Dokumentation der Randbedingungen nachzuziehen ist.

Offen bleibt, was der geführte Nachweis noch wert ist. Der Prüfstand war gegen 5 km/h aufgebaut. Die neue Schwelle ändert die Randbedingung, nicht unbedingt den Prüfaufbau. Ob der Nachweis weiterträgt, hängt davon ab, was am Stand wirklich gemessen wurde — und nicht vom Pflichttext allein. Ein Aufbau, der die Freigabe über den gesamten Geschwindigkeitsbereich erfasst hat, kann die schärfere Schwelle bereits enthalten. Ein Aufbau, der nur den alten Grenzwert bestätigt hat, nicht. Das steht selten im Attribut, oft nur im Versuchsbericht.

Der Fahrzeugversuch hängt an der ausgerollten Softwarefassung und an dem Fahrzeug, das damals verfügbar war. Auch er kann wahr bleiben und trotzdem nicht mehr tragen: dieselbe Messung, eine andere Geltung. Die SIL-Einstufung folgt nicht aus der Schwelle. Sie bleibt eine eigene Bewertung.

Wer nach Change Request 19 pauschal neu prüft, bindet einen Prüfstand und ein Fahrzeug, die Monate im Voraus vergeben sind. Wer pauschal stehen lässt, trägt die Nachweislage in die nächste Gutachterrunde. Beides sind Kategorien, keine Preise: eine Belegung, eine Runde, im schlechten Fall eine verschobene Inbetriebnahme.

Dasselbe Teilsystem, nächstes Fahrzeugprojekt

Dieselbe Türsteuerung läuft in einem zweiten Fahrzeugprojekt, oft mit eigener Lastenheftfassung und eigenen Ländervarianten. Ein Nachweis ist wiederverwendbar, wenn nachvollziehbar ist, gegen welche Anforderungsfassung und unter welchen Randbedingungen er geführt wurde. Fehlt dieser Anker, bleibt nur der Bericht und die Erinnerung, dass „etwas Vergleichbares schon gelaufen ist“. Ohne diese Rückverfolgbarkeit wird im Zweifel neu geprüft.

EN 50126, der Sicherheitsnachweis, die Begutachtung

EN 50126 setzt den Rahmen für Verifikation und Validierung. EN 50129 verlangt den Sicherheitsnachweis mit nachvollziehbaren Ketten. EN 50657 beziehungsweise EN 50128 gelten, wo Software im Teilsystem liegt. CSM-RA bewertet die Änderung, nicht das Werkzeug.

Cevelar hängt Klauseln aus EN 50126, EN 50128, EN 50129 und EN 50657 an die Pflicht und hält Historie und Nachweisketten. Den Sicherheitsnachweis führt ihr. Die Begutachtung durch ISA, AsBo oder NoBo besteht ihr. Die Plattform sagt weder eine Typzulassung noch eine Inbetriebnahmegenehmigung zu.

Normtexte

Frei zugängliche Regelwerke — etwa TSI-Texte und die Durchführungsverordnung zur CSM-RA — sind enthalten. Kostenpflichtige Normen, darunter EN 50126, EN 50128, EN 50129, EN 50657 sowie DIN- und VDE-Normen, bringt ihr unter eurer eigenen Lizenz ein. Wir verkaufen keine Normtexte weiter. Wir verarbeiten keine kostenpflichtigen Normtexte, für die uns keine Lizenz vorliegt. Im Bahnumfeld ist das ein Prüfkriterium, kein Nebensatz: der Klauselbezug ist eine Referenz, kein Ersatz für das Normexemplar.

Woran sich das im laufenden Projekt zeigen ließe

An einer Änderung, die schon in DOORS steht, und an der dazugehörigen Prüfplanung. Welche Nachweise nach dem Delta noch tragen, welche Prüfung neu muss, welche Belegung sich verschiebt. Nicht als Einführung, sondern an dem Modul, das ihr ohnehin pflegt. Gehostet in Deutschland, On-Premise auf Anfrage.

Gebaut von Ingenieuren aus Test und Validierung, nicht aus dem Toolvertrieb. Elf Jahre Prüf- und Validierungsarbeit stecken in der Logik hinter der Plattform. Wer wir sind