graphcode-Demo: City People Mover

Das Beispielsystem

Ein fahrerloser City People Mover: acht Stationen, Kabinen auf eigener Trasse, eine Leitstelle, Fahrgäste ohne Einweisung. Modelliert wurde er, um graphcode zu zeigen, ohne vorher etwas bauen zu müssen — kein Kundenprojekt, keine geschönten Zahlen.

Zusammen 219 Einträge und 402 Verknüpfungen. Unter den 64 Anforderungen sind 16 Risiken, jedes mit einer Gegenmaßnahme.

Eine Wirkkette: Türzyklus am Bahnsteig

Der Ablauf, der hinter dem Satz „Kabinentür und Bahnsteigtür öffnen nur gemeinsam, und nur im Stillstand“ steckt: Stillstandsnachweis, Nachweis der Türverriegelung, synchrone Freigabe beider Türen, Hindernisüberwachung. Elf Elemente, achtzehn Verbindungen — gezeichnet aus dem Modell, nicht gemalt.

Was das Modell über sich selbst sagt

Niemand tippt hier einen Prozentwert in eine Folie: Der Stand wird aus dem Modell berechnet. 0 von 219 Einträgen verletzen eine Regel — und trotzdem sind erst 3 von 8 Reifegrad-Toren bestanden.

Das Modell steht bewusst im Konzeptstand — entworfen, nicht gebaut. Genau das sagt es auch, ohne Beschönigung:

• Kein Test ist gelaufen. Alle 41 Tests sind als Konzept beschrieben, keiner trägt ein Ergebnis.
• Keines der 16 Risiken hat einen bestandenen Nachweis — darunter Türöffnung während der Fahrt, Auffahrunfall und Fahrgäste, die selbstständig in die Trasse steigen.
• 0 von 44 Verbindungen zwischen Funktionen sind integrationsgetestet. Deshalb fällt das Tor vor der Testphase durch, während die drei davor bestehen.

Ein Demo-Modell, das sich als fertig ausgibt, würde nichts beweisen. Dieses benennt, was offen ist — und wo es steht.

Was das Modell leistet

Was es nicht tut: Es entscheidet nichts. Die Prüfung kann sagen, dass das Modell widerspruchsfrei ist — nicht, dass es das gewünschte System beschreibt. Das bleibt Ihre Aufgabe, ebenso die Antworten auf die Fragen aus Ihrer Domäne. Der Preis ist eine Regel: Wer eine Anforderung schreibt, benennt den Test, der sie widerlegen würde.

Die 15 gedruckten Dokumente

Vollständig einsehbar, so wie sie aus dem Modell fallen. Fachsprache des Modells ist Englisch; die leeren Dokumente sind nicht kaputt, sondern ehrlich — im Konzeptstand gibt es dort noch nichts zu drucken.

• Anforderungsspezifikation (SRS) Alle 64 Anforderungen unter dem Element, das sie erfüllt — Akteure, Anwendungsfälle, Funktionen, Bausteine.
• Betriebskonzept (ConOps) Betriebsarten, Nutzergruppen, Szenarien und Randbedingungen des Systems.
• Architektur und Allokation (SDD) Welche Funktion in welchem Baustein sitzt — sieben Bausteine, 24 Funktionen.
• Schnittstellendokument (ICD) 32 Datenflüsse mit Protokoll, Format und beiden Enden.
• NFR-Register Sechs nicht-funktionale Anforderungen mit Budget und dem Test, der sie prüft.
• Anforderungs-Test-Matrix (RTM) Jede Anforderung mit dem Test, der sie widerlegen würde — und den Lücken.
• Testkonzept Testpyramide über 41 Tests — und die berechnete Lücke: 0 von 44 Funktionsverbindungen integrationsgetestet.
• Testmatrix (VCRM) Nachweisverfahren je Anforderung und Ergebnisstand je Test — durchweg offen.
• Integrations- und Testplan Leer — entsteht erst mit dem Implementierungsplan.
• Implementierungsplan Leer — Arbeitspakete werden erst zum Implementierungsstart aus dem Modell geschnitten.
• FMEA (Risikoanalyse) 16 Fehlermodi mit Schwere, Auftreten, Entdeckung, RPZ und Gegenmaßnahme.
• Trade Study Leer — im Konzeptstand ist noch keine Entwurfsentscheidung mit verworfener Alternative im Modell.
• Änderungsprotokoll Leer — 0 Änderungsanträge, nach Meilenstein gruppiert.
• Change-Request-Liste Leer — kein Änderungsantrag im Modell.
• Elementverzeichnis Alle 219 Einträge mit ihren Verknüpfungen — das Modell als Nachschlagewerk.

Stand: Modell-Snapshot vom 22.08.2026, erzeugt mit @sigloch/graphcode 0.17.0.