03_z71

.gitignore

@@ -0,0 +1 @@
+

Kapitel/00_abstract.typ

@@ -1,2 +1,2 @@
 #heading(level: 1, numbering: none)[Abstract (ca. 1 Seite)]
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ergänze hier die Zusammenfassung der Arbeit.
+Zusammenfassung der Arbeit.

Kapitel/01_einleitung.typ

@@ -1,20 +1,22 @@
 #heading(level: 1)[Einleitung (ca. 8 Seiten)]
 
 #heading(level: 2)[Ausgangssituation und Motivation]
-In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre gewachsenen Systeme neu zu bewerten. Besonders ERP-Lösungen, die über Jahrzehnte in Windows-Umgebungen gepflegt wurden, stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen. Dokumentierte Architekturentscheidungen sind selten, implizites Wissen steckt in Source-Control-Systemen oder bei einzelnen Entwickler:innen.
+In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre Produkte neu zu bewerten. Betroffen sind vor allem Systeme die über lange Jahre nur in Windows-Umgebungen vertrieben wurden. Diese stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen und fallen in der technologischen Schuld immer weiter Zurück. Eine technologische Weiterentwicklung ist nicht möglich und an einer Neuentwicklung führt oft kein Weg vorbei. Dokumentierte Anforderungen und Code sind allerdings selten. Das meiste Wissen steckt implizit im Code oder in der Köpfen der verlbeibenden Entwickler.
 
-Die c-entron GmbH in Ulm repräsentiert diesen Kontext. Das Unternehmen betreibt seit über zwanzig Jahren eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung deckt Auftragsabwicklung, Lager, Fakturierung und Projektabrechnung ab, ist aber eng mit der bisherigen Client/Server-Architektur gekoppelt. Kunden fordern inzwischen plattformunabhängige Oberflächen, Self-Service-Funktionen und flexible Betriebsmodelle. Die bestehende Anwendung limitiert Skalierung, Deployment und Benutzerführung, wodurch eine Migration auf eine webbasierte Plattform zwingend erforderlich wird.
+Die c-entron GmbH in Ulm ist von diesem Szenario voll Betroffen. Das Unternehmen betreibt seit über zwanzig Jahren eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung deckt Auftragsabwicklung, Lager, Fakturierung und Projektabrechnung ab, ist aber eng mit der bisherigen Client/Server-Architektur gekoppelt. Kunden erwarten zwischenzeitlich aber plattformunabhängige Oberflächen, Self-Service-Funktionen und flexible Betriebsmodelle wie z.B. SaaS (Software as a Service). Die bestehende Anwendung ist aber in ihrer Skalierung, Deployment und Abrechnung limitiert. Eine Migration auf eine webbasierte Plattform ist somit zwingend erforderlich. 
 
-Parallel dazu hat sich ein neues Instrumentarium etabliert. Large Language Models wie Chat GPT-5 oder Claude.ai können große durch agentische CLIs (Codex, Claude Code) große Mengen an Quellcode analysieren, Muster erkennen und textuell beschreiben. Damit entsteht die Chance, fehlende Anforderungsdokumentationen zumindest teilweise aus dem Code heraus zu rekonstruieren. Die praktische Nutzung dieses Potenzials ist bislang kaum erforscht – insbesondere nicht in mittelständischen Legacy-Projekten. Diese Arbeit adressiert genau diese Lücke und untersucht, wie KI-gestützte Verfahren für eine systematische Anforderungsextraktion eingesetzt werden können.
+Eine einfache Neuimplementierung auf Basis vorhandener Anfoderungs oder Code Dokumentation ist aber aus oben geschilderten Gründen nicht einfach möglich. Die Herausforderung die sich stellt ist mit möglichst geringem Aufwand eine vollständige Beschreibung für ein vollständiges ERP System zu erarbeiten. Eine Manuelle auswertung des Codes oder Obfläche auf Funktionalitäten ist aufgrund der extremen Komplexität, geschuldet der langjährgien Weiterententwicklung, nur mit sehr hohem Personalaufwand möglich und daher nicht realsierbar.
+
+In den letzen Jahren hat sich hierzu nun ein neues Instrumentarium etabliert. Large Language Models wie Chat GPT-5 oder Claude.ai können durch agentische CLIs (Codex, Claude Code) große Mengen an Quellcode analysieren, Anforderungen erarbeiten und textuell beschreiben. Damit entsteht die Chance, fehlende Anforderungsdokumentationen zumindest teilweise aus dem Code heraus zu rekonstruieren. Die praktische Nutzung dieses Potenzials ist bislang kaum erforscht. Diese Arbeit adressiert dies und untersucht, wie KI-gestützte Verfahren für eine systematische Anforderunganalyse eingesetzt werden können.
 
 #heading(level: 2)[Problemstellung]
-Im Projektumfeld der c-entron GmbH fehlen strukturierte Requirements für die bestehende ERP-Lösung. Die Analyse der Legacy-Codebasis ist zeitintensiv, personengebunden und anfällig für Auslassungen. Daraus ergeben sich mehrere Risiken:
+Für das ERP Software Produkt der c-entron fehlen strukturierte und dokumentierte Requirements. Die Analyse der bestehenden Codebasis ist zeitintensiv, ressourcenintensiv und anfällig für Insel- und Metawissen. Daraus ergeben sich mehrere Risiken:
 
-- **Re-Implementationsfehler:** Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration.
+- *Re-Implementationsfehler:* Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration. Zeitgleich sind Workaround of Symptom einer mangelhaften Erfassung der Anfoderungen bei originalen Implementierung und ein zeichen fehlender Weitsicht.
-- **Technische Schuld:** Entwickler:innen investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen.
+- *Technische Schuld:* Entwickler investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen. Neue Mitarbeiter sind auch nicht bewandt in alten technolgien und es fehlt das Verständnis für historische Zwänge und Zusammenhänge.
-- **Implizites Wissen:** Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen.
+- *Implizites Wissen:* Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen. Gleichzeitig führt die langjährige arbeit mit dem bestehenden System zu eingeschränkter Offenheit beim design neuer Lösungen ("Das haben wir schon immer so umgestzt").
-- **Komplexität der Codebasis:** Verschachtelte Abhängigkeiten, unterschiedliche Stile und technologiebedingte Zwänge erschweren eine modulare Anforderungsableitung.
+- *Komplexität der Codebasis:* Verschachtelte Abhängigkeiten, unterschiedliche Stile und technologiebedingte Zwänge erschweren eine modulare Anforderungsableitung.
-- **Fehlende Traceability:** Ohne Zuordnung zwischen Code und Geschäftsprozess fehlt die Grundlage für Priorisierung, Testkonzeption und spätere Wartung.
+- *Fehlende Traceability:* Ohne Zuordnung zwischen Code und Geschäftsprozess fehlt die Grundlage für Priorisierung, Testkonzeption und spätere Wartung. Große Teile des Codes sind auch generisch und lassen sich nicht einer konkreten Anforderung zuordnen, wie zum Beispiel das anzeigen eine Tabelle. Konkrete Datenflüsse lassen sich hier nur am laufenden System beobachten was die Analyse nochmal um eine Größenordnung Resourcenintensiver macht.
 
 Eine rein manuelle Rekonstruktion aller Anforderungen wäre wirtschaftlich kaum tragbar. Deshalb soll geprüft werden, ob KI-gestützte Verfahren Requirements so extrahieren können, dass sie als belastbare Basis für die Modernisierung dienen.
 
@@ -23,29 +25,28 @@ Diese Arbeit verfolgt das Ziel, ein vollständiges Vorgehen für KI-gestütztes
 
 - Entwicklung eines Prozessmodells, das Vorbereitung, Analyse, Validierung und Übergabe strukturiert.
 - Evaluation aktueller LLMs hinsichtlich Kontextfenster, Codeverständnis, Steuerbarkeit, Kosten und Datenschutz.
-- Durchführung und Vergleich von drei Claude-Code-basierten Versuchen (V01-V03) mit unterschiedlicher Tooling-Tiefe (Prompt-only, Agenten, Agenten+MCP).
+- Durchführung und Vergleich von drei Claude-Code basierten Versuchen mit unterschiedlicher Tooling-Tiefe (Prompt-only, Agenten, Agenten+MCP).
-- Integration von Stakeholder-Wissen durch Interviews, um nicht direkt aus dem Code ableitbare Anforderungen zu ergänzen.
 - Definition eines Evaluationsrahmens mit quantitativen und qualitativen Kriterien (Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Aufwandseinsparung).
-- Formulierung konkreter Handlungsempfehlungen für die c-entron GmbH sowie Übertragbarkeit auf ähnliche Unternehmen.
+- Integration von Stakeholder-Wissen durch Interviews, um die Qualität der KI ergebnisse zu bewerten und nicht direkt aus dem Code ableitbare Anforderungen zu ergänzen .
+
 
 #heading(level: 2)[Forschungsleitfragen]
 Die Zielsetzung wird über vier Forschungsleitfragen strukturiert:
 
-- **F1 - Einsatz von LLMs im Reverse Requirements Engineering:** Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?
+1. *Einsatz von LLMs im Reverse Requirements Engineering:* Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?
-- **F2 - Kombination von KI-Analyse und Stakeholder-Input:** Welche funktionalen und nicht-funktionalen Anforderungen lassen sich aus Code extrahieren, und welche Informationen müssen über Interviews ergänzt werden?
+2. *Kombination von KI-Analyse und Stakeholder-Input:* Welche funktionalen und nicht-funktionalen Anforderungen lassen sich aus Code extrahieren, und welche Informationen müssen über Interviews ergänzt werden?
-- **F3 - Qualitätsbewertung der generierten Requirements:** Wie beurteilen Fachexperten Vollständigkeit, Verständlichkeit, Nützlichkeit und Aufwandseinsparung der KI-Ergebnisse?
+3. *Qualitätsbewertung der generierten Requirements:* Wie beurteilen Fachexperten Vollständigkeit, Verständlichkeit, Nützlichkeit und Aufwandseinsparung der KI-Ergebnisse?
-- **F4 - Chancen und Grenzen des Ansatzes:** Welche Effizienzgewinne sind realistisch, wo liegen technische oder organisatorische Limitierungen, und welche Risiken (z. B. Halluzinationen, Datenschutz) müssen adressiert werden?
+4. *Chancen und Grenzen des Ansatzes:* Welche Effizienzgewinne sind realistisch, wo liegen technische oder organisatorische Limitierungen, und welche Risiken (z. B. Halluzinationen, Datenschutz) müssen adressiert werden?
 
 #heading(level: 2)[Aufbau der Arbeit]
-Die Arbeit ist in acht Kapitel gegliedert und folgt dem in den Vorlagen üblichen Aufbau:
+Die Arbeit ist in acht Kapitel gegliedert:
 
-1. **Einleitung:** Kontext, Problemstellung, Ziele und Forschungsfragen.
+1. *Einleitung:* Kontext, Problemstellung, Ziele und Forschungsfragen.
-2. **Theoretische Grundlagen:** Requirements Engineering, Reverse Engineering, Large Language Models sowie Qualitätssicherungskriterien.
+2. *Theoretische Grundlagen:* Requirements Engineering, Reverse Engineering, Large Language Models sowie Qualitätssicherungskriterien.
-3. **Fallstudie c-entron GmbH:** Unternehmensprofil, Produktarchitektur, Migrationsdruck und Rahmenbedingungen.
+3. *Fallstudie c-entron GmbH:* Unternehmensprofil, Produktarchitektur, Migrationsdruck und Rahmenbedingungen.
-4. **Konzeption und methodisches Vorgehen:** Prozessmodell, Technologieauswahl, Stakeholder-Einbindung und Datenbasis.
+4. *Konzeption und methodisches Vorgehen:* Prozessmodell, Technologieauswahl, Stakeholder-Einbindung und Datenbasis.
-5. **Ergebnisse:** Vollständige Ergebnisdarstellung der drei Versuche inkl. Artefaktlisten und beispielhafter Requirements/Use Cases aus den Ergebnisverzeichnissen.
+5. *Ergebnisse:* Vollständige Ergebnisdarstellung der drei Versuche inkl. Artefaktlisten und beispielhafter Requirements/Use Cases aus den Ergebnisverzeichnissen.
-6. **Evaluation:** Vorgehen, Metriken, Ergebnisse und Expertenfeedback.
+6. *Evaluation:* Vorgehen, Metriken, Ergebnisse und Expertenfeedback.
-7. **Diskussion:** Interpretation der Resultate, Limitationen und Implikationen für Forschung und Praxis.
+7. *Diskussion:* Interpretation der Resultate, Limitationen und Implikationen für Forschung und Praxis.
-8. **Fazit und Ausblick:** Zusammenfassung, Beantwortung der Forschungsfragen und Perspektiven für weitere Arbeiten.
+8. *Fazit und Ausblick:* Zusammenfassung, Beantwortung der Forschungsfragen und Perspektiven für weitere Arbeiten.
 
-Damit entsteht eine nachvollziehbare Linie von der Ausgangssituation über das Konzept bis zur Validierung.

Kapitel/02_theoretischer_hintergrund.typ

@@ -6,368 +6,11 @@
 
 #heading(level: 1)[Theoretische Grundlagen (ca. 12 Seiten)]
 
-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.
+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 Themen des Requirements Engineerings sowie die Idee des reverse Requirements Engineerings auf Basis bestehender Systeme eingeordnet. Anschließend werden Large Language Models und deren Einsatz 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  einzuordnen.
-
+
-#heading(level: 2)[Requirements Engineering und Reverse Requirements Engineering]
+#include "02_theoretischer_hintergrund/02_01_requirements_engineering.typ"
-
+#pagebreak()
-#heading(level: 3)[Begriff und Zielsetzung des Requirements Engineering]
+#include "02_theoretischer_hintergrund/02_02_large_language_models.typ"
-
+#pagebreak()
-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 @iso29148_2018 @ieee830_1998.
+#include "02_theoretischer_hintergrund/02_03_legacy_modernisierung.typ"
-
+#pagebreak()
-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 @kotonya1996viewpoints. 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).
-
-#heading(level: 3)[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 @glinz2007nfr. 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 @iso29148_2018 @ieee830_1998.
-
-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. #cite(<glinz2008quality>, form: "prose") 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 @iso25010_2011.
-
-Die Relevanz sauberer Requirements-Qualität zeigt sich auch in der Risikoperspektive. #cite(<lawrence2001toprisk>, form: "prose") 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.
-
-#heading(level: 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 @ieee830_1998 @iso29148_2018.
-
-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. #cite(<pohl2010re>, form: "prose") 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.
-
-#heading(level: 3)[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. #cite(<gotel1994traceability>, form: "prose") analysieren Traceability als wiederkehrendes Problem, insbesondere dort, wo Artefakte heterogen sind und die Disziplin zur Pflege fehlt. #cite(<ramesh2001traceability>, form: "prose") 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.
-
-#heading(level: 3)[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. #cite(<chikofsky1990taxonomy>, form: "prose") 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 #cite(<yu2005retr>, form: "prose") 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 @tahvildari2001reengineering.
-
-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.
-
-#heading(level: 3)[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: #cite(<storey2005program>, form: "prose") 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.
-
-#heading(level: 3)[Zwischenfazit zu 2.1]
-
-Requirements Engineering liefert Kriterien und Artefaktformen, um Anforderungen präzise, prüfbar und nachvollziehbar zu beschreiben @iso29148_2018 @ieee830_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.
-
-#heading(level: 2)[Large Language Models im Software Engineering]
-
-#heading(level: 3)[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 @bishop2006prml @goodfellow2016dl.
-
-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. #cite(<lecun2015deeplearning>, form: "prose") 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 @goodfellow2016dl.
-
-#figure(
-  image("../Abbildungen/abb_2_1_feedforward_nn.png", width: 85%),
-  caption: [Schematische Darstellung eines vollständig verbundenen Feedforward-Netzes.]
-)
-
-Ein einzelnes Neuron lässt sich als affine Transformation mit nachgeschalteter Aktivierungsfunktion formulieren:
-
-$
-z = sum_(i=1)^d w_i x_i + b, #h(1em) a = phi (z)
-$
-
-Typische Aktivierungsfunktionen sind die Sigmoid-Funktion und ReLU #cite(<goodfellow2016dl>):
-
-$
-sigma (z) = 1 / (1 + e^(-z)), #h(1em) op("ReLU") (z) = op("max") (0, z)
-$
-
-#figure(
-  image("../Abbildungen/abb_2_2_aktivierungsfunktionen.png", width: 85%),
-  caption: [Beispielhafte Aktivierungsfunktionen (Sigmoid, tanh, ReLU).]
-)
-
-Die Optimierung erfolgt üblicherweise iterativ. Für Gradientenabstieg gilt in kompakter Form:
-
-$
-theta^(t+1) = theta^(t) - eta nabla_theta cal(L) (theta^(t))
-$
-
-**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 @bishop2006prml @hastie2009esl.
-
-Die folgende Tabelle fasst die Abgrenzung zu häufigen ML-Familien zusammen:
-
-#figure(
-  kind: "table",
-  supplement: [Tabelle],
-  caption: [Abgrenzung zu häufigen Machine-Learning-Methoden.],
-  table(
-    columns: (1fr, 1.35fr, 1.2fr, 1.6fr),
-    align: (left, left, left, left),
-    [**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 @cortes1995svm],
-    [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 @breiman2001randomforests],
-    [Gradient Boosting],
-    [Tabellarische Daten, hohe Genauigkeit],
-    [sehr starke Praxisleistung],
-    [Hyperparameter-sensitiv, Trainingskosten @friedman2001gbm],
-    [Neuronale Netze (Deep Learning)],
-    [Unstrukturierte Daten (Text, Bild), große Datenmengen],
-    [Representation Learning, End-to-End],
-    [hoher Daten-/Rechenbedarf, schwerer zu erklären @lecun2015deeplearning],
-    [LLMs (Transformers)],
-    [Text- und Codeaufgaben, generative Assistenz],
-    [Vortraining nutzt große Korpora; flexible Transferleistung],
-    [Halluzinationen, Kontextlimit, Governance-Aufwand @vaswani2017attention @ji2023hallucination],
-  )
-)
-
-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 @vaswani2017attention.
-
-Self-Attention lässt sich im Transformer formal als gewichtete Kombination von Value-Vektoren beschreiben, wobei die Gewichte aus Query-Key-Ähnlichkeiten berechnet werden #cite(<vaswani2017attention>):
-
-$
-op("Attention") (Q, K, V) = op("softmax") ((Q K^T) / sqrt(d_k)) V
-$
-
-#figure(
-  image("../Abbildungen/abb_2_3_attention_heatmap.png", width: 85%),
-  caption: [Schematisches Beispiel einer Attention-Gewichtsmatrix (illustrativ).]
-)
-
-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 @fan2023llmse @salem2024surveyllmse @llm4se2024slr @llm4se2024survey.
-
-#heading(level: 3)[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 @openai2023gpt4.
-
-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. #cite(<lewis2020rag>, form: "prose") 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. #cite(<wei2022cot>, form: "prose") 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.
-
-#heading(level: 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 @roziere2023codellama. 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.
-
-#heading(level: 3)[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. #cite(<ji2023hallucination>, form: "prose") 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. #cite(<bender2021stochastic>, form: "prose") 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.
-
-#heading(level: 3)[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. #cite(<zhao2021nlpre>, form: "prose") 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 @borg2013traceability.
-
-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 @ji2023hallucination @hemmat2025directions.
-
-Systematische Übersichten ordnen die LLM-Nutzung im RE entlang klassischer Prozessschritte ein. #cite(<hemmat2025directions>, form: "prose") 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 #cite(<marques2024chatgptre>, form: "prose"). 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:** #cite(<norheim2024structuring>, form: "prose") untersuchen, wie LLMs naturalsprachliche Anforderungen in strukturiertere Formen überführen können. #cite(<okamoto2025restructuring>, form: "prose") adressieren die automatische Umstrukturierung von Software Requirements Specifications mit dem Ziel, Standardkonformität zu erhöhen.
-- **Qualitätsunterstützung und Defektanalyse:** #cite(<fantechi2023inconsistency>, form: "prose") evaluieren ChatGPT für Inkonsistenzdetektion in naturalsprachlichen Requirements. #cite(<luitel2024completeness>, form: "prose") untersuchen LLM-gestützte Assistenz zur Verbesserung der Requirements-Vollständigkeit.
-- **Elicitation und Stakeholder-Perspektiven:** #cite(<marczak2023humanvalue>, form: "prose") 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):** #cite(<nouri2024safety>, form: "prose") betrachten LLMs bei der Engineering-Unterstützung von Safety Requirements im Kontext autonomen Fahrens. #cite(<hassani2024legal>, form: "prose") 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 @fan2023llmse @hemmat2025directions. 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.
-
-#heading(level: 3)[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 @fan2023llmse @hemmat2025directions. 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.
-
-#heading(level: 3)[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 @hemmat2025directions @marques2024chatgptre. 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 @glinz2008quality und lässt sich auf Funktionsanforderungen übertragen.
-
-#heading(level: 3)[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 @fan2023llmse @ji2023hallucination. 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.
-
-#heading(level: 2)[Legacy-Modernisierung und Stand der Forschung]
-
-#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.
-
-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.
-
-#heading(level: 3)[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 @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 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.
-
-#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.
-
-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.
-
-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:
-
-- **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 @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.
-
-#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:
-
-- **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.
-
-#heading(level: 3)[Zwischenfazit zu 2.3]
-
-Legacy-Modernisierung ist ein sozio-technisches Vorhaben, das technische Umbauten und fachliche Zielsetzungen integrieren muss @bisbal1999legacy @sneed1995planning. Moderne Zielarchitekturen (Web/Cloud) verschieben zudem die Anforderungslandschaft, weil Betriebs- und Sicherheitsanforderungen stärker in den Vordergrund treten @kratzke2017cloudnative @security2014legacycloud. 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.
-
-#heading(level: 3)[Kapitelzusammenfassung und Anschluss]
-
-Die drei Themenblöcke dieses Kapitels greifen ineinander. Requirements Engineering liefert Kriterien, um Anforderungen prüfbar und nachvollziehbar zu formulieren @iso29148_2018. Reverse Requirements Engineering überträgt diese Kriterien in einen Kontext, in dem Anforderungen aus bestehenden Artefakten rekonstruiert werden müssen @chikofsky1990taxonomy @yu2005retr. Large Language Models können diese Rekonstruktion unterstützen, sind aber fehleranfällig und benötigen Prozesskontrollen, vor allem gegen Halluzinationen und Überinterpretation @ji2023hallucination @fan2023llmse. Legacy-Modernisierung schließlich liefert die praktische Motivation und zeigt, warum eine belastbare Anforderungsbasis migrationskritisch ist @bisbal1999legacy @sneed1995planning.
-
-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.

Kapitel/02_theoretischer_hintergrund/02_01_requirements_engineering.typ

@@ -0,0 +1,104 @@
+#heading(level: 2)[Requirements Engineering und Reverse Requirements Engineering]
+
+#heading(level: 3)[Begriff und Zielsetzung des Requirements Engineering]
+
+der Begriff Requirements Engineering (RE) umfasst die systematische Erhebung, Analyse, Spezifikation, Validierung und Verwaltung von Anforderungen an ein System über dessen Lebenszyklus. In Standards @iso29148_2018 @ieee830_1998 wird Reqirements Engineering 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.
+
+Im Kern adressiert das Requirments Engineering zwei Themen:
+
+- ***Kommunikation zwischen Domäne und Technik:*** Anforderungen müssen fachlich verständlich und gleichzeitig so präzise sein, dass sich daraus eine Software-Architektur ableiten lässt, die implementiert, getestet und geändert werden kann.
+- ***Umgang mit Unsicherheit und Wandel:*** Anforderungen sind zu Projektbeginn selten vollständig. Requriements Engingeeing ist daher nicht nur Dokumentation, sondern auch ein iterativer Klärungs- und Abstimmungsprozess.
+
+Ein etablierter Ansatz zur Strukturierung von diversen Sichtweisen ist das Viewpoint-Konzept @kotonya1996viewpoints, bei dem Anforderungen aus unterschiedlichen Perspektiven modelliert und anschließend konsolidiert werden .
+
+_Für diese Arbeit ist die Perspektivenorientierung relevant, weil implementierter Code typischerweise keine expliziten Stakeholder-Sichten enthält. Für eine Migration auf Basis eines Reverse Engeneering Ansatzes sind diese aber relevant für die implementierung und architekturlle Entscheidungen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben)._
+
+#heading(level: 3)[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 scharf ist. Eigenschaften können sowohl als Systemverhalten (z. B. „Audit-Log erzeugen") als auch als Qualitätsziel (z. B. „Nachvollziehbarkeit") formuliert werden @glinz2007nfr. Für das 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 gibt es etablierte Standards. @iso29148_2018 nennt unter anderem Eindeutigkeit, Konsistenz, Vollständigkeit, Verifizierbarkeit und Nachvollziehbarkeit als zentrale Eigenschaften. @ieee830_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 maßgeblich relevant:
+
+- *Verifizierbarkeit:* Ein Requirement ist so formuliert, dass ein Test oder eine 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 \ (z.B. „Das System soll Aufträge schnell verarbeiten" vs. „Das System soll einen Auftrag innerhalb von 2 Sekunden validieren und bestätigen")
+- *Nachvollziehbarkeit (Traceability):* Es ist erkennbar, aus welchem Requirement das Artefakt (Code, Konfiguration, Datenbank, Ticket, Interview) abgeleitet wurde.
+
+Nicht funktionale Anforderungen (z.B. Qualitätsanforderungen) bedürfen einer besonderen Betrachtung, weil sie über die reine Funktionsgleichheit hinaus die Zielarchitektur bestimmen. #cite(<glinz2008quality>, form: "prose") argumentiert, dass Qualitätsanforderungen risikobasiert und wertorientiert priorisiert werden sollten. Für Legacy-Migrationen ist dies nachvollziehbar: Ein „vollständiges" Requirements-Set ist praktisch schwer erreichbar, gleichzeitig sind bestimmte Non-Functional 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 @iso25010_2011.
+
+Die Relevanz saubere formulierter Requirements zeigt sich auch in der Risikoperspektive. #cite(<lawrence2001toprisk>, form: "prose") beschreiben Requirements Engineering als primäres Risiko, wenn Anforderungen unklar, instabil oder unvollständig sind. 
+\ \
+_Für diese Arbeit folgt daraus, dass KI-gestütztes Reverse-Requirements-Engineering nicht nur „mehr Text" erzeugen darf, sondern gezielt die Risiken der Unklarheit und der Fehlinterpretation reduzieren muss._
+
+#heading(level: 3)[Spezifikationsformen und Grad der Formalisierung]
+
+Requirements werden 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). Zudem existieren weniger formale Formen wie User Stories, Use-Case-Beschreibungen oder Backlog-Einträge, die in agilen Settings verwendung finden. @ieee830_1998 @iso29148_2018.
+
+Für Reverse Requirements Engineering sind zwei Punkte entscheidend:
+
+- *Form* beeinflusst Interpretierbarkeit: Eine kurze User Story („Als Nutzer möchte ich …") ist leicht verständlich, transportiert aber weniger 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. #cite(<pohl2010re>, form: "prose") betont Anforderungen-Validierung als eigene Disziplin.
+
+_Für diese Arbeit wir daher ein hybrider Stil gewählt: Requirements werden als kurze, klare Soll-Aussagen formuliert und jeweils um Kontext (Akteur/Prozess), Randbedingungen (Vorbedingungen, Datenobjekte) und mindestens eine Prüfidee ergänzt._
+
+#heading(level: 3)[Traceability als Verbindung zwischen Code und Requirement]
+
+Traceability bezeichnet die Verknüpfung von Requirements und Artefakten, wie z.B. Code oder Test. #cite(<gotel1994traceability>, form: "prose") bezeichnen Traceability als wiederkehrendes Problem, vor allem bei unterschiedlichen Arten von Artefakten. 
+
+Beim Reverse Requirements Engineering ist Traceability nicht nur ein „Nice-to-have", sondern eine Grundvoraussetzung.\
+Ein Requirement lässt sich gegen konkrete Codeausschnitte oder Laufzeitbeobachtungen prüfen da da Requirement ja aus dem Code selbst entsteht.
+
+In Legacy-Systemen ist die Ursprüngliche Traceability typischerweise unvollständig, falls überhaupt vorhanden: Hinweise finden sich in Commit-Messages, Branch-Namen, Datenbankskripten, Konfigurationsdateien, UI-Texten oder in impliziten Konventionen. Der Anspruch dieser Arbeit besteht daher nicht darin, „perfekte" Traceability wiederherzustellen, sondern eine minimal belastbare, reproduzierbare Verknüpfung zwischen extrahierten Requirements und Artefakten zu etablieren.
+
+#heading(level: 3)[Abgrenzung von Reverse Engineering zu Reverse Requirements Engineering]
+
+Reverse Engineering wird klassisch als Analyseprozess verstanden, der aus einem bestehenden System Wissen über Struktur, Verhalten und Designentscheidungen rekonstruiert. #cite(<chikofsky1990taxonomy>, form: "prose") prägen hierfür die Bennung und grenzen Reverse Engineering von Reengineering sowie Design Recovery ab. Für Requirements-nahe Fragestellungen ist hier relevant, dass Reverse Engineering nicht automatisch auch Requirements liefert, sondern erstmal nur technische Fakten (z. B. Abhängigkeiten, Datenflüsse, Zustandsautomaten).
+
+Reverse Requirements Engineering (RRE) fokussiert sich dagegen auf die rückwärtsgerichtete Gewinnung von Requirements 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? Was war das ursprüngliche Ziel der Imepementierung?
+- *Rekonstruktion eines Ist-Zustands:* Welche Funktionen und Regeln sind dagegen tatsächlich implementiert?
+
+Gerade im Legacy Umfeld ist diese Unterscheidung entscheidend. Die Codebasis enthält oft historisch entstandene Workarounds oder kundenspezifische Anpassungen. 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 #cite(<yu2005retr>, form: "prose") mit „RETR: Reverse Engineering to Requirements". Der Beitrag betont, dass Requirements-Rückgewinnung eine methodische Kette aus Artefaktsichtung, Strukturierung und Validierung benötigt. 
+
+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.
+
+_Da eine Dynamische Analyse durch ein LLM mit den gegebenen technischen Möglichkeiten derzeit unpraktikabel ist, fokussiert sich diese Arbeit auf die statische Analyse von Artefakten, ergänzt manuell erstellte Artefakte zur Laufzeit (z.B. Screenshots)._
+
+#heading(level: 3)[Typische Methodenkette für Requirements-Rückgewinnung aus Code]
+
+Aus Sicht dieser Arbeit lässt sich Reverse Requirements Engineering einer Legacy-Codebasis als wiederholbarer Ablauf darstellen. Die konkrete Implementierung 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 dient der Risikobewertung: Requirements, die überwiegend auf Sekundär- oder Kontextbelegen beruhen, sind anfälliger für Fehlinterpretation und sollten priorisiert validiert werden. Datenbankschemata und SQL-Statements sind häufig besonders aussagekräftig, weil sie Domänenobjekte, Kardinalitäten und Geschäftsregeln (z. B. referentielle Integrität, historisierte Tabellen) abbilden.
+
+_Für diese Arbeit werden in der Schrittkette lediglich Punk 1 und 7 manuell durchgeführt, während die Schritte 2-6 durch KI-gestützte Analyse automatisiert werden sollen._
+
+/*
+#heading(level: 3)[Zwischenfazit zu 2.1]
+
+Requirements Engineering liefert Kriterien und Artefaktformen, um Anforderungen präzise, prüfbar und nachvollziehbar zu beschreiben @iso29148_2018 @ieee830_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.
+*/

Kapitel/02_theoretischer_hintergrund/02_02_large_language_models.typ

@@ -0,0 +1,270 @@
+#import "@preview/cetz:0.4.2"
+#import "@preview/cetz-plot:0.1.3": plot
+
+#heading(level: 2)[Large Language Models im Software Engineering]
+
+#heading(level: 3)[Künstliche Intelligenz, Machine Learning und Einordnung von LLMs]
+
+Die Einordnung von Large Language Models folgt einer hierarchischen Begriffsstruktur, die sich in vier Ebenen gliedern lässt (vgl. @abb_hierarchie_ki):
+
+*Künstliche Intelligenz (KI)* ist der Oberbegriff für Verfahren, die Aufgaben bearbeiten, welche in der Praxis typischerweise kognitive Fähigkeiten erfordern (z. B. Klassifikation, Planung, Sprachverarbeitung) @bishop2006prml.
+
+*Machine Learning (ML)* ist ein Teilgebiet der KI, das Modelle aus Daten lernt, anstatt Regeln vollständig manuell zu spezifizieren (sogennante Expertensysteme). in der Praxis wird zwischen Systemen mit überwachtem Lernen (mit Zielwerten), unüberwachtem Lernen (ohne Zielwerte, System erkennt selbst eine Struktur) und Reinforcement Learning (Lernen über Rückmeldung, z.B. Ergebnis Richtig / Falsch) unterschieden @bishop2006prml @goodfellow2016dl. In der heutigen Welt sind Neuronale Netze die dominierende ML-Architektur, insbesondere für unstrukturierte Daten wie Text und Code.
+
+*Deep Learning* ist wiederum ein Teilbereich von ML, der neuronale Netze mit vielen Parametern und vielen (tiefen) Verarbeitungsebenen nutzt, um geeignete Repräsentationen aus Rohdaten zu lernen. Charakteristisch ist, dass Merkmalsextraktion und Modellanpassung gemeinsam über Optimierung (typischerweise Gradientenverfahren) erfolgen. 
+
+*Large Language Models (LLMs)* sind eine spezielle Ausprägung von Neuronalen Netzen, die auf sehr großen Text- und Codemengen vortrainiert werden. Zudem verfügen sie über sehr große Mengen (>Milliarden) von Eingabeparametern (Tokens) und viele Schichten (>100). In der aktuellen Modellgeneration dominiert die Transformer-Architektur @vaswani2017attention, deren Funktionsweise in den folgenden Abschnitten erläutert wird.
+
+#figure(
+  cetz.canvas({
+    import cetz.draw: *
+
+    rect((-6, -2.8), (6, 2.8), stroke: black + 0.6pt, fill: luma(242))
+    content((0, 2.35), text(size: 9pt, weight: "bold")[Künstliche Intelligenz (KI)])
+
+    rect((-5.4, -2.2), (5.4, 1.9), stroke: black + 0.6pt, fill: luma(228))
+    content((0, 1.45), text(size: 9pt, weight: "bold")[Machine Learning (ML)])
+
+    rect((-4.8, -1.6), (4.8, 1.0), stroke: black + 0.6pt, fill: luma(214))
+    content((0, 0.55), text(size: 9pt, weight: "bold")[Deep Learning])
+
+    rect((-4.2, -1.0), (4.2, 0.1), stroke: black + 0.6pt, fill: luma(200))
+    content((0, -0.45), text(size: 9pt, weight: "bold")[Large Language Models (LLMs)])
+  }),
+  caption: [Hierarchische Einordnung: KI ⊃ ML ⊃ Deep Learning ⊃ LLMs.],
+) <abb_hierarchie_ki>
+#pagebreak()
+*Neuronale Netze* lassen sich vereinfacht als parametrisierte Funktionsketten aus Schichten (Layern) beschreiben. Dabei geben die Schichten die Eingaben in zunehmend abstrakte Repräsentationen jeweils in die nächste Schicht weiter. Das Training erfolgt über eine Zielfunktion  und Gradientenberechnung. In der Praxis geschieht dies meist über Backpropagation und Varianten des Gradientenabstiegs @goodfellow2016dl.
+
+#figure(
+  cetz.canvas({
+    import cetz.draw: *
+
+    let r = 0.35
+    let lx = 3.0
+    let ny = 1.5
+
+    let ys-3 = (ny, 0, -ny)
+    let ys-2 = (ny / 2, -ny / 2)
+
+    let layers = (
+      (x: 0,      ys: ys-3, labels: ($x_1$, $x_2$, $x_3$)),
+      (x: lx,     ys: ys-3, labels: ($h_1$, $h_2$, $h_3$)),
+      (x: 2 * lx, ys: ys-2, labels: ($y_1$, $y_2$)),
+    )
+
+    // Kanten (zuerst zeichnen, damit Knoten darüber liegen)
+    for li in range(layers.len() - 1) {
+      let l1 = layers.at(li)
+      let l2 = layers.at(li + 1)
+      for y1 in l1.ys {
+        for y2 in l2.ys {
+          line(
+            (l1.x, y1), (l2.x, y2),
+            stroke: luma(160) + 0.4pt,
+          )
+        }
+      }
+    }
+
+    // Knoten
+    for layer in layers {
+      for (i, y) in layer.ys.enumerate() {
+        circle((layer.x, y), radius: r, stroke: black + 0.6pt, fill: white)
+        content((layer.x, y), layer.labels.at(i))
+      }
+    }
+
+    // Schichtbeschriftungen
+    let label-y = ny + 0.9
+    content((0, label-y), text(size: 9pt)[Eingabe])
+    content((lx, label-y), text(size: 9pt)[Verdeckte Schicht])
+    content((2 * lx, label-y), text(size: 9pt)[Ausgabe])
+  }),
+  caption: [Schematische Darstellung eines vollständig verbundenen Feedforward-Netzes.]
+)
+
+Ein einzelnes Neuron lässt sich als  Transformation mit nachgeschalteter Aktivierungsfunktion formulieren:
+
+$
+z = sum_(i=1)^d w_i x_i + b, #h(1em) a = phi (z)
+$
+
+Typische Aktivierungsfunktionen ($a = phi (z)$) sind die Sigmoid-Funktion, der hyperbolische Tangens und ReLU #cite(<goodfellow2016dl>):
+
+#grid(
+  columns: (1fr, 1fr, 1fr),
+  align: center,
+  column-gutter: 0.8em,
+  row-gutter: 0.4em,
+  text(weight: "bold")[Sigmoid],
+  text(weight: "bold")[tanh],
+  text(weight: "bold")[ReLU],
+  $ sigma(z) = frac(1, 1 + e^(-z)) $,
+  $ tanh(z) = frac(e^z - e^(-z), e^z + e^(-z)) $,
+  $ op("ReLU")(z) = max(0, z) $,
+)
+
+#figure(
+  cetz.canvas({
+    import cetz.draw: *
+
+    plot.plot(
+      size: (12, 7),
+      x-tick-step: 2,
+      y-tick-step: 1,
+      x-min: -6, x-max: 6,
+      y-min: -1.5, y-max: 6.5,
+      x-label: $x$,
+      y-label: $phi(x)$,
+      legend: "north-west",
+      {
+        plot.add(
+          style: (stroke: blue + 1.2pt),
+          domain: (-6, 6),
+          samples: 200,
+          label: [$sigma(x)$ (Sigmoid)],
+          x => 1 / (1 + calc.exp(-x)),
+        )
+        plot.add(
+          style: (stroke: orange + 1.2pt),
+          domain: (-6, 6),
+          samples: 200,
+          label: [$tanh(x)$],
+          x => {
+            let e2x = calc.exp(2 * x)
+            (e2x - 1) / (e2x + 1)
+          },
+        )
+        plot.add(
+          style: (stroke: green.darken(20%) + 1.2pt),
+          domain: (-6, 6),
+          samples: 200,
+          label: [ReLU $max(0, x)$],
+          x => calc.max(0, x),
+        )
+      },
+    )
+  }),
+  caption: [Beispielhafte Aktivierungsfunktionen (Sigmoid, tanh, ReLU).]
+)
+
+Die Optimierung erfolgt üblicherweise iterativ. Für Gradientenabstieg gilt in kompakter Form:
+
+$
+theta^(t+1) = theta^(t) - eta nabla_theta cal(L) (theta^(t))
+$
+
+
+LLMs unterscheiden sich von klassischen neuronalen Netzen nicht nur durch ihre Modellgröße, sondern vor allem durch ihre Zielsetzung: Sie sind Sprachmodelle -- Systeme, die Wahrscheinlichkeiten über Tokenfolgen schätzen und dadurch Texte fortsetzen, bewerten oder erzeugen können. Der Verarbeitungsablauf folgt dabei einem wiederkehrenden Muster.
+Zunächst wird die Texteingabe in Token zerlegt. Token sind die kleinsten Verarbeitungseinheiten des Modells. je nach Tokenisierungsverfahren können dies Wörter, Wortteile oder einzelne Zeichen sein. Der Satz „Das System prüft den Status" wird beispielsweise in die Folge [„Das", „System", „prüft", „den", „Status"] überführt. Für Quellcode gilt dasselbe Prinzip: Identifier, Schlüsselwörter und Operatoren werden in Einheiten aufgeteilt @goodfellow2016dl.
+
+Die resultierende Tokenfolge bildet den Kontext des Modells. Der Kontext umfasst alle Token, die das Modell in einem Verarbeitungsschritt gleichzeitig berücksichtigt. Aktuelle Modelle besitzen Kontextfenster von mehreren tausend bis über eine Million Token. Eingaben, die dieses Fenster überschreiten, müssen segmentiert oder komprimiert werden.
+
+Auf Basis des Kontexts berechnet das Modell eine Wahrscheinlichkeitsverteilung über alle möglichen nächsten Token. Das gewählte Token wird an die bisherige Folge angefügt, und die erweiterte Folge dient als Eingabe für den nächsten Berechnungsschritt. Dieser Prozess wiederholt sich, bis ein Abbruchkriterium erreicht ist (z. B. ein Stopptoken oder eine maximale Ausgabelänge). Da das Modell jedes Token statistisch aus dem bisherigen Kontext ableitet, können Ausgaben sprachlich konsistent wirken, ohne dass fachliche Korrektheit gewährleistet ist. Formal lässt sich das Trainingsziel als Maximierung der bedingten Log-Likelihood beschreiben:
+
+$
+max_(theta) sum_(t=1)^T log p_(theta) (x_t mid x_(<t))
+$
+
+Hierbei bezeichnet $x_(<t)$ die bisherige Tokenfolge und $p_(theta)(x_t mid x_(<t))$ die vom Modell geschätzte Wahrscheinlichkeit für das nächste Token $x_t$.
+
+In der aktuellen Modellgeneration dominiert die Transformer-Architektur @vaswani2017attention, deren Kernmechanismus die Self-Attention ist. Self-Attention ermöglicht es dem Modell, bei der Verarbeitung jedes Tokens die Beziehungen zu allen anderen Token im Kontext zu gewichten. Formal wird dies als gewichtete Kombination von Value-Vektoren beschrieben, wobei die Gewichte aus Query-Key-Ähnlichkeiten berechnet werden #cite(<vaswani2017attention>):
+
+$
+op("Attention") (Q, K, V) = op("softmax") ((Q K^T) / sqrt(d_k)) V
+$
+/*
+#figure(
+  image("../../Abbildungen/abb_2_3_attention_heatmap.png", width: 85%),
+  caption: [Schematisches Beispiel einer Attention-Gewichtsmatrix (illustrativ).]
+)
+*/
+
+LLMs werden daher im Software Engineering eingesetzt, weil sie sowohl Artefakte in Prosa (z. B. Anforderungen, Kommentare) als auch Codeartefakte (z. B. Klassen, Funktionen, DB Schemata) verarbeiten können. Verscheidene Arbeiten  versuchen daher LLM-Anwendungen nach Aufgabenklassen wie Codegenerierung, Codezusammenfassung, Fehlersuche, Testgenerierung oder Dokumentation zu ordnen @fan2023llmse @salem2024surveyllmse @llm4se2024slr @llm4se2024survey
+
+_Aus den folgenden Eigenschaften der LLMs ergeben sich daher für diese Arbeit Konsequenzen:_
+
+_- *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._
+
+
+
+#heading(level: 3)[LLM Training 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 @openai2023gpt4.
+
+Im Engineering-Kontext ist der Prompt damit nicht nur Eingabe, sondern auch ein Steuerungsinstrument.\ Für diese Arbeit sind vor allem folgende Hebel relevant:
+
+- *Aufgabe:* 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?
+- *KI Leitplanken:* Belegpflicht, Kennzeichnung unsicherer Aussagen, feste Templates, DOs and DONTs.
+
+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. #cite(<lewis2020rag>, form: "prose") 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. #cite(<wei2022cot>, form: "prose") 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._
+/*
+#heading(level: 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 @roziere2023codellama. 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.
+*/
+#heading(level: 3)[Qualitätsrisko Halluzinationen]
+
+Halluzinationen bezeichnen Ausgaben, die syntaktisch korrekt und plausibel wirken, aber nicht durch Eingabedaten oder Weltwissen gedeckt sind. #cite(<ji2023hallucination>, form: "prose") liefern die Begrifflichkeit und diskutieren Detektions- und Lösungsansätze. Für Requirements ist die Gefahr besonders kritisch, weil falsche Requirements nicht als „Bug" auffallen, sondern als scheinbar saubere Spezifikation in Architektur- und Funktionsentscheidungen 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 @bender2021stochastic. Taucht eine falsche Aussage in Trainingsdaten häufig auf, wird sie vom Modell übernommen und als Wahrheit ausgegeben.
+- *Reproduzierbarkeit:* Kleine Promptänderungen oder Parameterunterschiede können zu unterschiedlichen Ergebnissen führen. Für einen engineeringfähigen Prozess sind daher Leitplanken (z. B. feste Templates, deterministische Einstellungen, versionierte Prompts) notwendig.
+
+_Für diese Arbeit folgt daraus, dass LLM-Ausgaben im Requirements-Kontext nicht als Wahrheit", sondern als Vorschlag zu behandeln sind. Erst durch Traceability (Belege) und Validierung (Expertenreview, Laufzeitchecks) wird aus einer Hypothese eine belastbare Anforderung._
+
+#heading(level: 3)[LLMs im Requirements Engineering: Stand der Forschung]
+
+Aktuelle Arbeiten untersuchen, wie LLMs Texte erzeugen, umformulieren und strukturieren können, und verschieben den Schwerpunkt damit gegenüber klassischen NLP/IR-Ansätzen mit begrenzten Ausgaben (Labels, Links, Hinweise) von reinen Analysen der Zusammenhänge hin zu tatsächlicher Fomrulierung von Requirements. Dieser Übergang ist aber nicht ohne Risiken: Einerseits entsteht ein großes Potential, andererseits steigt das Risiko, dass sprachlich "gute" Texte als Spezifikation akzeptiert werden, obwohl die fachliche Basis unzureichend oder fehlerhaft ist (siehe Haluzinationen) @ji2023hallucination @hemmat2025directions.
+
+Eine systematische Übersicht ordnet die LLM-Nutzung im RE dabei entlang klassischer Prozessschritte ein und nennt als wiederkehrende Problemfelder _Qualitätssicherung, Nachvollziehbarkeit und Domänenabhängigkeit_ @hemmat2025directions. Ein weiteres Review zum LLM-Einsatz im Requirements Engineering diskutiert den Einsatz entlang typischer RE-Aktivitäten (Analyse, Spezifikation, Validierung) und hebt als zentrale Herausforderungen inkonsistente Ergebnisse durch limitierte Kontextgrößen und begrenztes Domänenwissen hervor @marques2024chatgptre.
+
+Dabei lassen sich aktuelle LLM-Arbeiten grob folgenden Themen zusammenfassen:
+
+- *Strukturierung und (Re-)Formulierung von Requirements:* Untersucht wird, wie LLMs natürlichsprachliche Anforderungen in strukturiertere Formen überführen können @norheim2024structuring, sowie die automatische Umstrukturierung von Software Requirements Specifications mit dem Ziel, Standardkonformität zu erhöhen @okamoto2025restructuring.
+- *Qualitätsunterstützung und Analyse:* ChatGPT wurde für die Inkonsistenzdetektion in naturalsprachlichen Requirements evaluiert @fantechi2023inconsistency; weitere Arbeiten untersuchen LLM-gestützte Assistenz zur Verbesserung der Requirements-Vollständigkeit @luitel2024completeness.
+- *Anforderungserhebung (Elicitation) und Perspektivenwechsel:* LLMs können zur Generierung wertorientierter User Stories als "Inspirationsimpulse" eingesetzt werden @marczak2023humanvalue. Diese Richtung ist für Reverse Requirements Engineering insofern 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):* Betrachtet wurden LLMs bei der Engineering-Unterstützung von Safety Requirements im Kontext autonomen Fahrens @nouri2024safety sowie für rechtliche Compliance- und Regulationsanalyse @hassani2024legal. Solche Arbeiten verdeutlichen, dass LLMs nicht nur Text umformulieren, sondern auch regulatorische Anforderugen (Normen, Regeln) einbinden können.
+
+Insgesamt ist die Studienlage bisher uneinheitlich. Viele Arbeiten sind kurze Workshopbeiträge oder erste Vorstudien mit kleinen Datensätzen, die automatische Messungen mit Experteneinschätzungen mischen. Auch die verwendeten Prompts, Modellversionen und Einstellungen sind selten einheitlich dokumentiert, wodurch sich Ergebnisse schwer wiederholen lassen @fan2023llmse @hemmat2025directions. 
+
+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) herauslesen und 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.
+
+#heading(level: 3)[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 @fan2023llmse @hemmat2025directions. 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.
+
+#heading(level: 3)[Qualitätsbewertung und Messgrößen im Requirements-Kontext]
+
+Die Qualität von LLM-Ergebnissen wird in vielen Arbeiten mit allgemeinen Textmetriken oder aufgabenspezifischen Benchmarks bewertet. Für die Requirements-Extraktion aus Code reichen solche Metriken nicht aus, da es hier weniger um sprachliche Ähnlichkeit geht, sondern um fachliche Korrektheit, Prüfbarkeit und Nachvollziehbarkeit @hemmat2025directions @marques2024chatgptre. Eine sinnvolle Bewertung orientiert sich daher an RE-Kriterien und unterscheidet drei Dimensionen:
+
+- *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 @glinz2008quality und lässt sich auf Funktionsanforderungen übertragen.
+/*
+#heading(level: 3)[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 @fan2023llmse @ji2023hallucination. 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.
+*/

Kapitel/02_theoretischer_hintergrund/02_03_legacy_modernisierung.typ

@@ -0,0 +1,59 @@
+#heading(level: 2)[Legacy-Modernisierung und Stand der Forschung]
+
+#heading(level: 3)[Charakteristika von Legacy-Systemen]
+
+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 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.
+
+Damit wird nachvollziehbar, warum Requirements-Extraktion aus der Codebasis nicht nur ein Dokumentationsprojekt ist. Es dient zeitglich auch zur Risikoreduktion.
+
+#heading(level: 3)[Modernisierungsstrategien]
+
+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.
+
+_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:_
+
++ *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.
+
+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.
+
+#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. 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 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 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.
+- *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 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 LLM-Unterstützung bei Moderniesierungen steh im Vergleich zu klassischen Reengineering-Ansätzen noch an den Anfängen. Die Übersichten zu LLM4SE @fan2023llmse @llm4se2024slr zeigen, dass ein Teil der Arbeiten auf Codeverständnis, Dokumentation und Artefakttransformation zielt. Spezifisch für Requirements Engineering zeigen Reviews und SLRs erste konkrete Forschungsrichtungen @marques2024chatgptre @hemmat2025directions.
+
+Aus dieser Literatur lassen sich zwei Aussagen ableiten. Zum einen sind LLMs besonders stark in der Strukturierung und sprachlichen Formulierung. Also dort, wo aus heterogenen Artefakten 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).
+
+_Dies ist auch die Zentrale Motivation dieser Arbeit: 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._
+
+/*
+#heading(level: 3)[Zwischenfazit zu 2.3]
+
+Legacy-Modernisierung ist ein sozio-technisches Vorhaben, das technische Umbauten und fachliche Zielsetzungen integrieren muss @bisbal1999legacy @sneed1995planning. Moderne Zielarchitekturen (Web/Cloud) verschieben zudem die Anforderungslandschaft, weil Betriebs- und Sicherheitsanforderungen stärker in den Vordergrund treten @kratzke2017cloudnative @security2014legacycloud. 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.
+*/
+#heading(level: 3)[Kapitelzusammenfassung und Anschluss]
+
+Die drei Themenblöcke dieses Kapitels greifen ineinander. Requirements Engineering liefert Kriterien, um Anforderungen prüfbar und nachvollziehbar zu formulieren @iso29148_2018. Reverse Requirements Engineering überträgt diese Kriterien in einen Kontext, in dem Anforderungen aus bestehenden Artefakten rekonstruiert werden müssen. Large Language Models können bei dieser Rekonstruktion unterstützen, sind aber fehleranfällig und benötigen Prozesskontrollen, vor allem gegen Halluzinationen und Überinterpretation. Legacy-Modernisierung schließlich liefert die praktische Motivation und zeigt, warum eine belastbare Anforderungsbasis migrationskritisch ist @bisbal1999legacy @sneed1995planning.
+
+

Kapitel/03_fallstudie.typ

@@ -6,96 +6,85 @@
 
 #heading(level: 1)[Fallstudie c-entron GmbH (ca. 6 Seiten)]
 
-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.
+Dieses Kapitel beschreibt die Anwendung auf die sich diese Arbeit bezieht. Betrachtet wird die Windows-basierte ERP-Software der c-entron GmbH, die auf eine webbasierte Plattform überführt werden soll. Ziel ist es, die fachlichen und technischen Rahmenbedingungen so darzustellen, dass die Anforderungen an ein KI-gestütztes Reverse Requirements Engineering nachvollziehbar werden. Zunächst werden Unternehmenskontext und Legacy-Software eingeordnet, anschließend folgen Migrationsstrategie und spezifische Herausforderungen.
 
 #heading(level: 2)[Unternehmenskontext und Legacy-Software]
 
 #heading(level: 3)[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.
+Die c-entron GmbH (Ulm) entwickelt und betreibt eine ERP-Suite für IT-Systemhäuser. Die Software ist über mehrere Jahrzehnte gewachsen, der Funktionsumfang entsprechend breit. Mit der historischen Tiefe gehen produktionsnahe Sonderfälle und kundenbezogene Varianten einher, die im Tagesgeschäft funktionieren, aber nur teilweise dokumentiert sind.
 
-Für den Kontext dieser Arbeit sind drei Aspekte wesentlich:
+Für diese Arbeit ist die Software relevant, weil sie Anforderungen in einer Form enthält, die für Reverse Requirements Engineering typisch schwierig ist. Geschäftskritische Prozesse wie Auftragsabwicklung, Lager und Fakturierung sind nicht nur in einzelnen Masken abgebildet, sondern in Validierungen, Statusübergängen und Datenmodellrestriktionen verteilt. Hinzu kommt die Kopplung an weitere Anwendungen über Import- und Exportschnittstellen. Aus diesen Artefakten müssen für die Modernisierung stabile Geschäftsregeln und Datenbeziehungen abgeleitet werden, die als Grundlage einer webbasierten Neuimplementierung dienen.
 
-- **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.
+#heading(level: 3)[Technologischer Ist-Stand]
 
-#heading(level: 3)[Technologischer Ist-Stand (Legacy-Charakteristik)]
+Die ERP-Suite ist als Windows-Anwendung in klassischer Client/Server-Architektur über Jahrzehnte gewachsen. Für die Modernisierung sind nicht das Alter, sondern die Kopplung der Komponenten und die lückenhafte Dokumentation entscheidend. Folgende Merkmale sind für die Fallstudie besonders relevant:
 
-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 @bisbal1999legacy.
+- *Enge Kopplung zwischen UI, Fachlogik und Persistenz:* Geschäftsregeln sind nicht in einer Schicht isoliert, sondern verteilen sich über mehrere Komponenten. So liegen Validierungen im Frontend-Code, während weitere Regeln als Trigger in der MSSQL-Datenbank realisiert sind.
+- *Implizite Regeln in Code und Daten:* Ein Teil der Anforderungen ist nicht explizit dokumentiert, sondern ergibt sich aus Validierungen, Standardwerten und Datenmodellannahmen.
+- *Evolution über lange Zeiträume:* Funktionserweiterungen und Fehlerkorrekturen haben zu Sonderfällen und Workarounds geführt, die fachlich begründet, aber selten als Requirement festgehalten sind. Regeln zum gleichen Fachthema (z. B. Preisberechnung) werden auf unterschiedlichen Masken nicht einheitlich angewendet, was die genaue Definition der Regel erschwert.
+- *Heterogene Artefakte:* Neben Quellcode existieren Konfigurationen, UI-Texte, Reportdefinitionen sowie Import- und Exportlogiken, die Anforderungen indirekt spiegeln.
 
-Für die Fallstudie lassen sich die folgenden, für Requirements-Rückgewinnung relevanten Charakteristika bündeln:
+Die Software ist damit ein geeigneter Gegenstand für Reverse Requirements Engineering. Die Anforderungen liegen nicht als gesammelte Dokumentation vor, sondern müssen erst rekonstruiert werden.
-
-- **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.
 
 #heading(level: 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 @iso29148_2018 @ieee830_1998. Im Fallunternehmen sind solche Artefakte nicht in ausreichender Tiefe verfügbar, sodass wesentliche Informationen in folgenden Quellen gebunden sind:
+Für das Modernisierungsvorhaben liegt keine schriftliche Anforderungsdokumentation vor. Vollständigkeit, Verifizierbarkeit und Traceability als zentrale Qualitätskriterien des Requirements Engineering müssen daher aus anderen Quellen hergestellt werden. Fachliche Regeln sind primär in der *Implementierung und im Laufzeitverhalten* gebunden. Änderungsanlässe, Bugfixes und Kundenanpassungen lassen sich ergänzend aus der *Change-Historie* in Issue-Tracker, Commits und Releases rekonstruieren. Ein wesentlicher Teil liegt zudem als *Erfahrungswissen einzelner Mitarbeiter* vor; dieses Domänenwissen ist personenbezogen und stellt ein Risiko bei Personalwechsel dar.
 
-- **Implementierung und Laufzeitverhalten:** Fachliche Regeln werden praktisch durch Codepfade und Datenzustände realisiert.
+_Für diese 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 mit Referenz zu existierenden Artefakten, die als Requirement prüfbar sind und die spätere Migration absichern._
-- **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.
 
 #heading(level: 3)[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:
+Für das Vorgehen in den folgenden Kapiteln ist es hilfreich, die vorhandenen Artefakte zu ordnen. In der ERP-Modernisierung sind insbesondere folgende Artefaktklassen Träger von Requirements:
 
-1. **Quellcode:** Implementierte Regeln, Berechtigungen, Statuslogik, Datenzugriffe.
+1. *Quellcode:* Implementierte Regeln, Berechtigungen, Statuslogik, Datenzugriffe.
-2. **Konfiguration und Parameter:** Feature-Schalter, Mandantenparameter, systemweite Defaults.
+2. *Konfiguration und Parameter:* Feature-Schalter, Mandantenparameter, systemweite Defaults.
-3. **UI- und Reportartefakte:** Feldbezeichnungen, Validierungstexte, Druck-/Exportformate.
+3. *UI- und Reportartefakte:* Feldbezeichnungen, Validierungstexte, Druck- und Exportformate.
-4. **Datenstrukturbezogene Artefakte:** Datenmodelle, Constraints, Referenzen, historisierte Strukturen.
+4. *Datenstrukturbezogene Artefakte:* Datenmodelle, Constraints, Referenzen, historisierte Strukturen.
-5. **Projektartefakte:** Tickets, Release Notes, Testfälle, Migrationsnotizen.
+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.
+Quellcode und Datenstrukturen liefern den belastbarsten Beleg für eine Regel, während Tickets und Release Notes vor allem den Anlass einer Änderung dokumentieren. Die fachliche Validierung wird gezielt auf risikoreiche oder unsichere Aussagen gelenkt.
 
 #heading(level: 2)[Migrationsstrategie und spezifische Herausforderungen]
 
-#heading(level: 3)[Zielbild der Modernisierung]
+#heading(level: 3)[Ziel 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 @iso25010_2011.
+Ziel der Modernisierung ist eine webbasierte SaaS-Plattform, die sowohl Cloud- als auch On-Premise-Betrieb unterstützt. Neben der Funktionsäquivalenz zur bestehenden ERP-Suite stehen nicht-funktionale Anforderungen wie Skalierbarkeit, Mandantenfähigkeit und KI-Anbindung im Vordergrund. Konkret leiten sich für das Fallunternehmen die folgenden Anforderungen ab:
 
-Aus Sicht des Fallunternehmens ist das Zielbild in drei Dimensionen zu konkretisieren:
+- *Cloud- und On-Premise-Fähigkeit:* Die Anwendung wird containerisiert ausgeliefert und ist damit unabhängig von einem bestimmten Infrastrukturanbieter. Neben dem zentralen SaaS-Betrieb bleibt eine Einzelinstallation beim Kunden möglich.
+- *Multi-Tenant-Fähigkeit:* Mehrere Mandanten teilen sich eine gemeinsame Datenbank, sodass auch kleinere Kunden ohne vollen Installationsaufwand bedient werden können. Für größere Kunden ist weiterhin eine Einzelinstallation vorgesehen.
+- *Datenbanksystem-Unabhängigkeit:* Geschäftslogik und Abfragen werden möglichst vollständig im Code abgebildet und nicht im DBMS. Damit sinken Migrationsaufwände, und im Multi-Tenant-Betrieb lassen sich günstige oder kostenlose Datenbanksysteme einsetzen.
+- *Skalierbarkeit:* Das Backend ist über Microservices und Load-Balancing horizontal skalierbar, um auch bei größeren Kunden performant zu bleiben.
+- *KI-Fähigkeit:* Schnittstellen zu KI-Systemen (z. B. MCP-Server, RAG-Embeddings) sind von Beginn an in der Architektur vorgesehen.
+- *Web-Frontend:* Eine responsive Web-Oberfläche ermöglicht die geräteübergreifende Nutzung.
+- *Zentrale Stammdatenverwaltung:* Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Anker für weitere Produkte der Firma.
 
-- **Benutzeroberfläche und Interaktion:** Webbasierte Oberflächen, Rollen- und Rechtekonzepte, konsistente Navigation.
+Als Performance-Ziel wird ein Sweetspot von 5 bis 100 gleichzeitigen Nutzern pro Mandant festgelegt (Priorität 1). Kleinere Installationen mit 1 bis 5 Nutzern (Priorität 2) sowie größere Installationen oberhalb von 100 Nutzern (Priorität 3) werden ebenfalls unterstützt.
-- **Betriebsmodell und Deployment:** Automatisierte Bereitstellung, Skalierung, Updatefähigkeit und Wartbarkeit über Releases.
-- **Integrationen und Daten:** Stabilisierung von Schnittstellen, Datenmigration und Sicherstellung konsistenter Geschäftsobjekte.
 
 #heading(level: 3)[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 @sneed1995planning @bisbal1997overview. 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.
+Migrationsstrategien für Legacy-Software reichen von leichtgewichtigen Ansätzen wie Rehosting bis zur schrittweisen Neuimplementierung zentraler Funktionen. Gegenstand dieser Arbeit ist nicht die vollständige Migrationsplanung, 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 Implementierungsentscheidungen der Zielplattform werden nur insoweit diskutiert, als sie Requirements beeinflussen, etwa bei Sicherheits- und Betriebsanforderungen. Die technische Migration selbst — Datenmigration, Refactoring im Detail oder Release-Planung — wird als Rahmenbedingung verstanden und in späteren Kapiteln methodisch adressiert.
-
-- 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.
 
 #heading(level: 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:
+Aus dem Ist-Zustand ergeben sich mehrere Herausforderungen, die das Vorgehen des Reverse Requirements Engineering unmittelbar prägen:
 
-- **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.
+- *Funktionsäquivalenz mit Randfällen:* Ein erheblicher Teil des Systemwertes steckt in implementierten Ausnahmen und Prozessvarianten. Diese sind im Code zwar nachvollziehbar, aber selten dokumentiert; Traceability und Validierung haben damit hohe Priorität.
-- **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.
+- *Implizite Geschäftsregeln:* Geschäftslogik ist häufig als Prüf- und Statuslogik realisiert. Ohne strukturierte Extraktion droht, 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.
+- *Datenzentrierte Domäne:* ERP-Funktionalität ist eng mit Datenobjekten und historisierten Zuständen verbunden. Anforderungen müssen daher auch als Daten- und Integritätsanforderungen formuliert werden, nicht nur UI-nah.
-- **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 @security2014legacycloud.
+- *Nicht-funktionale Anforderungen:* Mit der webbasierten Zielplattform steigen die Anforderungen an Sicherheit, Verfügbarkeit und Observability. Insbesondere Identitätsmanagement und Datenflusskontrolle sind in Legacy-to-Cloud-Migrationen wiederkehrende Problemfelder.
-- **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.
+- *Organisatorische Randbedingungen:* Ressourcen für manuelle Analyse sind begrenzt und an erfahrene Mitarbeiter gebunden. Die Analysearbeit muss skalierbar und ihre Ergebnisse müssen reproduzierbar sein.
 
 #heading(level: 3)[Konsequenzen für das Vorgehen in dieser Arbeit]
 
-Aus den genannten Herausforderungen ergeben sich konkrete Anforderungen an das in Kapitel 4 entwickelte Vorgehen:
+Aus den 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).
+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.
+2. *Explizite Unsicherheitskennzeichnung:* Aussagen, die nicht eindeutig aus Artefakten ableitbar sind, werden als Hypothesen markiert und priorisiert validiert.
-3. **Segmentierung und Kontextsteuerung:** Da Artefakte verteilt sind, ist eine systematische Auswahl relevanter Kontexte notwendig, um Überinterpretation zu reduzieren.
+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.
+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 die Claude-Code-basierte Durchfuehrung, Kapitel 5 dokumentiert die Ergebnisse der Versuche, und Kapitel 6 evaluiert die Eignung im Fallkontext der c-entron GmbH.
+Im nächsten Kapitel werden das methodische Vorgehen und die Claude-Code-basierte Durchführung beschrieben. Kapitel 5 dokumentiert die Ergebnisse der Versuche, Kapitel 6 evaluiert die Eignung im Fallkontext der c-entron GmbH.

Masterarbeit_draft.typ

@@ -4,7 +4,7 @@
   "KI-gestütztes Reverse Requirements Engineering bei Legacy-Software",
   "Masterarbeit an der Hochschule Neu-Ulm",
   "Christoph Schwörer",
-  "Master of Science",
+  "Master of Business Administration",
   "Prof. Dr. Daniel Schallmo",
   "XX 2026"
 )

Versuche/Versuch 04/Prompts

@@ -0,0 +1,46 @@
+Prompt 1:
+
+1. Lies alle Dateien in \Versuche.
+2. Schau dir die Datei @ERP_WEB/UseCases_Short.md genau an. Gibt es Usecases in den anderen Dateien die hier nicht erwähnt sind? Ignoiere alle Usecases zu Produktionsplanung und TicketManagement
+
+-----
+Return1.md
+
+----- 
+Prompt 2
+
+1, 2 , 3, sind ok der Rest nur leidlich. Erstelle die Liste nochmal neu. Ignoriere dabei alles zu RMM anbindung (Asset Management generell ist ok), Validierungsregeln und REST API. Es geht hierbei darum die Anwendungs Funktion der Software abzubilden. API Endpunkte oder Valididerung sind konkrete implementierungen....
+
+-----
+Return2.md
+
+-----
+Prompt 3
+Dann kopiere UseCases_short.md zu UseCases_short_V2.md und füge die neuen Usecases an passender Stelle ein
+
+----
+Return3.md
+
+----
+UseCases_Short_V2.md
+
+-----
+Prompt 4
+Erstelle jetzt eine neue Datei UseCases_long.md und schreibe eine Ausführliche Beschreibung der UseCases in @ERP_WEB/UseCases_Short_V2.md . Konzentriere dich auf die Funktionalen Bestandteile. In der Beschreibung soll kein Code oder technische implementierung vorkommen. 
+
+----
+Prompt5
+Kannst du das Pro Usecase auch so aufsplitten und nicht als prosa schreiben? Bitte auch alle Usecases hierfür nochmal mit der vollen Doku in \Versuche inhaltlich abgleichen. 
+
+Jeder Use Case beschreibt aus Anwendersicht:
+Was der Benutzer tut
+Warum er es tut (Geschäftszweck)
+Was das erwartete Ergebnis ist
+
+
+-----
+Prompt6
+Erstelle noch ein Inhaltsverzeichnis
+
+------
+Usecases_Long.md

Versuche/Versuch 04/Return1.md

@@ -0,0 +1,97 @@
+# Use-Case-Vergleich: UseCases_Short.md vs. andere Dateien
+
+## Referenz-Datei: ERP_WEB/UseCases_Short.md
+- **748 Use Cases** in 17 Modulen (1-17)
+- Deckt ab: Abrechnung, Administration, Adressen/CRM, Automatisierung, Buchhaltung, Controlling, Einkauf, Verkauf, Helpdesk, MyCentron, Logistik, Stammdaten, Vertraege, CentronNexus, Asset Management, Terminverwaltung, State Machines & Wizards
+
+> **Hinweis**: Use Cases zu **Produktionsplanung** und **TicketManagement** wurden wie gewuenscht ignoriert.
+
+---
+
+## Fehlende Use Cases (in anderen Dateien vorhanden, NICHT in UseCases_Short.md)
+
+### 1. Aus `ERP_WEB/FOLGEMEETING_VORBEREITUNG.md`
+
+| UC-ID | Titel | Bemerkung |
+|-------|-------|-----------|
+| **UC-021** | **Warenausgang (Goods Issue/Outbound)** | Kein eigener Use Case in UseCases_Short - nur Kommissionierung (11.4) und Versand sind abgedeckt, aber nicht explizit "Warenausgang" als eigenstaendiger Prozess |
+| **UC-022** | **Bestandsverwaltung (Inventory Management)** | Inventur (11.3) ist vorhanden, aber allgemeine Bestandsverwaltung (Umbuchungen, Bestandskorrekturen, Mindestbestandswarnungen) fehlt als eigene Kategorie |
+| **UC-031** | **Aktivitaeten (CRM Activities)** | Aktivitaets-Tracking (Anrufe, Besuche, Emails, Notizen) als CRM-Funktion fehlt komplett in UseCases_Short |
+| **UC-032** | **Anfragen/Leads (Inquiries/Leads)** | Lead-Management, Lead-Qualifizierung, Lead-Konvertierung zu Angebot/Kunde fehlt komplett |
+| **UC-041** | **Automatische Abrechnung (Automatic Billing)** | Zwar ist Vertragsabrechnung (1.1) vorhanden, aber ein uebergreifender Use Case fuer automatisierte/zeitgesteuerte Abrechnung ohne manuellen Eingriff fehlt |
+| **UC-042** | **Workflow-Engine (allgemein)** | Eine generische Workflow-Engine als eigener Use Case (nicht nur Ticket-Prozesse oder Freigaben) fehlt |
+| **UC-052** | **OPOS-Import (Bestandsabgleich)** | OPOS (5.5) deckt offene Posten ab, aber ein spezifischer Import/Sync-Use-Case fuer Bestandsabgleich mit externen Systemen fehlt |
+| **UC-060** | **Umsatzreporting** | Analytics (6.1) hat Verkaufsstatistik, aber ein dedizierter Umsatzreport (nach Perioden, Filialen, Produktgruppen, Vergleich) fehlt als eigenstaendiger UC |
+| **UC-061** | **Lagerwert-Report** | Lagerbestandsentwicklung (6.1.8) ist erwaehnt, aber ein spezifischer Lagerwert-Report (Bewertung, Abschreibung, Slow-Mover) fehlt |
+| **UC-062** | **Aufwand/Kosten-Analyse** | Kostentraeger/Kostenstellen (12.3) existiert, aber eine uebergreifende Aufwand/Kosten-Analyse fehlt |
+| **UC-070** | **Kundenbereich Read-Only (Kundenportal)** | Ein Self-Service-Kundenportal (Rechnungen einsehen, Tickets erstellen, Vertraege sehen) fehlt komplett in UseCases_Short |
+
+### 2. Aus `Versuch 03/ERP_DOCUMENTATION/USE_CASES_STATE_MACHINES.md`
+
+| UC-ID | Titel | Bemerkung |
+|-------|-------|-----------|
+| **UC-018** | **Item Lost During Inventory Count** | Artikel-Verlust waehrend Inventur - nicht in UseCases_Short (17.3 hat nur Retoure, Verschrottung, Umbuchung, Ersatz) |
+| **UC-021** | **Batched Item Processing - Intake to Stock** | Batch-Wareneingang (mehrere Artikel gleichzeitig einlagern) - fehlt als eigener Workflow |
+| **UC-022** | **Item Condition Change & Metadata Update** | Zustandsaenderung eines Artikels (z.B. von "Neu" auf "Gebraucht") - fehlt |
+| **UC-023** | **Serial Number Discrepancy Resolution** | Seriennummer-Abweichung klaeren - fehlt |
+| **UC-024** | **Deactivation of Demo Unit** | Demo-Geraet deaktivieren/ausmustern - fehlt |
+| **UC-030** | **CRM Project Lifecycle - Successful Close** | CRM-Projekte (3.3) haben CRUD, aber der vollstaendige Lifecycle als State Machine (Opportunity -> Proposal -> Negotiation -> Won/Lost) fehlt |
+
+### 3. Aus `ERP_DOCUMENTATION/USE_CASES_WIZARD_WORKFLOWS.md`
+
+| Bereich | Fehlende Use Cases | Bemerkung |
+|---------|-------------------|-----------|
+| **Fehlerbehandlung Abrechnung** | Billing mit fehlenden Mengen erkennen und korrigieren; Barcode-Varianz-Override; E-Mail-Versandfehler mit Retry; Druckerverbindungsfehler mit PDF-Fallback; Teilweise erfolgreiche Abrechnung mit Error-Logging; Kontingent-Erschoepfungswarnung und Billing-Pause | UseCases_Short hat keine Error-Recovery-Szenarien fuer die Abrechnung |
+| **Reporting Abrechnung** | Abrechnungsvorschau-Verifizierung vor Versand; Post-Billing Abstimmungsbericht | Fehlt als eigenstaendiger Workflow |
+| **Kontingent-Details** | Monatliches Geld-Kontingent mit Overbooking; Stunden-Kontingent fuer Dienstleister; Quartals-Kontingent mit Warengruppen-Zuordnung; Kontingent-Uebertrag in naechste Periode; Gratis-Perioden-Zuweisung (Promotion); Kontingent-Umverteilung waehrend Vertragslaufzeit | UseCases_Short (17.6) hat nur 4 generische Kontingent-UCs, die Wizard-Datei hat 7 spezifische Szenarien |
+| **Preise & Rabatte** | Stufen-Volumenrabatt; Warengruppen-Mengenpreise; Artikelspezifische Preis-Ueberschreibung; Stundenzuschlaege (Arbeitsstufen); Kombinations-Preisregeln; Erweiterte bedingte Preisgestaltung | UseCases_Short (17.8.7) hat nur "Preis- und Rabattstrukturen" als einen einzigen UC |
+| **SLA-Details** | Quartalmaessige praeventive Wartung; 24/7 Notfallsupport (2h Reaktionszeit); Geschaeftszeiten-Support (4h Response); Bedarfs-Wartung; Multi-Tier SLA (Gold/Silber/Bronze) | UseCases_Short (17.8.8) hat nur einen generischen SLA-UC |
+
+### 4. Aus `ERP_DOCUMENTATION/USE_CASES_ASSET_MANAGEMENT.md`
+
+| Bereich | Fehlende Use Cases | Bemerkung |
+|---------|-------------------|-----------|
+| **AD-Benutzerausschluss-Details** | Ausschluss nach SamAccountName; Ausschluss nach ObjectSID; Ausschlusstyp aendern; Benutzer wieder einschliessen; Bestehenden Ausschluss bearbeiten | UseCases_Short (15.4) hat 5 generische UCs, die Detaildatei beschreibt spezifischere Szenarien |
+| **RMM-Artikeltyp-Details** | 20+ spezifische Check-Types (CPU, Memory, Disk, Backup, Antivirus, Patch Status, etc.) | UseCases_Short (15.3) hat nur 5 generische UCs |
+
+### 5. Aus `Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md`
+
+Diese Meta-Analyse identifiziert **1.211 undokumentierte Use Cases** (71% Luecke). Die wichtigsten fehlenden Bereiche (ohne Produktionsplanung und TicketManagement):
+
+| Bereich | Geschaetzte fehlende UCs | Status in UseCases_Short |
+|---------|--------------------------|--------------------------|
+| **Quality/Compliance** | ~25 Use Cases | KOMPLETT FEHLEND - Qualitaetskontrolle, Zertifizierungen, Sicherheitschecklisten |
+| **Social Media & Marketing** | ~10 Use Cases | KOMPLETT FEHLEND - Social Feeds, Accounts, Posts, Engagement |
+| **Data Exchange/EDI (erweitert)** | ~50 Use Cases | Nur minimal dokumentiert (7.3 hat 6 UCs, aber 40+ DB-Tabellen existieren) |
+| **Validierungsregeln** | ~381 Regeln | 431 Regeln im Code, nur 50 dokumentiert |
+| **REST API Endpunkte** | ~254 Endpunkte | 284 Endpunkte existieren, nur ~30 durch UCs abgedeckt |
+
+---
+
+## Zusammenfassung: Komplett fehlende Themen in UseCases_Short.md
+
+### Kategorie A: Ganz neue Module/Bereiche (nicht erwaehnt)
+1. **Kundenportal / Self-Service** (UC-070) - Kunden koennen Rechnungen, Tickets, Vertraege einsehen
+2. **CRM Aktivitaeten-Tracking** (UC-031) - Anrufe, Besuche, E-Mails, Notizen als CRM-Aktivitaeten
+3. **Lead-Management** (UC-032) - Anfragen, Leads, Qualifizierung, Konvertierung
+4. **Quality & Compliance** - Sicherheitschecklisten, Materialpruefung, Umweltanforderungen, Audits
+5. **Social Media Management** - Social Feeds, Accounts, Posts, Kommentare, Engagement
+
+### Kategorie B: Existierende Module mit fehlender Tiefe
+6. **Warenausgang** (UC-021) - als eigenstaendiger Prozess neben Kommissionierung
+7. **Allgemeine Bestandsverwaltung** (UC-022) - Umbuchungen, Korrekturen, Mindestbestaende
+8. **Workflow-Engine** (UC-042) - generische Workflow-Automatisierung
+9. **Lagerwert-Reporting** (UC-061) - Bewertung, Slow-Mover, Abschreibung
+10. **Aufwand/Kosten-Analyse** (UC-062) - uebergreifende Analyse
+11. **Abrechnungs-Fehlerbehandlung** - 6 Recovery-Szenarien aus Wizard-Workflows
+12. **Kontingent-Szenarien** - 7 spezifische Szenarien vs. 4 generische in UseCases_Short
+13. **Preis-/Rabattstrukturen** - 6 spezifische Szenarien vs. 1 generischer UC
+14. **SLA-Szenarien** - 5 spezifische Szenarien vs. 1 generischer UC
+15. **Artikel-Lifecycle-Erweiterungen** - Verlust, Batch-Eingang, Zustandsaenderung, SN-Abweichung, Demo-Deaktivierung
+16. **CRM-Projekt-Lifecycle** - als vollstaendige State Machine
+17. **Automatische Abrechnung** (UC-041) - zeitgesteuert ohne manuellen Eingriff
+
+### Anzahl fehlender Use Cases (geschaetzt)
+- **Kategorie A (neue Bereiche)**: ~50-70 Use Cases
+- **Kategorie B (fehlende Tiefe)**: ~40-50 Use Cases
+- **Gesamt**: ~90-120 Use Cases fehlen in UseCases_Short.md

Versuche/Versuch 04/Return2.md

@@ -0,0 +1,232 @@
+# Use-Case-Vergleich: UseCases_Short.md vs. andere Dateien
+
+## Referenz-Datei: ERP_WEB/UseCases_Short.md
+- **748 Use Cases** in 17 Modulen (1-17)
+- Deckt ab: Abrechnung, Administration, Adressen/CRM, Automatisierung, Buchhaltung, Controlling, Einkauf, Verkauf, Helpdesk, MyCentron, Logistik, Stammdaten, Vertraege, CentronNexus, Asset Management, Terminverwaltung, State Machines & Wizards
+
+> **Ignoriert**: Produktionsplanung, TicketManagement, RMM-Anbindung, REST API Endpunkte, Validierungsregeln
+
+---
+
+## Fehlende Anwendungsfunktionen (in anderen Dateien, NICHT in UseCases_Short.md)
+
+### A. Komplett fehlende Funktionsbereiche
+
+#### A1. Kundenportal / Self-Service (UC-070)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Ein kundengerichtetes Portal, in dem Kunden (nicht Mitarbeiter!) ihre Daten einsehen koennen:
+- Beleg-Uebersicht (Rechnungen, Lieferscheine, Angebote)
+- Zahlungshistorie
+- Kontaktinformationen
+- Optional: Tickets erstellen/einsehen
+
+**Abgrenzung**: CentronNexus (Modul 14) ist das **interne** Web-Portal fuer Mitarbeiter. Das Kundenportal ist eine voellig andere Zielgruppe.
+
+---
+
+#### A2. CRM-Aktivitaeten (UC-031)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Erstellen und Verwalten von CRM-Aktivitaeten als eigene Entitaet:
+- Anrufe protokollieren
+- Kundenbesuche dokumentieren
+- E-Mail-Korrespondenz verknuepfen
+- Notizen/Vermerke erstellen
+- Wiedervorlagen/Follow-ups planen
+- Aktivitaeten einem Kunden zuordnen
+
+**Abgrenzung**: UC 3.1.4 "Adresse mit Aktivitaetshistorie anzeigen" zeigt nur die Historie an - es gibt keinen Use Case fuer das ERSTELLEN und VERWALTEN von Aktivitaeten.
+
+---
+
+#### A3. Lead-Management / Anfragen (UC-032)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Der gesamte Prozess von der Anfrage bis zum Angebot:
+- Anfrage/Lead erfassen (Webformular, Telefon, Messe)
+- Lead qualifizieren (Interessensprofil, Budget, Dringlichkeit)
+- Lead-Status tracken (Neu, Kontaktiert, Qualifiziert, Verloren)
+- Lead zu Angebot/Kunde konvertieren
+
+**Abgrenzung**: CRM-Projekte (3.3) beginnen erst bei einem konkreten Projekt. Der fruehe Vertriebstrichter (Lead -> Opportunity) fehlt.
+
+---
+
+#### A4. Arbeitssicherheit / Qualitaets-Compliance
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen vorhanden**: AGArbeitssicherheit, AGMaterial, AGUmweltschutz, AGPrufvorschrift, ArtikelAGArbeitssicherheit, ArtikelAGMaterial, Arbeitssicherheit
+**Was fehlt**: Ein ganzes Modul fuer Arbeits-/Qualitaetssicherheit:
+- Sicherheitschecklisten pro Arbeitsplatz/Taetigkeit verwalten
+- Materialsicherheit dokumentieren (Gefahrstoffe, Umgang)
+- Umweltschutzanforderungen erfassen und pruefen
+- Pruefvorschriften fuer Artikel/Materialien definieren
+- Arbeitssicherheits-Audits durchfuehren und dokumentieren
+- Compliance-Berichte fuer ISO-Zertifizierungen generieren
+
+**Hinweis**: Nicht zu verwechseln mit den Compliance-Erwaenungen in UseCases_Short (DSGVO 2.2, Report-Compliance 12.7.5 etc.) - dort geht es um Daten-Compliance. Hier geht es um **physische Arbeitssicherheit und Materialqualitaet**.
+
+---
+
+#### A5. Social-Media-Management
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen vorhanden**: SocialMediaStream, SocialMediaStreamAccount, SocialMediaAction, SocialMediaComment, SocialMediaLike
+**Was fehlt**:
+- Social-Media-Accounts verknuepfen (Facebook, Twitter, LinkedIn)
+- Social-Media-Feeds ueberwachen
+- Posts planen und veroeffentlichen
+- Kommentare und Interaktionen verwalten
+- Engagement-Metriken analysieren
+- Leads aus Social Media generieren
+
+---
+
+### B. Fehlende Funktionen in bestehenden Modulen
+
+#### B1. Warenausgang (UC-021)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Logistik (11)
+**Was fehlt**: Der Warenausgang als eigenstaendiger Prozess:
+- Lagerausbuchung bei Lieferschein-Erstellung
+- FIFO-/Seriennummern-Auswahl beim Ausbuchen
+- Bestandsaktualisierung nach Warenausgang
+- Warenausgangs-Protokoll/Beleg
+
+**Abgrenzung**: Kommissionierung (11.4) ist das Zusammenstellen der Ware. Warenausgang ist die tatsaechliche Bestandsreduzierung und Buchung.
+
+---
+
+#### B2. Allgemeine Bestandsfuehrung (UC-022)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Logistik (11)
+**Was fehlt**: Laufende Bestandsverwaltung zwischen Inventuren:
+- Lagerbestandsabfrage (Menge, Reserviert, Verfuegbar)
+- Lagerumbuchung zwischen Lagerorten
+- Manuelle Bestandskorrektur mit Begruendung
+- Mindestbestandswarnungen
+- Bestandsabstimmung (Soll/Ist-Vergleich)
+
+**Abgrenzung**: Inventur (11.3) ist die periodische Zaehlung. Bestandsfuehrung ist der taegliche Umgang mit Bestaenden.
+
+---
+
+#### B3. Lagerwert-Report (UC-061)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Controlling (6)
+**Was fehlt**: Ein dedizierter Lagerwert-Bericht:
+- Bestaende x Einstandspreis = Lagerwert
+- FIFO- vs. Durchschnittsbewertung
+- Slow-Mover-Identifikation
+- Abweichungsanalyse (Bewertungsdifferenzen)
+- Lagerwert-Entwicklung ueber Zeit
+
+**Abgrenzung**: UC 6.1.8 "Lagerbestands-Entwicklung und Umschlag" erwaehnt Mengen, aber nicht die wertmaessige Betrachtung (Lagerbewertung, Slow-Mover, FIFO).
+
+---
+
+#### B4. Aufwand/Kosten-Analyse (UC-062)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Controlling (6)
+**Was fehlt**: Uebergreifende Aufwands- und Kostenanalyse:
+- Zeitaufwand pro Kunde/Projekt aggregieren
+- Kostenvergleich: geplant vs. tatsaechlich
+- Gewinnmarge pro Projekt/Kunde berechnen
+- Aufwand/Kosten-Report exportieren
+
+**Abgrenzung**: Kostentraeger/Kostenstellen (12.3) ist Stammdaten-Verwaltung. Hier geht es um die analytische Auswertung.
+
+---
+
+#### B5. Automatische Abrechnung (UC-041)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Abrechnung (1) / Automatisierung (4)
+**Was fehlt**: Zeitgesteuerte Abrechnung ohne Benutzereingriff:
+- Regelmaessige Abrechnungsjobs konfigurieren (taeglich, woechentlich, monatlich)
+- MSP-Gebuehren automatisch fakturieren
+- Vertragsgebundene Abrechnungen nach Intervall ausfuehren
+- Ergebnis-Benachrichtigung an Sachbearbeiter
+
+**Abgrenzung**: Modul 1.1 (Vertragsabrechnung) ist ein Wizard, den ein Benutzer manuell durchlaeuft. UC-041 beschreibt die vollautomatische Abrechnung im Hintergrund.
+
+---
+
+#### B6. Abteilungstaetigkeiten
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen**: AbtTaetigkeiten, AbtTaetigkeitenZuordnung
+**Modul**: Administration (2.14)
+**Was fehlt**: Verwaltung von Taetigkeiten pro Abteilung:
+- Taetigkeitsprofile definieren (z.B. "Vertrieb Innendienst", "Service Aussendienst")
+- Mitarbeiter Taetigkeiten zuordnen
+- Taetigkeiten fuer Kapazitaetsplanung nutzen
+
+**Abgrenzung**: Abteilungsverwaltung (2.14) hat nur "Abteilung erstellen" und "Abteilung zuordnen". Die Taetigkeitsebene fehlt.
+
+---
+
+#### B7. Artikel-Lifecycle-Sonderfaelle
+**Quelle**: USE_CASES_STATE_MACHINES.md
+**Modul**: State Machines (17.3)
+**Was fehlt in 17.3** (dort nur: Retoure, Verschrottung, Umbuchung, Ersatz):
+- **Artikel verloren bei Inventur** - Buchung und Dokumentation wenn ein Artikel bei der Inventur nicht auffindbar ist
+- **Seriennummer-Abweichung** - Workflow wenn gescannte SN nicht mit erwarteter SN uebereinstimmt
+- **Demo-Geraet deaktivieren** - Spezial-Lifecycle fuer Demo-/Leihgeraete (Aktiv -> Rueckruf -> Aufbereitung -> Wiederverwendung/Entsorgung)
+- **Artikel-Zustandsaenderung** - Aenderung des Zustands (Neu -> Gebraucht, Repariert -> Einsatzbereit)
+- **Batch-Wareneingang** - Einlagerung mehrerer Artikel gleichzeitig (z.B. nach Paletten-Lieferung)
+
+---
+
+#### B8. CRM-Projekt als vollstaendiger Lifecycle
+**Quelle**: USE_CASES_STATE_MACHINES.md (UC-030)
+**Modul**: CRM-Projekte (3.3)
+**Was fehlt**: Die State Machine des CRM-Projekts:
+- Status-Uebergaenge: Opportunity -> Proposal -> Negotiation -> Won/Lost
+- Automatische Eskalation bei Inaktivitaet
+- Win/Loss-Analyse nach Abschluss
+- Pipeline-Ansicht aller Projekte nach Status
+
+**Abgrenzung**: Modul 3.3 hat CRUD-Operationen und "als verloren markieren" (3.3.7), aber den vollstaendigen Sales-Pipeline-Lifecycle mit Statusuebergaengen und Analyse nicht.
+
+---
+
+#### B9. Kontingent-Szenarien (Vertiefung)
+**Quelle**: USE_CASES_WIZARD_WORKFLOWS.md
+**Modul**: Kontingent-State-Machine (17.6)
+**Was fehlt** (17.6 hat nur 4 generische UCs):
+- Geld-Kontingent mit Overbooking-Regelung
+- Stunden-Kontingent fuer Dienstleister
+- Quartals-Kontingent mit Warengruppen-Zuordnung
+- Kontingent-Uebertrag in Folgeperiode
+- Gratis-Perioden (Promotions)
+- Kontingent-Umverteilung waehrend Vertragslaufzeit
+
+---
+
+#### B10. Workflow-Engine / Automatisierungsregeln (UC-042)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Automatisierung (4)
+**Was fehlt**: Eine generische Workflow-Engine:
+- Trigger definieren: Beleg-Status, Datumsregeln, Betragschwellen
+- Aktionen konfigurieren: E-Mail senden, Report generieren, Daten aendern, Aufgabe erstellen
+- Bedingungslogik (Wenn-Dann-Sonst)
+- Workflow-Ketten (Aktion A loest Aktion B aus)
+
+**Abgrenzung**: "Erwartete Events" (4.1/4.2) deckt Event-basierte Triggers ab. Die generische Workflow-Engine geht darueber hinaus - sie verkettet Aktionen und hat Bedingungslogik.
+
+---
+
+## Zusammenfassung
+
+| # | Fehlende Funktion | Typ | Quelle |
+|---|-------------------|-----|--------|
+| **A1** | Kundenportal / Self-Service | Neues Modul | FOLGEMEETING |
+| **A2** | CRM-Aktivitaeten | Neues Modul | FOLGEMEETING |
+| **A3** | Lead-Management | Neues Modul | FOLGEMEETING |
+| **A4** | Arbeitssicherheit / Qualitaets-Compliance | Neues Modul | DB-Schema |
+| **A5** | Social-Media-Management | Neues Modul | DB-Schema |
+| **B1** | Warenausgang | Fehlender Prozess in Logistik | FOLGEMEETING |
+| **B2** | Allgemeine Bestandsfuehrung | Fehlender Prozess in Logistik | FOLGEMEETING |
+| **B3** | Lagerwert-Report | Fehlender Report in Controlling | FOLGEMEETING |
+| **B4** | Aufwand/Kosten-Analyse | Fehlender Report in Controlling | FOLGEMEETING |
+| **B5** | Automatische Abrechnung | Fehlender Prozess in Abrechnung | FOLGEMEETING |
+| **B6** | Abteilungstaetigkeiten | Fehlend in Administration | DB-Schema |
+| **B7** | Artikel-Lifecycle-Sonderfaelle (5 Stueck) | Fehlend in State Machines | State Machines |
+| **B8** | CRM-Projekt Sales Pipeline | Fehlend in CRM-Projekte | State Machines |
+| **B9** | Kontingent-Szenarien (6 Stueck) | Fehlende Tiefe in Vertraege | Wizard Workflows |
+| **B10** | Workflow-Engine / Automatisierungsregeln | Fehlend in Automatisierung | FOLGEMEETING |

Versuche/Versuch 04/Return3.md

@@ -0,0 +1,241 @@
+# Use-Case-Vergleich: UseCases_Short.md vs. andere Dateien
+
+## Referenz-Datei: ERP_WEB/UseCases_Short.md
+- **748 Use Cases** in 17 Modulen (1-17)
+- Deckt ab: Abrechnung, Administration, Adressen/CRM, Automatisierung, Buchhaltung, Controlling, Einkauf, Verkauf, Helpdesk, MyCentron, Logistik, Stammdaten, Vertraege, CentronNexus, Asset Management, Terminverwaltung, State Machines & Wizards
+
+> **Ignoriert**: Produktionsplanung, TicketManagement, RMM-Anbindung, REST API Endpunkte, Validierungsregeln
+
+---
+
+## Fehlende Anwendungsfunktionen (in anderen Dateien, NICHT in UseCases_Short.md)
+
+### A. Komplett fehlende Funktionsbereiche
+
+#### A1. Kundenportal / Self-Service (UC-070)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Ein kundengerichtetes Portal, in dem Kunden (nicht Mitarbeiter!) ihre Daten einsehen koennen:
+- Beleg-Uebersicht (Rechnungen, Lieferscheine, Angebote)
+- Zahlungshistorie
+- Kontaktinformationen
+- Optional: Tickets erstellen/einsehen
+
+**Abgrenzung**: CentronNexus (Modul 14) ist das **interne** Web-Portal fuer Mitarbeiter. Das Kundenportal ist eine voellig andere Zielgruppe.
+
+---
+
+#### A2. CRM-Aktivitaeten (UC-031)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Erstellen und Verwalten von CRM-Aktivitaeten als eigene Entitaet:
+- Anrufe protokollieren
+- Kundenbesuche dokumentieren
+- E-Mail-Korrespondenz verknuepfen
+- Notizen/Vermerke erstellen
+- Wiedervorlagen/Follow-ups planen
+- Aktivitaeten einem Kunden zuordnen
+
+**Abgrenzung**: UC 3.1.4 "Adresse mit Aktivitaetshistorie anzeigen" zeigt nur die Historie an - es gibt keinen Use Case fuer das ERSTELLEN und VERWALTEN von Aktivitaeten.
+
+---
+
+#### A3. Lead-Management / Anfragen (UC-032)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Der gesamte Prozess von der Anfrage bis zum Angebot:
+- Anfrage/Lead erfassen (Webformular, Telefon, Messe)
+- Lead qualifizieren (Interessensprofil, Budget, Dringlichkeit)
+- Lead-Status tracken (Neu, Kontaktiert, Qualifiziert, Verloren)
+- Lead zu Angebot/Kunde konvertieren
+
+**Abgrenzung**: CRM-Projekte (3.3) beginnen erst bei einem konkreten Projekt. Der fruehe Vertriebstrichter (Lead -> Opportunity) fehlt.
+
+---
+
+#### A4. Arbeitssicherheit / Qualitaets-Compliance
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen vorhanden**: AGArbeitssicherheit, AGMaterial, AGUmweltschutz, AGPrufvorschrift, ArtikelAGArbeitssicherheit, ArtikelAGMaterial, Arbeitssicherheit
+**Was fehlt**: Ein ganzes Modul fuer Arbeits-/Qualitaetssicherheit:
+- Sicherheitschecklisten pro Arbeitsplatz/Taetigkeit verwalten
+- Materialsicherheit dokumentieren (Gefahrstoffe, Umgang)
+- Umweltschutzanforderungen erfassen und pruefen
+- Pruefvorschriften fuer Artikel/Materialien definieren
+- Arbeitssicherheits-Audits durchfuehren und dokumentieren
+- Compliance-Berichte fuer ISO-Zertifizierungen generieren
+
+**Hinweis**: Nicht zu verwechseln mit den Compliance-Erwaenungen in UseCases_Short (DSGVO 2.2, Report-Compliance 12.7.5 etc.) - dort geht es um Daten-Compliance. Hier geht es um **physische Arbeitssicherheit und Materialqualitaet**.
+
+---
+
+#### A5. Social-Media-Management
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen vorhanden**: SocialMediaStream, SocialMediaStreamAccount, SocialMediaAction, SocialMediaComment, SocialMediaLike
+**Was fehlt**:
+- Social-Media-Accounts verknuepfen (Facebook, Twitter, LinkedIn)
+- Social-Media-Feeds ueberwachen
+- Posts planen und veroeffentlichen
+- Kommentare und Interaktionen verwalten
+- Engagement-Metriken analysieren
+- Leads aus Social Media generieren
+
+---
+
+### B. Fehlende Funktionen in bestehenden Modulen
+
+#### B1. Warenausgang (UC-021)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Logistik (11)
+**Was fehlt**: Der Warenausgang als eigenstaendiger Prozess:
+- Lagerausbuchung bei Lieferschein-Erstellung
+- FIFO-/Seriennummern-Auswahl beim Ausbuchen
+- Bestandsaktualisierung nach Warenausgang
+- Warenausgangs-Protokoll/Beleg
+
+**Abgrenzung**: Kommissionierung (11.4) ist das Zusammenstellen der Ware. Warenausgang ist die tatsaechliche Bestandsreduzierung und Buchung.
+
+---
+
+#### B2. Allgemeine Bestandsfuehrung (UC-022)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Logistik (11)
+**Was fehlt**: Laufende Bestandsverwaltung zwischen Inventuren:
+- Lagerbestandsabfrage (Menge, Reserviert, Verfuegbar)
+- Lagerumbuchung zwischen Lagerorten
+- Manuelle Bestandskorrektur mit Begruendung
+- Mindestbestandswarnungen
+- Bestandsabstimmung (Soll/Ist-Vergleich)
+
+**Abgrenzung**: Inventur (11.3) ist die periodische Zaehlung. Bestandsfuehrung ist der taegliche Umgang mit Bestaenden.
+
+---
+
+#### B3. Lagerwert-Report (UC-061)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Controlling (6)
+**Was fehlt**: Ein dedizierter Lagerwert-Bericht:
+- Bestaende x Einstandspreis = Lagerwert
+- FIFO- vs. Durchschnittsbewertung
+- Slow-Mover-Identifikation
+- Abweichungsanalyse (Bewertungsdifferenzen)
+- Lagerwert-Entwicklung ueber Zeit
+
+**Abgrenzung**: UC 6.1.8 "Lagerbestands-Entwicklung und Umschlag" erwaehnt Mengen, aber nicht die wertmaessige Betrachtung (Lagerbewertung, Slow-Mover, FIFO).
+
+---
+
+#### B4. Aufwand/Kosten-Analyse (UC-062)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Controlling (6)
+**Was fehlt**: Uebergreifende Aufwands- und Kostenanalyse:
+- Zeitaufwand pro Kunde/Projekt aggregieren
+- Kostenvergleich: geplant vs. tatsaechlich
+- Gewinnmarge pro Projekt/Kunde berechnen
+- Aufwand/Kosten-Report exportieren
+
+**Abgrenzung**: Kostentraeger/Kostenstellen (12.3) ist Stammdaten-Verwaltung. Hier geht es um die analytische Auswertung.
+
+---
+
+#### B5. Automatische Abrechnung (UC-041)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Abrechnung (1) / Automatisierung (4)
+**Was fehlt**: Zeitgesteuerte Abrechnung ohne Benutzereingriff:
+- Regelmaessige Abrechnungsjobs konfigurieren (taeglich, woechentlich, monatlich)
+- MSP-Gebuehren automatisch fakturieren
+- Vertragsgebundene Abrechnungen nach Intervall ausfuehren
+- Ergebnis-Benachrichtigung an Sachbearbeiter
+
+**Abgrenzung**: Modul 1.1 (Vertragsabrechnung) ist ein Wizard, den ein Benutzer manuell durchlaeuft. UC-041 beschreibt die vollautomatische Abrechnung im Hintergrund.
+
+---
+
+#### B6. Abteilungstaetigkeiten
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen**: AbtTaetigkeiten, AbtTaetigkeitenZuordnung
+**Modul**: Administration (2.14)
+**Was fehlt**: Verwaltung von Taetigkeiten pro Abteilung:
+- Taetigkeitsprofile definieren (z.B. "Vertrieb Innendienst", "Service Aussendienst")
+- Mitarbeiter Taetigkeiten zuordnen
+- Taetigkeiten fuer Kapazitaetsplanung nutzen
+
+**Abgrenzung**: Abteilungsverwaltung (2.14) hat nur "Abteilung erstellen" und "Abteilung zuordnen". Die Taetigkeitsebene fehlt.
+
+---
+
+#### B7. Artikel-Lifecycle-Sonderfaelle
+**Quelle**: USE_CASES_STATE_MACHINES.md
+**Modul**: State Machines (17.3)
+**Was fehlt in 17.3** (dort nur: Retoure, Verschrottung, Umbuchung, Ersatz):
+- **Artikel verloren bei Inventur** - Buchung und Dokumentation wenn ein Artikel bei der Inventur nicht auffindbar ist
+- **Seriennummer-Abweichung** - Workflow wenn gescannte SN nicht mit erwarteter SN uebereinstimmt
+- **Demo-Geraet deaktivieren** - Spezial-Lifecycle fuer Demo-/Leihgeraete (Aktiv -> Rueckruf -> Aufbereitung -> Wiederverwendung/Entsorgung)
+- **Artikel-Zustandsaenderung** - Aenderung des Zustands (Neu -> Gebraucht, Repariert -> Einsatzbereit)
+- **Batch-Wareneingang** - Einlagerung mehrerer Artikel gleichzeitig (z.B. nach Paletten-Lieferung)
+
+---
+
+#### B8. CRM-Projekt als vollstaendiger Lifecycle
+**Quelle**: USE_CASES_STATE_MACHINES.md (UC-030)
+**Modul**: CRM-Projekte (3.3)
+**Was fehlt**: Die State Machine des CRM-Projekts:
+- Status-Uebergaenge: Opportunity -> Proposal -> Negotiation -> Won/Lost
+- Automatische Eskalation bei Inaktivitaet
+- Win/Loss-Analyse nach Abschluss
+- Pipeline-Ansicht aller Projekte nach Status
+
+**Abgrenzung**: Modul 3.3 hat CRUD-Operationen und "als verloren markieren" (3.3.7), aber den vollstaendigen Sales-Pipeline-Lifecycle mit Statusuebergaengen und Analyse nicht.
+
+---
+
+#### B9. Kontingent-Szenarien (Vertiefung)
+**Quelle**: USE_CASES_WIZARD_WORKFLOWS.md
+**Modul**: Kontingent-State-Machine (17.6)
+**Was fehlt** (17.6 hat nur 4 generische UCs):
+- Geld-Kontingent mit Overbooking-Regelung
+- Stunden-Kontingent fuer Dienstleister
+- Quartals-Kontingent mit Warengruppen-Zuordnung
+- Kontingent-Uebertrag in Folgeperiode
+- Gratis-Perioden (Promotions)
+- Kontingent-Umverteilung waehrend Vertragslaufzeit
+
+---
+
+#### B10. Workflow-Engine / Automatisierungsregeln (UC-042)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Automatisierung (4)
+**Was fehlt**: Eine generische Workflow-Engine:
+- Trigger definieren: Beleg-Status, Datumsregeln, Betragschwellen
+- Aktionen konfigurieren: E-Mail senden, Report generieren, Daten aendern, Aufgabe erstellen
+- Bedingungslogik (Wenn-Dann-Sonst)
+- Workflow-Ketten (Aktion A loest Aktion B aus)
+
+**Abgrenzung**: "Erwartete Events" (4.1/4.2) deckt Event-basierte Triggers ab. Die generische Workflow-Engine geht darueber hinaus - sie verkettet Aktionen und hat Bedingungslogik.
+
+---
+
+## Implementierung
+
+### Schritt 1: Datei kopieren
+- Kopiere `ERP_WEB/UseCases_Short.md` nach `ERP_WEB/UseCases_Short_V2.md`
+
+### Schritt 2: Fehlende Use Cases einfuegen (an passender Stelle im Dokument)
+
+**Einfuegestellen und neue UCs:**
+
+| Position in Datei | Was einfuegen |
+|---|---|
+| Nach 1.1 (Vertragsabrechnung) | **1.x Automatische Abrechnung** (B5) - zeitgesteuerte Abrechnung |
+| Nach 3.1 (Adressstamm) | **3.x CRM-Aktivitaeten** (A2) - Anrufe, Besuche, Mails, Notizen |
+| Nach 3.3 (CRM-Projekte) | CRM-Projekt-Lifecycle als State Machine ergaenzen (B8) |
+| Nach 3.4 (Kampagnen) | **3.x Lead-Management** (A3) - Anfragen, Leads, Qualifizierung |
+| Nach 3.4 (Kampagnen) | **3.x Social-Media-Management** (A5) |
+| Nach 4.2 (Erwartete Events) | **4.x Workflow-Engine** (B10) |
+| Nach 6.1 (Analytics) | **6.x Lagerwert-Report** (B3) und **6.x Aufwand/Kosten-Analyse** (B4) |
+| Nach 11.3 (Inventur) | **11.x Warenausgang** (B1) und **11.x Bestandsfuehrung** (B2) |
+| Nach 2.14 (Abteilungsverwaltung) | **2.x Abteilungstaetigkeiten** (B6) |
+| Neues Modul 18 | **Arbeitssicherheit / Qualitaets-Compliance** (A4) |
+| Neues Modul 19 | **Kundenportal / Self-Service** (A1) |
+| In 17.3 (Artikel-Lifecycle) | 5 Sonderfaelle ergaenzen (B7) |
+| In 17.6 (Kontingent) | 6 spezifische Szenarien ergaenzen (B9) |
+
+### Schritt 3: Nummerierung konsistent halten
+- Neue Unterkategorien erhalten die naechste freie Nummer im jeweiligen Modul
+- Stil und Format beibehalten (#### fuer UC-Titel, Beschreibungstext darunter)

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.

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.

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

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.
-

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.
-

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.
-