02_03 z42

2026-05-04 19:24:14 +02:00
parent 2ccc4245d3
commit 26aaeec7dc
8 changed files with 18073 additions and 19186 deletions
--- a/Kapitel/02_theoretischer_hintergrund/02_03_legacy_modernisierung.typ
+++ b/Kapitel/02_theoretischer_hintergrund/02_03_legacy_modernisierung.typ
@@ -2,57 +2,48 @@
 #heading(level: 3)[Charakteristika von Legacy-Systemen]
-Legacy-Systeme sind nicht allein durch ihr Alter definiert, sondern durch ihren Kontext: Sie tragen geschäftskritische Funktionen, sind über lange Zeit erweitert worden und weisen oft starke technische und organisatorische Abhängigkeiten auf. #cite(<bisbal1999legacy>, form: "prose") beschreiben typische Merkmale wie enge Kopplung, heterogene Technologien, schwer austauschbare Komponenten und unzureichende Dokumentation. Gerade letzteres ist für Modernisierungsvorhaben problematisch, weil Entscheidungen ohne belastbare Anforderungsbasis zu Funktionsverlusten und Akzeptanzproblemen führen können.
+Legacy-Systeme sind nicht allein durch ihr Alter, sondern durch ihren Kontext definiert. Sie tragen geschäftskritische Funktionen, sind über lange Zeit erweitert worden und weisen oft starke technische und organisatorische Abhängigkeiten auf. Typische Merkmale sind enge Kopplung, heterogene und zersplitterte Technologien, schwer austauschbare oder sogar schon abgekündigte Komponenten und unzureichende Dokumentation @bisbal1999legacy. Gerade die fehlende Dokumentation ist für Modernisierungsvorhaben problematisch, weil Entscheidungen ohne belastbare Anforderungsbasis zu Funktionsverlusten und Fehlentscheidungen führen können.
-Im ERP-Kontext verschärfen sich diese Merkmale häufig durch:
+Im ERP-Kontext verschärfen sich diese Merkmale häufig durch eine ausgeprägte Domänenkomplexität, da Geschäftsregeln variantenreich und teilweise kundenspezifisch sind. Hinzu kommt eine starke Datenzentrierung. Prozesse hängen stark von Datenmodellen, Stammdatenqualität und historisch gewachsenen Datenkonventionen ab. Verstärkt wird dies durch eine hohe Integrationsvielfalt, da Schnittstellen zu Drittsystemen (z. B. Buchhaltung, Shop, Dokumentenmanagement) über Jahre organisch entstanden sind.
- **Domänenkomplexität:** Geschäftsregeln sind zahlreich, variantenreich und teilweise kundenspezifisch.
+Damit wird nachvollziehbar, warum Requirements-Extraktion aus der Codebasis nicht nur ein Dokumentationsprojekt ist. Es dient zeitglich auch zur Risikoreduktion.
 - **Datenzentrierung:** Prozesse hängen stark von Datenmodellen, Stammdatenqualität und historisch gewachsenen Datenkonventionen ab.
 - **Integrationslast:** Schnittstellen zu Drittsystemen (z. B. Buchhaltung, Shop, Dokumentenmanagement) sind über Jahre organisch entstanden.
-Damit wird nachvollziehbar, warum Requirements-Extraktion aus der Codebasis nicht nur ein Dokumentationsprojekt, sondern ein Risikoreduktionsinstrument für Migrationen ist.
+#heading(level: 3)[Modernisierungsstrategien]
-#heading(level: 3)[Modernisierungsstrategien und Reengineering als Prozess]
+Eine Modernisierung kann durch unterschiedliche Methoden umgesetz werden, von "Lift-and-Shift" bis zur vollständigen Neuimplementierung "auf der grünen Wiese". Die Literatur betont wiederholt, dass die Wahl einer Strategie von Risiko, Zielarchitektur und verfügbaren Ressourcen abhängt und daher explizit geplant werden sollte @sneed1995planning. Eine zentrale Aussage ist dabei, dass Reengineering nicht als rein technischer Umbau verstanden werden darf. Ohne fachliche Leitplanken entstehen technische Verbesserungen, die am Bedarf vorbeilaufen oder bestehende Fachlogik unabsichtlich verändern. Zudem können gewonnene fachliche Erkenntnisse ohne klare Dokumentation und Nachvollziehbarkeit nicht in die Zielarchitektur überführt werden, was zu einem erneuten Anforderungsdefizit führt.
-Modernisierung kann unterschiedliche Strategien annehmen, von "Lift-and-Shift" bis zur vollständigen Neuimplementierung. Die Literatur betont wiederholt, dass die Wahl einer Strategie von Risiko, Zielarchitektur und verfügbaren Ressourcen abhängt und daher explizit geplant werden sollte @sneed1995planning. Eine zentrale Aussage ist dabei, dass Reengineering nicht als rein technischer Umbau verstanden werden kann: Ohne fachliche Leitplanken entstehen technische Verbesserungen, die am Bedarf vorbeilaufen oder bestehende Fachlogik unabsichtlich verändern.
+_Aus Sicht dieser Arbeit lassen sich Modernisierungsmethodiken pragmatisch entlang zweier Dimensionen einordnen: (1) Wie stark wird die bestehende Implementierung weitergenutzt? (2) Wie stark wird die Zielarchitektur verändert? Daraus ergeben sich typische Strategietypen, die in der Praxis auch kombiniert auftreten:_
-Aus Sicht dieser Arbeit lassen sich Modernisierungsstrategien pragmatisch entlang zweier Achsen einordnen: (1) Wie stark wird die bestehende Implementierung weitergenutzt? (2) Wie stark wird die Zielarchitektur verändert? Daraus ergeben sich typische Strategietypen, die in der Praxis auch kombiniert auftreten:
+ *Weiterbetrieb mit Hülle (Wrapping):* Die Legacy-Logik bleibt bestehen, wird aber über neue Schnittstellen oder eine neue GUI zugänglich gemacht. Vorteil ist geringe Eingriffstiefe; Nachteil ist, dass technische Schulden und Engpässe erhalten bleiben.
 + *Schrittweise Modularisierung:* Teile der Legacy-Anwendung werden sukzessive in neue Komponenten überführt, während andere Teile weiterlaufen. Vorteil ist Risikostreuung und frühe Nutzenrealisierung; Nachteil ist erhöhte Integrationskomplexität während der Übergangsphase.
 + *Reengineering/Refactoring:* Die bestehende Logik wird strukturell überarbeitet (z. B. Entkopplung, Schichten, bessere Testbarkeit), ohne den Funktionsumfang grundsätzlich zu verändern. Vorteil ist bessere Wartbarkeit; Nachteil ist hoher Analyseaufwand, gerade ohne Requirementsbasis.
 + *Neuimplementierung mit Funktionsparität:* Die Legacy-Logik wird auf neuer Technologie nachgebaut, häufig mit dem Anspruch, zunächst funktional äquivalent zu sein. Vorteil ist saubere Zielarchitektur; Nachteil ist die hohe Abhängigkeit von vollständigen, korrekten Requirements.
- **Weiterbetrieb mit Hülle (Wrapping):** Die Legacy-Logik bleibt bestehen, wird aber über neue Schnittstellen oder UI-Schichten zugänglich gemacht. Vorteil ist geringe Eingriffstiefe; Nachteil ist, dass technische Schulden und Engpässe erhalten bleiben.
+Für ein ERP-System ist die Wahl einer Strategie stark datengetrieben. Datenmodelle und Businesslogik definieren die Leitplanken einer Migration. Damit steigt die Wichtigkeit von Requirements, die Datenobjekte, Zustandsmodelle und Integrationspunkte ausdrücken. Besonders kritisch sind dabei Anforderungen, die in der Legacy-Implementierung als implizite Konvention existieren (z. B. Statuscodes, historische Sonderfälle, kundenspezifische Maskenlogik), weil sie ohne gezielte Extraktion und Validierung leicht verloren gehen.
 - **Schrittweise Modularisierung:** Teile der Legacy-Anwendung werden sukzessive in neue Komponenten überführt, während andere Teile weiterlaufen. Vorteil ist Risikostreuung und frühe Nutzenrealisierung; Nachteil ist erhöhte Integrationskomplexität während der Übergangsphase.
 - **Reengineering/Refactoring:** Die bestehende Logik wird strukturell überarbeitet (z. B. Entkopplung, Schichten, bessere Testbarkeit), ohne den Funktionsumfang grundsätzlich zu verändern. Vorteil ist bessere Wartbarkeit; Nachteil ist hoher Analyseaufwand, gerade ohne Requirementsbasis.
 - **Neuimplementierung mit Funktionsparität:** Die Legacy-Logik wird auf neuer Technologie nachgebaut, häufig mit dem Anspruch, zunächst funktional äquivalent zu sein. Vorteil ist saubere Zielarchitektur; Nachteil ist die hohe Abhängigkeit von vollständigen, korrekten Requirements.
 Für ERP-Systeme ist die Wahl einer Strategie stark datengetrieben. Datenmodelle, Schnittstellenverträge und Buchungslogik definieren die „harten Kanten" einer Migration. Damit steigt der Stellenwert von Requirements, die Datenobjekte, Zustandsmodelle und Integrationspunkte explizit machen. Besonders migrationskritisch sind dabei Anforderungen, die in der Legacy-Implementierung als implizite Konvention existieren (z. B. Statuscodes, historische Sonderfälle, kundenspezifische Maskenlogik), weil sie ohne gezielte Extraktion und Validierung leicht verloren gehen.
 #cite(<bisbal1997overview>, form: "prose") geben einen Überblick über Migrationsansätze und ordnen typische Risikofelder ein, darunter Datenmigration, Funktionsäquivalenz und organisatorische Abhängigkeiten. #cite(<wu1997toolkit>, form: "prose") argumentieren ergänzend, dass Werkzeugunterstützung nur dann wirksam ist, wenn sie in eine methodische Kette eingebettet ist. Diese Argumentation ist direkt anschlussfähig an KI-gestützte Verfahren: Auch LLM-basierte Automatisierung entfaltet Nutzen nur innerhalb eines reproduzierbaren Prozesses mit klaren Kontrollpunkten.
 #heading(level: 3)[Zielarchitekturen: Web, Cloud und „Cloud-native"]
-Die Modernisierung vieler Legacy-Anwendungen zielt auf webbasierte, plattformunabhängige Oberflächen und auf Betriebsmodelle, die Skalierung, automatisiertes Deployment und schnelle Iteration unterstützen. #cite(<kratzke2017cloudnative>, form: "prose") fassen in einer systematischen Mapping Study zusammen, welche Merkmale cloud-nativer Anwendungen in der Forschung und Praxis wiederkehren. Dazu zählen typischerweise automatisierte Bereitstellung, resiliente Komponenten, horizontale Skalierung und eine stärkere Trennung von Build- und Run-Umgebungen.
+Die Modernisierung vieler Legacy-Anwendungen zielt auf webbasierte, plattformunabhängige Oberflächen und auf Betriebsmodelle, die Skalierung, automatisiertes Deployment und schnelle Iteration unterstützen. Eine systematische Mapping Study fasst zusammen, welche Merkmale cloud-nativer Anwendungen in Forschung und Praxis wiederkehren @kratzke2017cloudnative. Dazu zählen typischerweise automatisierte Bereitstellung, resiliente Komponenten, horizontale Skalierung und eine stärkere Trennung von Build- und Run-Umgebungen.
-Im selben Zielraum werden Microservices häufig als Architekturstil diskutiert. #cite(<pahl2016microservices>, form: "prose") kartieren Forschung zu Microservices und zeigen wiederkehrende Problemfelder, unter anderem die Wahl der richtigen Servicegranularität, die erhöhte Komplexität im Betrieb und Anforderungen an Observability. Für Migrationsprojekte ist daraus eine pragmatische Schlussfolgerung ableitbar: Modularisierung ist ein Ziel, erzeugt aber zugleich neue Anforderungen (z. B. Deployment-Pipelines, Monitoring, Sicherheitskonzepte), die im Requirements-Set sichtbar sein müssen.
+Im selben Zusammenhang werden Microservices häufig als Architekturstil diskutiert. Eine Analyse der Forschung zu Microservices zeigt wiederkehrende Problemfelder, unter anderem die Wahl der richtigen Servicegranularität, die erhöhte Komplexität im Betrieb und Anforderungen an Observability @pahl2016microservices. Für Migrationsprojekte ist daraus eine pragmatische Schlussfolgerung ableitbar: Modularisierung ist ein Ziel, erzeugt aber zugleich neue Anforderungen (z. B. Deployment-Pipelines, Monitoring, Sicherheitskonzepte), die im Requirements-Set sichtbar sein müssen.
-Für die Requirementsarbeit bedeutet die Zielarchitekturverschiebung eine Verschiebung des Schwerpunktes: Während in klassischen Client/Server-Architekturen die fachliche Funktionslogik oft dominiert, rücken in Web- und Cloud-Kontexten betriebliche und sicherheitsbezogene Qualitätsmerkmale stärker in den Vordergrund. ISO/IEC 25010:2011 bietet hierfür eine hilfreiche Taxonomie @iso25010_2011. Für Modernisierungsvorhaben lassen sich vor allem folgende Qualitätsmerkmale als wiederkehrend beobachten:
+Für die Requirementsentwicklung bedeutet diese neue Zielarchitektur eine Verschiebung des Schwerpunktes. Während in klassischen Server/Client-Architekturen die fachliche Funktionslogik oft dominiert, rücken in Web- und Cloud-Kontexten auf den Betrieb bezogene (Deployment, Monitoring, Skalierung) und sicherheitsrelevante Qualitätsmerkmale (SaaS, Multi-Tennanting) stärker in den Vordergrund. ISO/IEC 25010:2011 bietet hierfür eine hilfreiche Taxonomie @iso25010_2011. Für Modernisierungsvorhaben lassen sich vor allem folgende Qualitätsmerkmale als wiederkehrend beobachten:
- **Sicherheit:** Identitäten, Rollenmodelle, Mandantenfähigkeit, Auditierbarkeit.
+- *Sicherheit:* Identitäten, Rollenmodelle, Mandantenfähigkeit, Auditierbarkeit.
- **Zuverlässigkeit:** Fehlerresistenz, Wiederanlauf, Degradationsverhalten.
+- *Zuverlässigkeit:* Fehlerresistenz, Wiederanlauf, Degradationsverhalten.
- **Performance-Effizienz:** Antwortzeiten, Lastverhalten, Skalierungsgrenzen.
+- *Performance-Effizienz:* Antwortzeiten, Lastverhalten, Skalierungsgrenzen.
- **Wartbarkeit:** Änderbarkeit, Testbarkeit, Modularität und technische Schuld.
+- *Wartbarkeit:* Änderbarkeit, Testbarkeit, Modularität und technische Schuld.
- **Kompatibilität und Interoperabilität:** Schnittstellenstabilität, Integrationsfähigkeit mit Drittsystemen.
+- *Kompatibilität und Interoperabilität:* Schnittstellenstabilität, Integrationsfähigkeit mit Drittsystemen.
-Diese Merkmale sind nicht neu, ihre Sichtbarkeit im Projekt nimmt jedoch zu, weil Cloud- und Webbetrieb ein engeres Zusammenspiel von Entwicklung und Betrieb erzwingt. Für Reverse Requirements Engineering folgt daraus, dass der Blick auf die Legacy-Codebasis systematisch um Betriebs- und Sicherheitsanforderungen ergänzt werden muss, auch wenn diese im Code nur indirekt sichtbar sind (z. B. über Deployment-Skripte, Konfigurationen, Logging-Policies oder Rechteprüfungen).
+Diese Merkmale sind nicht neu, ihre Sichtbarkeit im Projekt nimmt jedoch zu, weil Cloud- und Webbetrieb ein engeres Zusammenspiel von Entwicklung und Betrieb erzwingt. 
-Sicherheitsanforderungen werden in Cloud-Migrationskontexten häufig unterschätzt. Eine systematische Mapping Study zu Security-Aspekten bei Legacy-to-Cloud-Migrationen @security2014legacycloud zeigt, dass Identitätsmanagement, Datenflusskontrolle und Compliance wiederkehrende Kernprobleme sind. Für diese Arbeit bedeutet dies, dass Requirements-Extraktion aus Code um Sicherheits- und Datenschutzanforderungen ergänzt werden muss, da sie nicht in jedem Quellcodefragment explizit sichtbar sind.
+_Für das Reverse Requirements Engineering im Rahmen dieser Arbeit folgt daraus, dass der Blick auf die Legacy-Codebasis systematisch um Betriebs- und Sicherheitsanforderungen ergänzt werden muss, auch wenn diese im Code nur indirekt sichtbar sind (z. B. über Deployment-Skripte, Konfigurationen, Logging-Policies oder Rechteprüfungen)._
 #heading(level: 3)[Stand der Forschung: KI-Unterstützung in Modernisierungsvorhaben]
 Die Forschung zu KI- bzw. LLM-Unterstützung im Modernisierungskontext ist im Vergleich zu klassischen Reengineering-Ansätzen jünger. Die Übersichten zu LLM4SE @fan2023llmse @llm4se2024slr zeigen, dass ein Teil der Arbeiten auf Codeverständnis, Dokumentation und Artefakttransformation zielt. Spezifisch für Requirements Engineering bündeln Reviews und SLRs erste Evidenz und Forschungsrichtungen @marques2024chatgptre @hemmat2025directions.
-Aus dieser Literatur lassen sich zwei robuste Aussagen ableiten:
+Aus dieser Literatur lassen sich zwei robuste Aussagen ableiten. Zum einen sind LLMs besonders stark in der Strukturierung und sprachlichen Formulierung, also dort, wo aus fragmentierten Hinweisen ein konsistenter Text entstehen muss. Zum anderen benötigen LLMs technische und organisatorische Sicherungen, wenn Ergebnisse als Entscheidungsgrundlage in Migrationen dienen sollen (z. B. Belege, Review, reproduzierbarer Prozess).
 - **LLMs sind besonders stark in der Strukturierung und sprachlichen Formulierung**, also dort, wo aus fragmentierten Hinweisen ein konsistenter Text entstehen muss.
 - **LLMs benötigen technische und organisatorische Sicherungen**, wenn Ergebnisse als Entscheidungsgrundlage in Migrationen dienen sollen (z. B. Belege, Review, reproduzierbarer Prozess).
 Damit ist eine zentrale Motivation dieser Arbeit begründet: Eine Legacy-Modernisierung benötigt belastbare Requirements, die im Legacy-Kontext oft fehlen. LLMs sind als Assistenz zur Rekonstruktion naheliegend, müssen jedoch methodisch so eingesetzt werden, dass Verlässlichkeit und Nachvollziehbarkeit systematisch erhöht werden.
--- a/Masterarbeit_draft.pdf
+++ b/Masterarbeit_draft.pdf
--- a/kapitel_1_einleitung.md
+++ b/kapitel_1_einleitung.md
@@ -1,101 +0,0 @@
 # 1. Einleitung
 ## 1.1 Ausgangssituation und Motivation
 Die digitale Transformation stellt mittelständische Softwareunternehmen vor vielfältige Herausforderungen. Insbesondere gewachsene Legacy-Systeme, die über Jahre hinweg kontinuierlich erweitert wurden, erfordern zunehmend eine strategische Neuausrichtung. Diese Systeme bilden häufig das Rückgrat geschäftskritischer Prozesse, ihre technologische Basis entspricht jedoch nicht mehr den Anforderungen moderner Cloud- und Web-Architekturen. Die Migration solcher Systeme gestaltet sich komplex, da historisch gewachsene Funktionalitäten oft nicht vollständig dokumentiert sind und implizites Wissen bei einzelnen Entwickler:innen oder langjährigen Mitarbeiter:innen verankert ist.
 Die c-entron GmbH steht exemplarisch für diese Herausforderung. Das mittelständische Softwareunternehmen mit Sitz in Ulm entwickelt und vertreibt seit über zwei Jahrzehnten eine Windows-basierte ERP-Software, die speziell für IT-Systemhäuser konzipiert wurde. Die Software deckt ein breites Funktionsspektrum ab – von der Auftragsverwaltung über Lagerhaltung bis hin zur Fakturierung und Projektabrechnung. Über die Jahre ist eine umfangreiche, funktionsreiche Lösung entstanden, die bei der Zielgruppe etabliert ist und einen hohen Reifegrad aufweist.
 Mit einer expansiven Vertriebsstrategie und dem Ziel, neue Marktsegmente zu erschließen, steht die c-entron GmbH jedoch vor der Notwendigkeit, ihre Software-Architektur grundlegend zu modernisieren. Die native Windows-Anwendung stößt an Grenzen der Skalierbarkeit – sowohl in der Entwicklung als auch im Betrieb und Roll-out. Kunden erwarten zunehmend webbasierte, plattformunabhängige Lösungen mit modernen Benutzeroberflächen und flexiblen Deployment-Optionen. Eine Migration zu einer modernen, webbasierten Plattform ist daher unumgänglich geworden.
 Diese Modernisierung erfordert jedoch nicht lediglich eine technologische Neuentwicklung, sondern setzt eine umfassende Analyse der bestehenden Funktionalität voraus. Genau hier zeigt sich eine zentrale Herausforderung vieler Legacy-Systeme: Die funktionalen und nicht-funktionalen Anforderungen wurden über die Jahre nie systematisch dokumentiert. Was im Code implementiert ist, existiert oft nicht in strukturierter Form als Anforderungsspezifikation. Dies erschwert eine gezielte und vollständige Migration erheblich.
 Parallel zu dieser praktischen Herausforderung hat sich in den letzten Jahren ein neues technologisches Paradigma etabliert: Large Language Models (LLMs) wie GPT-4, Claude oder Code-Llama haben gezeigt, dass sie in der Lage sind, Code zu verstehen, zu analysieren und zu dokumentieren. Diese Modelle bieten potenziell neue Möglichkeiten, die Lücke zwischen implizitem Wissen in Codebasen und expliziter Anforderungsdokumentation zu schließen. Der Einsatz von LLMs für Reverse Requirements Engineering – also die nachträgliche Extraktion von Anforderungen aus bestehendem Code – ist jedoch noch wenig erforscht und in der Praxis kaum systematisch erprobt.
 Genau an dieser Schnittstelle zwischen praktischem Bedarf und technologischer Innovation setzt die vorliegende Arbeit an. Sie untersucht, wie KI-gestützte Verfahren eingesetzt werden können, um aus Legacy-Software strukturierte Requirements zu extrahieren und damit eine fundierte Basis für Migrationsprojekte zu schaffen. Die Arbeit adressiert damit sowohl eine wissenschaftliche Forschungslücke als auch einen konkreten Anwendungsfall mit hoher praktischer Relevanz für mittelständische Softwareunternehmen.
 ## 1.2 Problemstellung
 Die zentrale Problemstellung dieser Arbeit ergibt sich aus der fehlenden Anforderungsdokumentation der bestehenden ERP-Software der c-entron GmbH. Diese Situation ist symptomatisch für viele über Jahre gewachsene Softwaresysteme: Während der kontinuierlichen Weiterentwicklung lag der Fokus auf der Implementierung neuer Features und der Behebung von Fehlern. Anforderungen wurden primär implizit durch Code-Commits, Ticket-Systeme und direktes Kundenfeedback kommuniziert, jedoch nicht systematisch in Form strukturierter Requirements erfasst.
 Die fehlende Dokumentation erschwert die gezielte Migration erheblich, da sowohl funktionale Redundanzen als auch implizit verankerte Prozesse nur durch aufwendige manuelle Analysen identifiziert werden können. Konkret führt dies zu folgenden Problemen:
 **Re-Implementationsfehler und unvollständige Migration:** Ohne vollständige Kenntnis aller implementierten Funktionen besteht das Risiko, dass bei der Neuentwicklung Features übersehen oder falsch interpretiert werden. Insbesondere Edge Cases, Sonderfälle und historisch gewachsene Workarounds sind häufig nur im Code ersichtlich und werden in manuellen Reviews leicht übersehen. Dies kann dazu führen, dass geschäftskritische Prozesse bei Kunden nach der Migration nicht mehr korrekt funktionieren.
 **Hohe technische Schuld und Ineffizienzen:** Die Analyse und das Verständnis der Legacy-Codebasis binden erhebliche Entwicklungsressourcen. Entwickler:innen müssen Code lesen, verstehen und dokumentieren – ein zeitintensiver Prozess, der vom eigentlichen Entwickeln der neuen Lösung ablenkt. Zudem besteht die Gefahr, dass veraltete oder redundante Funktionalitäten unreflektiert in die neue Architektur übernommen werden, anstatt sie kritisch zu hinterfragen und zu modernisieren.
 **Implizites Wissen und Wissenstransfer:** Ein erheblicher Teil des Domänenwissens ist bei einzelnen langjährigen Mitarbeiter:innen verankert, die die Entstehungsgeschichte bestimmter Features kennen. Dieses implizite Wissen ist schwer zu erfassen und zu formalisieren. Bei Personalwechseln oder in größeren Teams führt dies zu Wissenslücken und Abhängigkeiten von Einzelpersonen.
 **Komplexität gewachsener Codebasen:** Die über Jahre gewachsene Codebasis der c-entron GmbH weist typische Charakteristika von Legacy-Systemen auf: verschachtelte Abhängigkeiten, historisch bedingte Architekturentscheidungen, unterschiedliche Code-Stile verschiedener Entwicklungsphasen und eine enge Kopplung an spezifische Technologien. Diese Komplexität erschwert nicht nur das Verständnis, sondern auch die Extraktion klarer, modularer Anforderungen für die Neuimplementierung.
 **Fehlende Traceability:** Ohne strukturierte Requirements fehlt die Nachvollziehbarkeit, warum bestimmte Funktionen existieren, welche Geschäftsprozesse sie unterstützen und welche Stakeholder-Anforderungen sie erfüllen. Dies erschwert sowohl die Priorisierung im Migrationsprojekt als auch die spätere Wartung und Weiterentwicklung der neuen Software.
 Die manuelle Erhebung und Dokumentation aller Anforderungen wäre mit einem prohibitiv hohen Aufwand verbunden. Hier könnten KI-gestützte Verfahren, insbesondere Large Language Models mit ihren Code-Verständnis-Fähigkeiten, einen wesentlichen Beitrag leisten. Die zentrale Fragestellung ist daher, inwieweit LLMs in der Lage sind, aus bestehendem Quellcode systematisch und strukturiert Requirements zu extrahieren, die als Grundlage für eine Neuentwicklung dienen können.
 Diese Problemstellung ist nicht nur für die c-entron GmbH relevant, sondern betrifft eine Vielzahl mittelständischer Softwareunternehmen, die vor ähnlichen Modernisierungsherausforderungen stehen. Die Entwicklung eines systematischen, KI-gestützten Ansatzes für Reverse Requirements Engineering könnte daher einen signifikanten Beitrag zur Bewältigung dieser weit verbreiteten Herausforderung leisten.
 ## 1.3 Zielsetzung
 Das übergeordnete Ziel dieser Masterarbeit ist die Entwicklung, Implementierung und Evaluation eines KI-gestützten Verfahrens für Reverse Requirements Engineering bei Legacy-Software. Konkret soll ein LLM-basierter Agent konzipiert und prototypisch umgesetzt werden, der in der Lage ist, aus der bestehenden Codebasis der c-entron GmbH strukturierte, vollständige und nachvollziehbare Requirements zu extrahieren.
 Die Arbeit verfolgt dabei mehrere spezifische Teilziele:
 **Konzeptionelle Entwicklung eines Prozessmodells:** Es soll ein theoretisch fundiertes und praktisch anwendbares Prozessmodell entwickelt werden, das beschreibt, wie Unternehmen systematisch den Übergang von Legacy-Software zu modernen Architekturen mithilfe von KI-gestützter Anforderungserhebung gestalten können. Dieses Prozessmodell soll die verschiedenen Phasen – von der Vorbereitung über die Analyse bis zur Validierung – strukturieren und Best Practices sowie kritische Erfolgsfaktoren identifizieren.
 **Technologische Evaluation und Auswahl:** Im Rahmen der Arbeit sollen aktuelle Large Language Models hinsichtlich ihrer Eignung für das Reverse Requirements Engineering evaluiert werden. Dabei sind Kriterien wie Code-Verständnis, Kontextfenster-Größe, Kontrollierbarkeit, Datenschutz-Compliance und Kosten zu berücksichtigen. Die Evaluation soll zu einer begründeten Auswahl eines Hauptmodells sowie gegebenenfalls ergänzender Modelle für spezifische Teilaufgaben führen.
 **Prototypische Implementierung eines LLM-Agenten:** Basierend auf der Konzeption soll ein funktionsfähiger Prototyp entwickelt werden, der die Codebasis der c-entron GmbH analysieren und daraus Requirements extrahieren kann. Der Agent soll dabei sowohl funktionale als auch nicht-funktionale Anforderungen identifizieren, diese strukturiert beschreiben und mit Traceability-Metadaten anreichern, die eine Nachvollziehbarkeit zur Codebasis ermöglichen.
 **Integration von Stakeholder-Wissen:** Da nicht alle Anforderungen – insbesondere nicht-funktionale Aspekte wie Performance-Erwartungen, Sicherheitsanforderungen oder Usability-Präferenzen – vollständig aus dem Code ableitbar sind, soll ein hybrider Ansatz verfolgt werden. Durch strukturierte Interviews mit relevanten Stakeholdern (Entwickler:innen, Product Owner, Kunden) sollen diese Aspekte erhoben und mit den KI-generierten Requirements abgeglichen und angereichert werden.
 **Systematische Evaluation:** Die Qualität der extrahierten Requirements soll anhand definierter Kriterien systematisch evaluiert werden. Dabei sollen sowohl quantitative Metriken (z.B. Vollständigkeit im Vergleich zu einem Referenzset, Anzahl identifizierter Requirements) als auch qualitative Bewertungen durch Expert:innen der c-entron GmbH einfließen. Zentrale Evaluationskriterien sind Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Stakeholder-Alignment und Aufwandsreduktion im Vergleich zu rein manuellen Verfahren.
 **Governance und Compliance:** Da der Einsatz externer KI-Dienste mit sensiblen Codedaten verbunden ist, sollen auch Aspekte des Datenschutzes, des IP-Schutzes und der IT-Sicherheit adressiert werden. Die Arbeit soll Handlungsempfehlungen ableiten, wie Unternehmen KI-gestützte Analysen unter Einhaltung regulatorischer Anforderungen und Sicherheitsrichtlinien durchführen können.
 **Praxistransfer und Handlungsempfehlungen:** Die Erkenntnisse aus der prototypischen Umsetzung und Evaluation sollen in konkrete Handlungsempfehlungen für die c-entron GmbH überführt werden. Dabei geht es sowohl um die operative Nutzung des entwickelten Ansatzes im Migrationsprojekt als auch um die potenzielle Integration in bestehende Toolchains (z.B. Jira, Confluence). Zudem soll die Übertragbarkeit auf andere Kontexte und Unternehmensgrößen diskutiert werden.
 Zusammenfassend verfolgt die Arbeit das Ziel, einen wissenschaftlich fundierten und praktisch erprobten Beitrag zur Bewältigung einer zentralen Herausforderung bei der Modernisierung von Legacy-Software zu leisten: die systematische und effiziente Rekonstruktion von Anforderungen durch den Einsatz moderner KI-Technologien.
 ## 1.4 Forschungsleitfragen
 Zur strukturierten Bearbeitung der Zielsetzung werden folgende Forschungsleitfragen formuliert, die sich an den zentralen Aspekten der Arbeit orientieren:
 **F1: Wie können Large Language Models systematisch für Reverse Requirements Engineering in Legacy-Software eingesetzt werden?**
 Diese Frage adressiert die grundlegende Konzeption des Ansatzes. Sie umfasst sowohl die technische Ebene (Wie müssen LLMs konfiguriert und gesteuert werden? Welche Prompt-Engineering-Strategien sind erfolgreich?) als auch die methodische Ebene (Welche Schritte sind notwendig? Wie wird der Prozess strukturiert? Welche Rolle spielen menschliche Expert:innen?). Die Beantwortung dieser Frage erfordert die Entwicklung eines Prozessmodells, das beschreibt, wie der KI-Einsatz in den Gesamtkontext der Anforderungserhebung eingebettet wird.
 **F2: Welche funktionalen und nicht-funktionalen Anforderungen lassen sich durch eine Kombination aus KI-gestützter Codeanalyse und Stakeholder-Interviews extrahieren?**
 Diese Frage fokussiert auf die inhaltliche Dimension der extrahierten Requirements. Sie untersucht, welche Arten von Anforderungen durch LLMs aus Code identifizierbar sind und wo die Grenzen der automatisierten Extraktion liegen. Insbesondere soll analysiert werden, wie funktionale Requirements (Was soll das System tun?) und nicht-funktionale Requirements (Wie soll das System beschaffen sein?) aus unterschiedlichen Quellen – Code, Dokumentation, Interviews – zusammengeführt werden können. Die hybride Vorgehensweise aus KI-Analyse und menschlichem Input steht hier im Fokus.
 **F3: Wie bewerten Fachexpert:innen die Qualität und Vollständigkeit der durch KI gewonnenen Requirements?**
 Diese Frage adressiert die Evaluation des entwickelten Ansatzes aus Sicht der praktischen Anwendbarkeit. Sie untersucht, inwieweit die extrahierten Requirements den Qualitätsansprüchen von Software-Entwickler:innen, Projektmanager:innen und anderen Stakeholdern genügen. Dabei sollen sowohl objektive Kriterien (z.B. Vollständigkeit im Vergleich zu einem Referenzset) als auch subjektive Einschätzungen (Verständlichkeit, Präzision, Nützlichkeit für die Weiterentwicklung) erfasst werden. Diese Frage ist zentral für die Beurteilung, ob der entwickelte Ansatz in der Praxis eingesetzt werden kann.
 **F4: Welche Chancen und Grenzen ergeben sich beim KI-gestützten Requirements Engineering in Legacy-Umgebungen?**
 Diese Frage nimmt eine kritisch-reflektierende Perspektive ein und untersucht sowohl die Potenziale als auch die Limitationen des Ansatzes. Chancen können sich etwa in der Effizienzsteigerung, der Systematisierung oder der Entdeckung bisher unbekannter Abhängigkeiten ergeben. Grenzen zeigen sich möglicherweise bei implizitem Wissen, das nicht im Code abgebildet ist, bei der Zuverlässigkeit von LLM-Ausgaben (Halluzinationen) oder bei spezifischen technischen Einschränkungen (Kontextfenster-Größe, Kosten). Die Beantwortung dieser Frage liefert wichtige Erkenntnisse für die Einordnung der Ergebnisse und die Ableitung von Handlungsempfehlungen.
 Diese vier Forschungsleitfragen strukturieren die Arbeit und leiten sowohl die theoretische Fundierung als auch die empirische Untersuchung. Ihre Beantwortung erfolgt durch die Kombination aus Literaturanalyse, technologischer Evaluation, prototypischer Implementierung und systematischer Validierung im Unternehmenskontext der c-entron GmbH.
 ## 1.5 Aufbau der Arbeit
 Die vorliegende Arbeit ist in acht Kapitel gegliedert, die aufeinander aufbauen und einen systematischen Weg von der theoretischen Fundierung über die praktische Umsetzung bis zur kritischen Reflexion beschreiben.
 **Kapitel 1 – Einleitung** führt in die Thematik ein, beschreibt die Ausgangssituation der c-entron GmbH, formuliert die Problemstellung und leitet daraus die Zielsetzung sowie die Forschungsleitfragen ab.
 **Kapitel 2 – Theoretische Grundlagen** schafft das theoretische Fundament der Arbeit. Es werden zunächst die Konzepte des Requirements Engineering und des Reverse Requirements Engineering erläutert, wobei der Fokus auf Qualitätskriterien für Requirements und den besonderen Herausforderungen bei Legacy-Software liegt. Anschließend wird der Stand der Technik zu Large Language Models im Software Engineering aufgearbeitet. Dabei werden die Funktionsweise, Fähigkeiten und Grenzen aktueller Modelle (GPT-4o, Claude 3.5, Code-Llama) diskutiert. Das Kapitel schließt mit einer systematischen Analyse des Forschungsstands zu KI-gestütztem Requirements Engineering und Legacy-Modernisierung ab und identifiziert die Forschungslücke, die diese Arbeit adressiert.
 **Kapitel 3 – Fallstudie c-entron GmbH** stellt den Unternehmenskontext detailliert vor. Es beschreibt das Geschäftsmodell, die Zielgruppe und die technologischen Charakteristika der bestehenden ERP-Software. Die geplante Migrationsstrategie wird ebenso erläutert wie die spezifischen Herausforderungen, die sich aus der gewachsenen Codebasis ergeben. Dieses Kapitel schafft das Verständnis für den konkreten Anwendungsfall und die praktischen Rahmenbedingungen der Arbeit.
 **Kapitel 4 – Konzeption und methodisches Vorgehen** entwickelt das zentrale Prozessmodell für KI-gestütztes Reverse Requirements Engineering. Zunächst werden die Anforderungen an das Verfahren definiert – sowohl funktional als auch nicht-funktional. Anschließend wird das Prozessmodell mit seinen verschiedenen Phasen, Aktivitäten und Rollen beschrieben. Die Technologieauswahl und -evaluation wird dokumentiert, wobei die Entscheidung für spezifische LLMs begründet wird. Das Kapitel beschreibt zudem die methodische Einbindung von Stakeholdern durch Interviews und die Integration der Datengrundlagen (Code-Repositories, Dokumentation, Ticket-Systeme).
 **Kapitel 5 – Prototypische Umsetzung** dokumentiert die technische Implementierung des LLM-Agenten. Es wird die Architektur des Systems beschrieben, einschließlich der einzelnen Komponenten für Code-Analyse, Requirements-Extraktion und Traceability. Die Integration in bestehende Toolchains (Jira, Confluence) wird konzeptionell skizziert. Zudem werden die getroffenen Maßnahmen zu Governance, Datenschutz und IP-Schutz dargelegt, um den Einsatz im Unternehmenskontext rechtskonform zu gestalten.
 **Kapitel 6 – Evaluation** präsentiert die systematische Bewertung des entwickelten Ansatzes. Nach Darstellung des Evaluationsdesigns und der definierten Qualitätskriterien (Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Stakeholder-Alignment, Aufwandsreduktion) werden die Durchführung und die Ergebnisse der Evaluation detailliert beschrieben. Dies umfasst sowohl quantitative Messungen als auch qualitative Expertenreviews. Die Ergebnisse werden strukturiert aufbereitet und bilden die empirische Basis für die nachfolgende Diskussion.
 **Kapitel 7 – Diskussion** interpretiert die Evaluationsergebnisse vor dem Hintergrund der Forschungsleitfragen. Es werden die Potenziale des KI-gestützten Ansatzes erörtert – etwa in Bezug auf Effizienzgewinne, Systematisierung und Vollständigkeit. Gleichzeitig werden Limitationen kritisch reflektiert, darunter technische Einschränkungen, Zuverlässigkeitsfragen und organisatorische Voraussetzungen. Das Kapitel leitet aus den Erkenntnissen Implikationen sowohl für die wissenschaftliche Forschung als auch für die praktische Anwendung in Unternehmen ab.
 **Kapitel 8 – Fazit und Ausblick** fasst die zentralen Erkenntnisse der Arbeit zusammen und beantwortet die eingangs formulierten Forschungsleitfragen. Es werden konkrete Handlungsempfehlungen für die c-entron GmbH formuliert, die sowohl den operativen Einsatz des Prototyps als auch die Weiterentwicklung des Ansatzes betreffen. Das Kapitel schließt mit einem Ausblick auf zukünftige Forschungsfelder und Entwicklungsperspektiven im Bereich KI-gestütztes Requirements Engineering.
 Diese Gliederung gewährleistet eine systematische Bearbeitung der Forschungsfragen und verbindet theoretische Fundierung mit praktischer Anwendung. Die Fallstudie bei der c-entron GmbH dient dabei als roter Faden, der alle Kapitel miteinander verknüpft und die wissenschaftlichen Erkenntnisse in einen konkreten Praxiskontext einbettet.
--- a/kapitel_1_einleitung_adapted.md
+++ b/kapitel_1_einleitung_adapted.md
@@ -1,44 +0,0 @@
 # 1. Einleitung
 ## 1.1 Ausgangssituation und Motivation
 Die c-entron GmbH betreibt seit über zwei Jahrzehnten eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung ist funktional breit aufgestellt (u. a. Auftragsabwicklung, Lager, Fakturierung, Projektabrechnung), wächst aber auf einer klassischen Client/Server-Architektur weiter. Mit dem Wunsch nach webbasierten Oberflächen, Self-Service-Funktionen und flexibleren Betriebsmodellen stößt dieses Setup an Grenzen: Skalierung, Deployment und Nutzerführung lassen sich nur mit hohem Aufwand weiterentwickeln.
 Gleichzeitig liegt ein großer Teil des Systemwissens implizit im Quellcode oder bei langjährigen Mitarbeitenden. Architekturentscheidungen sind selten dokumentiert, und viele Spezialfälle sind nur über Code-Historien nachvollziehbar. Damit erschwert sich die Vorbereitung einer Migration auf eine webbasierte Plattform erheblich.
 Aktuelle Large Language Models (LLMs) wie GPT-4, Claude oder Code Llama können Code analysieren und beschreiben. Sie eröffnen die Möglichkeit, aus einer Legacy-Codebasis zumindest einen Teil der Requirements zu rekonstruieren. Wie tragfähig diese Unterstützung in einem mittelständischen Umfeld tatsächlich ist, ist bislang kaum erprobt. Genau hier setzt die Arbeit an.
 ## 1.2 Problemstellung
 Für die bestehende ERP-Lösung fehlen strukturierte Requirements. Die Codebasis ist groß, historisch gewachsen und nur teilweise dokumentiert. Die Analyse bindet erfahrene Entwickler, ist fehleranfällig und lässt sich kaum skalieren. Daraus ergeben sich wesentliche Risiken für die Migration:
 - Funktionen oder Edge Cases gehen bei der Neuimplementierung verloren, weil sie nur im Code sichtbar sind.
 - Zeit fließt in das Entziffern alter Strukturen, statt in die neue Plattform; technische Schulden werden mitgeschleppt.
 - Domänenwissen konzentriert sich auf wenige Personen, wodurch Personalwechsel zu Wissensverlust führen.
 - Ohne eindeutige Traceability fehlt die Grundlage für Priorisierung, Tests und spätere Wartung.
 Eine rein manuelle Rekonstruktion aller Anforderungen ist wirtschaftlich schwer darstellbar. Es soll daher geprüft werden, ob KI-gestützte Verfahren einen belastbaren Anteil dieser Arbeit übernehmen können.
 ## 1.3 Zielsetzung
 Die Arbeit entwickelt und bewertet ein Vorgehen für KI-gestütztes Reverse Requirements Engineering in einem mittelständischen ERP-Kontext. Kernergebnisse sollen sein:
 - ein praxistaugliches Prozessmodell mit klaren Phasen für Vorbereitung, Analyse, Validierung und Übergabe,
 - eine evaluierte Auswahl geeigneter LLMs (u. a. Kontextfenster, Codeverständnis, Kosten, Datenschutz),
 - ein Prototyp, der Code analysiert, Requirements formuliert und Traceability-Informationen erfasst,
 - eine Ergänzung der KI-Ergebnisse durch Stakeholder-Interviews, wo Code allein nicht reicht,
 - ein Evaluationsrahmen (quantitativ und qualitativ) sowie Governance-Empfehlungen für den Umgang mit sensiblen Daten,
 - Handlungsempfehlungen für die c-entron GmbH und Hinweise zur Übertragbarkeit auf ähnliche Unternehmen.
 ## 1.4 Forschungsleitfragen
 Die Arbeit beantwortet vier Leitfragen:
 - **F1:** Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte braucht es, um LLMs reproduzierbar für Reverse Requirements Engineering einzusetzen?
 - **F2:** Welche funktionalen und nicht-funktionalen Anforderungen lassen sich direkt aus Code ableiten, und wo müssen Interviews und vorhandene Dokumentation ergänzen?
 - **F3:** Wie bewerten Fachexperten Vollständigkeit, Verständlichkeit und Nutzen der KI-Ergebnisse im Vergleich zu manuellen Ansätzen?
 - **F4:** Welche Chancen (Effizienz, Systematisierung) und Grenzen (Halluzinationen, Datenschutz, Kontextgröße) sind beim KI-gestützten Requirements Engineering in Legacy-Umgebungen zu erwarten?
 ## 1.5 Aufbau der Arbeit
 Die acht Kapitel folgen einer durchgängigen Linie: Einleitung (Kap. 1), theoretische Grundlagen zu Requirements Engineering, Reverse Engineering und LLMs (Kap. 2), Fallstudie c-entron GmbH (Kap. 3), Konzept und methodisches Vorgehen (Kap. 4), prototypische Umsetzung des LLM-Agenten (Kap. 5), Evaluation (Kap. 6), Diskussion der Ergebnisse (Kap. 7) sowie Fazit und Ausblick (Kap. 8). Damit entsteht ein klarer Bogen von der Ausgangslage bis zur Validierung des Ansatzes.
--- a/kapitel_2_Theoretische_Grundlagen.md
+++ b/kapitel_2_Theoretische_Grundlagen.md
@@ -1,380 +0,0 @@
 # 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_{<t})
 $$
 Für das Requirements Engineering ist diese Abgrenzung wichtig, weil LLMs aufgrund ihrer generativen Natur Texte produzieren können, die sprachlich konsistent wirken, aber fachlich falsch sein können. Klassische Modelle liefern in solchen Fällen eher „falsche Vorhersagen“, erzeugen jedoch nicht ohne weiteres neue, plausibel klingende Spezifikationen.
 Für die Sprachverarbeitung ist der Begriff "Sprachmodell" relevant: Ein Sprachmodell schätzt Wahrscheinlichkeiten über Tokenfolgen und kann dadurch Texte fortsetzen oder bewerten. Large Language Models (LLMs) sind eine Ausprägung solcher Sprachmodelle, die auf Deep-Learning-Architekturen beruhen und auf sehr großen Korpora vortrainiert werden. In der aktuellen Modellgeneration dominiert die Transformer-Architektur, deren Kernprinzip die Self-Attention ist (Vaswani et al. 2017).
 Self-Attention lässt sich im Transformer formal als gewichtete Kombination von Value-Vektoren beschreiben, wobei die Gewichte aus Query-Key-Ähnlichkeiten berechnet werden (Vaswani et al. 2017):
 $$
 \mathrm{Attention}(Q,K,V)=\mathrm{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V
 $$
 ![Abbildung 2-3: Schematisches Beispiel einer Attention-Gewichtsmatrix (illustrativ).](Abbildungen/abb_2_3_attention_heatmap.png)
 Für diese Arbeit sind drei Konsequenzen dieser Modellklasse besonders relevant:
 * **Kontextfenster:** Modelle verarbeiten Eingaben nur bis zu einer maximalen Tokenanzahl. Längere Artefakte müssen segmentiert oder komprimiert werden.
 * **Tokenisierung:** Quellcode und Fachsprache werden in Token zerlegt. Dies beeinflusst, wie gut Identifier, Struktur und Domänenterminologie repräsentiert werden.
 * **Generativer Charakter:** Ausgaben sind nicht deterministisch. Temperatur, Sampling-Strategien und Promptform beeinflussen Reproduzierbarkeit.
 LLMs werden im Software Engineering eingesetzt, weil sie sowohl natürlichsprachliche Artefakte (z. B. Anforderungen, Kommentare) als auch Codeartefakte (z. B. Klassen, Funktionen, Tests) verarbeiten können. Surveyarbeiten ordnen LLM-Anwendungen nach Aufgabenklassen wie Codegenerierung, Codezusammenfassung, Fehlersuche, Testgenerierung oder Dokumentation (Fan et al. 2023; Salem et al. 2024; arXiv:2308.10620; arXiv:2312.15223).
 ### 2.2.2 Training, Instruction Tuning und Prompting
 LLMs werden typischerweise in mehreren Phasen entwickelt. In einer Vortrainingsphase lernen Modelle aus großen Text- und Codekorpora statistische Regularitäten. Für den Einsatz als Assistenzsysteme werden Modelle häufig zusätzlich auf Anweisungen und Dialogformate ausgerichtet („instruction tuning“). Der GPT-4 Technical Report beschreibt diese Ausrichtung auf Systemebene und diskutiert Safety- und Evaluationsaspekte, ohne die vollständige Trainingspipeline offen zu legen (OpenAI 2023, arXiv:2303.08774).
 Im Engineering-Kontext ist der Prompt damit nicht nur Eingabe, sondern ein Steuerungsinstrument. Für diese Arbeit sind vor allem folgende Hebel relevant:
 * **Aufgabenrahmen:** Ziel, gewünschtes Artefaktformat, Definition von Begriffen und Abgrenzung (z. B. „Requirement“ vs. „Designentscheidung“).
 * **Kontextwahl:** Welche Code- und Textartefakte werden bereitgestellt, und welche Teile werden bewusst ausgeblendet, um Überinterpretation zu begrenzen?
 * **Ausgabe-Constraints:** Belegpflicht, Kennzeichnung unsicherer Aussagen, deterministische Parameter (z. B. niedrige Temperatur), feste Templates.
 Da LLMs ein begrenztes Kontextfenster besitzen, wird in Forschung und Praxis häufig Retrieval-Augmented Generation (RAG) eingesetzt: Relevante Textstellen werden zunächst über Suche/Retrieval ausgewählt und anschließend als Kontext in die Generierung eingebracht. Lewis et al. (2020, arXiv:2005.11401) beschreiben dieses Grundprinzip für wissensintensive Aufgaben. Für Requirements-Extraktion aus Legacy-Code ist RAG naheliegend, weil relevante Regeln, Konfigurationen und UI-Strings über große Repositories verteilt sind und eine „Alles in den Prompt“-Strategie nicht skaliert.
 Prompting-Strategien wie Chain-of-Thought können die Qualität komplexer Ableitungen verbessern, bergen im Requirements-Kontext jedoch ein Risiko: Längere Begründungen können plausibel wirken und dadurch Fehlannahmen stabilisieren. Wei et al. (2022, arXiv:2201.11903) zeigen Chain-of-Thought als wirksame Prompttechnik; für diese Arbeit folgt daraus vor allem, dass Begründungen stets mit Artefaktbelegen gekoppelt werden müssen und nicht als eigenständige Evidenz gelten.
 ### 2.2.3 LLMs für Code: Spezialisierung, Stärken und Grenzen
 Neben allgemeinen Modellen existieren code-spezialisierte LLMs, die auf Codekorpora vortrainiert oder nachtrainiert wurden. Ein prominentes Beispiel ist Code Llama, dessen Technical Report Training und Evaluationsaufbau beschreibt und die Ausrichtung auf Codeaufgaben explizit macht (Rozière et al. 2023). Aus praktischer Sicht sind bei code-spezifischen Modellen typischerweise drei Stärken zu beobachten:
 * **Syntaxnahe Mustererkennung:** Wiederkehrende Idiome, Framework-Patterns und typische Kontrollstrukturen werden zuverlässig erkannt.
 * **Semantische Zusammenfassung:** Funktionen und Module lassen sich in natürliche Sprache übertragen, inklusive grober Zweckbeschreibung.
 * **Transformation und Vorschläge:** Refactorings, Testideen oder API-Skizzen können generiert und iterativ verfeinert werden.
 Den Stärken stehen systematische Grenzen gegenüber. LLMs „verstehen“ Code nicht im Sinne einer formalen Semantik. Sie approximieren Bedeutung über Muster aus Trainingsdaten und aus dem gegebenen Kontext. Insbesondere in Legacy-Systemen mit proprietären Frameworks, kundenspezifischen Erweiterungen und historisch gewachsenen Konventionen ist die Wahrscheinlichkeit hoch, dass Modelle plausible, aber falsche Erklärungen liefern. Genau diese Plausibilität ist im Requirements-Kontext kritisch, weil Text als Spezifikation eine höhere Autorität erhält als eine rein technische Zusammenfassung.
 ### 2.2.4 Halluzinationen und Verlässlichkeit: Relevanz für Requirements
 Halluzinationen bezeichnen Ausgaben, die syntaktisch korrekt und plausibel wirken, aber nicht durch Eingabedaten oder Weltwissen gedeckt sind. Ji et al. (2023) liefern eine Taxonomie und diskutieren Detektions- und Mitigationsansätze. Für Requirements ist die Gefahr besonders kritisch, weil falsche Requirements nicht als „Bug“ im Text auffallen, sondern als scheinbar saubere Spezifikation in nachgelagerte Architektur- und Implementationsentscheidungen einfließen können.
 Zusätzlich zu Halluzinationen sind zwei weitere Verlässlichkeitsthemen relevant:
 * **Daten- und Domänenbias:** Modelle spiegeln Verteilungen und Annahmen aus Trainingsdaten wider. Bender et al. (2021) diskutieren solche Risiken systematisch und betonen Governance-Fragen.
 * **Reproduzierbarkeit:** Kleine Promptänderungen oder Parameterunterschiede können zu variierenden Ergebnissen führen. Für einen engineeringfähigen Prozess sind daher Steuerungsmechanismen (z. B. feste Templates, deterministische Einstellungen, versionierte Prompts) notwendig.
 Für diese Arbeit folgt daraus, dass LLM-Ausgaben im Requirements-Kontext nicht als „Quelle“, sondern als Hypothesenmaterial zu behandeln sind. Erst durch Traceability (Belege) und Validierung (Expertenreview, Laufzeitchecks) wird aus einer Hypothese eine belastbare Anforderung.
 ### 2.2.5 LLMs im Requirements Engineering: Stand der Forschung
 Die Forschung zu LLMs im Requirements Engineering ist dynamisch und lässt sich sinnvoll in eine Vorgeschichte (NLP/IR-Ansätze) und in aktuelle LLM-spezifische Arbeiten gliedern. Vor dem breiten Aufkommen von LLMs wurden Aufgaben wie Terminologieextraktion, Klassifikation, Qualitätsprüfung und Traceability häufig mit Natural Language Processing (NLP) und Information Retrieval (IR) adressiert. Zhao et al. (2021) geben einen Überblick über NLP-Verfahren im Requirements Engineering, inklusive typischer Problemklassen (z. B. Mehrdeutigkeit, Konsistenz, Vollständigkeit). Für Traceability ist die IR-basierte Link-Recovery-Literatur ein wichtiger Referenzpunkt, weil sie zeigt, welche Artefakte (Requirements, Code, Dokumentation) typischerweise verknüpft werden und welche Evaluationsmuster (Precision/Recall, Gold-Standards) sich etabliert haben (Borg, Runeson und Ardö 2013).
 Aktuelle Arbeiten zu LLMs im Requirements Engineering verschieben den Schwerpunkt. Während NLP/IR-Ansätze oft auf klar definierten Teilaufgaben mit begrenzten Ausgaben (Labels, Links, Hinweise) beruhen, können LLMs artefaktnahe Texte erzeugen, umformulieren und strukturieren. Dieser Übergang ist ambivalent: Einerseits entsteht ein direkter Produktivitätshebel, andererseits steigt das Risiko, dass sprachlich "gute" Texte als Spezifikation akzeptiert werden, obwohl die fachliche Basis unzureichend ist (Ji et al. 2023; Hemmat et al. 2025).
 Systematische Übersichten ordnen die LLM-Nutzung im RE entlang klassischer Prozessschritte ein. Hemmat et al. (2025) fassen Forschungsrichtungen zu LLMs im Software Requirements Engineering zusammen und nennen als wiederkehrende Problemfelder Qualitätssicherung, Nachvollziehbarkeit und Domänenabhängigkeit. Eine weitere Review zum ChatGPT-Einsatz im Requirements Engineering liefern Marques et al. (2024). Sie diskutieren den Einsatz entlang typischer RE-Aktivitäten (Elicitation, Analyse, Spezifikation, Validierung) und heben als zentrale Herausforderungen inkonsistente Ergebnisse, begrenztes Domänenwissen sowie die Schwierigkeit belastbarer Evaluationen hervor.
 In der Detailperspektive lassen sich aktuelle LLM-Arbeiten grob nach Anwendungsfeldern bündeln:
 * **Strukturierung und (Re-)Formulierung von Requirements:** Norheim und Rebentisch (2024) untersuchen, wie LLMs naturalsprachliche Anforderungen in strukturiertere Formen überführen können. Okamoto und Kusumoto (2025) adressieren die automatische Umstrukturierung von Software Requirements Specifications mit dem Ziel, Standardkonformität zu erhöhen.
 * **Qualitätsunterstützung und Defektanalyse:** Fantechi et al. (2023) evaluieren ChatGPT für Inkonsistenzdetektion in naturalsprachlichen Requirements. Luitel, Hassani und Sabetzadeh (2024) untersuchen LLM-gestützte Assistenz zur Verbesserung der Requirements-Vollständigkeit.
 * **Elicitation und Stakeholder-Perspektiven:** Marczak-Czajka und Cleland-Huang (2023) zeigen, wie LLMs zur Generierung wertorientierter User Stories als "Inspirationsimpulse" eingesetzt werden können. Diese Richtung ist für Reverse Requirements Engineering indirekt relevant, weil sie zeigt, wie LLMs fehlende Stakeholder-Sichten ergänzen können, ohne den Code als Primärbeleg zu ersetzen.
 * **Domänenspezifische Requirements (Safety/Compliance):** Nouri et al. (2024) betrachten LLMs bei der Engineering-Unterstützung von Safety Requirements im Kontext autonomen Fahrens. Hassani (2024) diskutiert LLM-Einsatz für rechtliche Compliance- und Regulationsanalyse. Solche Arbeiten verdeutlichen, dass LLMs nicht nur Text umformulieren, sondern auch Wissensstrukturen (Normen, Regeln) operationalisieren sollen; zugleich erhöhen sich die Anforderungen an Belegbarkeit und Haftung.
 Über die einzelnen Studien hinaus ist der Evidenzstand derzeit heterogen. Viele Arbeiten sind als Workshopbeiträge oder "preliminary evaluations" angelegt, nutzen begrenzte Datensätze und kombinieren automatische Metriken mit Expertenurteilen. Zudem sind Prompting-Strategien, Modellversionen und Kontexteinstellungen häufig nicht vollständig standardisiert, was die Reproduzierbarkeit erschwert (Fan et al. 2023; Hemmat et al. 2025). Aus Sicht dieser Arbeit folgt daraus eine klare Konsequenz: LLMs sind im Requirements Engineering am stärksten als Assistenzsysteme in einem kontrollierten Prozess, in dem (1) Aussagen mit Belegen verknüpft werden, (2) Unsicherheit explizit markiert wird und (3) fachliche Validierung als definierter Kontrollpunkt erfolgt.
 Für Reverse Requirements Engineering lässt sich der Nutzen damit präzisieren: LLMs können Kandidaten-Requirements aus großen Artefaktmengen (Code, Kommentare, UI-Strings, Konfiguration) verdichten und in eine konsistente Spezifikationsform überführen. Die fachliche Belastbarkeit entsteht jedoch erst durch Traceability zu Codebelegen und die Validierung durch Experten, insbesondere bei Safety-, Compliance- und Abrechnungslogik.
 ### 2.2.6 Absicherung: Human-in-the-loop, Belege und Prozesskontrollen
 Die Literatur legt nahe, dass LLMs im Software Engineering dann robust eingesetzt werden können, wenn sie in einen Prozess eingebettet sind, der Fehler systematisch begrenzt (Fan et al. 2023; Hemmat et al. 2025). Für die Requirements-Extraktion aus Legacy-Code sind folgende Kontrollen praxisnah:
 * **Belegpflicht (Evidence-First):** Jedes generierte Requirement erhält mindestens einen konkreten Beleg (Datei/Komponente/Query/GUI-String) sowie eine kurze Begründung, warum der Beleg die Aussage trägt.
 * **Trennung von Fakt und Interpretation:** Technische Fakten (z. B. „Status = 'Closed' verhindert Update“) werden getrennt von fachlicher Interpretation (z. B. „Abgeschlossene Aufträge sind schreibgeschützt“) dokumentiert.
 * **Mehrstufige Validierung:** Automatische Checks (z. B. Linting auf Verbformen, Konsistenzregeln) werden mit Expertenreview kombiniert.
 * **Reproduzierbarkeit:** Versionierung von Promptvorlagen, Modellversionen und Kontextzuschnitten, um Ergebnisse vergleichbar zu machen.
 Diese Kontrollen adressieren nicht alle Risiken, reduzieren aber die typischen Fehlerklassen (Halluzination, Überinterpretation, fehlende Konsistenz) und schaffen die Grundlage für eine belastbare Evaluation in Kapitel 6.
 ### 2.2.7 Qualitätsbewertung und Messgrößen im Requirements-Kontext
 Die Qualität von LLM-Ergebnissen wird in vielen Arbeiten über allgemeine Textmetriken oder Task-spezifische Benchmarks bewertet. Für Requirements-Extraktion aus Code sind solche Metriken nur begrenzt aussagekräftig, weil der zentrale Anspruch nicht „sprachliche Ähnlichkeit“, sondern fachliche Korrektheit, Prüfbarkeit und Nachvollziehbarkeit ist (Hemmat et al. 2025; Marques et al. 2024). Eine zweckmäßige Qualitätsbewertung sollte daher an RE-Kriterien anschließen und explizit zwischen drei Ebenen unterscheiden:
 * **Statement-Qualität:** Ist ein Requirement eindeutig, vollständig im Satzbau, frei von nicht belegten Annahmen und mit Akzeptanzkriterium bzw. Prüfidee versehen?
 * **Set-Qualität:** Ist die Menge der Requirements konsistent, nicht redundant und deckt die relevanten Prozesse und Varianten ab, ohne sich in Detailfällen zu verlieren?
 * **Traceability-Qualität:** Sind Belege reproduzierbar auffindbar (z. B. Dateipfad, Methode, SQL-Query), und lässt sich die Ableitung von „Beleg → Requirement“ nachvollziehen?
 Für Legacy-Migrationen ist zudem die Fehlerkostenperspektive entscheidend. Ein fehlendes Requirement kann zu Funktionsverlust führen, ein falsches Requirement kann zu fehlerhaften Designentscheidungen führen, und ein unpräzises Requirement verursacht Review- und Nacharbeit. Daraus folgt eine pragmatische Bewertung: Requirements mit hoher Migrationskritikalität (z. B. Sicherheitsregeln, Abrechnungslogik, Berechtigungen) sollten strengere Evidenzanforderungen und intensivere Reviews erhalten als periphere Funktionen. Dieses Prinzip ist kompatibel mit der risikobasierten Priorisierung von Qualitätsanforderungen (Glinz 2008) und lässt sich auf Funktionsanforderungen übertragen.
 ### 2.2.8 Zwischenfazit zu 2.2
 LLMs liefern im Software Engineering eine leistungsfähige Assistenz für Analyse, Zusammenfassung und Textproduktion, sind jedoch nicht verlässlich im Sinne formaler Korrektheit (Fan et al. 2023; Ji et al. 2023). Für Requirements ist der entscheidende Punkt, dass die Qualität nicht an der sprachlichen Glätte, sondern an Nachvollziehbarkeit und Prüfbarkeit hängt. Daraus folgt für diese Arbeit ein designierter "Sicherheitsgurt": Evidence-First, Traceability und Human-in-the-loop sind keine Zusatzoptionen, sondern Kernelemente des Vorgehens.
 ## 2.3 Legacy-Modernisierung und Stand der Forschung
 ### 2.3.1 Charakteristika von Legacy-Systemen
 Legacy-Systeme sind nicht allein durch ihr Alter definiert, sondern durch ihren Kontext: Sie tragen geschäftskritische Funktionen, sind über lange Zeit erweitert worden und weisen oft starke technische und organisatorische Abhängigkeiten auf. Bisbal et al. (1999) beschreiben typische Merkmale wie enge Kopplung, heterogene Technologien, schwer austauschbare Komponenten und unzureichende Dokumentation. Gerade letzteres ist für Modernisierungsvorhaben problematisch, weil Entscheidungen ohne belastbare Anforderungsbasis zu Funktionsverlusten und Akzeptanzproblemen führen können.
 Im ERP-Kontext verschärfen sich diese Merkmale häufig durch:
 * **Domänenkomplexität:** Geschäftsregeln sind zahlreich, variantenreich und teilweise kundenspezifisch.
 * **Datenzentrierung:** Prozesse hängen stark von Datenmodellen, Stammdatenqualität und historisch gewachsenen Datenkonventionen ab.
 * **Integrationslast:** Schnittstellen zu Drittsystemen (z. B. Buchhaltung, Shop, Dokumentenmanagement) sind über Jahre organisch entstanden.
 Damit wird nachvollziehbar, warum Requirements-Extraktion aus der Codebasis nicht nur ein Dokumentationsprojekt, sondern ein Risikoreduktionsinstrument für Migrationen ist.
 ### 2.3.2 Modernisierungsstrategien und Reengineering als Prozess
 Modernisierung kann unterschiedliche Strategien annehmen, von "Lift-and-Shift" bis zur vollständigen Neuimplementierung. Die Literatur betont wiederholt, dass die Wahl einer Strategie von Risiko, Zielarchitektur und verfügbaren Ressourcen abhängt und daher explizit geplant werden sollte (Sneed 1995). Eine zentrale Aussage ist dabei, dass Reengineering nicht als rein technischer Umbau verstanden werden kann: Ohne fachliche Leitplanken entstehen technische Verbesserungen, die am Bedarf vorbeilaufen oder bestehende Fachlogik unabsichtlich verändern.
 Aus Sicht dieser Arbeit lassen sich Modernisierungsstrategien pragmatisch entlang zweier Achsen einordnen: (1) Wie stark wird die bestehende Implementierung weitergenutzt? (2) Wie stark wird die Zielarchitektur verändert? Daraus ergeben sich typische Strategietypen, die in der Praxis auch kombiniert auftreten:
 * **Weiterbetrieb mit Hülle (Wrapping):** Die Legacy-Logik bleibt bestehen, wird aber über neue Schnittstellen oder UI-Schichten zugänglich gemacht. Vorteil ist geringe Eingriffstiefe; Nachteil ist, dass technische Schulden und Engpässe erhalten bleiben.
 * **Schrittweise Modularisierung:** Teile der Legacy-Anwendung werden sukzessive in neue Komponenten überführt, während andere Teile weiterlaufen. Vorteil ist Risikostreuung und frühe Nutzenrealisierung; Nachteil ist erhöhte Integrationskomplexität während der Übergangsphase.
 * **Reengineering/Refactoring:** Die bestehende Logik wird strukturell überarbeitet (z. B. Entkopplung, Schichten, bessere Testbarkeit), ohne den Funktionsumfang grundsätzlich zu verändern. Vorteil ist bessere Wartbarkeit; Nachteil ist hoher Analyseaufwand, gerade ohne Requirementsbasis.
 * **Neuimplementierung mit Funktionsparität:** Die Legacy-Logik wird auf neuer Technologie nachgebaut, häufig mit dem Anspruch, zunächst funktional äquivalent zu sein. Vorteil ist saubere Zielarchitektur; Nachteil ist die hohe Abhängigkeit von vollständigen, korrekten Requirements.
 Für ERP-Systeme ist die Wahl einer Strategie stark datengetrieben. Datenmodelle, Schnittstellenverträge und Buchungslogik definieren die „harten Kanten“ einer Migration. Damit steigt der Stellenwert von Requirements, die Datenobjekte, Zustandsmodelle und Integrationspunkte explizit machen. Besonders migrationskritisch sind dabei Anforderungen, die in der Legacy-Implementierung als implizite Konvention existieren (z. B. Statuscodes, historische Sonderfälle, kundenspezifische Maskenlogik), weil sie ohne gezielte Extraktion und Validierung leicht verloren gehen.
 Bisbal et al. (1997) geben einen Überblick über Migrationsansätze und ordnen typische Risikofelder ein, darunter Datenmigration, Funktionsäquivalenz und organisatorische Abhängigkeiten. Wu et al. (1997) argumentieren ergänzend, dass Werkzeugunterstützung nur dann wirksam ist, wenn sie in eine methodische Kette eingebettet ist. Diese Argumentation ist direkt anschlussfähig an KI-gestützte Verfahren: Auch LLM-basierte Automatisierung entfaltet Nutzen nur innerhalb eines reproduzierbaren Prozesses mit klaren Kontrollpunkten.
 ### 2.3.3 Zielarchitekturen: Web, Cloud und „Cloud-native“
 Die Modernisierung vieler Legacy-Anwendungen zielt auf webbasierte, plattformunabhängige Oberflächen und auf Betriebsmodelle, die Skalierung, automatisiertes Deployment und schnelle Iteration unterstützen. Kratzke und Quint (2017) fassen in einer systematischen Mapping Study zusammen, welche Merkmale cloud-nativer Anwendungen in der Forschung und Praxis wiederkehren. Dazu zählen typischerweise automatisierte Bereitstellung, resiliente Komponenten, horizontale Skalierung und eine stärkere Trennung von Build- und Run-Umgebungen.
 Im selben Zielraum werden Microservices häufig als Architekturstil diskutiert. Pahl und Jamshidi (2016) kartieren Forschung zu Microservices und zeigen wiederkehrende Problemfelder, unter anderem die Wahl der richtigen Servicegranularität, die erhöhte Komplexität im Betrieb und Anforderungen an Observability. Für Migrationsprojekte ist daraus eine pragmatische Schlussfolgerung ableitbar: Modularisierung ist ein Ziel, erzeugt aber zugleich neue Anforderungen (z. B. Deployment-Pipelines, Monitoring, Sicherheitskonzepte), die im Requirements-Set sichtbar sein müssen.
 Für die Requirementsarbeit bedeutet die Zielarchitekturverschiebung eine Verschiebung des Schwerpunktes: Während in klassischen Client/Server-Architekturen die fachliche Funktionslogik oft dominiert, rücken in Web- und Cloud-Kontexten betriebliche und sicherheitsbezogene Qualitätsmerkmale stärker in den Vordergrund. ISO/IEC 25010:2011 bietet hierfür eine hilfreiche Taxonomie. Für Modernisierungsvorhaben lassen sich vor allem folgende Qualitätsmerkmale als wiederkehrend beobachten:
 * **Sicherheit:** Identitäten, Rollenmodelle, Mandantenfähigkeit, Auditierbarkeit.
 * **Zuverlässigkeit:** Fehlerresistenz, Wiederanlauf, Degradationsverhalten.
 * **Performance-Effizienz:** Antwortzeiten, Lastverhalten, Skalierungsgrenzen.
 * **Wartbarkeit:** Änderbarkeit, Testbarkeit, Modularität und technische Schuld.
 * **Kompatibilität und Interoperabilität:** Schnittstellenstabilität, Integrationsfähigkeit mit Drittsystemen.
 Diese Merkmale sind nicht neu, ihre Sichtbarkeit im Projekt nimmt jedoch zu, weil Cloud- und Webbetrieb ein engeres Zusammenspiel von Entwicklung und Betrieb erzwingt. Für Reverse Requirements Engineering folgt daraus, dass der Blick auf die Legacy-Codebasis systematisch um Betriebs- und Sicherheitsanforderungen ergänzt werden muss, auch wenn diese im Code nur indirekt sichtbar sind (z. B. über Deployment-Skripte, Konfigurationen, Logging-Policies oder Rechteprüfungen).
 Sicherheitsanforderungen werden in Cloud-Migrationskontexten häufig unterschätzt. Eine systematische Mapping Study zu Security-Aspekten bei Legacy-to-Cloud-Migrationen (Security in Legacy Systems Migration to the Cloud 2014, DOI: 10.5220/0004979900260037) zeigt, dass Identitätsmanagement, Datenflusskontrolle und Compliance wiederkehrende Kernprobleme sind. Für diese Arbeit bedeutet dies, dass Requirements-Extraktion aus Code um Sicherheits- und Datenschutzanforderungen ergänzt werden muss, da sie nicht in jedem Quellcodefragment explizit sichtbar sind.
 ### 2.3.4 Stand der Forschung: KI-Unterstützung in Modernisierungsvorhaben
 Die Forschung zu KI- bzw. LLM-Unterstützung im Modernisierungskontext ist im Vergleich zu klassischen Reengineering-Ansätzen jünger. Die Übersichten zu LLM4SE (Fan et al. 2023; arXiv:2308.10620) zeigen, dass ein Teil der Arbeiten auf Codeverständnis, Dokumentation und Artefakttransformation zielt. Spezifisch für Requirements Engineering bündeln Reviews und SLRs erste Evidenz und Forschungsrichtungen (Marques et al. 2024; Hemmat et al. 2025).
 Aus dieser Literatur lassen sich zwei robuste Aussagen ableiten:
 * **LLMs sind besonders stark in der Strukturierung und sprachlichen Formulierung**, also dort, wo aus fragmentierten Hinweisen ein konsistenter Text entstehen muss.
 * **LLMs benötigen technische und organisatorische Sicherungen**, wenn Ergebnisse als Entscheidungsgrundlage in Migrationen dienen sollen (z. B. Belege, Review, reproduzierbarer Prozess).
 Damit ist eine zentrale Motivation dieser Arbeit begründet: Eine Legacy-Modernisierung benötigt belastbare Requirements, die im Legacy-Kontext oft fehlen. LLMs sind als Assistenz zur Rekonstruktion naheliegend, müssen jedoch methodisch so eingesetzt werden, dass Verlässlichkeit und Nachvollziehbarkeit systematisch erhöht werden.
 ### 2.3.5 Zwischenfazit zu 2.3
 Legacy-Modernisierung ist ein sozio-technisches Vorhaben, das technische Umbauten und fachliche Zielsetzungen integrieren muss (Bisbal et al. 1999; Sneed 1995). Moderne Zielarchitekturen (Web/Cloud) verschieben zudem die Anforderungslandschaft, weil Betriebs- und Sicherheitsanforderungen stärker in den Vordergrund treten (Kratzke und Quint 2017; Security in Legacy Systems Migration to the Cloud 2014). Für die vorliegende Arbeit folgt daraus, dass Requirements-Extraktion nicht nur der Funktionsrekonstruktion dient, sondern die Grundlage für Migrationsentscheidungen, Priorisierung und Qualitätssicherung bildet.
 ### 2.3.6 Kapitelzusammenfassung und Anschluss
 Die drei Themenblöcke dieses Kapitels greifen ineinander. Requirements Engineering liefert Kriterien, um Anforderungen prüfbar und nachvollziehbar zu formulieren (ISO/IEC/IEEE 29148:2018). Reverse Requirements Engineering überträgt diese Kriterien in einen Kontext, in dem Anforderungen aus bestehenden Artefakten rekonstruiert werden müssen (Chikofsky und Cross 1990; Yu et al. 2005). Large Language Models können diese Rekonstruktion unterstützen, sind aber fehleranfällig und benötigen Prozesskontrollen, vor allem gegen Halluzinationen und Überinterpretation (Ji et al. 2023; Fan et al. 2023). Legacy-Modernisierung schließlich liefert die praktische Motivation und zeigt, warum eine belastbare Anforderungsbasis migrationskritisch ist (Bisbal et al. 1999; Sneed 1995).
 Damit ist das Fundament gelegt, um in Kapitel 3 den konkreten Fallkontext zu beschreiben und in Kapitel 4 ein Vorgehensmodell zu entwickeln, das KI-Unterstützung, Traceability und Validierung systematisch miteinander verbindet.
 ## Literatur
 - Bender, E. M.; Gebru, T.; McMillan-Major, A.; Shmitchell, S. (2021): *On the Dangers of Stochastic Parrots*. Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency (FAccT). https://doi.org/10.1145/3442188.3445922
 - Breiman, L. (2001): *Random Forests*. Machine Learning. https://doi.org/10.1023/A:1010933404324
 - Bishop, C. M. (2006): *Pattern Recognition and Machine Learning*. Springer. https://link.springer.com/book/9780387310732
 - Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J. (1997): *An overview of legacy information system migration*. APSEC/ICSC. https://doi.org/10.1109/apsec.1997.640219
 - Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J. (1999): *Legacy information systems: issues and directions*. IEEE Software. https://doi.org/10.1109/52.795108
 - Borg, M.; Runeson, P.; Ardö, A. (2013): *Recovering from a decade: a systematic mapping of information retrieval approaches to software traceability*. Empirical Software Engineering. https://doi.org/10.1007/s10664-013-9255-y
 - Chikofsky, E. J.; Cross, J. H. (1990): *Reverse engineering and design recovery: a taxonomy*. IEEE Software. https://doi.org/10.1109/52.43044
 - Cortes, C.; Vapnik, V. (1995): *Support-vector networks*. Machine Learning. https://doi.org/10.1007/BF00994018
 - Fan, A.; Gokkaya, B.; Harman, M.; Lyubarskiy, M. (2023): *Large Language Models for Software Engineering: Survey and Open Problems*. ICSE-FoSE. https://doi.org/10.1109/icse-fose59343.2023.00008
 - Fantechi, A.; Gnesi, S.; Passaro, L.; Semini, L. (2023): *Inconsistency Detection in Natural Language Requirements using ChatGPT: a Preliminary Evaluation*. IEEE Requirements Engineering Conference (RE). https://doi.org/10.1109/re57278.2023.00045
 - Friedman, J. H. (2001): *Greedy function approximation: A gradient boosting machine*. The Annals of Statistics. https://doi.org/10.1214/AOS/1013203451
 - Goodfellow, I.; Bengio, Y.; Courville, A. (2016): *Deep Learning*. MIT Press. https://www.deeplearningbook.org/
 - Glinz, M. (2007): *On Non-Functional Requirements*. 15th IEEE International Requirements Engineering Conference (RE 2007). https://doi.org/10.1109/re.2007.45
 - Glinz, M. (2008): *A Risk-Based, Value-Oriented Approach to Quality Requirements*. IEEE Software. https://doi.org/10.1109/ms.2008.31
 - Gotel, O.; Finkelstein, A. (1994): *An analysis of the requirements traceability problem*. International Conference on Requirements Engineering (ICRE). https://doi.org/10.1109/icre.1994.292398
 - Hastie, T.; Tibshirani, R.; Friedman, J. (2009): *The Elements of Statistical Learning* (2nd ed.). Springer. https://hastie.su.domains/ElemStatLearn/
 - Hemmat, A.; Sharbaf, M.; Kolahdouz-Rahimi, S.; Lano, K.; Tehrani, S. Y. (2025): *Research directions for using LLM in software requirement engineering: a systematic review*. Frontiers in Computer Science. https://doi.org/10.3389/fcomp.2025.1519437
 - IEEE (1998): *IEEE Std 830-1998 – Recommended Practice for Software Requirements Specifications*. https://standards.ieee.org/standard/830-1998.html
 - ISO/IEC (2011): *ISO/IEC 25010:2011 – Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models*. https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
 - ISO/IEC/IEEE (2018): *ISO/IEC/IEEE 29148:2018 – Systems and software engineering — Life cycle processes — Requirements engineering*. https://www.iso.org/standard/72089.html
 - Ji, Z.; Lee, N.; Frieske, R.; Yu, T.; et al. (2023): *Survey of Hallucination in Natural Language Generation*. ACM Computing Surveys. https://doi.org/10.1145/3571730
 - Kotonya, G.; Sommerville, I. (1996): *Requirements engineering with viewpoints*. Software Engineering Journal. https://doi.org/10.1049/sej.1996.0002
 - Kratzke, N.; Quint, P.-C. (2017): *Understanding cloud-native applications after 10 years of cloud computing - A systematic mapping study*. Journal of Systems and Software. https://doi.org/10.1016/j.jss.2017.01.001
 - LeCun, Y.; Bengio, Y.; Hinton, G. (2015): *Deep learning*. Nature. https://doi.org/10.1038/nature14539
 - Lawrence, B.; Wiegers, K.; Ebert, C. (2001): *The top risk of requirements engineering*. IEEE Software. https://doi.org/10.1109/52.965804
 - Lewis, P.; Perez, E.; Piktus, A.; Petroni, F.; et al. (2020): *Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks*. arXiv:2005.11401. https://arxiv.org/abs/2005.11401
 - Luitel, D.; Hassani, S.; Sabetzadeh, M. (2024): *Improving requirements completeness: automated assistance through large language models*. Requirements Engineering. https://doi.org/10.1007/s00766-024-00416-3
 - Marczak-Czajka, A.; Cleland-Huang, J. (2023): *Using ChatGPT to Generate Human-Value User Stories as Inspirational Triggers*. IEEE REW. https://doi.org/10.1109/rew57809.2023.00016
 - Marques, N.; Silva, R. R.; Bernardino, J. (2024): *Using ChatGPT in Software Requirements Engineering: A Comprehensive Review*. Future Internet. https://doi.org/10.3390/fi16060180
 - Norheim, J. J.; Rebentisch, E. (2024): *Structuring Natural Language Requirements with Large Language Models*. IEEE REW. https://doi.org/10.1109/rew61692.2024.00013
 - Nouri, A.; Cabrero-Daniel, B.; Törner, F.; Sivencrona, H. (2024): *Engineering Safety Requirements for Autonomous Driving with Large Language Models*. IEEE RE. https://doi.org/10.1109/re59067.2024.00029
 - Okamoto, R.; Kusumoto, S. (2025): *Towards the Automatic Restructuring of Software Requirements Specifications to Conform to Standards Using Large Language Models*. IEEE RE. https://doi.org/10.1109/re63999.2025.00056
 - OpenAI (2023): *GPT-4 Technical Report*. arXiv:2303.08774. https://arxiv.org/abs/2303.08774
 - Pahl, C.; Jamshidi, P. (2016): *Microservices: A Systematic Mapping Study*. CLOSER / Cloud Computing and Services Science. https://doi.org/10.5220/0005785501370146
 - Pohl, K. (2010): *Requirements Engineering: Fundamentals, Principles, and Techniques*. Springer. https://doi.org/10.1007/978-3-642-12578-2
 - Ramesh, B.; Jarke, M. (2001): *Toward reference models for requirements traceability*. IEEE Transactions on Software Engineering. https://doi.org/10.1109/32.895989
 - Rozière, B.; et al. (2023): *Code Llama: Open Foundation Models for Code*. arXiv:2308.12950. https://arxiv.org/abs/2308.12950
 - Ruan, K.; Chen, X.; Jin, Z. (2023): *Requirements Modeling Aided by ChatGPT: An Experience in Embedded Systems*. IEEE REW. https://doi.org/10.1109/rew57809.2023.00035
 - Salem, N.; Hudaib, A.; Al-Tarawneh, K.; Salem, H. (2024): *A survey on the application of large language models in software engineering*. Computer Research and Modeling. https://doi.org/10.20537/2076-7633-2024-16-7-1715-1726
 - Hassani, S. (2024): *Enhancing Legal Compliance and Regulation Analysis with Large Language Models*. IEEE RE. https://doi.org/10.1109/re59067.2024.00065
 - Security in Legacy Systems Migration to the Cloud (2014): *Security in Legacy Systems Migration to the Cloud: A Systematic Mapping Study*. Proceedings of the 11th International Workshop on Security in Information Systems. https://doi.org/10.5220/0004979900260037
 - Sneed, H. M. (1995): *Planning the reengineering of legacy systems*. IEEE Software. https://doi.org/10.1109/52.363168
 - Storey, M.-A. (2005): *Theories, methods and tools in program comprehension: past, present and future*. International Workshop on Program Comprehension (IWPC). https://doi.org/10.1109/wpc.2005.38
 - Tahvildari, L.; Kontogiannis, K.; Mylopoulos, J. (2001): *Requirements-driven software re-engineering framework*. Working Conference on Reverse Engineering (WCRE). https://doi.org/10.1109/wcre.2001.957811
 - Vaswani, A.; Shazeer, N.; Parmar, N.; Uszkoreit, J.; et al. (2017): *Attention Is All You Need*. arXiv:1706.03762. https://arxiv.org/abs/1706.03762
 - Wei, J.; Wang, X.; Schuurmans, D.; Bosma, M.; et al. (2022): *Chain-of-Thought Prompting Elicits Reasoning in Large Language Models*. arXiv:2201.11903. https://arxiv.org/abs/2201.11903
 - Wu, B.; Lawless, D.; Bisbal, J.; Grimson, J. (1997): *Legacy systems migration - a method and its tool-kit framework*. APSEC/ICSC. https://doi.org/10.1109/apsec.1997.640188
 - Yu, Y.; Mylopoulos, J.; Wang, Y.; Liaskos, S.; et al. (2005): *RETR: Reverse Engineering to Requirements*. Working Conference on Reverse Engineering (WCRE). https://doi.org/10.1109/wcre.2005.27
 - Zhao, L.; Alhoshan, W.; Ferrari, A.; Letsholo, K. J. (2021): *Natural Language Processing for Requirements Engineering*. ACM Computing Surveys. https://doi.org/10.1145/3444689
 - arXiv (2024): *Large Language Models for Software Engineering: A Systematic Literature Review*. arXiv:2308.10620. https://arxiv.org/abs/2308.10620
 - arXiv (2024): *A Survey on Large Language Models for Software Engineering*. arXiv:2312.15223. https://arxiv.org/abs/2312.15223
--- a/kapitel_3_fallstudie.md
+++ b/kapitel_3_fallstudie.md
@@ -1,96 +0,0 @@
 # 3. Fallstudie c-entron GmbH
 Dieses Kapitel beschreibt den Anwendungskontext der Arbeit in Form einer Fallstudie. Im Mittelpunkt steht eine gewachsene, Windows-basierte ERP-Software der c-entron GmbH, die im Rahmen einer Modernisierung auf eine webbasierte Plattform überführt werden soll. Ziel des Kapitels ist es, die fachlichen und technischen Rahmenbedingungen so zu strukturieren, dass die Anforderungen an ein KI-gestütztes Reverse Requirements Engineering nachvollziehbar werden. Dazu werden zunächst Unternehmenskontext und Legacy-Software eingeordnet und anschließend die Migrationsstrategie sowie die spezifischen Herausforderungen zusammengefasst.
 ## 3.1 Unternehmenskontext und Legacy-Software
 ### 3.1.1 Unternehmens- und Domänenkontext
 Die c-entron GmbH (Ulm) wird in dieser Arbeit als Fallunternehmen betrachtet. Das Unternehmen entwickelt und betreibt eine ERP-Suite, die sich an IT-Systemhäuser und deren typische Abläufe richtet. Im Vergleich zu neu entstehenden SaaS-Produkten ist die betrachtete Lösung über einen langen Zeitraum in einem stabilen Marktsegment gereift. Damit ist der Funktionsumfang breit, zugleich ist die Implementierung historisch gewachsen und enthält produktionsnahe Randfälle, Ausnahmen und kundenbezogene Varianten.
 Für den Kontext dieser Arbeit sind drei Aspekte wesentlich:
 * **Geschäftskritische Domäne:** ERP-Systeme bilden Kernprozesse ab. Änderungen wirken direkt auf Abrechnung, Lieferfähigkeit und Projektsteuerung.
 * **Hohe Integrationsdichte:** ERP-Funktionen sind typischerweise über Schnittstellen, Datenimporte/-exporte und angebundene Drittsysteme mit weiteren Anwendungen gekoppelt.
 * **Regel- und Datenorientierung:** Ein großer Teil der Logik manifestiert sich in Validierungen, Statusübergängen, Berechtigungsprüfungen und Datenmodellrestriktionen.
 Die Software deckt nach vorliegendem Projektkontext unter anderem Auftragsabwicklung, Lagerfunktionen, Fakturierung sowie Projektabrechnung ab. Für die Modernisierung ist daher nicht nur die Rekonstruktion einzelner Masken oder Funktionen relevant, sondern vor allem die Ableitung stabiler Geschäftsregeln und Datenbeziehungen, die als Basis für eine webbasierte Neuimplementierung dienen.
 ### 3.1.2 Technologischer Ist-Stand (Legacy-Charakteristik)
 Die betrachtete ERP-Suite ist als Windows-basierte Anwendung in einer klassischen Client/Server-Architektur gewachsen. Aus Sicht der Modernisierung ist weniger das „Alter“ entscheidend als die Kombination aus technischer Kopplung, historischer Evolution und begrenzter Dokumentation. Diese Merkmalskombination ist typisch für Legacy-Systeme (Bisbal et al. 1999).
 Für die Fallstudie lassen sich die folgenden, für Requirements-Rückgewinnung relevanten Charakteristika bündeln:
 * **Enge Kopplung zwischen UI, Fachlogik und Persistenz:** Geschäftsregeln sind nicht konsistent in einer Schicht isoliert, sondern verteilen sich über unterschiedliche Komponenten.
 * **Implizite Regeln in Code und Daten:** Ein Teil der Anforderungen ist nicht explizit dokumentiert, sondern ergibt sich aus Validierungen, Prüfpfaden, Standardwerten und Datenmodellannahmen.
 * **Evolution über lange Zeiträume:** Funktionserweiterungen und Fehlerkorrekturen führen zu Sonderfällen und Workarounds, die fachlich begründet sein können, aber selten als Requirements festgehalten sind.
 * **Heterogene Artefakte:** Neben Quellcode existieren Konfigurationen, UI-Texte, Reportdefinitionen, Skripte oder Import-/Exportlogiken, die Anforderungen indirekt spiegeln.
 In der Summe ist der Ist-Zustand damit ein realitätsnaher Prüfstand für Reverse Requirements Engineering: Die Anforderungen liegen nicht als konsolidierte Spezifikation vor, sondern müssen aus einem Bündel technischer Artefakte rekonstruiert und anschließend fachlich validiert werden.
 ### 3.1.3 Dokumentations- und Wissenslage
 Für das betrachtete Modernisierungsvorhaben ist die Ausgangslage geprägt durch fehlende oder nur teilweise gepflegte Anforderungsdokumentation. In Standards des Requirements Engineering wird eine nachvollziehbare Spezifikation mit Qualitätskriterien wie Eindeutigkeit, Verifizierbarkeit und Traceability als Zielbild beschrieben (ISO/IEC/IEEE 29148:2018; IEEE 830-1998). Im Fallunternehmen sind solche Artefakte nicht in ausreichender Tiefe verfügbar, sodass wesentliche Informationen in folgenden Quellen gebunden sind:
 * **Implementierung und Laufzeitverhalten:** Fachliche Regeln werden praktisch durch Codepfade und Datenzustände realisiert.
 * **Change-Historie und Tickets:** Änderungsanlässe, Bugfixes und Kundenanpassungen sind häufig über Issue-Tracker, Commits oder Releases rekonstruierbar.
 * **Erfahrungswissen einzelner Mitarbeiter:** Domänenwissen ist personenbezogen und damit ein Risiko bei Personalwechsel.
 Für die vorliegende Arbeit folgt daraus, dass der Wert eines KI-gestützten Reverse Requirements Engineering nicht in der Generierung „gut klingender“ Spezifikationstexte liegt, sondern in der systematischen Extraktion belegbarer Aussagen, die als Requirements prüfbar sind und die spätere Migration absichern.
 ### 3.1.4 Relevante Artefakte der Fallstudie
 Für die Anforderungen an das Vorgehen in späteren Kapiteln ist es hilfreich, den Artefaktraum der Fallstudie zu strukturieren. Im Kontext der ERP-Modernisierung sind insbesondere folgende Artefaktklassen als Requirements-Träger relevant:
 1. **Quellcode:** Implementierte Regeln, Berechtigungen, Statuslogik, Datenzugriffe.
 2. **Konfiguration und Parameter:** Feature-Schalter, Mandantenparameter, systemweite Defaults.
 3. **UI- und Reportartefakte:** Feldbezeichnungen, Validierungstexte, Druck-/Exportformate.
 4. **Datenstrukturbezogene Artefakte:** Datenmodelle, Constraints, Referenzen, historisierte Strukturen.
 5. **Projektartefakte:** Tickets, Release Notes, Testfälle, Migrationsnotizen.
 Diese Artefakte sind nicht gleichwertig. Für Requirements-Rückgewinnung ist entscheidend, dass Belege in ihrer Aussagekraft bewertet und im Prozess sichtbar gemacht werden. Damit wird die fachliche Validierung gezielt auf risikoreiche oder unsichere Aussagen gelenkt.
 ## 3.2 Migrationsstrategie und spezifische Herausforderungen
 ### 3.2.1 Zielbild der Modernisierung
 Das Modernisierungsziel ist eine webbasierte Plattform, die plattformunabhängige Nutzung und modernere Betriebsmodelle unterstützt. Damit verschiebt sich der Schwerpunkt von einer rein funktionalen Betrachtung hin zu einem Zusammenspiel aus Funktionsäquivalenz und nicht-funktionalen Zielgrößen, insbesondere im Bereich Betrieb, Sicherheit und Änderbarkeit. Das Qualitätsmodell ISO/IEC 25010:2011 bietet hierfür eine etablierte Taxonomie, um solche Zielgrößen systematisch zu erfassen (ISO/IEC 25010:2011).
 Aus Sicht des Fallunternehmens ist das Zielbild in drei Dimensionen zu konkretisieren:
 * **Benutzeroberfläche und Interaktion:** Webbasierte Oberflächen, Rollen- und Rechtekonzepte, konsistente Navigation.
 * **Betriebsmodell und Deployment:** Automatisierte Bereitstellung, Skalierung, Updatefähigkeit und Wartbarkeit über Releases.
 * **Integrationen und Daten:** Stabilisierung von Schnittstellen, Datenmigration und Sicherstellung konsistenter Geschäftsobjekte.
 ### 3.2.2 Strategische Optionen und Abgrenzung
 Die Literatur zur Legacy-Modernisierung betont, dass Migrationen unterschiedliche Strategien annehmen können und dass eine bewusste Planung notwendig ist, um Risiken zu steuern (Sneed 1995; Bisbal et al. 1997). In der Praxis reichen Optionen von minimal-invasiven Ansätzen (z. B. Rehosting) bis zur schrittweisen Neuimplementierung zentraler Funktionen. Für diese Arbeit ist weniger die vollständige Migrationsplanung Gegenstand, sondern die Frage, wie eine belastbare Requirementsbasis für die Umsetzung erzeugt wird.
 Die Abgrenzung des Beitrags lautet daher:
 * Schwerpunkt ist die **Rückgewinnung und Strukturierung** von Requirements aus bestehenden Artefakten.
 * Architektur- und Implementationsentscheidungen der Zielplattform werden nur soweit diskutiert, wie sie Requirements beeinflussen (z. B. Sicherheits- und Betriebsanforderungen).
 * Die eigentliche technische Migration (Datenmigration, Refactoring im Detail, Release-Planung) wird als Rahmenbedingung verstanden und in späteren Kapiteln methodisch adressiert.
 ### 3.2.3 Spezifische Herausforderungen im Fallunternehmen
 Die Fallstudie weist mehrere Herausforderungen auf, die für die Methodik des Reverse Requirements Engineering unmittelbar relevant sind. Die folgenden Punkte bündeln die zentralen Problemfelder und leiten Anforderungen an das Vorgehen ab:
 * **Funktionsäquivalenz und Randfälle:** Ein großer Teil des Systemwertes liegt in korrekt implementierten Ausnahmen, Sonderfällen und Prozessvarianten. Diese sind im Code sichtbar, aber selten dokumentiert. Daraus folgt eine hohe Priorität für Traceability und Validierung.
 * **Implizite Geschäftsregeln:** Geschäftslogik ist häufig als Prüf- und Statuslogik realisiert. Ohne strukturierte Extraktion besteht das Risiko, dass Regeln in der Neuimplementierung vereinfacht oder falsch interpretiert werden.
 * **Datenzentrierte Domäne:** ERP-Funktionalität ist eng mit Datenobjekten, Relationen und historisierten Zuständen gekoppelt. Anforderungen müssen daher nicht nur UI-nah formuliert werden, sondern auch als Daten- und Integritätsanforderungen.
 * **Nicht-funktionale Anforderungen rücken in den Vordergrund:** Mit einer webbasierten Zielplattform steigen Anforderungen an Sicherheitsmechanismen, Verfügbarkeit, Rollout-Fähigkeit und Observability. Studien zu Security-Aspekten in Legacy-to-Cloud-Migrationen zeigen, dass Identitätsmanagement, Datenflusskontrolle und Compliance wiederkehrende Kernprobleme sind (Security in Legacy Systems Migration to the Cloud 2014).
 * **Organisatorische Randbedingungen:** Ressourcen für manuelle Analyse sind begrenzt und hängen von erfahrenen Mitarbeitern ab. Daraus folgt die Notwendigkeit, Analysearbeit skalierbar zu machen und Ergebnisse reproduzierbar zu erzeugen.
 ### 3.2.4 Konsequenzen für das Vorgehen in dieser Arbeit
 Aus den genannten Herausforderungen ergeben sich konkrete Anforderungen an das in Kapitel 4 entwickelte Vorgehen:
 1. **Belegpflicht und Nachvollziehbarkeit:** Jede extrahierte Anforderung muss auf Artefakte zurückgeführt werden können (Datei, Modul, Datenobjekt, UI-Text).
 2. **Explizite Unsicherheitskennzeichnung:** Aussagen, die nicht eindeutig aus Artefakten ableitbar sind, müssen als Hypothesen markiert und priorisiert validiert werden.
 3. **Segmentierung und Kontextsteuerung:** Da Artefakte verteilt sind, ist eine systematische Auswahl relevanter Kontexte notwendig, um Überinterpretation zu reduzieren.
 4. **Human-in-the-loop:** Fachliche Validierung ist zwingend, da „plausible“ Textausgaben kein hinreichender Beweis für fachliche Korrektheit sind.
 Damit schafft dieses Kapitel die Grundlage für die folgenden Abschnitte: Kapitel 4 beschreibt das methodische Vorgehen und das Prozessmodell, Kapitel 5 überführt es in einen Prototyp, und Kapitel 6 evaluiert die Eignung im Fallkontext der c-entron GmbH.
--- a/kapitel_4_konzeption_methodisches_vorgehen.md
+++ b/kapitel_4_konzeption_methodisches_vorgehen.md
@@ -1,164 +0,0 @@
 # 4. Konzeption und methodisches Vorgehen
 Dieses Kapitel beschreibt das Forschungsdesign und das Vorgehensmodell der Arbeit. Ziel ist es, den Einsatz von Large Language Models (LLMs) für Reverse Requirements Engineering so zu strukturieren, dass Ergebnisse nachvollziehbar, überprüfbar und reproduzierbar sind. Hierzu wird zunächst das Forschungsdesign als Fallstudie im Unternehmenskontext eingeordnet. Anschließend wird ein Prozessmodell für KI-gestütztes Reverse Requirements Engineering entwickelt. Abschließend werden Kriterien zur Technologieauswahl, Modellkonfiguration sowie die Einbindung von Stakeholdern und die Datengrundlage beschrieben.
 ## 4.1 Forschungsdesign und Vorgehensmodell
 ### 4.1.1 Einordnung als Fallstudie und Artefaktentwicklung
 Die Arbeit ist als anwendungsnahe Untersuchung im Kontext einer konkreten Legacy-Modernisierung angelegt. Der Kernbeitrag besteht nicht nur in einer Beschreibung von LLM-Fähigkeiten, sondern in der Entwicklung eines Vorgehens, das unter realistischen Randbedingungen (große Codebasis, heterogene Artefakte, begrenzte Expertenzeit) umsetzbar ist. Das Forschungsdesign kombiniert daher:
 1. **Literaturbasierte Fundierung:** Ableitung von Anforderungen an Requirements-Qualität, Traceability und Qualitätskriterien (ISO/IEC/IEEE 29148:2018; IEEE 830-1998).
 2. **Artefaktentwicklung:** Konzeption eines reproduzierbaren Prozessmodells für KI-gestütztes Reverse Requirements Engineering.
 3. **Prototypische Umsetzung:** Implementationsnahe Ausgestaltung des Prozesses als Agenten-/Toolchain-Workflow.
 4. **Fallbezogene Evaluation:** Überprüfung der Praktikabilität und der Ergebnisqualität durch Review und Abgleich mit Artefakten und Expertenwissen.
 Diese Kombination ist notwendig, weil LLM-Ergebnisse im Requirements-Kontext nur dann einen belastbaren Nutzen stiften, wenn sie in einen Prozess eingebettet sind, der Belege, Unsicherheit und Validierung explizit adressiert. LLM-Ausgaben werden daher nicht als Spezifikation „an sich“ betrachtet, sondern als Zwischenartefakte, die über Belegpflicht und Review zu Requirements konsolidiert werden.
 ### 4.1.2 Datenerhebung, Artefaktanalyse und Auswertungslogik
 Die Datengrundlage der Arbeit ist artefaktzentriert. Der Ausgangspunkt ist die bestehende Legacy-Codebasis und die zugehörigen projektinternen Artefakte. Die Analyse folgt einer Logik aus (1) technischer Faktenerhebung und (2) semantischer Interpretation:
 * **Faktenerhebung:** Identifikation von Komponenten, Datenobjekten, Schnittstellen und Regelstellen (z. B. Validierungen, Statuswechsel, Rechteprüfungen).
 * **Semantische Interpretation:** Ableitung fachlicher Aussagen aus den Fakten (z. B. „Ein Auftrag darf nur fakturiert werden, wenn …“).
 * **Formalisierung:** Überführung in Requirements mit Akteur, Vorbedingung, Ergebnis und Prüfidee.
 * **Absicherung:** Zuordnung von Belegen und Review durch Domänenexperten.
 Für die Auswertung ist wichtig, dass die Arbeit nicht versucht, „Vollständigkeit“ absolut zu beweisen. Stattdessen wird eine risikobasierte Perspektive gewählt: Requirements werden dort vertieft und geprüft, wo Migration, Sicherheit oder Datenintegrität besonders kritisch sind. Diese Priorisierung ist anschlussfähig an die RE-Literatur, die Qualitätsanforderungen als risikobasiert zu behandeln empfiehlt (Glinz 2008).
 ### 4.1.3 Gütekriterien: Nachvollziehbarkeit, Prüfbarkeit, Reproduzierbarkeit
 Im Requirements Engineering gelten Kriterien wie Eindeutigkeit, Konsistenz, Vollständigkeit, Verifizierbarkeit und Traceability als zentrale Qualitätsmerkmale (ISO/IEC/IEEE 29148:2018). Für KI-gestützte Extraktion wird diese Liste operationalisiert, um überprüfbare Prozessanforderungen zu erhalten. Für die Arbeit sind besonders relevant:
 * **Traceability:** Jedes extrahierte Requirement muss auf Artefakte zurückgeführt werden können (Code, Konfiguration, Datenobjekt, UI-Text). Traceability ist in der Literatur als zentrales, dauerhaftes Problemfeld beschrieben und wird als Voraussetzung für belastbare Weiterentwicklung betrachtet (Gotel und Finkelstein 1994; Ramesh und Jarke 2001).
 * **Prüfbarkeit:** Requirements werden so formuliert, dass eine Testidee oder ein Abnahmekriterium ableitbar ist.
 * **Reproduzierbarkeit:** Prompting-Strategien, Kontextauswahl und Parameter werden dokumentiert, sodass Analysen unter gleichen Bedingungen wiederholbar sind.
 LLMs erzeugen nicht-deterministische Ausgaben. Deshalb wird im Vorgehensmodell eine „Kontrollspur“ vorgesehen: Kontextquellen, Promptversionen und Resultate werden versioniert, und Unsicherheit wird explizit markiert, um spätere Überprüfung zu ermöglichen. Der Umgang mit Halluzinationen ist dabei ein zentrales Risiko, da plausible Texte fachlich falsch sein können (Ji et al. 2023).
 ## 4.2 Prozessmodell für KI-gestütztes Reverse Requirements Engineering
 ### 4.2.1 Prozessüberblick und Rollen
 Das Prozessmodell strukturiert die Arbeit in Phasen, die wiederholbar durchlaufen werden können. Es unterscheidet technische und fachliche Rollen:
 * **Analyseverantwortlicher:** Steuert Scope, Artefaktauswahl und Toolchain.
 * **Domänenexperte:** Validiert fachliche Bedeutung, Ausnahmen und Prioritäten.
 * **Entwicklung/Architektur:** Nutzt konsolidierte Requirements als Basis für Zielarchitektur und Umsetzung.
 Der Prozess besteht aus sieben Phasen, die iterativ angewendet werden:
 1. **Scope und Domänenabgrenzung**
 2. **Artefakterhebung und Kontextaufbereitung**
 3. **Technische Analyse (Struktur, Daten, Schnittstellen)**
 4. **Retrieval und Kontextsteuerung (RAG)**
 5. **Requirements-Extraktion und Strukturierung**
 6. **Traceability-Anreicherung und Unsicherheitsmarkierung**
 7. **Review, Konsolidierung und Übergabe**
 ### 4.2.2 Artefaktpipeline: Sammeln, Normalisieren, Indexieren
 Die zentrale technische Voraussetzung ist eine Artefaktpipeline, die die Codebasis und flankierende Quellen in eine Form überführt, die sowohl maschinell suchbar als auch für LLMs nutzbar ist. Die Pipeline umfasst:
 * **Sammeln:** Repository, Konfigurationen, UI-Texte, Datenbankschemata, Tickets, Release Notes.
 * **Normalisieren:** Extraktion von Metadaten (Pfad, Modul, Änderungsdatum), Entfernen von Rauschen (Build-Artefakte), Vereinheitlichung von Encodings.
 * **Segmentieren:** Zerlegung großer Dateien in semantische Chunks (z. B. pro Klasse, Methode, SQL-Statement).
 * **Indexieren:** Aufbau eines Suchindex (klassisch oder embeddings-basiert) zur späteren Kontextauswahl.
 Die Segmentierung ist entscheidend, weil LLMs nur ein begrenztes Kontextfenster besitzen. Eine „Alles-in-einen-Prompt“-Strategie skaliert nicht. Retrieval-Augmented Generation (RAG) adressiert dieses Problem, indem relevante Textstellen gezielt in den Prompt geladen werden (Lewis et al. 2020).
 ### 4.2.3 Prompt- und Output-Templates für Requirements
 Um Ergebnisse konsistent auszuwerten, werden Requirements in einem festen Template erzeugt. Ein zweckmäßiges Format umfasst:
 * **ID**
 * **Titel**
 * **Akteur/Rolle**
 * **Vorbedingungen**
 * **Beschreibung des Verhaltens**
 * **Akzeptanzkriterien**
 * **Belege (Artefaktverweise)**
 * **Unsicherheitsmarker / offene Fragen**
 Dieses Template reduziert Interpretationsspielraum und macht Reviews effizienter. Es adressiert zudem ein zentrales Risiko: LLMs können sprachlich „glatte“ Requirements erzeugen, die jedoch ohne Belege und Akzeptanzkriterien nicht belastbar sind. Der Prozess erzwingt daher eine Belegpflicht und die Ableitung von Prüfkriterien als Standardausgabe.
 ### 4.2.4 Kontrollpunkte und Fehlerbegrenzung
 Die Prozesskontrollen sind so gewählt, dass typische LLM-Fehlermuster begrenzt werden:
 * **Belegpflicht:** Keine Requirements ohne Artefaktbezug.
 * **Konfliktprüfung:** Abgleich widersprüchlicher Aussagen über mehrere Belegstellen.
 * **Unsicherheitskennzeichnung:** Hypothesen werden explizit markiert und priorisiert geprüft.
 * **Human-in-the-loop:** Fachliche Validierung als fester Schritt, nicht als optionales „Nachlesen“.
 Diese Kontrollen sind notwendig, weil Halluzinationen und Bias-Risiken in der LLM-Literatur als strukturelle Probleme beschrieben werden (Bender et al. 2021; Ji et al. 2023). Für Requirements bedeutet dies, dass Prozessqualität und Governance nicht nachgelagert, sondern integraler Bestandteil sein müssen.
 ## 4.3 Technologieauswahl und LLM-Konfiguration
 ### 4.3.1 Auswahlkriterien für Modelle und Betriebsform
 Die Auswahl eines LLMs im Unternehmenskontext folgt nicht nur der Modellqualität, sondern auch Randbedingungen. Für diese Arbeit werden die folgenden Kriterien als handlungsleitend betrachtet:
 * **Kontextfenster und Eingabekosten:** Große Artefakte erfordern Segmentierung; zu kleine Kontextfenster erhöhen den Retrieval-Aufwand.
 * **Codefähigkeit:** Verständnis von Identifiern, Kontrollfluss, Datenzugriffsmustern und typischen Framework-Idiomen.
 * **Steuerbarkeit:** Möglichkeiten zur Formatsteuerung (z. B. JSON-Outputs), deterministische Parameter, Prompt-Constraints.
 * **Betriebs- und Datenschutzanforderungen:** Umgang mit Quellcode als potenziell vertraulichem Material.
 * **Reproduzierbarkeit:** Versionierung von Modell, Prompt, Retrieval-Konfiguration.
 Survey- und SLR-Arbeiten zu LLMs im Software Engineering betonen, dass Nutzen stark davon abhängt, wie Modelle in Toolchains integriert und abgesichert werden (Fan et al. 2023; Hou et al. 2023; Zhang et al. 2023). Diese Perspektive prägt die Technologieauswahl in Kapitel 5.
 ### 4.3.2 Konfiguration: Parameter und Prompting
 Da LLM-Ausgaben sensitiv auf Prompting und Sampling reagieren, wird eine konservative Konfiguration gewählt:
 * **Niedrige Temperatur** zur Reduktion von Varianz.
 * **Explizite Ausgabeformate** (Templatepflicht, strukturierte Felder).
 * **Beleganforderungen** (z. B. „nennen Sie Datei + Funktion/SQL“).
 * **Stop-Kriterien** (bei fehlenden Belegen: offene Frage statt Behauptung).
 Chain-of-Thought-Strategien können die Qualität komplexer Ableitungen steigern, erhöhen im Requirements-Kontext jedoch das Risiko, dass Begründungen als Evidenz missverstanden werden. In dieser Arbeit werden Begründungen daher nur als Hilfsmittel akzeptiert, nicht als Beleg (Wei et al. 2022).
 ### 4.3.3 Retrieval-Strategie und Kontextfenstersteuerung
 RAG wird in dieser Arbeit als zentrales Skalierungsprinzip betrachtet (Lewis et al. 2020). Die Kontextfenstersteuerung folgt einer einfachen Heuristik:
 1. Suche nach relevanten Stellen (Keywords, Identifier, Datenobjekte).
 2. Ergänzung um Nachbarschaftskontext (z. B. Aufrufer, SQL-Definition, UI-String).
 3. Begrenzung der Kontextmenge durch Ranking und Redundanzfilter.
 Wichtig ist, dass Retrieval nicht „Wahrheit“ garantiert. Es liefert lediglich die evidenznahe Basis, an die Generierung gekoppelt wird. Daraus folgt, dass Retrieval-Konfigurationen (Chunkgröße, Overlap, Ranking) dokumentiert werden müssen, um Ergebnisse reproduzierbar zu halten.
 ## 4.4 Stakeholder-Einbindung und Datengrundlage
 ### 4.4.1 Stakeholderrollen und Verantwortlichkeiten
 LLM-gestützte Requirements-Rückgewinnung ist ohne Domänenvalidierung nicht belastbar. Für die Fallstudie werden daher Stakeholderrollen unterschieden:
 * **Fachexperten (Domäne/Support):** kennen Ausnahmen, Kundenvarianten und Abläufe.
 * **Entwickler/Architekten:** ordnen Codeartefakte ein und bewerten technische Machbarkeit.
 * **Produktverantwortliche:** priorisieren Requirements in Bezug auf Migrationsziel und Wertbeitrag.
 Die Beteiligung dient nicht nur der Korrektur von Detailfragen, sondern der Abgrenzung von Soll- und Ist-Zustand. Gerade Legacy-Systeme enthalten historisch gewachsene Workarounds, die fachlich nicht zwingend gewünscht sind (Bisbal et al. 1999).
 ### 4.4.2 Interviewleitfaden und Workshopformat
 Die Stakeholder-Einbindung wird als Kombination aus Interviews und Validierungsworkshops strukturiert. Ein schlanker Leitfaden fokussiert auf:
 * kritische Geschäftsobjekte und Statusmodelle,
 * typische Fehlerfälle und Ausnahmen,
 * Sicherheits- und Complianceanforderungen,
 * Integrationen und Schnittstellen,
 * Kriterien für „Done“ in der Migration (Abnahmelogik).
 Workshops dienen der Konsolidierung: Requirements werden mit Belegen präsentiert, offene Punkte markiert und Entscheidungen (z. B. „Ist-Übernahme“ vs. „Soll-Anpassung“) festgehalten. Dieses Vorgehen ist konsistent mit RE-Standards, die Validierung und Stakeholderabstimmung als zentrale Schritte behandeln (ISO/IEC/IEEE 29148:2018).
 ### 4.4.3 Datengrundlage und Umgang mit sensiblen Informationen
 Die Datengrundlage umfasst Quellcode und begleitende Projektartefakte. Aus Governance-Sicht ist Quellcode als sensibel zu betrachten. Daraus folgt:
 * Trennung zwischen Artefakten, die für Retrieval/Prompts verwendet werden dürfen, und solchen, die ausgeschlossen werden (z. B. Zugangsdaten).
 * Protokollierung, welche Artefakte in einen Prompt eingeflossen sind.
 * Minimierung von Kontext (Need-to-know), um Datenabflussrisiken zu reduzieren.
 Diese Maßnahmen werden in Kapitel 5 konkretisiert, da dort die Toolchain-Integration und der Umgang mit Logging, Prompt-Historien und IP-Aspekten umgesetzt werden.
--- a/kapitel_5_prototypische_umsetzung.md
+++ b/kapitel_5_prototypische_umsetzung.md
@@ -1,124 +0,0 @@
 # 5. Prototypische Umsetzung
 Dieses Kapitel beschreibt die prototypische Umsetzung des in Kapitel 4 definierten Vorgehens. Ziel ist ein Workflow, der (1) Code- und Projektartefakte analysiert, (2) daraus strukturierte Requirements ableitet, (3) Belege und Unsicherheiten explizit erfasst und (4) die Ergebnisse so bereitstellt, dass sie in eine Migration überführt werden können. Die Umsetzung wird nicht als „vollautomatische Requirements-Generierung“ verstanden, sondern als Assistenzsystem mit klaren Kontrollpunkten.
 ## 5.1 Architektur des LLM-Agenten
 ### 5.1.1 Architekturüberblick
 Der Prototyp folgt einer Pipeline-Architektur, die Analyse, Retrieval und Generierung entkoppelt. Damit wird die Komplexität kontrollierbar und einzelne Komponenten können iterativ verbessert werden. Der Agent ist in vier Schichten gegliedert:
 1. **Ingestion-Schicht:** Sammeln und Vorverarbeiten von Artefakten.
 2. **Retrieval-Schicht:** Auswahl relevanter Kontexte (RAG) zur Skalierung über große Repositories.
 3. **Reasoning-/Generation-Schicht:** LLM-gestützte Ableitung und Strukturierung der Requirements.
 4. **Traceability- und Output-Schicht:** Persistenz, Belege, Review-Export.
 Retrieval-Augmented Generation ist in dieser Architektur das zentrale Prinzip, um mit begrenzten Kontextfenstern umzugehen und Aussagen an konkrete Belege zu binden (Lewis et al. 2020).
 ### 5.1.2 Ingestion: Artefaktaufbereitung und Chunking
 Die Ingestion-Schicht übernimmt:
 * Erfassung von Quellcode, Konfigurationen, UI-Strings, SQL-Artefakten und Projektdokumenten,
 * Normalisierung von Encodings und Metadaten (Pfad, Modul, Änderungsdatum),
 * Segmentierung in semantische Einheiten (z. B. Klasse/Methode, SQL-Statement, Konfigblock),
 * Ablage in einem Index, der später Retrieval ermöglicht.
 Die Segmentierung verfolgt ein Ziel: Kontext soll klein genug sein, um präzise zu sein, aber groß genug, um Regeln nicht aus dem Zusammenhang zu reißen. Für Legacy-Code bedeutet dies typischerweise, dass neben einer Regelstelle auch angrenzende Strukturen (z. B. Statusenum, Datenobjektdefinition) berücksichtigt werden müssen.
 ### 5.1.3 Retrieval: Kontextauswahl und Ranking
 Retrieval ist als zweistufiges Verfahren umgesetzt:
 1. **Kandidatensuche:** Identifier, Domänenterminologie, Datenobjekte, UI-Labels und Query-Fragmente erzeugen eine erste Trefferliste.
 2. **Ranking und Kontextbündelung:** Treffer werden nach Nähe zum Untersuchungsziel (z. B. „Fakturierung“, „Berechtigung“) sortiert und als Kontextpakete zusammengeführt.
 Damit wird vermieden, dass LLMs ohne ausreichende Belege „auffüllen“. Gleichzeitig bleibt das System flexibel: Neue Untersuchungsfragen können durch andere Retrieval-Queries adressiert werden, ohne dass die gesamte Pipeline angepasst werden muss.
 ### 5.1.4 Requirements-Extraktion und Traceability-Datenmodell
 Die Generation-Schicht erzeugt Requirements nicht als Freitext, sondern als strukturierte Einträge. Ein Eintrag umfasst mindestens:
 * **Requirement-Text** (präzise, testbar),
 * **Akzeptanzkriterien** (Prüfidee, Mess- oder Beobachtbarkeit),
 * **Belege** (Dateipfade, Funktionen, SQL-Statements, UI-Strings),
 * **Unsicherheit** (Markierung fehlender Evidenz oder konkurrierender Interpretationen),
 * **Tags** (Domänenbereich, Datenobjekte, Risiko).
 Traceability ist dabei ein zentrales Designkriterium. Die Literatur beschreibt Traceability als Voraussetzung, um Anforderungen über Lebenszyklen hinweg zu begründen und zu pflegen (Gotel und Finkelstein 1994; Ramesh und Jarke 2001). Für den Prototyp bedeutet dies: Der Agent darf Requirements nicht „aus dem Nichts“ formulieren, sondern muss die Verbindung zu den Artefakten als Primäroutput liefern.
 ## 5.2 Toolchain-Integration
 ### 5.2.1 Integration in Repository und Entwicklungsworkflow
 Die Toolchain-Integration zielt darauf, Analyseergebnisse in vorhandene Arbeitsabläufe zu integrieren. Dazu gehören:
 * **Repository-Integration:** Analyse auf einem definierten Stand (Commit/Tag), um Reproduzierbarkeit sicherzustellen.
 * **Versionierung von Prompts und Konfigurationen:** Prompt-Templates, Retrieval-Parameter und Modellversionen werden dokumentiert, damit Ergebnisse nachvollziehbar bleiben.
 * **Ergebnisablage:** Requirements werden in einem Format abgelegt, das Reviews ermöglicht (z. B. Markdown, Tabellenexport) und später in Tickets oder Spezifikationen überführt werden kann.
 Reproduzierbarkeit ist in diesem Kontext nicht nur ein wissenschaftliches Kriterium, sondern eine praktische Voraussetzung: Ohne klare Zuordnung zu einem Code-Stand entsteht bei späteren Änderungen ein nicht auflösbarer Interpretationskonflikt.
 ### 5.2.2 Einbindung in Wissens- und Ticket-Systeme
 In Modernisierungsvorhaben sind Ticketsysteme und Wissensbasen zentrale Koordinationspunkte. Der Prototyp ist so konzipiert, dass Requirements:
 * als Backlog-Einträge überführt werden können,
 * mit Belegen verlinkt sind (Pfad + Stelle),
 * Review-Kommentare aufnehmen können,
 * als konsolidierte Spezifikation exportierbar bleiben.
 Die Integration ist bewusst „leichtgewichtig“ gehalten: Ziel ist nicht, ein neues Requirements-Tool zu ersetzen, sondern die Lücke der fehlenden Legacy-Spezifikation zu schließen und die Migration mit belegbaren Requirements zu stabilisieren.
 ### 5.2.3 Logging, Nachvollziehbarkeit und Qualitätsmetriken
 Da LLMs nicht deterministisch sind, wird Logging als Qualitätsinstrument verstanden. Pro Analysezyklus werden mindestens gespeichert:
 * Scope-Definition,
 * verwendete Artefaktlisten und Retrieval-Treffer,
 * Promptversion und Modellparameter,
 * Rohoutput des Modells,
 * konsolidierter Requirement-Eintrag und Review-Status.
 Diese Daten erlauben es, Fehlerquellen zu identifizieren (z. B. falscher Kontext, widersprüchliche Belege) und den Prozess iterativ zu verbessern. Gleichzeitig muss Logging gegen Datenschutz- und IP-Risiken abgewogen werden (siehe 5.3).
 ## 5.3 Governance, Datenschutz und IP
 ### 5.3.1 Risiko- und Maßnahmenmodell
 Der Einsatz von LLMs im Kontext von Quellcode berührt Governance-Fragen. In der Literatur wird betont, dass große Sprachmodelle systemische Risiken wie Bias, Fehlverhalten und fehlende Transparenz aufweisen können (Bender et al. 2021). Für die Fallstudie sind insbesondere folgende Risikoklassen relevant:
 * **Falschaussagen/Halluzinationen:** plausibel klingende, aber unbelegte Requirements (Ji et al. 2023).
 * **Datenabfluss:** unbeabsichtigte Preisgabe von Quellcode oder Betriebsinformationen.
 * **IP- und Lizenzrisiken:** unklare Rechte bei Weiterverarbeitung, Speicherung oder externem Modellbetrieb.
 * **Compliance:** Anforderungen aus Datenschutz oder Sicherheit, die in der Zielplattform nachweisbar erfüllt werden müssen.
 Das Maßnahmenmodell kombiniert technische, organisatorische und prozessuale Kontrollen:
 * Belegpflicht und Review,
 * Minimierung des Kontexts (Need-to-know),
 * Zugriffskontrollen auf Indizes und Logs,
 * Trennung von sensiblen Artefakten (z. B. Secrets) aus dem Analyseumfang.
 ### 5.3.2 Datenschutzorientierte Konfiguration und Datenminimierung
 Datenschutzanforderungen werden im Prototyp durch Datenminimierung operationalisiert. Praktisch bedeutet dies:
 * Keine Analyse von Artefakten, die Zugangsdaten oder personenbezogene Inhalte enthalten.
 * Begrenzte Promptkontexte: nur die für die Fragestellung relevanten Codeausschnitte.
 * Reduzierte Speicherung: Prompt-Logs werden, wenn erforderlich, nur mit Hashes/Metadaten gespeichert, nicht als vollständige Inhalte.
 Für den praktischen Einsatz ist zudem zu klären, ob Modelle lokal (On-Premise) oder als Cloud-Service betrieben werden. Diese Arbeit bewertet den Prototyp so, dass beide Betriebsformen abbildbar bleiben. Die konkrete Wahl ist eine Governance-Entscheidung, die von Schutzbedarf, Kosten und Betriebsaufwand abhängt.
 ### 5.3.3 IP, Verantwortlichkeit und Human-in-the-loop
 Der Prototyp ist so gestaltet, dass fachliche Verantwortung nicht an das Modell delegiert wird. LLMs liefern Vorschläge, Strukturierung und Zusammenfassungen, aber keine autoritativen Spezifikationsentscheidungen. Diese Trennung ist notwendig, weil die Qualität der Ergebnisse von Kontext, Prompt und Modellverhalten abhängt und sich ohne Review nicht verlässlich absichern lässt.
 Für Requirements-Artefakte gelten daher folgende Prinzipien:
 * **LLM-Output ist ein Zwischenartefakt:** erst Review und Konsolidierung erzeugen „gültige“ Requirements.
 * **Verantwortung liegt beim Projektteam:** insbesondere für Abnahmen und Architekturentscheidungen.
 * **Transparenz durch Belege:** damit Entscheidungen nachvollziehbar bleiben und in der Migration überprüfbar sind.
 Damit ist die prototypische Umsetzung nicht als Ersatz für Requirements Engineering zu verstehen, sondern als skalierbares Werkzeug, das fehlende Legacy-Dokumentation durch belegbare, reviewbare Artefakte ergänzt.