# 2. Theoretische Grundlagen Dieses Kapitel beschreibt die theoretischen Grundlagen, die für die Konzeption und Bewertung eines KI-gestützten Reverse Requirements Engineering in Legacy-Umgebungen benötigt werden. Zunächst werden zentrale Begriffe des Requirements Engineering sowie die Idee der rückwärtsgerichteten Anforderungsgewinnung aus bestehenden Systemen eingeordnet. Anschließend werden Large Language Models als Werkzeugklasse im Software Engineering beschrieben, inklusive typischer Leistungsgrenzen und Absicherungsmechanismen. Abschließend werden Grundlagen der Legacy-Modernisierung sowie etablierte Migrationsstrategien zusammengefasst, um den Kontext der Fallstudie und die Zielrichtung einer webbasierten Modernisierung einzuordnen. ## 2.1 Requirements Engineering und Reverse Requirements Engineering ### 2.1.1 Begriff und Zielsetzung des Requirements Engineering Requirements Engineering (RE) umfasst die systematische Erhebung, Analyse, Spezifikation, Validierung und Verwaltung von Anforderungen an ein System über dessen Lebenszyklus. In Standards und Lehrwerken wird RE als eigenständiger Prozess verstanden, der sowohl fachliche Ziele (z. B. unterstützte Geschäftsprozesse) als auch technische und organisatorische Randbedingungen (z. B. Sicherheitsvorgaben, Betriebsmodelle) in überprüfbare Aussagen überführt (ISO/IEC/IEEE 29148:2018; IEEE 830-1998). Im Kern adressiert RE zwei Spannungsfelder: * **Kommunikation zwischen Domäne und Technik:** Anforderungen müssen fachlich verständlich und gleichzeitig so präzise sein, dass sie implementiert, getestet und geändert werden können. * **Umgang mit Unsicherheit und Wandel:** Anforderungen sind zu Projektbeginn selten vollständig. RE ist daher nicht nur Dokumentation, sondern ein iterativer Klärungs- und Abstimmungsprozess. Ein etablierter Ansatz zur Strukturierung heterogener Sichtweisen ist das Viewpoint-Konzept, bei dem Anforderungen aus unterschiedlichen Perspektiven modelliert und anschließend konsolidiert werden (Kotonya und Sommerville 1996). Für die vorliegende Arbeit ist diese Perspektivenorientierung relevant, weil eine Codebasis typischerweise keine expliziten Stakeholder-Sichten enthält, diese aber für eine Migration wieder sichtbar gemacht werden müssen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben). ### 2.1.2 Arten von Requirements und Qualitätskriterien In der Literatur wird häufig zwischen funktionalen Anforderungen (Was soll das System tun?) und Qualitäts- bzw. nicht-funktionalen Anforderungen (Welche Eigenschaften und Randbedingungen gelten?) unterschieden. Die Praxis zeigt jedoch, dass diese Trennung nicht immer trennscharf ist: Eigenschaften können sowohl als Systemverhalten (z. B. „Audit-Log erzeugen“) als auch als Qualitätsziel (z. B. „Nachvollziehbarkeit“) formuliert werden (Glinz 2007). Für Reverse Requirements Engineering ist diese Unschärfe besonders relevant, weil Quellcode meist Verhalten konkretisiert, Qualitätsziele aber häufig implizit bleiben (z. B. Performance-Workarounds, Sicherheitsannahmen). Für die Qualität einzelner Requirements sind in Standards und RE-Forschung wiederkehrende Kriterien etabliert. ISO/IEC/IEEE 29148:2018 nennt unter anderem Eindeutigkeit, Konsistenz, Vollständigkeit, Verifizierbarkeit und Nachvollziehbarkeit als zentrale Eigenschaften. IEEE 830-1998 formuliert ähnliche Prinzipien für Software Requirements Specifications, mit stärkerem Fokus auf Dokumentstruktur und Lesbarkeit. Für die Bewertung von KI-extrahierten Requirements sind drei Kriterien unmittelbar handhabbar: * **Verifizierbarkeit:** Ein Requirement ist so formuliert, dass eine Testidee oder Prüfmethode ableitbar ist (z. B. Messkriterium, Akzeptanzbedingung). * **Eindeutigkeit:** Formulierungen vermeiden Mehrdeutigkeiten und definieren Begriffe, die in der Domäne unterschiedlich interpretiert werden können. * **Nachvollziehbarkeit (Traceability):** Es ist erkennbar, aus welchem Artefakt (Code, Konfiguration, Datenbank, Ticket, Interview) das Requirement abgeleitet wurde. Qualitätsanforderungen verdienen im Modernisierungskontext eine gesonderte Betrachtung, weil sie über die reine Funktionsgleichheit hinaus die Zielarchitektur motivieren. Glinz (2008) argumentiert, dass Qualitätsanforderungen risikobasiert und wertorientiert priorisiert werden sollten. Für Legacy-Migrationen ist dies plausibel: Ein „vollständiges“ Requirements-Set ist praktisch schwer erreichbar, gleichzeitig sind bestimmte Quality Requirements (z. B. Datenschutz, Verfügbarkeit, Rollout-Fähigkeit) hochkritisch, weil sie Architekturentscheidungen dominieren. Für die inhaltliche Strukturierung von Qualitätsanforderungen ist das Qualitätsmodell ISO/IEC 25010:2011 verbreitet, das Qualitätsmerkmale wie Performance-Effizienz, Zuverlässigkeit, Sicherheit oder Wartbarkeit systematisch ordnet. Für Reverse Requirements Engineering ist dies hilfreich, weil aus Code häufig nur Teilaspekte sichtbar werden (z. B. Caching-Mechanismen als Hinweis auf Performance-Annahmen), während andere Qualitätsziele (z. B. „Maintainability“) eher indirekt über Architekturentscheidungen und Entwicklungspraktiken wirksam werden. Die Relevanz sauberer Requirements-Qualität zeigt sich auch in der Risikoperspektive. Lawrence, Wiegers und Ebert (2001) beschreiben Requirements Engineering als primäre Risikozone, wenn Anforderungen unklar, instabil oder unvollständig sind. Für diese Arbeit folgt daraus, dass KI-gestützte Requirements-Extraktion nicht nur „mehr Text“ erzeugen darf, sondern gezielt die Risiken der Unklarheit und der Fehlinterpretation reduzieren muss. ### 2.1.3 Spezifikationsformen und Grad der Formalisierung Requirements werden in der Praxis in unterschiedlichen Repräsentationsformen dokumentiert. Standards wie IEEE 830-1998 und ISO/IEC/IEEE 29148:2018 fokussieren auf strukturierte Spezifikationen (z. B. SRS) und definieren typische Kapitel (Zweck, Systemkontext, funktionale Anforderungen, Schnittstellen, Qualitätsanforderungen, Annahmen). Daneben existieren weniger formale Formen wie User Stories, Use-Case-Beschreibungen oder Backlog-Einträge, die vor allem in agilen Settings verbreitet sind. Für Reverse Requirements Engineering sind zwei Punkte entscheidend: * **Form beeinflusst Interpretierbarkeit:** Eine knappe User Story („Als Nutzer möchte ich …“) ist leicht verständlich, transportiert aber selten Randbedingungen, Datenregeln oder Fehlerfälle. Eine SRS-Formulierung kann präziser sein, erfordert aber mehr Kontext und Definitionen. * **Grad der Formalisierung beeinflusst Prüfbarkeit:** Je stärker Requirements mit Akzeptanzkriterien, Beispielen oder Messgrößen verknüpft sind, desto einfacher sind Reviews und Tests. Pohl (2010) betont Anforderungen-Validierung als eigene Disziplin, die ohne prüfbare Formulierungen methodisch kaum belastbar ist. Im Kontext dieser Arbeit bietet sich daher ein hybrider Stil an: Requirements werden als kurze, klare Soll-Aussagen formuliert und jeweils um Kontext (Akteur/Prozess), Randbedingungen (Vorbedingungen, Datenobjekte) und mindestens eine Prüfidee ergänzt. LLMs können die sprachliche Konsistenz unterstützen, die notwendige Präzisierung muss jedoch durch Belege und Validierung abgesichert werden. ### 2.1.4 Traceability als Verbindung zwischen Code und Requirement Traceability bezeichnet die Möglichkeit, Beziehungen zwischen Requirements und anderen Artefakten herzustellen und über den Lebenszyklus zu pflegen. Gotel und Finkelstein (1994) analysieren Traceability als wiederkehrendes Problem, insbesondere dort, wo Artefakte heterogen sind und die Disziplin zur Pflege fehlt. Ramesh und Jarke (2001) schlagen Referenzmodelle vor, die Traceability-Typen und -Ziele strukturieren, etwa die Rückverfolgbarkeit zur Begründung (Rationale), zu Designentscheidungen oder zur Evolution eines Requirements. Für Reverse Requirements Engineering ist Traceability nicht nur ein „Nice-to-have“, sondern eine Sicherheitsmaßnahme: * **Plausibilisierung:** Ein Requirement lässt sich gegen konkrete Codeausschnitte oder Laufzeitbeobachtungen prüfen. * **Abgrenzung:** Es wird klar, ob eine Aussage wirklich aus der Codebasis folgt oder aus Interpretationen und Ergänzungen entsteht. * **Änderungsmanagement:** Bei Codeänderungen lässt sich ermitteln, welche Requirements betroffen sein könnten. In Legacy-Systemen ist Traceability typischerweise fragmentiert: Hinweise finden sich in Commit-Messages, Branch-Namen, Datenbankskripten, Konfigurationsdateien, UI-Texten oder in impliziten Konventionen. Der methodische Anspruch dieser Arbeit besteht daher nicht darin, „perfekte“ Traceability wiederherzustellen, sondern eine minimal belastbare, reproduzierbare Verknüpfung zwischen extrahierten Requirements und Belegen zu etablieren. ### 2.1.5 Reverse Engineering und Reverse Requirements Engineering Reverse Engineering wird klassisch als Analyseprozess verstanden, der aus einem bestehenden System Wissen über Struktur, Verhalten und Designentscheidungen rekonstruiert. Chikofsky und Cross (1990) prägen hierfür eine Taxonomie und grenzen Reverse Engineering von Reengineering sowie Design Recovery ab. Für Requirements-nahe Fragestellungen ist hier relevant, dass Reverse Engineering nicht automatisch „Anforderungen“ liefert, sondern zunächst technische Fakten (z. B. Abhängigkeiten, Datenflüsse, Zustandsautomaten). Reverse Requirements Engineering (RRE) fokussiert auf die rückwärtsgerichtete Gewinnung von Anforderungen aus bestehenden Artefakten. Dabei kann das Ziel unterschiedlich interpretiert werden: * **Rekonstruktion eines Soll-Zustands:** Welche fachlichen Anforderungen werden durch die aktuelle Implementierung implizit erfüllt? * **Rekonstruktion eines Ist-Zustands:** Welche Funktionen und Regeln sind tatsächlich implementiert, unabhängig davon, ob sie intendiert waren? Gerade im Migrationskontext ist diese Unterscheidung entscheidend. Die Codebasis enthält oft historisch entstandene Workarounds oder kundenspezifische Anpassungen. Diese können fachlich gewollt, technisch opportunistisch oder schlicht „mitgewachsen“ sein. Ohne zusätzliche Validierung besteht das Risiko, dass RRE den Ist-Zustand als Soll-Zustand fehlinterpretiert. Frühe Ansätze zur Brücke zwischen Reverse Engineering und Requirements liefern beispielsweise Yu et al. (2005) mit „RETR: Reverse Engineering to Requirements“. Der Beitrag betont, dass Requirements-Rückgewinnung eine methodische Kette aus Artefaktsichtung, Strukturierung und Validierung benötigt. In ähnlicher Richtung beschreibt ein requirementsgetriebenes Reengineering-Framework, wie Requirements als Leitplanken für Reengineering-Entscheidungen genutzt werden können (Tahvildari, Kontogiannis und Mylopoulos 2001). Methodisch lassen sich dabei grob zwei Analysestränge unterscheiden: * **Statische Analyse:** Ableitung von Struktur- und Datenflussinformationen aus Code und Artefakten ohne Ausführung (z. B. Abhängigkeiten, SQL-Statements, Aufrufketten). Statische Analyse ist skaliert gut, erkennt aber nicht zuverlässig Laufzeitbedingungen (z. B. Feature Flags, Konfigurationsvarianten). * **Dynamische Analyse:** Beobachtung von Laufzeitverhalten durch Logging, Tracing oder instrumentierte Tests (z. B. welche Regeln bei bestimmten Eingaben greifen). Dynamische Analyse ist näher am realen Verhalten, benötigt aber reproduzierbare Szenarien und Testdaten. Reverse Requirements Engineering in einem Migrationsprojekt profitiert typischerweise von einer Kombination beider Stränge. Ohne dynamische Belege steigt das Risiko, dass nicht offensichtliche Bedingungen (z. B. kundenspezifische Schalter) übersehen werden; ohne statische Analyse bleibt die Abdeckung häufig zu gering. ### 2.1.6 Typische Methodenkette für Requirements-Rückgewinnung aus Code Aus Sicht dieser Arbeit lässt sich Reverse Requirements Engineering in einer Legacy-Codebasis als wiederholbarer Ablauf strukturieren. Die konkrete Ausgestaltung hängt vom System und den verfügbaren Artefakten ab, die grundlegenden Schritte sind jedoch weitgehend stabil: 1. **Scope und Domänenabgrenzung:** Auswahl relevanter Module, Datenobjekte und Prozesse (z. B. Auftragsabwicklung, Fakturierung). 2. **Artefakterhebung:** Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen, Change-Historie. 3. **Technische Analyse:** Struktur- und Abhängigkeitsanalyse, Identifikation von Kernkomponenten, Regeln und Integrationspunkten. 4. **Semantische Interpretation:** Ableitung fachlicher Aussagen aus technischen Implementierungen (z. B. Statusübergänge, Berechtigungsprüfungen). 5. **Formalisierung als Requirements:** Überführung in klare, testbare Anforderungen mit Kontext (Akteur, Vorbedingung, Ergebnis). 6. **Traceability-Anreicherung:** Verknüpfung jedes Requirements mit Belegen (Datei, Klasse, Methode, SQL-Statement, UI-String). 7. **Validierung:** Review durch Fachexperten und Abgleich mit Laufzeitverhalten, Tickets oder Kundenwissen. In der Praxis unterscheiden sich Artefakte darin, wie direkt sie fachliche Aussagen stützen. Quellcode, der eine Regel hart erzwingt (z. B. „Update nur bei Status X“), ist als Beleg stärker als Kommentare oder UI-Texte, die lediglich Absichten ausdrücken. Für eine belastbare Requirementsbasis ist es daher sinnvoll, Belege zu klassifizieren und die Aussagekraft zu kennzeichnen, beispielsweise: * **Primärbelege:** Durchgesetzte Regeln im Code oder in Datenbankconstraints (z. B. Statusmaschinen, Validierungslogik, Berechtigungschecks). * **Sekundärbelege:** Indirekte Hinweise wie UI-Labels, Fehlermeldungen, Report-Layouts, Mappingtabellen oder Konfigurationsschalter. * **Kontextbelege:** Ticketbeschreibungen, Commit-Messages oder Interviewaussagen, die Motivation und Ausnahmen erklären, aber nicht zwingend im Code sichtbar sind. Diese Einteilung ist kein Selbstzweck. Sie hilft, Risiken sichtbar zu machen: Requirements, die überwiegend auf Sekundär- oder Kontextbelegen beruhen, sind anfälliger für Fehlinterpretation und sollten priorisiert validiert werden. Gerade in ERP-Systemen sind Datenbankschemata und SQL-Statements häufig besonders aussagekräftig, weil sie Domänenobjekte, Kardinalitäten und Geschäftsregeln (z. B. referentielle Integrität, historisierte Tabellen) sichtbar machen, die in UI- oder Servicecode nur indirekt erscheinen. Ein weiterer Hebel ist das Mining der Änderungshistorie. Commit-Messages, Diff-Hotspots oder Branch-Konventionen können Hinweise liefern, welche Bereiche besonders volatil sind, welche Kundenvarianten existieren und wo in der Vergangenheit Fehler oder Workarounds eingeführt wurden. Für Reverse Requirements Engineering folgt daraus, dass Requirements nicht nur „aus dem aktuellen Code“, sondern idealerweise auch aus der Evolution des Codes abgeleitet werden, um implizite Stabilitätsannahmen und technische Schulden zu erkennen. Der kritische Schritt ist die semantische Interpretation. Program Comprehension ist hierfür das methodische Fundament: Storey (2005) zeigt, dass Programmverständnis in der Praxis aus einer Kombination von statischer Analyse, Navigation, Visualisierung und Hypothesenbildung besteht. RRE übernimmt diesen kognitiven Prozess, erweitert ihn jedoch um das Ziel, Aussagen als Requirements zu formulieren, die unabhängig vom Code als Spezifikation nutzbar sind. ### 2.1.7 Zwischenfazit zu 2.1 Requirements Engineering liefert Kriterien und Artefaktformen, um Anforderungen präzise, prüfbar und nachvollziehbar zu beschreiben (ISO/IEC/IEEE 29148:2018; IEEE 830-1998). Reverse Requirements Engineering überträgt diese Zielsetzung in einen Kontext, in dem Requirements nicht vorliegen, sondern aus technischen Artefakten rekonstruiert werden. Für die vorliegende Arbeit folgt daraus, dass Automatisierung (z. B. durch KI) nur dann praktikabel ist, wenn Traceability und Validierung als feste Prozessbestandteile mitgeführt werden. ## 2.2 Large Language Models im Software Engineering ### 2.2.1 Künstliche Intelligenz, Machine Learning und Einordnung von LLMs Künstliche Intelligenz (KI) ist ein Oberbegriff für Verfahren, die Aufgaben bearbeiten, die in der Praxis typischerweise kognitive Fähigkeiten erfordern (z. B. Klassifikation, Planung, Sprachverarbeitung). Machine Learning (ML) ist dabei ein Teilgebiet, das Modelle aus Daten lernt, anstatt Regeln vollständig manuell zu spezifizieren. In der gängigen Einordnung wird zwischen überwachtem Lernen (mit Zielwerten), unüberwachtem Lernen (Struktur in Daten) und Reinforcement Learning (Lernen über Rückmeldesignale) unterschieden (Bishop 2006; Goodfellow, Bengio und Courville 2016). Deep Learning bezeichnet ML-Verfahren, die neuronale Netze mit vielen Parametern und mehreren Verarbeitungsebenen nutzen, um geeignete Repräsentationen aus Rohdaten zu lernen. Charakteristisch ist, dass Merkmalsextraktion und Modellanpassung gemeinsam über Optimierung (typischerweise Gradientenverfahren) erfolgen. LeCun, Bengio und Hinton (2015) beschreiben Deep Learning als zentrale Entwicklungslinie moderner KI, insbesondere für Wahrnehmungs- und Sprachaufgaben. Neuronale Netze lassen sich dabei vereinfacht als parametrisierte Funktionsketten aus Schichten beschreiben, die Eingaben in zunehmend abstrakte Repräsentationen überführen. Das Training erfolgt über eine Zielfunktion (Loss) und Gradientenberechnung, praktisch meist über Backpropagation und Varianten des Gradientenabstiegs (Goodfellow, Bengio und Courville 2016). ![Abbildung 2-1: Schematische Darstellung eines vollständig verbundenen Feedforward-Netzes.](Abbildungen/abb_2_1_feedforward_nn.png) Ein einzelnes Neuron lässt sich als affine Transformation mit nachgeschalteter Aktivierungsfunktion formulieren: $$ z = \sum_{i=1}^{d} w_i x_i + b,\quad a = \varphi(z) $$ Typische Aktivierungsfunktionen sind die Sigmoid-Funktion und ReLU (Goodfellow, Bengio und Courville 2016): $$ \sigma(z)=\frac{1}{1+e^{-z}},\quad \mathrm{ReLU}(z)=\max(0,z) $$ ![Abbildung 2-2: Beispielhafte Aktivierungsfunktionen (Sigmoid, tanh, ReLU).](Abbildungen/abb_2_2_aktivierungsfunktionen.png) Die Optimierung erfolgt üblicherweise iterativ. Für Gradientenabstieg gilt in kompakter Form: $$ \theta^{(t+1)}=\theta^{(t)}-\eta \nabla_\theta \mathcal{L}(\theta^{(t)}) $$ #### 2.2.1.1 Abgrenzung neuronaler Netze und LLMs zu anderen ML-Methoden Neuronale Netze sind ein Teilbereich von ML, sie ersetzen jedoch nicht automatisch klassische Verfahren. In der Praxis hängt die Methodenauswahl von Datenart, Datenmenge, Interpretierbarkeit und Betriebsvorgaben ab (Bishop 2006; Hastie, Tibshirani und Friedman 2009). Tabelle 2-1 fasst die Abgrenzung zu häufigen ML-Familien zusammen: | Methodik | Typischer Einsatz | Stärken | Grenzen | |---|---|---|---| | Lineare/GLM-Modelle | Strukturierte Daten, Baselines | schnell, gut interpretierbar | begrenzte Nichtlinearität (ohne Feature Engineering) | | Support Vector Machines (SVM) | Klassifikation/Regression, mittlere Datenmengen | starke Theorie, robuste Margin-Idee | Skalierung/Kernelwahl, eingeschränkte Erklärbarkeit (Cortes und Vapnik 1995) | | Entscheidungsbäume/Ensembles | Tabellarische Daten | nichtlinear, oft gute Performance | Overfitting ohne Regularisierung; Ensembles weniger interpretierbar | | Random Forests | Tabellarische Daten, robuste Defaults | stabil, gute Generalisierung | begrenzte Extrapolation, Erklärbarkeit indirekt (Breiman 2001) | | Gradient Boosting | Tabellarische Daten, hohe Genauigkeit | sehr starke Praxisleistung | Hyperparameter-sensitiv, Trainingskosten (Friedman 2001) | | Neuronale Netze (Deep Learning) | Unstrukturierte Daten (Text, Bild), große Datenmengen | Representation Learning, End-to-End | hoher Daten-/Rechenbedarf, schwerer zu erklären (LeCun, Bengio und Hinton 2015) | | LLMs (Transformers) | Text- und Codeaufgaben, generative Assistenz | Vortraining nutzt große Korpora; flexible Transferleistung | Halluzinationen, Kontextlimit, Governance-Aufwand (Vaswani et al. 2017; Ji et al. 2023) | LLMs unterscheiden sich dabei von vielen klassischen Verfahren nicht nur durch Modellgröße, sondern auch durch Zielsetzung: Häufig wird ein generatives, autoregressives Sprachmodell trainiert, das die nächste Tokenwahrscheinlichkeit modelliert: $$ \max_\theta \sum_{t=1}^{T} \log p_\theta(x_t \mid x_{