Vom Code zur Spezifikation

Wer ein gewachsenes System ablösen, modernisieren oder ausschreiben will, beginnt in der Regel mit der Frage, was das neue System können soll. Das ist die falsche Reihenfolge. Die einzige vollständige Beschreibung dessen, was ein Unternehmen heute fachlich tut, steckt im Bestand: im Quellcode und in der täglichen Bedienung. Dieser Beitrag zeigt, wie wir Anforderungen aus dem Bestand rekonstruieren, was eine IST-Spezifikation enthalten muss und wie daraus ein belastbares SOLL entsteht.

Warum das IST vor dem SOLL kommt

Im ersten Beitrag dieser Serie habe ich beschrieben, warum Legacy-Systeme ein Wissensarchiv sind: Das Wissen der Kolleginnen und Kollegen, die in Pension gehen, steckt nicht in Dokumenten, sondern im Custom Code. Daraus folgt eine praktische Konsequenz für jedes Modernisierungsvorhaben: Bevor jemand beschreibt, wie es werden soll, muss belegt sein, wie es ist.

In der Praxis passiert häufig das Gegenteil. Ein Ablöseprojekt startet mit SOLL-Workshops. Der Fachbereich beschreibt, was er sich vom neuen System wünscht, die IT ergänzt Architekturvorgaben, und das Altsystem gilt als bekannt, weil man es ja täglich benutzt. Das Lastenheft, das so entsteht, ist eine Sammlung von Wünschen und Erinnerungen. Die Sonderfälle, die das Altsystem über zwanzig Jahre eingesammelt hat, stehen nicht darin: die Rundungsregel für eine bestimmte Vertragsart, die Ausnahme für einen einzelnen Großkunden, die Schnittstelle, die nachts einen Report für die Buchhaltung erzeugt. Sie tauchen erst auf, wenn das neue System sie nicht mehr kann, meist in der Abnahme oder nach dem Go-live.

Drei Dinge liefert nur eine belegte IST-Spezifikation:

• Vollständigkeit der Regeln. Das Altsystem enthält jede Geschäftsregel, die heute gilt, inklusive der Regeln, die niemand mehr erklären kann. Workshops liefern die Regeln, an die sich jemand erinnert.
• Schnittstellen und Datenflüsse. Welche Systeme lesen und schreiben welche Daten, welche Batches laufen nachts, was hängt woran? Das steht nirgends außer im Code.
• Eine Grundlage für Schätzung und Ausschreibung. Ohne IST wird der Umfang geschätzt, mit IST wird er gezählt. Für Ausschreibungen ist das der Unterschied zwischen Risikozuschlägen der Anbieter und einem kalkulierbaren Angebot.

Für uns ist das eine direkte Anwendung des Prinzips „Own the Spec, not the Code“. Bei Bestandssystemen besitzt das Unternehmen meist beides nicht: nicht den Code in verständlicher Form und nicht die Spezifikation. Der erste Schritt ist deshalb die Rekonstruktion.

Wer das IST nicht besitzt, schreibt das SOLL aus der Erinnerung.

Zwei Wege in den Bestand: Quellcode und Nutzung

Anforderungen lassen sich aus zwei Quellen rekonstruieren, und beide haben ihre Berechtigung. Wir setzen dafür zwei agentische Plattformen ein, die Teil unserer Beratungsleistung sind.

Whitebox: aus dem Quellcode. SLIP, die Sysparency Legacy-Code Intelligence Platform, liest den Quellcode und die vorhandene Dokumentation eines Systems ein, unabhängig von der Technologie: SAP/ABAP, IBM Mainframe mit COBOL, PL/I und JCL, IBM i, NATURAL/ADABAS oder Open Systems wie Java, Python, C/C++ und JavaScript. Entscheidend ist die Reihenfolge der Analyse. Zuerst stellt eine deterministische, symbolische Analyse die Fakten fest: Aufruf- und Abhängigkeitsgraphen, Lese- und Schreibzugriffe auf Daten, Bildschirm- und Prozessflüsse, Schnittstellen und Jobs. Erst danach erklären KI-Agenten jeden Baustein zweimal, fachlich für den Fachbereich und technisch für Architektur und Entwicklung. Die KI erfindet keine Struktur, sie erklärt eine bewiesene. Jede Aussage ist bis auf Programm und Zeile nachweisbar.

Blackbox: aus der beobachteten Nutzung. App2Spec betrachtet das System so, wie Anwenderinnen und Anwender es sehen. Entweder bedient ein KI-Agent die Anwendung selbstständig und erkundet Masken, Dialoge und Navigationspfade, oder die Plattform zeichnet die Arbeit echter Benutzerinnen und Benutzer auf, jeden Bildschirm und jedes Ereignis inklusive Screenshot. Daraus entstehen Screens, Bedienelemente, Navigationspfade, Datenfelder, abgeleitete Geschäftsregeln und End-to-End-Prozesse mit Prozessdiagrammen. Jede Aussage ist mit Screenshot und Ereignisprotokoll belegt.

Welcher Weg der richtige ist, hängt von der Situation ab:

Der dritte Fall ist in unseren Projekten der häufigste. Der Code sagt, was ein System kann; die Nutzung sagt, was davon gebraucht wird. Erst die Kombination zeigt, welche Funktionen seit Jahren niemand mehr aufruft und welche Regel täglich hundertfach greift. Beides ist für das SOLL wichtig, aus entgegengesetzten Gründen.

Was eine IST-Spezifikation enthalten muss

Eine IST-Spezifikation ist weder ein kommentiertes Code-Listing noch eine Sammlung von Screenshots. Sie ist eine fachliche Beschreibung des Systems in einer Struktur, die für die nächsten Schritte taugt: Ausschreibung, SOLL-Konzeption, Migration oder agentische Neuentwicklung. In unseren Projekten hat sich ein fester Aufbau bewährt:

1. Prozesse. End-to-End-Abläufe von der Auslösung bis zum Ergebnis, als Prozessdiagramm und in Textform, mit den beteiligten Rollen und Systemen.
2. Masken und Bedienelemente. Jeder Screen mit seinen Feldern, Aktionen und Navigationspfaden, damit erkennbar ist, was Anwenderinnen und Anwender tatsächlich tun.
3. Datenobjekte und Felder. Welche Daten das System führt, wo sie entstehen, wer sie liest und wer sie schreibt.
4. Geschäftsregeln. Validierungen, Berechnungen, Berechtigungen und Sonderfälle, jeweils mit der Bedingung, unter der sie greifen.
5. Schnittstellen und Batches. Ein- und ausgehende Verbindungen, nächtliche Verarbeitungen, Abhängigkeiten zwischen Jobs.
6. Evidenz je Aussage. Programm und Zeile oder Screenshot und Ereignisprotokoll, direkt aus der Spezifikation heraus aufrufbar.

Der letzte Punkt ist der wichtigste. Eine Spezifikation ist nur so viel wert wie das Vertrauen, das sie genießt. Wenn der Fachbereich eine Geschäftsregel anzweifelt, soll niemand diskutieren müssen, wer sich richtig erinnert. Ein Klick zeigt die Fundstelle. Für Revision, Ausschreibung und Abnahme ist das der Unterschied zwischen einer Meinung und einem Beleg.

Weil beide Plattformen ihre Ergebnisse in einem Wissensgraphen mit typisierten, standardisierten Entitäten ablegen, sind IST-Spezifikationen über Anwendungen hinweg einheitlich strukturiert. Das zahlt sich aus, sobald mehr als ein System betroffen ist, etwa bei einer Landschaftsanalyse oder einer Konsolidierung.

Was kein Werkzeug entscheiden kann, entscheiden Menschen. Unsere Expertinnen und Experten validieren die Spezifikation gemeinsam mit dem Fachbereich an den Stellen, an denen es auf fachliche Wahrheit ankommt. Die typische Frage lautet: Ist diese Regel gewollt, oder ist sie ein Fehler, der über die Jahre zur Gewohnheit wurde? Der Code kennt die Antwort nicht. Er weiß nur, dass die Regel existiert.

Vom IST zum SOLL: die Delta-Frage

Mit einer belegten IST-Spezifikation ändert sich der Charakter der SOLL-Workshops. Die Frage lautet nicht mehr „Was wünschen Sie sich?“, sondern „Was davon behalten wir, was ändern wir, was streichen wir?“. Aus einer offenen Erhebung wird eine Delta-Entscheidung, die der Fachbereich auf Basis von Fakten trifft.

• Behalten. Die Mehrheit der Geschäftsregeln trägt das Geschäft und wird unverändert übernommen. Sie wandern eins zu eins in das SOLL, mit ihrem Beleg aus dem IST. Nach unserer Erfahrung ist das der größte Teil des Umfangs, und genau dieser Teil fehlt in Lastenheften, die aus Workshops entstehen.
• Ändern. Bekannte Schmerzpunkte, neue regulatorische Anforderungen, geänderte Prozesse. Hier findet die eigentliche fachliche Arbeit statt, jetzt aber vor dem Hintergrund einer vollständigen Ausgangslage.
• Streichen. Funktionen, die laut Nutzungsaufzeichnung niemand mehr aufruft, historische Sonderfälle ohne aktiven Anwendungsfall, Schnittstellen zu Systemen, die es nicht mehr gibt. Streichen ist die günstigste Entscheidung im ganzen Projekt, und sie ist nur mit belegtem IST möglich.

Technisch führen wir die IST-Spezifikationen aus App2Spec und SLIP in den ReqPOOL Requirements Manager und entwickeln sie dort zur SOLL-Spezifikation weiter. reqChecker prüft jede Anforderung nach den Kriterien von IREB und ISO/IEC/IEEE 29148 auf Eindeutigkeit und Verifizierbarkeit und schlägt testbare Formulierungen vor. Das Ergebnis ist eine Spezifikation, die zwei Adressaten dient: als Lastenheft für eine Ausschreibung, in der Anbieter auf Fakten statt auf Risikozuschläge kalkulieren, oder als maschinenlesbarer Bauauftrag für die agentische Neuentwicklung mit reqCoder, unserem vollständigen, vollautomatisierten agentischen Software Development Lifecycle, der bei uns intern bereits im Einsatz ist.

Was sich im Projekt konkret ändert

Ich werde oft gefragt, ob das Reverse Engineering ein Projekt nicht verlängert. Nach unserer Erfahrung aus ReqPOOL-Projekten ist das Gegenteil der Fall: Es verkürzt das Projekt, weil es die teuerste Phase nach vorne holt. Die Sonderfälle werden am Anfang gefunden, nicht in der Abnahme. Drei Dinge ändern sich sichtbar:

• Die Erfassung dauert Tage, nicht Monate. Quellcode-Extraktion und Aufnahme-Sessions laufen agentisch. Die Analyse eines Systems, die manuell Monate an Workshops und Dokumentation erfordert, liegt nach unseren Erfahrungswerten aus ReqPOOL-Projekten in Tagen vor, projektspezifisch validierbar. Der Aufwand der Menschen konzentriert sich auf die Validierung.
• Workshops werden kürzer und besser. Statt das System aus der Erinnerung zu beschreiben, prüft der Fachbereich eine belegte Beschreibung und entscheidet über das Delta. Die Diskussionen drehen sich um Entscheidungen, nicht um Fakten.
• Das Wissen bleibt im Unternehmen. Dokumentation, Wissensgraph und Assistent verbleiben als Arbeitsmittel beim Kunden. Die nächste Frage „Was geht kaputt, wenn wir das ändern?“ wird nicht mehr an die eine Person gestellt, die es noch weiß, sondern in Sekunden aus dem Wissensgraphen beantwortet.

Für regulierte Branchen kommt hinzu, dass beide Plattformen in der EU gehostet werden, Kundendaten und Quellcode nicht zum Training von KI-Modellen verwendet werden und in ReqPOOL-Beratungsprojekten keine Lizenzkosten für die eingesetzten Werkzeuge entstehen. Sie bezahlen Expertise und Aufwand; die IST-Spezifikation gehört Ihnen.

Der nächste Schritt

Wenn ein Ablöse- oder Modernisierungsvorhaben ansteht, ist die belegte IST-Spezifikation der erste Schritt, und zwar vor dem ersten SOLL-Workshop. Wie wir Bestandssysteme aus Quellcode und Nutzung rekonstruieren, beschreibt unsere Leistung Reverse Engineering; die beiden Wege im Detail finden Sie auf den Seiten zu App2Spec und SLIP. In einem Expertengespräch klären wir, welches Ihrer Systeme sich für einen Start eignet und ob der Whitebox-Weg, der Blackbox-Weg oder beide angebracht sind.