Überarbeitung layout und Kap 4

.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,32 @@
+#set terms(separator: [], hanging-indent: 0pt, tight: false)
+#show terms.item: it => block(below: 0.8em, [
+  #strong(it.term) \
+  #it.description
+])
+#show terms: it => {
+  it
+  v(2cm)
+}
+
 #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 +35,27 @@ 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).
-- 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:
+Diese 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

@@ -4,370 +4,23 @@
   #hide(bibliography("../literatur.bib", style: "apa"))
 ]
 
+#set terms(separator: [], hanging-indent: 0pt, tight: false)
+#show terms.item: it => block(below: 0.8em, [
+  #strong(it.term) \
+  #it.description
+])
+#show terms: it => {
+  it
+  v(2cm)
+}
+
 #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 inklusive typischer Leistungsgrenzen und Absicherungsmechanismen beschrieben. 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 Requirements 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 Requirements 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. Requirements Engineering 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-Engineering-Ansatzes sind diese aber relevant für die Implementierung und architekturelle 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 wird 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 das 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 Benennung 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 Implementierung?
+/ 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 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 Punkte 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

@@ -4,98 +4,92 @@
   #hide(bibliography("../literatur.bib", style: "apa"))
 ]
 
+#set terms(separator: [], hanging-indent: 0pt, tight: false)
+#show terms.item: it => block(below: 0.8em, [
+  #strong(it.term) \
+  #it.description
+])
+#show terms: it => {
+  it
+  v(2cm)
+}
+
 #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äteherstellerunabhängige Nutzung.
+/ Zentrale Datenverwaltung: Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Basis für weitere Produkte der Firma.
 
-- **Benutzeroberfläche und Interaktion:** Webbasierte Oberflächen, Rollen- und Rechtekonzepte, konsistente Navigation.
+Als Performance-Ziel wird ein Bereich von 5 bis 100 gleichzeitigen Nutzern pro Mandant festgelegt. Kleinere Installationen mit 1 bis 5 Nutzern sowie größere Installationen oberhalb von 100 Nutzern werden ebenfalls unterstützt, bleiben aber opportunistische Ziele.
-- **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 Refactoring 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, also Datenmigration, Refactoring im Detail, Reimplementierung oder Release-Planung, wird lediglich als Randbedingung mit betrachtet.
-
-- 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:
+
+/ Randfäll und Varianten: Ein erheblicher Teil des Systemumfangs steckt in implementierten Sonderfällen und Varianten. Diese sind im Code zwar nachvollziehbar, aber selten dokumentiert und zur Laufzeit auch jeweils nur einzeln zu analysieren da sie sich oft gegenseitig ausschließen.
+/ Daten und Logische Redundanz: Historisch wurden zusätzliche Funktionen oft inmplementiert indem Code oder Masken hinzugefügt wurden ohne alten code zu verändern. Daher kommt es vor, dass die die gleiche Anforderung auf Unterschiedlichen Masken oder Berechnungspfaden mehrfach unterschiedliche implementiert wurde.
+/ Implizite Geschäftsregeln: Geschäftslogik ist häufig als Prüf- und Statuslogik oder über Randbediungungen in Eingabefeldern realisiert. Eine zuordung zu anderen zusammenghörigen Regeln fällt hier schwer.
+/ Kontextbasierte Logik: Funktionalitäten und Logik sind oft nur lose über  historische Zuständen verbunden. Eine Regel kann daher nur bei Betrachtung eines vollständigen historischen Datensatzes im Kontext abgeleitet werden.
+/ Nicht-funktionale Anforderungen: Mit dem Wechsel auf einen neuen Tech-Stack ist zu prüfen, welche der bisherigen nicht-funktionalen Anforderungen weiterhin Gültigkeit haben und welche neu definiert werden müssen. Annahmen zu Performance, Sicherheit oder Verfügbarkeit gelten unter veränderten Architektur- und Betriebsbedingungen nicht automatisch weiter.
 
-- **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 @security2014legacycloud.
-- **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.
 
 #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 vier konkrete Anforderungen an das Vorgehen. Zunächst gilt eine *Belegpflicht*. Jede extrahierte Anforderung muss auf ein Artefakt wie eine Datei, ein Modul, ein Datenobjekt oder einen UI-Text zurückgeführt werden können. Aussagen, die nicht eindeutig aus Artefakten ableitbar sind, werden *explizit als Hypothesen markiert* und priorisiert validiert. Da Artefakte verteilt sind, ist eine *Segmentierung und Kontextsteuerung* notwendig, um Überinterpretation zu reduzieren. Schließlich ist eine fachliche Validierung durch einen *Human-in-the-loop* zwingend, da „plausible" Textausgaben kein hinreichender Beweis für fachliche Korrektheit sind.
 
-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 die Claude-Code-basierte Durchfuehrung, Kapitel 5 dokumentiert die Ergebnisse der Versuche, und Kapitel 6 evaluiert die Eignung im Fallkontext der c-entron GmbH.

Kapitel/04_konzeption_methodisches_vorgehen.typ

@@ -1,420 +1,228 @@
+#import "@preview/cetz:0.4.2"
+
 #let __is_thesis = context { query(<__thesis_document>).len() > 0 }
 #if __is_thesis == false [
   #set cite(style: "apa")
   #hide(bibliography("../literatur.bib", style: "apa"))
-  // Fallback for standalone preview of this chapter (without global thesis style).
-  #show raw: set text(font: "DejaVu Sans Mono", size: 9.5pt, fill: luma(20))
-  #show raw.where(block: true): it => block(
-    width: 100%,
-    fill: luma(240),
-    stroke: 0.5pt + luma(190),
-    inset: 9pt,
-    radius: 4pt,
-    above: 0.8em,
-    below: 0.8em,
-    it,
-  )
 ]
 
+#set terms(separator: [], hanging-indent: 0pt, tight: false)
+#show terms.item: it => block(below: 0.8em, [
+  #strong(it.term) \
+  #it.description
+])
+#show terms: it => block(below: 1.6em, it)
+
 #heading(level: 1)[Konzeption und methodisches Vorgehen (ca. 12 Seiten)]
 
-Dieses Kapitel beschreibt die tatsaechlich durchgefuehrte Methodik mit Fokus auf Claude Code als zentralem Arbeitswerkzeug. Alle Informationen sind versuchsweise gebuendelt dargestellt, sodass pro Versuch die Konfiguration, die Prompts, die eingesetzten Tools und die resultierenden Artefakte geschlossen nachvollziehbar sind.
+Dieses Kapitel beschreibt die Methodik, mit der die in Kapitel 1 beschriebenen Ziele und Forschungsleitfragen beantwortet werden sollen. Ausgangspunkt ist das methodische Design. Aus diesem Design leiten sich alle weiteren methodischen Entscheidungen ab. Vorausgegangene Proof-of-Concept-Läufe haben einzelne Aspekte des Vorgehens informell erprobt und das hier dargestellte Vorgehen geprägt, sie sind aber nicht Gegenstand der Auswertung. Die eigentliche Untersuchung wird in den folgenden Abschnitten geplant und in den folgenden Kapiteln durchgeführt und bewertet.
+
+#heading(level: 2)[Methodisches Design im Überblick]
+
+Das Vorgehen ist entlang der vier Forschungsleitfragen aus Kapitel 1 strukturiert. Diese werden im Folgenden mit Frage 1 (Steuerung und Reproduzierbarkeit), Frage 2 (KI-Extraktion und Stakeholder-Input), Frage 3 (Qualitätsbewertung) und Frage 4 (Chancen, Grenzen und Risiken) bezeichnet. Aus jeder Leitfrage folgt unmittelbar eine Datenquelle und ein Auswertungsweg. Damit ist sichergestellt, dass die methodischen Bausteine nicht nachträglich auf die Fragen abgebildet werden, sondern aus ihnen hervorgehen.
+
+#figure(
+  cetz.canvas({
+    import cetz.draw: *
+
+    let stages = (
+      (y:  4.0, label: "Codebasis",      q: none),
+      (y:  2.0, label: "KI-Extraktion",  q: (num: "Frage 1", text: "Welche Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?")),
+      (y:  0.0, label: "Strukturierung", q: (num: "Frage 2", text: "Welche Anforderungen lassen sich aus Code extrahieren, welche müssen über Interviews ergänzt werden?")),
+      (y: -2.0, label: "Validierung",    q: (num: "Frage 3", text: "Wie beurteilen Fachexperten Vollständigkeit, Verständlichkeit und Nützlichkeit der KI-Ergebnisse?")),
+      (y: -4.0, label: "Bewertung",      q: (num: "Frage 4", text: "Welche Effizienzgewinne, Limitierungen und Risiken sind realistisch und müssen adressiert werden?")),
+    )
+
+    let box-half-w = 1.5
+    let box-half-h = 0.4
+    let stage-x = -5.0
+    let arrow-gap = 0.1
+
+    for s in stages {
+      rect(
+        (stage-x - box-half-w, s.y - box-half-h),
+        (stage-x + box-half-w, s.y + box-half-h),
+        stroke: black + 0.6pt, fill: luma(240),
+      )
+      content((stage-x, s.y), text(size: 9pt, weight: "bold")[#s.label])
+    }
+
+    for i in range(stages.len() - 1) {
+      let s1 = stages.at(i)
+      let s2 = stages.at(i + 1)
+      line(
+        (stage-x, s1.y - box-half-h - arrow-gap),
+        (stage-x, s2.y + box-half-h + arrow-gap),
+        mark: (end: ">"),
+        stroke: black + 0.6pt,
+      )
+    }
+
+    let q-x = stage-x + box-half-w + 0.6
+    for s in stages {
+      if s.q != none {
+        content(
+          (q-x, s.y),
+          anchor: "west",
+          box(
+            width: 9cm,
+            text(size: 9pt)[*#s.q.num:* #s.q.text],
+          ),
+        )
+      }
+    }
+  }),
+  caption: [Methodisches Design im Überblick. Die vertikale Sequenz zeigt den Ablauf von der Codebasis bis zur Bewertung. Pro Phase ist die zugeordnete Forschungsleitfrage angeben.],
+) <abb_forschungsdesign>
 
-#heading(level: 2)[Claude Code als Werkzeug]
+Der untersuchte Prozess folgt einer durchgehenden Kette von der Codebasis bis zum Requirement. Auf der Codebasis setzt eine KI-gestützte Extraktion auf. Die Ergebnisse werden in eine konsistente Spezifikationsform überführt und durch Fachexperten validiert. Die abschließende Bewertung erfolgt mit Hilfe vordefinierter Qalitätskriterien.
 
-Claude Code wurde in dieser Arbeit als lokales Analysewerkzeug genutzt: ueber die CLI im Projektarbeitsverzeichnis und ueber die VS-Code-Einbindung. Die Arbeitslogik folgt einem schrittweisen Ausbau:
+Aus diesem Ablauf ergeben sich drei methodische Module, die in den folgenden Abschnitten ausgearbeitet werden. Erstens der *kontrollierte Tooling-Vergleich*. Es ist eine Versuchsreihe vorgesehen, die auf derselben Codebasis und mit demselben Grundprompt arbeitet und sich gezielt nur in einzelnen Werkzeugkomponenten unterscheidet. Die konkrete Anzahl und Zuschnitt der Versuche werden im Untersuchungsdesign festgelegt. Zweitens die *strukturierte Stakeholder-Validierung*. Jede extrahierte Anforderung soll durch Domänenexperten geprüft, anhand einer Likert-Skala bewertet und durch halbstrukturierte Interviews ergänzt werden. Drittens die *RE-Qualitätsbewertung*. Die Bewertungskriterien werden vor der Durchführung definiert, sodass eine nachträgliche Kriterienwahl ausgeschlossen ist. Die Bewertung schließt neben der klassischen RE-Qualität auch die Migrations- und Konsolidierungsperspektive ein, also die Frage, ob eine extrahierte Anforderung im Zielsystem in dieser Form erhalten bleiben oder mit anderen zusammengeführt werden sollte.
 
-- Baseline nur mit Prompt + CLI (Versuch 01),
+#heading(level: 2)[Bezugsrahmen: Der RRE-Prozess als Untersuchungsgegenstand]
-- Spezialisierung ueber Agenten-Dateien (Versuch 02),
-- Erweiterung um MCP-Server fuer zusaetzliche Tool- und Datenzugriffe (Versuch 03).
 
-Technisch wurde Claude Code entlang der offiziellen Dokumentation eingesetzt:
+Das in dieser Arbeit untersuchte Vorgehen folgt der in Kapitel 2 hergeleiteten siebenstufigen Methodenkette für Reverse Requirements Engineering. Die Schritte bauen aufeinander auf und decken den Weg von der ersten Abgrenzung des Untersuchungsgegenstands bis zur Validierung der gewonnenen Anforderungen ab.
 
-- Session-Start und Ausfuehrung ueber CLI (`claude`, `claude -p`),
+1. *Scope und Domänenabgrenzung:* Auswahl relevanter Module, Datenobjekte und Prozesse.
-- lokale IDE-Anbindung in VS Code,
+2. *Artefakterhebung:* Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen und Change-Historie.
-- Einbindung externer MCP-Server ueber das `claude mcp`-Konzept,
+3. *Technische Analyse:* Struktur- und Abhängigkeitsanalyse sowie Identifikation von Kernkomponenten, Regeln und Integrationspunkten.
-- Nutzung des MCP-Scopes fuer projektspezifische Tool-Konfigurationen.
+4. *Semantische Interpretation:* Ableitung fachlicher Aussagen aus technischen Implementierungen.
+5. *Formalisierung:* Überführung in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. *Traceability-Anreicherung:* Verknüpfung jedes Requirements mit Artefaktbelegen.
+7. *Validierung:* Review durch Fachexperten und Abgleich mit Laufzeitverhalten oder Tickets.
 
-Die technische Einordnung stuetzt sich auf die offizielle Claude-Code-Dokumentation zu Quickstart, CLI-Nutzung, IDE-Integration und MCP sowie auf das Produktupdate zu Remote MCP @claudecode_quickstart_2026 @claudecode_cli_2026 @claudecode_ide_2026 @claudecode_mcp_2026 @anthropic_remote_mcp_2025.
+In dieser Arbeit werden lediglich Schritt 1 und Schritt 7 manuell durchgeführt. Die dazwischenliegenden Schritte 2 bis 6 sollen KI-gestützt automatisiert werden. Der Untersuchungsschwerpunkt liegt damit nicht nur auf der Anforderungsbeschreibung, sondern vor allem auch auf der zuverlässigen Erzeugung dieser Beschreibung durch ein LLM.
 
-Damit fungiert Claude Code in dieser Arbeit nicht nur als Chat-Interface, sondern als orchestrierender Agent-Laufzeitkontext fuer Prompting, rollenbasierte Agenten und MCP-basierte Toolaufrufe.
+Damit das Vorgehen belastbar bleibt, sind in jeder Iteration drei Eigenschaften sicherzustellen:
 
-#heading(level: 2)[Versuch 01]
+/ Belegpflicht: Jede extrahierte Anforderung muss auf ein konkretes Artefakt wie eine Datei, ein Modul, ein Datenobjekt oder einen UI-Text zurückführbar sein.
+/ Explizite Hypothesenmarkierung: Aussagen, die nicht eindeutig aus Artefakten ableitbar sind, werden als Hypothesen markiert und gesondert validiert.
+/ Human-in-the-loop: Die fachliche Validierung durch Domänenexperten ist nicht optional. Plausibel formulierte LLM-Ausgaben sind kein hinreichender Beweis für sachliche Korrektheit.
 
-#heading(level: 3)[Allgemeine Beschreibung]
+Mit der Festlegung der Schrittfolge, der Aufteilung zwischen Mensch und KI sowie den drei Pflicht-Eigenschaften ist der Bezugsrahmen geklärt, in dem die folgenden Abschnitte ihre Detailfragen verorten.
 
-Versuch 01 bildet die Baseline ohne Agenten und ohne MCP. Ziel war eine erste formale Requirements-Extraktion direkt aus der Codebasis mit minimaler Tooling-Komplexitaet.
+#heading(level: 2)[Werkzeugbasis: Auswahl des LLM]
 
-#heading(level: 3)[Konfiguration]
+Die Wahl des konkret eingesetzten LLM bestimmt maßgeblich, welche Steuerungsmechanismen praktisch umgesetzt werden können und wie reproduzierbar die Ergebnisse erzeugt werden. Aus diesem Grund wird die Werkzeugauswahl nicht implizit vorausgesetzt, sondern entlang der fünf Kriterien aus der Zielsetzung begründet. Diese Kriterien sind Kontextfenster, Codeverständnis, Steuerbarkeit, Kosten und Datenschutz.
 
-- Claude Code CLI lokal im Projektverzeichnis,
+Zur Auswahl stehen vier aktuell verfügbare Optionen. Anthropic Claude wird über die CLI-Variante Claude Code eingebunden, die agentisches Arbeiten und MCP-Integration nativ unterstützt. OpenAI bietet mit GPT-5 und der Codex-CLI eine vergleichbare agentische Schnittstelle. Als weitere Optionen kommen Qwen 3.5 Coder mit der Möglichkeit zur lokalen Ausführung ohne Cloud-Versand sowie DeepSeek R1 als cloudbasierte Alternative infrage.
-- Nutzung aus VS Code (integriertes Terminal),
-- keine Agenten-Dateien,
-- keine MCP-Server.
 
-#heading(level: 3)[Verwendeter Prompt]
+#figure(
+  table(
+    columns: (1.4fr, 1fr, 1fr, 1fr, 1fr),
+    align: (left, left, left, left, left),
+    stroke: 0.4pt,
+    [*Kriterium*], [*Claude (Claude Code)*], [*GPT-5 (Codex)*], [*DeepSeek R1 (Cloud)*], [*Qwen 3.5 Coder (lokal)*],
+    [Kontextfenster], [bis 1 M Tokens], [bis 400 k Tokens], [bis 128 k Tokens], [bis 256 k Tokens],
+    [Codeverständnis], [hoch], [hoch], [hoch], [hoch],
+    [Steuerbarkeit (Agenten, MCP)], [nativ], [über Codex-CLI], [über API], [über Qwen Code CLI],
+    [Kosten], [API-Abrechnung], [API-Abrechnung], [API-Abrechnung], [Eigenbetrieb],
+    [Datenschutz], [Cloud-Versand], [Cloud-Versand], [Cloud-Versand], [On-Premise],
+  ),
+  caption: [Vergleich der LLM-Optionen entlang der fünf Auswahlkriterien.],
+) <tab_llm_vergleich>
 
-```text
+Für diese Arbeit fällt die Entscheidung auf Claude Code als primäres Werkzeug. Ausschlaggebend sind das große Kontextfenster, die native Unterstützung von Agenten und MCP-Servern sowie eine offen dokumentierte CLI für reproduzierbare Aufrufe. Die kostenseitigen und datenschutzrechtlichen Nachteile gegenüber lokalen Modellen werden durch gezielte Konfigurationsmaßnahmen adressiert. Qwen 3.5 Coder und DeepSeek R1 werden für einen optionalen LLM-Querschnitt offengehalten, sind aber nicht das primäre Werkzeug. Qwen 3.5 Coder wird dabei lokal über LM Studio als Inferenz-Runtime betrieben. Die Anbindung erfolgt über den OpenAI-kompatiblen HTTP-Endpunkt von LM Studio, an den die Qwen Code CLI und gegebenenfalls MCP-Clients adressiert werden. Damit bleibt der Versuchsaufbau ohne Cloud-Versand und ohne Übertragung kundenbezogener Codeausschnitte an externe Anbieter.
-Please analyze this software project and write a reuqirements specification according to modern standards.
-```
 
-#heading(level: 3)[Tools und Artefakte]
+#heading(level: 2)[Untersuchungsdesign: Kontrollierter Tooling-Vergleich]
 
-- Tooling: Claude Code CLI + VS Code Integration.
+Das Untersuchungsdesign folgt einer schrittweise aufbauenden Vergleichslogik. Versuch 1 bis 3 bilden den Kern der Reihe und werden ausschließlich auf Claude Code durchgeführt. Ausgehend von einer Baseline werden in jedem weiteren Versuch zusätzliche Werkzeugkomponenten hinzugefügt, sodass der Effekt jeder Komponente isoliert beobachtbar ist. Alle drei Versuche arbeiten auf derselben Codebasis und mit demselben Grundprompt. Variiert wird ausschließlich die Werkzeugkonfiguration. Der optionale Versuch 4 kehrt die Logik um: Die in Versuch 1 bis 3 wirksamste Konfiguration wird fixiert und auf den drei alternativen Modellen wiederholt, um modellabhängige von werkzeugabhängigen Effekten trennen zu können.
-- Ergebnisfokus: formale Requirements-Spezifikation (StRS/SyRS/SwRS) mit hoher Strukturierungsdichte.
 
-#heading(level: 3)[Beispielhafte Ergebnisanforderungen]
+/ Versuch 1 (Baseline, Prompt-only): Reine Prompt-Steuerung ohne Agentendateien und ohne externe Tools. Die Hypothese lautet, dass eine formal strukturierte Anforderungsmenge bereits ohne Spezialisierung erreichbar ist, allerdings mit begrenzter Discovery-Breite und ohne dynamische Code- oder Datenbeobachtung.
 
-Quelle: `Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md`
+/ Versuch 2 (Spezialisierung über Agenten): Wie Versuch 1, ergänzt um rollenspezialisierte Agentendateien für Stakeholder-Analyse, System-Requirements, Software-Requirements und einen ISO-29148-Orchestrator. Die Hypothese lautet, dass Spezialisierung die Strukturierungstiefe und die Normkonformität erhöht, ohne die Discovery-Breite signifikant zu verschlechtern.
 
-```text
+/ Versuch 3 (Toolzugriff über MCP-Server): Wie Versuch 2, ergänzt um strukturierten Tool-Zugriff über MCP. Vorgesehen sind drei Server für Symbol-Navigation auf Code-Ebene, für Datenbank-Inspektion auf Schema- und Datensatzebene sowie optional für GUI-Beobachtung. Die Hypothese lautet, dass strukturierter Tool-Zugriff die Discovery-Breite vergrößert und zuvor undokumentierte Use Cases sichtbar macht, allerdings zu Lasten erhöhter Steuerungskomplexität.
-### StR-001: Comprehensive Customer Account Management
-**Statement**: The system shall provide comprehensive customer account management capabilities including contact information, relationship mapping, interaction history, and account hierarchy management.
-```
 
-```text
+/ Versuch 4 (optional, LLM-Querschnitt): Die in den ersten drei Versuchen wirksamste Konfiguration wird auf allen drei alternativen Modellen wiederholt: GPT-5 über die Codex-CLI, DeepSeek R1 über die Cloud-API sowie Qwen 3.5 Coder lokal über LM Studio. Wo einzelne Werkzeugkomponenten in der jeweiligen Umgebung nicht eins zu eins verfügbar sind, wird ein funktional äquivalenter Ersatz gewählt und dokumentiert. Ziel ist eine Einschätzung, in welchem Maße die in Versuch 1 bis 3 beobachteten Effekte modellabhängig oder werkzeugabhängig sind.
-### SyR-001
-The system SHALL implement a multi-layered architecture with clear separation of concerns.
-```
 
-#heading(level: 3)[Einordnung]
+#figure(
+  table(
+    columns: (auto, 1fr, 1.4fr),
+    align: (left, left, left),
+    stroke: 0.4pt,
+    [*Versuch*], [*Werkzeugkonfiguration*], [*Hypothese*],
+    [V1 Baseline], [Prompt-only, ohne Agenten, ohne Tools], [Formal strukturierte Spezifikation erreichbar, Discovery-Breite begrenzt],
+    [V2 Agenten], [Wie V1, ergänzt um rollenspezialisierte Agentendateien], [Höhere Strukturierungstiefe und Normkonformität bei vergleichbarer Breite],
+    [V3 MCP-Tools], [Wie V2, ergänzt um MCP-Server für Code, Datenbank und optional GUI], [Größere Discovery-Breite, höhere Steuerungskomplexität],
+    [V4 (optional)], [Beste Konfiguration aus V1–V3, wiederholt auf GPT-5 (Codex), DeepSeek R1 (Cloud) und Qwen 3.5 Coder (lokal, LM Studio)], [Trennung modell- gegenüber werkzeugabhängiger Effekte],
+  ),
+  caption: [Übersicht der geplanten Versuche mit Werkzeugkonfiguration und Arbeitshypothese.],
+) <tab_versuchsreihe>
 
-Die Baseline zeigt, dass bereits ohne Agenten/MCP belastbare, formal strukturierte Anforderungen erzeugbar sind. Gleichzeitig bleibt die Discovery-Breite begrenzt.
+Konstanten und Variablen sind in jedem Versuch klar dokumentiert. In Versuch 1 bis 3 umfassen die Konstanten Codebasis, Grundprompt, Modellfamilie, Validierungsstichprobe und Bewertungskriterien; variabel ist ausschließlich die Werkzeugkonfiguration. In Versuch 4 wird die Logik umgekehrt: Die Werkzeugkonfiguration ist die Konstante, das Modell die Variable. Damit lassen sich Unterschiede in Versuch 1 bis 3 ursächlich der Werkzeugvariation und in Versuch 4 ursächlich der Modellwahl zuordnen.
 
-#heading(level: 2)[Versuch 02]
+#heading(level: 2)[Stakeholder-Validierung als Verifikationsverfahren]
-
-#heading(level: 3)[Allgemeine Beschreibung]
-
-Versuch 02 fokussiert die ISO-29148-orientierte Konsolidierung. Dazu wurde Claude Code weiterhin lokal genutzt, jedoch um spezialisierte Agenten-Dateien erweitert.
-
-#heading(level: 3)[Konfiguration]
-
-- Claude Code CLI lokal + VS Code,
-- agentenbasierte Spezialisierung ueber MD-Dateien in `Versuche/Versuch 02/Tools/agents/`,
-- kein MCP-Fokus in diesem Lauf.
-
-#heading(level: 3)[Verwendeter Prompt]
-
-```text
-Please analyze this software project and write a ISO 29148 compliant reuqirements specification.
-Use Agents wherever possible.
-```
-
-#heading(level: 3)[Tools und Agenten]
-
-Beispiele aus dem Versuchsordner:
-
-- `iso29148-master-orchestrator-agent.md`
-- `iso29148-stakeholder-agent.md`
-- `iso29148-system-requirements-agent.md`
-- `iso29148-software-requirements-agent`
-
-#heading(level: 3)[Agentenbeispiel (Auszug, erste 100 Zeilen) - Versuch 02]
-
-Quelle: `Versuche/Versuch 02/Tools/agents/iso29148-master-orchestrator-agent.md`
-
-````md
-# Enhanced ISO 29148 Master Orchestrator Agent with Milestone System
-
-You are the Lead Requirements Analyst coordinating the complete ISO/IEC/IEEE 29148 requirements extraction with comprehensive documentation, quality assurance, and milestone-based execution control.
-
-## Your Mission
-Orchestrate a complete requirements analysis using all three ISO 29148 levels, ensuring consistency, completeness, and traceability. Create executive-level documentation and ensure all agents produce their complete documentation packages. **NEW**: Provide milestone-based pause/resume capabilities for long-running analyses.
-
-## CRITICAL: Documentation Requirements
-**You MUST ensure:**
-1. Each agent creates their complete documentation package
-2. You create the integrated master document
-3. All work is saved to `/docs/requirements/`
-4. Complete traceability is maintained
-5. Executive dashboards and reports are generated
-6. **NEW**: Milestone state is persisted for pause/resume functionality
-7. VERIFY each agent has created their files before proceeding
-
-## NEW: Milestone System Architecture
-
-### Milestone Configuration
-```json
-{
-  "project_name": "[Project Name]",
-  "execution_id": "[UUID]",
-  "created_at": "[ISO DateTime]",
-  "milestones": {
-    "M0_SETUP": {
-      "name": "Project Analysis and Setup",
-      "status": "pending|in_progress|completed|failed",
-      "started_at": null,
-      "completed_at": null,
-      "dependencies": [],
-      "outputs": ["project_structure.json", "directory_setup.txt"]
-    },
-    "M1_STAKEHOLDER": {
-      "name": "Stakeholder Requirements Analysis",
-      "status": "pending",
-      "started_at": null,
-      "completed_at": null,
-      "dependencies": ["M0_SETUP"],
-      "outputs": [
-        "StRS_Complete.md",
-        "StRS_Summary.md", 
-        "StRS_Traceability.csv",
-        "StRS_Diagrams.md",
-        "StRS_Evidence.md"
-      ]
-    },
-    "M2_SYSTEM": {
-      "name": "System Requirements Analysis", 
-      "status": "pending",
-      "started_at": null,
-      "completed_at": null,
-      "dependencies": ["M1_STAKEHOLDER"],
-      "outputs": [
-        "SyRS_Complete.md",
-        "SyRS_Summary.md",
-        "SyRS_API_Specification.yaml",
-        "SyRS_Architecture.md",
-        "SyRS_Interfaces.md",
-        "SyRS_Traceability.csv"
-      ]
-    },
-    "M3_SOFTWARE": {
-      "name": "Software Requirements Analysis",
-      "status": "pending", 
-      "started_at": null,
-      "completed_at": null,
-      "dependencies": ["M2_SYSTEM"],
-      "outputs": [
-        "SwRS_Complete.md",
-        "SwRS_CodeCatalog.md",
-        "SwRS_Algorithms.md", 
-        "SwRS_DataModel.md",
-        "SwRS_TestSpecification.md",
-        "SwRS_Traceability.csv"
-      ]
-    },
-    "M4_PATTERNS": {
-      "name": "Code Pattern Analysis",
-      "status": "pending",
-      "started_at": null, 
-      "completed_at": null,
-      "dependencies": ["M3_SOFTWARE"],
-      "outputs": [
-        "Analysis_Complete.md",
-        "Pattern_Catalog.csv",
-        "Business_Rules.md",
-        "Validation_Rules.md",
-        "Security_Patterns.md",
-        "Performance_Patterns.md",
-        "Integration_Patterns.md"
-      ]
-    },
-    "M5_INTEGRATION": {
-      "name": "Integration and Master Documentation",
-      "status": "pending",
-      "started_at": null,
-      "completed_at": null, 
-      "dependencies": ["M1_STAKEHOLDER", "M2_SYSTEM", "M3_SOFTWARE", "M4_PATTERNS"],
-````
-Hinweis: Der Auszug endet nach Zeile 100; die Originaldatei umfasst 620 Zeilen und ist an dieser Stelle nicht zu Ende.
-
-#heading(level: 3)[Beispielhafte Ergebnisanforderungen]
-
-Quellen:
-
-- `Versuche/Versuch 02/Ergenisse/system/SyRS_Complete.md`
-- `Versuche/Versuch 02/Ergenisse/software/SwRS_Complete.md`
-
-```text
-**SyR-001**: The system SHALL implement a multi-layered architecture with clear separation of concerns.
-**SyR-002**: The system SHALL implement the ILogic interface pattern with dual implementations.
-```
-
-```text
-**SW-FUNC-001**: The software SHALL provide comprehensive account management functionality.
-**SW-API-001**: The software SHALL provide comprehensive REST API.
-```
-
-#heading(level: 3)[Einordnung]
-
-Versuch 02 lieferte die staerkste formale Konsolidierung (StRS/SyRS/SwRS, hohe Traceability), erwies sich fuer die Gesamtentdeckung jedoch als vergleichsweise rigide.
-
-#heading(level: 2)[Versuch 03]
-
-#heading(level: 3)[Allgemeine Beschreibung]
-
-Versuch 03 erweitert das Vorgehen aus Versuch 02 um MCP-Server, um neben formaler Strukturierung vor allem die Discovery-Breite zu vergroessern (Use-Case-Fund, Gap-Analyse).
-
-#heading(level: 3)[Konfiguration]
-
-- Claude Code CLI lokal + VS Code,
-- Agenten-Dateien in `Versuche/Versuch 03/Tools/Agents/`,
-- MCP-Server gemaess Protokoll: Serena MCP, Windows-MCP (AutoIt-basiert), MSSQL MCP.
-
-#heading(level: 3)[Verwendeter Prompt]
-
-```text
-Please analyze this software project and write a reuqirements specification according to modern standards.
-Use Agents and MCP servers wherever possible.
-Keep superflous texts to a minimum and concentrate on actual requirements.
-```
-
-#heading(level: 3)[Tools und Agenten]
-
-Beispiele aus dem Versuchsordner:
-
-- `centron-documentation-writer.md`
-- `nhibernate-query-reviewer.md`
-- `centron-code-reviewer.md`
-- `webservice-developer.md`
-
-#heading(level: 3)[Agentenbeispiel (Auszug, erste 100 Zeilen) - Versuch 03]
-
-Quelle: `Versuche/Versuch 03/Tools/Agents/nhibernate-query-reviewer.md`
-
-````md
----
-name: nhibernate-query-reviewer
-description: Reviews NHibernate queries and LINQ expressions for c-entron.NET. Detects N+1 queries, cartesian products, and compatibility issues. Use when writing complex queries or experiencing performance problems. Keywords: NHibernate, LINQ, query, performance, N+1, optimization, Fetch.
----
-
-# NHibernate Query Reviewer Agent
-
-> **Type**: Review / Analysis
-> **Purpose**: Review database queries to ensure efficiency, proper structure, and compatibility with NHibernate's LINQ provider limitations.
-
-## Agent Role
-
-You are a specialized **NHibernate Query Reviewer** for the c-entron.NET solution, focused on query optimization and performance.
-
-### Primary Responsibilities
-
-1. **N+1 Detection**: Identify and fix lazy loading issues that cause multiple database roundtrips
-2. **Performance Analysis**: Review queries for cartesian products, missing indexes, and inefficient patterns
-3. **NHibernate Compatibility**: Ensure LINQ expressions translate correctly to SQL
-4. **Best Practices**: Enforce soft delete filtering, eager loading strategies, and proper transaction usage
 
-### Core Capabilities
+Die Stakeholder-Validierung ist das zentrale Verifikationsverfahren dieser Arbeit. Sie ist nicht als nachgelagerter Schritt gedacht, sondern bildet das Maß, an dem die KI-Ergebnisse gemessen werden. Plausibel formulierte LLM-Ausgaben sind nicht hinreichend. Eine Anforderung gilt erst dann als belastbar, wenn sie durch einen Domänenexperten geprüft und bestätigt wurde.
 
-- **N+1 Query Detection**: Identify lazy loading in loops causing performance degradation
+Vorgesehen sind bis zu drei Validatoren mit jeweils mehrjähriger Erfahrung in der c-entron-Codebasis und in den fachlich abgedeckten Geschäftsprozessen. Da im Unternehmen nicht mehr für jeden Fachbereich ein dedizierter Experte verfügbar ist, kann eine vollständige modulweise Abdeckung durch bereichsspezifische Validatoren nicht garantiert werden. Die Validatorengruppe deckt die Codebasis stattdessen in Summe ab. Die Teilnehmer sind bereits identifiziert; der Interview-Leitfaden ist im Anhang dokumentiert.
-- **Cartesian Product Prevention**: Detect multiple Fetch operations on collections
-- **LINQ Compatibility**: Validate expressions work with NHibernate's LINQ provider
-- **Optimization Recommendations**: Suggest Fetch, FetchMany, Future queries for better performance
-- **Soft Delete Validation**: Ensure all queries filter IsDeleted records
 
-## When to Invoke This Agent
+Für die Validierung wird pro Versuchslauf eine Zufallsstichprobe aus den extrahierten Anforderungen gezogen und auf die bis zu drei Teilnehmer verteilt. Die Stichprobengröße wird vor Versuchsbeginn festgelegt und im Versuchsprotokoll dokumentiert. Eine bereichs- oder risikoklassenspezifische Stratifizierung ist nicht vorgesehen, da die personelle Verfügbarkeit der Fachexperten eine flächendeckende Modulabdeckung nicht zulässt.
 
-This agent should be activated when:
+Jede Anforderung wird entlang von sechs Dimensionen bewertet:
-- Complex LINQ queries are written
-- Performance issues suspected with database access
-- Need query optimization recommendations
-- Validating NHibernate compatibility of LINQ expressions
-- Reviewing data access code for N+1 problems
-- Before committing database access code
 
-**Trigger examples:**
+/ Sachliche Korrektheit: Beschreibt die Anforderung das tatsächliche Systemverhalten?
-- "Review this query for N+1 problems"
+/ Vollständigkeit: Sind Akteur, Vorbedingung und Ergebnis ausreichend spezifiziert?
-- "Optimize the GetAccountContracts query"
+/ Verständlichkeit: Lässt sich die Anforderung ohne Rückfrage interpretieren?
-- "Check if this LINQ expression will work with NHibernate"
+/ Redundanzfreiheit: Ist die Anforderung von anderen klar abgegrenzt?
-- "Why is my query slow?"
+/ Übernahmewürdigkeit: Soll die Anforderung im Zielsystem in ihrer Funktion erhalten bleiben, oder ist sie ein historisch gewachsener Workaround, ein Sonderfall oder eine veraltete Logik, die im Zuge der Neuimplementierung entfallen sollte?
+/ Konsolidierungsbedarf: Bestehen andere Anforderungen, die dieselbe fachliche Funktion abbilden und im Zielsystem zu einer gemeinsamen Anforderung zusammengeführt werden sollten? Ein typisches Beispiel sind die in der bestehenden c-entron-Codebasis getrennt geführten Datensätze für Drucker („Stammblätter") und sonstige Hardware („Assets"), die im Zielsystem zu einem konsolidierten Asset-Konzept zusammengeführt werden sollen.
 
-## Technology Adaptation
+Die Bewertung erfolgt auf einer fünfstufigen Likert-Skala mit definierten Ankern an den Polen, wobei 1 für „trifft nicht zu" und 5 für „trifft voll zu" steht. Bei migrationskritischen Anforderungen ist eine doppelte Bewertung durch zwei Validatoren vorgesehen, um die Inter-Rater-Reliabilität abschätzen zu können.
 
-**IMPORTANT**: This agent adapts to c-entron.NET's NHibernate configuration.
+Ergänzend zur itemweisen Bewertung werden mit den Validatoren halbstrukturierte Interviews geführt. Themenblöcke sind die Erkennung impliziter Regeln, fehlende Stakeholder-Sichten, migrationsspezifische Risiken, der Konsolidierungsbedarf gegenüber der Zielarchitektur einschließlich der Identifikation historisch gewachsener Workarounds und Doublettenstrukturen sowie die Nützlichkeit der KI-Ergebnisse im Vergleich zu einer hypothetischen manuellen Analyse. Die Auswertung erfolgt über thematische Codierung und wird mit den itemweisen Bewertungen trianguliert.
 
-**Configuration Source**: [CLAUDE.md](../../CLAUDE.md)
+Eine Anforderung gilt im Sinne dieser Arbeit als belastbar, wenn drei Quellen sie stützen: ein konkreter Code-Beleg, eine KI-Ausgabe und eine Expertenbestätigung. Diese Triangulation reduziert das Risiko, dass eine plausibel formulierte aber inhaltlich falsche LLM-Ausgabe ungeprüft in die Spezifikation übernommen wird.
 
-Before beginning work, review CLAUDE.md for:
+#heading(level: 2)[Evaluationsrahmen]
-- **ORM**: NHibernate 5.x with FluentNHibernate
-- **Database**: SQL Server 2019+
-- **Pattern**: Always filter !x.IsDeleted
-- **Eager Loading**: Fetch/FetchMany for navigation properties
-- **Future Queries**: Batch loading for multiple collections
-- **Transactions**: Required for all modifications
 
-## Instructions & Workflow
+Der Evaluationsrahmen wird vor der Durchführung der Versuche definiert. Damit wird eine nachträgliche Anpassung der Kriterien an die Ergebnisse ausgeschlossen. Die Bewertung orientiert sich an den drei Qualitätsdimensionen, die in den theoretischen Grundlagen als Standard-Kriterien für Requirements-Sätze hergeleitet wurden.
 
-### Standard Procedure
+*Statement-Qualität.* Pro einzelner Anforderung wird gemessen, ob sie eindeutig formuliert, vollständig im Satzbau, frei von unbelegten Annahmen und mit Akzeptanzkriterium oder Prüfidee versehen ist. Die Messung erfolgt über die zuvor beschriebene Likert-Skala.
 
-1. **Load Relevant Lessons Learned** ⚠️ **IMPORTANT**
+*Set-Qualität.* Pro Spezifikations-Set, also Stakeholder-, System- und Software-Requirements, wird gemessen, ob die Menge konsistent, nicht redundant und ausreichend breit ist, ohne sich in Detailfällen zu verlieren. Dabei wird zwischen output-interner Redundanzfreiheit, also dem Fehlen von Doubletten in der vom LLM erzeugten Spezifikation, und migrationsbezogenem Konsolidierungsbedarf, also legacy-bedingt getrennt geführten Strukturen mit derselben fachlichen Funktion, unterschieden. Die Messung erfolgt qualitativ durch Expertenbewertung und ergänzend durch maschinelle Konsistenzprüfungen wie doppelte IDs oder fehlende Belege.
 
-   As a review and analysis agent, start by loading past lessons:
+*Traceability-Qualität.* Pro Beleg-Verknüpfung wird gemessen, ob der Beleg reproduzierbar auffindbar ist, etwa über Dateipfad, Methode oder SQL-Query, und ob die Ableitung vom Beleg zur Anforderung nachvollziehbar bleibt.
 
-   - Use Serena MCP `list_memories` to see available memories
+Ergänzend zur Qualitätsbewertung wird eine Aufwands-Kennzahl in hybrider Form erhoben. Sie kombiniert quantitative Indikatoren mit einer groben Stundenschätzung als Plausibilitätsprüfung. Indikatoren sind unter anderem Tokenkosten, Bearbeitungsdauer pro Modul und Anzahl der Validierungs-Iterationen. Die Stundenschätzung erfolgt als grobe Vergleichsangabe gegen ein hypothetisches manuelles Vorgehen, in dem ein erfahrener Analyst die gleichen Module ohne KI-Unterstützung dokumentiert hätte. Sie liefert keinen exakten Effizienzfaktor, sondern eine Größenordnung.
-   - Use `read_memory` to load relevant past findings:
-     - `"lesson-query-*"` - Query optimization lessons
-     - `"pattern-nhibernate-*"` - NHibernate patterns
-     - `"lesson-performance-*"` - Performance findings
-   - Apply insights from past lessons throughout review
-   - This prevents repeating past N+1 mistakes
 
-2. **Context Gathering**
+#heading(level: 2)[Reproduzierbarkeit und Risikomanagement]
-   - Review [CLAUDE.md](../../CLAUDE.md) for NHibernate patterns
-   - Use Serena MCP `find_symbol` to locate query implementations
-   - Use Serena MCP `find_referencing_symbols` to understand query usage
-   - Identify query complexity and data access patterns
 
-3. **Query Analysis**
+Reproduzierbarkeit und Risikomanagement sind als querschnittliche Aspekte angelegt. Sie betreffen alle Versuchsdurchläufe gleichermaßen und werden hier zusammengefasst.
-   - Check for N+1 query patterns (lazy loading in loops)
-   - Verify soft delete filtering (!x.IsDeleted)
-   - Validate LINQ expression compatibility
-   - Look for cartesian products (multiple Fetch on collections)
-   - Check transaction usage for modifications
-   - **Apply insights from loaded lessons**
 
-4. **Optimization**
+Alle steuerungsrelevanten Artefakte werden versioniert vorgehalten. Hierzu zählen die verwendeten Prompts in ihrer Textfassung, die Agentendateien mit ihren Rollenbeschreibungen, die MCP-Server-Konfigurationen sowie die Angaben zu Modellversion, Temperatur und Kontextfenstergröße. Für lokal betriebene Modelle werden zusätzlich die Inferenz-Runtime mit Version (LM Studio), die Quantisierungsstufe des verwendeten Modell-Builds sowie weitere Sampling-Parameter wie top\_p und repeat penalty dokumentiert, da diese Stellgrößen die Reproduzierbarkeit der Ausgaben spürbar beeinflussen. Jeder Versuchsordner enthält die vollständige Konfiguration als Single Source. Wo möglich, werden deterministische Einstellungen gewählt.
-   - Suggest Fetch/FetchMany for eager loading
-   - Recommend Future queries for multiple collections
-   - Propose projection for limited data needs
-   - Identify missing indexes
-   - **Check recommendations against past patterns**
 
-5. **Verification**
+Da die Codebasis kundenbezogene Strukturen enthält, werden datenschutzkritische Werkzeuge bewusst eingegrenzt. MCP-Server für Datenbank-Inspektion und Symbol-Navigation werden lokal betrieben. An externe LLM-Anbieter werden nur diejenigen Codeausschnitte gesendet, die für den jeweiligen Analyseschritt notwendig sind. Personenbezogene Daten oder vollständige Datenexporte sind ausgeschlossen.
-   - Estimate performance impact
-   - Verify proposed optimizations don't introduce new issues
-   - Use `/optimize` command for additional suggestions
-````
-Hinweis: Der Auszug endet nach Zeile 100; die Originaldatei umfasst 284 Zeilen und ist an dieser Stelle nicht zu Ende.
 
-#heading(level: 3)[Beispielhafte Ergebnis-Use-Cases]
+Die folgenden vier Risikokategorien werden adressiert:
 
-Quelle: `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.md`
+/ Halluzinationen: Begegnet durch Belegpflicht und Stakeholder-Validierung. Jede Anforderung ohne nachvollziehbaren Beleg wird als Hypothese markiert.
+/ Reproduzierbarkeitsverlust: Begegnet durch versionierte Prompts und deterministische Einstellungen, soweit das Modell sie unterstützt.
+/ Domänen- und Datenbias: Begegnet durch eine Stichprobenwahl, die alle relevanten Module abdeckt und nicht nur die in der KI-Ausgabe häufig auftauchenden.
+/ Datenschutzverletzungen: Begegnet durch On-Premise-MCP, kontrollierten Versand und Logging der externen Aufrufe.
 
-```text
+#heading(level: 2)[Konkrete Konfigurationen der geplanten Versuche]
-### 2. Click Counter Management (Usage-Based Billing)
-**Purpose**: Retrieve current meter readings for click counter devices
-**Use Cases**: Copy machines, printers, industrial equipment with usage meters
-Method: LoadCounterAsync(List<int> contractsI3D)
-```
 
-```text
+Dieser Abschnitt konkretisiert die zuvor beschriebene Versuchsreihe auf Konfigurationsebene. Jeder Versuch ist durch seinen Prompt, seine Agentenliste und seine MCP-Server-Liste vollständig beschrieben. Modellversion, Kontextfenster und Temperatur werden im Versuchsordner protokolliert.
-**Use Case**: Track counter reading trends, detect anomalies
-Method: IAutomatedBillingLogic.GetCounterHistory(List<string> lstParam)
-```
 
-#heading(level: 3)[MCP-Server: Detaillierte Beschreibung]
+#figure(
+  table(
+    columns: (auto, 1fr, 1fr, 1fr),
+    align: (left, left, left, left),
+    stroke: 0.4pt,
+    [*Element*], [*V1 Baseline*], [*V2 Agenten*], [*V3 MCP-Tools*],
+    [Modell], [Claude (Claude Code)], [Claude (Claude Code)], [Claude (Claude Code)],
+    [Grundprompt], [Standard-Extraktionsprompt], [Standard-Extraktionsprompt], [Standard-Extraktionsprompt],
+    [Agentendateien], [keine], [Stakeholder, System, Software, ISO-29148-Orchestrator], [Wie V2, ergänzt um codebasis-spezifische Reviewer],
+    [MCP-Server], [keine], [keine], [Symbol-Navigation, Datenbank-Inspektion, optional GUI-Beobachtung],
+    [Validierungsstichprobe], [Stratifiziert], [Stratifiziert], [Stratifiziert],
+  ),
+  caption: [Detail-Konfiguration der drei Kernversuche.],
+) <tab_versuchskonfiguration>
 
-#heading(level: 4)[MCP-Grundprinzip]
+Die Versuchsordner-Struktur folgt einer einheitlichen Konvention. Pro Versuch existiert ein Unterordner mit den Konfigurationsartefakten, ein Eingangsprotokoll mit Modell- und Werkzeugangaben, ein Ergebnis-Unterordner sowie eine Verlaufsdokumentation für die Validierungsschritte. Damit ist jeder Versuch eigenständig reproduzierbar.
-
-Model Context Protocol (MCP) definiert eine standardisierte Kopplung zwischen einem Host (hier: Claude Code), einem MCP-Client und einem oder mehreren MCP-Servern. Server stellen dabei typischerweise drei Artefaktarten bereit: `tools` (aufrufbare Funktionen), `resources` (lesbare Kontexte) und `prompts` (wiederverwendbare Prompt-Bausteine). Dieses Modell wurde in Versuch 03 genutzt, um ueber den reinen Repository-Kontext hinaus weitere Wissens- und Interaktionskanaele einzubinden @mcp_intro_2026.
-
-#heading(level: 4)[Serena MCP]
-
-Serena ist ein MCP-Server fuer semantische Code-Retrieval- und Editieroperationen auf Symbol-Ebene (z. B. `find_symbol`, `find_referencing_symbols`, `insert_after_symbol`). Im Unterschied zu rein textbasierter Suche werden Codeobjekte (Klassen, Methoden, Referenzen) strukturell adressiert. In Versuch 03 wurde Serena vor allem fuer gezielte Modulnavigation und die persistenten Memory-Notizen zwischen Analyseiterationen eingesetzt @serena_mcp_2026 @mcp_servers_repo_2026.
-
-#heading(level: 4)[Windows-MCP (AutoIt-basiert)]
-
-Der im Protokoll genannte Windows-MCP-Ansatz (AutoIt-basiert) realisiert Desktop-Automatisierung ueber MCP. Laut Projektbeschreibung kapselt der Server AutoIt-Funktionen als MCP-Tools und bietet zusaetzlich Ressourcen (Dateizugriff, Screenshots) sowie Prompt-Templates fuer typische Automationsaufgaben. Fuer die Fallstudie ist das relevant, weil GUI-basierte Pfade (Dialoge, Formulare, visuelle Workflows) nicht nur aus Quellcode, sondern auch aus Interaktionsablaeufen rekonstruiert werden koennen @windows_mcp_autoit_2026.
-
-#heading(level: 4)[MSSQL MCP]
-
-MSSQL MCP ermoeglicht den kontrollierten Zugriff auf Microsoft SQL Server ueber MCP. Typische Funktionen sind Tabellenauflistung, Schema-Inspektion, Lesen von Inhalten und kontrollierte SQL-Ausfuehrung. Die dokumentierten Security-Hinweise betonen Least-Privilege-Berechtigungen, restriktive Verbindungskonfigurationen und Logging. In Versuch 03 wurde dieser Zugriff fuer die funktionale Absicherung von Datenmodellen und Use-Case-Hypothesen genutzt @mssql_mcp_2026.
-
-#heading(level: 3)[Einordnung]
-
-Durch die MCP-Erweiterung konnte Versuch 03 die funktionale Breite deutlich steigern und einen grossen Dokumentations-Gap sichtbar machen. Gegenueber Versuch 02 sinkt dabei der formale ISO-Fokus, was fuer Discovery jedoch methodisch beabsichtigt war.
-
-#heading(level: 2)[Quellenhinweis]
-
-Die fuer dieses Kapitel genutzten Webquellen zu Claude Code und MCP-Servern sind im Literaturverzeichnis als Online-Quellen erfasst; die inhaltliche Referenzierung erfolgt direkt im Text der Abschnitte zu Versuch 03.
 
+#heading(level: 2)[Überleitung]
 
+Mit der vorangegangenen Methodikbeschreibung ist das Untersuchungsdesign vollständig dokumentiert. Das folgende Kapitel beschreibt die Durchführung der geplanten Versuche und stellt die erzeugten Ergebnisartefakte vor. Daran schließt sich die Anwendung des hier definierten Evaluationsrahmens auf die Ergebnisse an. Den Abschluss bildet die Diskussion der gewonnenen Erkenntnisse im Hinblick auf die vier Forschungsleitfragen.

Kapitel/04_konzeption_methodisches_vorgehen_VarianteA.typ

@@ -0,0 +1,18 @@
+#let __is_thesis = context { query(<__thesis_document>).len() > 0 }
+#if __is_thesis == false [
+  #set cite(style: "apa")
+  #hide(bibliography("../literatur.bib", style: "apa"))
+]
+
+#heading(level: 1)[Konzeption und methodisches Vorgehen (ca. 12 Seiten)]
+
+// TODO Variante B – wird abschnittsweise gefüllt:
+// 4.1 Forschungsdesign-Überblick
+// 4.2 Bezugsrahmen: Der RRE-Prozess als Untersuchungsgegenstand
+// 4.3 Werkzeugbasis: LLM-Auswahl und Claude Code
+// 4.4 Untersuchungsdesign: Tooling-Ablation als kontrollierte Variation
+// 4.5 Stakeholder-Validierung als zentrales Verifikationsverfahren
+// 4.6 Evaluationsrahmen
+// 4.7 Reproduzierbarkeit und Risikomanagement
+// 4.8 Konkrete Konfigurationen der drei Versuche
+// 4.9 Überleitung

Kapitel/05_prototypische_umsetzung.typ

@@ -6,172 +6,5 @@
 
 #heading(level: 1)[Ergebnisse (ca. 10 Seiten)]
 
-Dieses Kapitel dokumentiert die tatsaechlich erzeugten Ergebnisse der drei Versuche (V01-V03). Neben den Kennzahlen werden die Ergebnisartefakte aus den jeweiligen Ergebnisverzeichnissen strukturiert aufgelistet und durch exemplarische Requirements bzw. Use Cases belegt.
+// TODO Variante B – Inhalte aus 05_prototypische_umsetzung_VarianteA.typ übernehmen
-
+// und explizit als „Ergebnisse der Versuche" strukturieren (keine Versuchs-Logbuch-Optik).
-#heading(level: 2)[Ergebnisueberblick]
-
-#table(
-  columns: (1fr, 1fr, 1fr, 1fr),
-  stroke: 0.4pt,
-  [**Kennzahl**], [**V01**], [**V02**], [**V03**],
-  [Konsolidierte Anforderungen/Faehigkeiten], [277], [220], [1720],
-  [Formale Anforderungen (StRS+SyRS+SwRS)], [277], [220], [0],
-  [Explizite Use Cases], [0], [46], [1720],
-  [Undokumentierte Use Cases], [n.v.], [n.v.], [1211],
-  [ISO-29148-Compliance], [qualitativ A+], [96,1%], [n.v.],
-  [Traceability], [100% laut Doku], [100% bidirektional], [n.v.],
-  [Ergebnisdateien gesamt], [11], [37], [30]
-)
-
-#heading(level: 2)[V01 Ergebnisse (Baseline)]
-
-#heading(level: 3)[Ergebnisdateien in `Versuche/Versuch 01/Ergebnisse`]
-
-- `Versuche/Versuch 01/Ergebnisse/Centron_Software_Requirements_Specification.md`
-- `Versuche/Versuch 01/Ergebnisse/Centron_Software_Requirements_Specification.pdf`
-- `Versuche/Versuch 01/Ergebnisse/complete-iso29148-requirements-specification.md`
-- `Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md`
-- `Versuche/Versuch 01/Ergebnisse/iso29148-integrated-requirements-analysis.md`
-- `Versuche/Versuch 01/Ergebnisse/iso29148-integrated-requirements-analysis.pdf`
-- `Versuche/Versuch 01/Ergebnisse/nhibernate-orm-analysis.md`
-- `Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.md`
-- `Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.pdf`
-- `Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.md`
-- `Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.pdf`
-
-#heading(level: 3)[Beispielhafte Requirements aus den Ergebnisdateien]
-
-```text
-StR-001: Comprehensive Customer Account Management
-Statement: The system shall provide comprehensive customer account management capabilities...
-(Quelle: ISO29148_Complete_Requirements_Specification.md)
-```
-
-```text
-FR-001: User Authentication System
-Requirement: The system shall provide secure user authentication...
-(Quelle: system/SyRS_Complete_Detailed.md)
-```
-
-#heading(level: 2)[V02 Ergebnisse (ISO-Konsolidierung mit Agenten)]
-
-#heading(level: 3)[Ergebnisdateien in `Versuche/Versuch 02/Ergenisse`]
-
-- `Versuche/Versuch 02/Ergenisse/COMPLETE_REQUIREMENTS_SPECIFICATION.md`
-- `Versuche/Versuch 02/Ergenisse/COMPLETE_REQUIREMENTS_SPECIFICATION.pdf`
-- `Versuche/Versuch 02/Ergenisse/README.md`
-- `Versuche/Versuch 02/Ergenisse/TABLE_FORMATTING_STATUS.md`
-- `Versuche/Versuch 02/Ergenisse/.execution_state/baseline_metrics.json`
-- `Versuche/Versuch 02/Ergenisse/.execution_state/directory_setup.txt`
-- `Versuche/Versuch 02/Ergenisse/.execution_state/milestone_state.json`
-- `Versuche/Versuch 02/Ergenisse/.execution_state/project_structure.json`
-- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Executive_Summary.md`
-- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Master_Requirements.md`
-- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Quality_Report.md`
-- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Traceability_Master.csv`
-- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Validation_Checklist.md`
-- `Versuche/Versuch 02/Ergenisse/software/Analysis_Complete.md`
-- `Versuche/Versuch 02/Ergenisse/software/Business_Rules.md`
-- `Versuche/Versuch 02/Ergenisse/software/Integration_Patterns.md`
-- `Versuche/Versuch 02/Ergenisse/software/Pattern_Catalog.csv`
-- `Versuche/Versuch 02/Ergenisse/software/Performance_Patterns.md`
-- `Versuche/Versuch 02/Ergenisse/software/Security_Patterns.md`
-- `Versuche/Versuch 02/Ergenisse/software/SwRS_Algorithms.md`
-- `Versuche/Versuch 02/Ergenisse/software/SwRS_CodeCatalog.md`
-- `Versuche/Versuch 02/Ergenisse/software/SwRS_Complete.md`
-- `Versuche/Versuch 02/Ergenisse/software/SwRS_DataModel.md`
-- `Versuche/Versuch 02/Ergenisse/software/SwRS_TestSpecification.md`
-- `Versuche/Versuch 02/Ergenisse/software/SwRS_Traceability.csv`
-- `Versuche/Versuch 02/Ergenisse/software/Validation_Rules.md`
-- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Complete.md`
-- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Diagrams.md`
-- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Evidence.md`
-- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Summary.md`
-- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Traceability.csv`
-- `Versuche/Versuch 02/Ergenisse/system/SyRS_API_Specification.yaml`
-- `Versuche/Versuch 02/Ergenisse/system/SyRS_Architecture.md`
-- `Versuche/Versuch 02/Ergenisse/system/SyRS_Complete.md`
-- `Versuche/Versuch 02/Ergenisse/system/SyRS_Interfaces.md`
-- `Versuche/Versuch 02/Ergenisse/system/SyRS_Summary.md`
-- `Versuche/Versuch 02/Ergenisse/system/SyRS_Traceability.csv`
-
-#heading(level: 3)[Beispielhafte Requirements aus den Ergebnisdateien]
-
-```text
-SyR-001: The system SHALL implement a multi-layered architecture with clear separation of concerns.
-(Quelle: Ergenisse/system/SyRS_Complete.md)
-```
-
-```text
-SyR-013: The system SHALL provide secure user authentication with multi-factor authentication support.
-(Quelle: Ergenisse/system/SyRS_Complete.md)
-```
-
-```text
-SW-ARCH-001: The software SHALL implement a 6-layer architecture pattern.
-(Quelle: Ergenisse/software/SwRS_Complete.md)
-```
-
-#heading(level: 2)[V03 Ergebnisse (Discovery-Erweiterung mit Agenten und MCP)]
-
-#heading(level: 3)[Ergebnisdateien in `Versuche/Versuch 03/ERP_DOCUMENTATION`]
-
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/ANALYSIS_SUMMARY.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/BUSINESS_GLOSSAR_MIT_DB_MAPPING.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/BUSINESS_GLOSSAR.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/BUSINESS_GLOSSAR.pdf`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/COMPLETE_DATABASE_SCHEMA.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/DOCUMENTATION_INDEX.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/EXPORT_COMPLETE_SCHEMA.sql`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/README_USE_CASE_ANALYSIS.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/README.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/SCREENSHOT_ANALYSIS_SUMMARY.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/SCREENSHOT_MAPPING_COMPLETE.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/SCREENSHOT_PROJECT_INDEX.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/SSMS_DB_SCHEMA.sql`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_REST_API.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_WORKFLOWS.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASE_ANALYSIS_README.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASE_MAPPING.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS_DE.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS_DE.pdf`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.pdf`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW_CONTROLLERS.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW_GUI_MAPPING.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW_IMPLEMENTATION_GUIDE.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW_XAML_TEMPLATES.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.md`
-- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.pdf`
-
-#heading(level: 3)[Beispielhafte Use Cases aus den Ergebnisdateien]
-
-```text
-1.1.1 Personalized User Welcome
-Purpose: Display personalized greeting with user name and context-aware dashboard content.
-(Quelle: ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md)
-```
-
-```text
-1.1.6 Work Status Alerts
-Purpose: Alert users to missing or incomplete work time entries.
-(Quelle: ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md)
-```
-
-```text
-Key Finding: 1,720+ use cases discovered; current documentation gap: 71%.
-(Quelle: ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md)
-```
-
-#heading(level: 2)[Ergebnisfazit]
-
-Die Ergebnislage zeigt drei komplementaere Stufen:
-
-- **V01** liefert eine belastbare formale Baseline.
-- **V02** liefert die staerkste ISO-29148-konforme Konsolidierung mit hoher Traceability.
-- **V03** liefert die groesste funktionale Breite und identifiziert den groessten Dokumentations-Gap.
-
-Damit liegt eine vollstaendige empirische Grundlage fuer die anschliessende Evaluation (Kapitel 6) vor: formal-strukturierte Requirements (V01/V02) plus breite Discovery-Evidenz (V03).

Kapitel/05_prototypische_umsetzung_VarianteA.typ

@@ -0,0 +1,10 @@
+#let __is_thesis = context { query(<__thesis_document>).len() > 0 }
+#if __is_thesis == false [
+  #set cite(style: "apa")
+  #hide(bibliography("../literatur.bib", style: "apa"))
+]
+
+#heading(level: 1)[Ergebnisse (ca. 10 Seiten)]
+
+// TODO Variante B – Inhalte aus 05_prototypische_umsetzung_VarianteA.typ übernehmen
+// und explizit als „Ergebnisse der Versuche" strukturieren (keine Versuchs-Logbuch-Optik).

Kapitel/06_evaluation.typ

@@ -6,119 +6,5 @@
 
 #heading(level: 1)[Evaluation (ca. 12 Seiten)]
 
-Die Evaluation folgt der in Kapitel 4 beschriebenen Iterationslogik und bewertet die drei real durchgefuehrten Versuche (V01-V03) vergleichend. Ziel ist nicht die Darstellung eines einzelnen "besten" Laufs, sondern die Einordnung der methodischen Entwicklung von einer Baseline ueber eine formale ISO-Konsolidierung bis zur anschliessenden Discovery-Erweiterung.
+// TODO Variante B – Anwendung des in Kap 4.6 definierten Evaluationsrahmens auf die
-
+// Ergebnisse aus Kap 5. Keine Erst-Definition von Kriterien hier.
-#heading(level: 2)[Evaluationsdesign und Datenbasis]
-
-Die Auswertung basiert ausschliesslich auf den erzeugten Artefakten in:
-
-- `Versuche/Versuch 01/Versuch01.md` und `Versuche/Versuch 01/Requirements.md`,
-- `Versuche/Versuch 02/Versuch02.md` und `Versuche/Versuch 02/Requirements.md`,
-- `Versuche/Versuch 03/Versuch03.md` und `Versuche/Versuch 03/Requirements.md`.
-
-Dabei wurden nur konsolidierte, in den Dateien ausgewiesene Kennzahlen uebernommen. Fokus der Bewertung:
-
-1. Umfang der rekonstruierten Faehigkeiten/Requirements,
-2. Formalisierungsgrad (StRS/SyRS/SwRS vs. reine Use-Case-Discovery),
-3. Traceability- und ISO-29148-Naehe,
-4. methodischer Nutzen der eingesetzten Tooling-Konfiguration.
-
-#heading(level: 2)[Quantitative Ergebnisse der Versuchsreihe]
-
-#table(
-  columns: (1fr, 1fr, 1fr, 1fr),
-  stroke: 0.4pt,
-  [**Kennzahl**], [**V01**], [**V02**], [**V03**],
-  [Konsolidierte Requirements/Faehigkeiten], [277], [220], [1720],
-  [Formale Requirements (StRS+SyRS+SwRS)], [277], [220], [0],
-  [StRS / SyRS / SwRS], [35 / 75 / 167], [84 / 53 / 83], [0 / 0 / 0],
-  [Explizite Use Cases], [0], [46], [1720 (Use-Case-fokussiert)],
-  [Undokumentierte Use Cases], [n.v.], [n.v.], [1211],
-  [ISO-29148-Compliance], [qualitativ A+], [96,1% (100% mandatory)], [n.v.],
-  [Traceability], [100% laut Doku], [100% bidirektional], [n.v.],
-  [Ergebnisdateien gesamt], [11], [37], [30]
-)
-
-Ergaenzende Kontextkennzahlen aus den Versuchsdateien:
-
-- V01: Analyse von 34 C\#-Projekten und 12.507+ Source Files.
-- V02: 14.940 Dateien (13.717 C\#, 1.189 XAML, 34 Projekte), 46 explizite Use Cases in die formale Requirements-Struktur integriert.
-- V03: 150.000+ LoC analysiert, 3.412 potenzielle Use Cases identifiziert, 71% dokumentationsbezogener Gap (1211 von 1720 Use Cases vormals undokumentiert).
-
-#heading(level: 2)[Vergleichende Analyse]
-
-#heading(level: 3)[Versuch 01: Formale Baseline ohne Tooling-Erweiterung]
-
-V01 zeigt, dass bereits ohne Agenten/MCP eine formal strukturierte Requirements-Spezifikation erzeugt werden kann. Die Staerke liegt in der klaren Dreiebenenstruktur (StRS/SyRS/SwRS). Die Schwaeche ist die begrenzte Discovery-Perspektive: explizite Use-Case-Rekonstruktion und Gap-Bewertung bleiben gering ausgepraegt.
-
-#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V01)]
-
-- **Verwendeter Prompt:** "Please analyze this software project and write a reuqirements specification according to modern standards."
-- **Agentenbeispiele:** Keine Agenten (bewusste Baseline ohne agentische Zerlegung und ohne MCP).
-- **Beispielhafte Ergebnis-Requirements:**
-  - `Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md`: u. a. `StR-001` (Comprehensive Customer Account Management).
-  - `Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.md`: u. a. `FR-001` (User Authentication System) und `FR-002` (Role-Based Access Control).
-  - `Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.md`: softwareseitige Architektur- und Umsetzungsanforderungen im SwRS-Format.
-
-#heading(level: 3)[Versuch 02: ISO-orientierte Konsolidierung mit Agenten]
-
-V02 fokussiert die formale Konsolidierung und liefert eine ISO-29148-nahe Zielstruktur mit hoher Traceability. Mit 220 konsolidierten Requirements, 96,1% ISO-29148-Compliance und 100% bidirektionaler Traceability ist der Lauf methodisch sauber und reviewfaehig. Gleichzeitig zeigte sich die zentrale Grenze dieses Schritts: Die reine ISO-orientierte Ableitung war fuer den Gesamtumfang zu rigide und fuer die Discovery-Breite nicht vollumfaenglich genug.
-
-#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V02)]
-
-- **Verwendeter Prompt:** "Please analyze this software project and write a ISO 29148 compliant reuqirements specification. Use Agents wherever possible."
-- **Agentenbeispiele:**
-  - `Versuche/Versuch 02/Tools/agents/iso29148-master-orchestrator-agent.md`
-  - `Versuche/Versuch 02/Tools/agents/iso29148-stakeholder-agent.md`
-  - `Versuche/Versuch 02/Tools/agents/iso29148-system-requirements-agent.md`
-  - `Versuche/Versuch 02/Tools/agents/iso29148-software-requirements-agent`
-- **Beispielhafte Ergebnis-Requirements:**
-  - `Versuche/Versuch 02/Ergenisse/system/SyRS_Complete.md`: u. a. `SyR-001` (Multi-Layer Architecture), `SyR-002` (Dual Data Access Pattern), `SyR-013` (Authentication).
-  - `Versuche/Versuch 02/Ergenisse/software/SwRS_Complete.md`: u. a. `SW-ARCH-001` (6-Layer Architecture), `SW-ARCH-002` (ILogic-Pattern), `SW-FUNC-001` (Account Management).
-  - `Versuche/Versuch 02/Ergenisse/master/ISO29148_Quality_Report.md`: qualitaetssichernde Gesamtbewertung (u. a. 100% Traceability).
-
-#heading(level: 3)[Versuch 03: Discovery-Erweiterung mit Agenten und MCP]
-
-V03 erweitert deshalb die Methodik um MCP-gestuetzte Discovery. Der Lauf vergroessert die funktionale Breite deutlich (1720 konsolidierte Faehigkeiten, davon 1211 vormals undokumentierte Use Cases) und eignet sich besonders fuer Gap-Analysen und Vollstaendigkeitspruefung. Die Kehrseite ist ein geringerer Formalisierungsgrad gegenueber der ISO-Konsolidierung.
-
-#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V03)]
-
-- **Verwendeter Prompt:** "Please analyze this software project and write a reuqirements specification according to modern standards. Use Agents and MCP servers wherever possible. Keep superflous texts to a minimum and concentrate on actual requirements."
-- **Agentenbeispiele:**
-  - `Versuche/Versuch 03/Tools/Agents/centron-documentation-writer.md`
-  - `Versuche/Versuch 03/Tools/Agents/nhibernate-query-reviewer.md`
-  - `Versuche/Versuch 03/Tools/Agents/centron-code-reviewer.md`
-  - `Versuche/Versuch 03/Tools/Agents/webservice-developer.md`
-- **MCP-Beispiele:** Serena-MCP (Memory), Windows-MCP (UI-Interaktion), MSSQL-MCP (DB-Schemazugriff).
-- **Beispielhafte extrahierte Use-Case-/Anforderungsartefakte:**
-  - `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md`: u. a. Use Cases `1.1.1` (Personalized User Welcome), `1.1.6` (Work Status Alerts), `3.1` (Quick Ticket Creation).
-  - `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.md`: moduluebergreifende, strukturierte Use-Case-Dokumentation fuer c-entron.NET.
-  - `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md`: 1.720+ Use Cases und ca. 71% Dokumentations-Gap als Discovery-Nachweis.
-
-#heading(level: 2)[Abgleich mit den geplanten Methoden]
-
-Der Soll-Ist-Abgleich zeigt eine hohe Passung zur geplanten Gesamtmethodik, wenn diese als iterative Kombination aus *Discovery* und *Konsolidierung* verstanden wird:
-
-- Die Standardrecherche (ISO/IEC/IEEE 29148) wurde fruehzeitig umgesetzt.
-- Ein Baseline-Lauf ohne Spezialisierung wurde durchgefuehrt (V01).
-- Eine strukturierte ISO-Konsolidierung wurde realisiert (V02).
-- Danach wurde die Abdeckung durch MCP-gestuetzte Discovery erweitert (V03), weil der ISO-Lauf allein zu rigide und nicht vollumfaenglich genug war.
-
-Abweichung zur urspruenglich linearen Planung: Stakeholder-Interviews und flaechendeckende fachliche Reviews wurden in der betrachteten Phase noch nicht vollstaendig abgeschlossen. Die Methodik wird deshalb in der Ergebnisinterpretation als "technisch validierte Vorstufe" einer finalen fachlichen Konsolidierung eingeordnet.
-
-#heading(level: 2)[Bewertung der Forschungsleitfragen auf Basis der aktuellen Evidenz]
-
-- **F1 (reproduzierbarer LLM-Einsatz):** beantwortbar. Die drei Versuche zeigen, dass reproduzierbare Prozessschritte und klar unterscheidbare Konfigurationen moeglich sind.
-- **F2 (Ableitung aus Code vs. Zusatzquellen):** teilweise beantwortbar. Codebasierte Extraktion funktioniert, video- und interviewbasierte Ergaenzungen sind noch offen.
-- **F3 (Qualitaet aus Expertensicht):** noch nicht abschliessend beantwortbar, da systematische Expertenratings nicht vollstaendig dokumentiert vorliegen.
-- **F4 (Chancen und Grenzen):** beantwortbar. Chancen liegen in Skalierung und Strukturierung; Grenzen in Halluzinationsrisiken, fehlender Vollstaendigkeit ohne Zusatzquellen und hohem Konsolidierungsbedarf.
-
-#heading(level: 2)[Limitationen]
-
-Die aktuelle Evidenz ist durch drei Punkte begrenzt:
-
-1. Vollstaendige Video-Transkription und -Auswertung fehlen noch.
-2. Ein methodischer Endabgleich zwischen Video- und Codeperspektive ist noch nicht abgeschlossen.
-3. Die fachliche Endklassifikation aller Use-Case-Cluster (Ja/Nein/Neu/TBD) liegt noch nicht durchgaengig vor.
-
-Diese Limitationen betreffen vor allem die finale Vollstaendigkeitsaussage, nicht jedoch die grundlegende Wirksamkeit der iterativen Methodik.

Kapitel/06_evaluation_VarianteA.typ

@@ -0,0 +1,10 @@
+#let __is_thesis = context { query(<__thesis_document>).len() > 0 }
+#if __is_thesis == false [
+  #set cite(style: "apa")
+  #hide(bibliography("../literatur.bib", style: "apa"))
+]
+
+#heading(level: 1)[Evaluation (ca. 12 Seiten)]
+
+// TODO Variante B – Anwendung des in Kap 4.6 definierten Evaluationsrahmens auf die
+// Ergebnisse aus Kap 5. Keine Erst-Definition von Kriterien hier.

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"
 )
@@ -41,8 +41,11 @@
   #include "Kapitel/01_einleitung.typ"
   #include "Kapitel/02_theoretischer_hintergrund.typ"
   #include "Kapitel/03_fallstudie.typ"
+  #pagebreak()
   #include "Kapitel/04_konzeption_methodisches_vorgehen.typ"
+  #pagebreak()
   #include "Kapitel/05_prototypische_umsetzung.typ"
+  #pagebreak()
   #include "Kapitel/06_evaluation.typ"
   #include "Kapitel/07_diskussion.typ"
   #include "Kapitel/08_fazit_ausblick.typ"

Stilvorlage.md

@@ -23,6 +23,11 @@ Leitfaden, um den Schreibstil der in `StilVorlagen` vorhandenen Dokumente für K
 5. **Listen für Kernaussagen:** Risiken, Ziele, Materialien, Fragen etc. werden häufig als Bullet- oder Nummernlisten dargestellt.
 6. **Zeitform und Perspektive:** Vergangene Versuche im Präteritum ("wir führten durch"), allgemeine Beschreibungen im Präsens. Häufig "wir" oder passive Konstruktionen.
 7. **Keine Gender-Doppelpunkt-Formen:** Personengruppen werden ohne Doppelpunkte oder Binnen-I angesprochen (z.B. "Entwickler" statt "Entwickler:innen"), analog zu den Vorlagendokumenten.
+8. **Mehr Fließtext, sparsame Listen:** Bullet- und Nummernlisten nur dann, wenn die Punkte klar parallel sind (Materialien, Anforderungen, Risiken). Erklärende Inhalte und Schlussfolgerungen gehören in Fließtext.
+9. **Keine Gedankenstrich-Einschübe in Sätzen:** Sätze werden nicht über Gedankenstriche („— …, …, … —") parenthetisch erweitert. Stattdessen entweder Komma-getrennte Nebensätze, Klammer-Einschübe oder ein eigener Satz.
+10. **Referenzen am Satzende:** Quellenangaben (z.B. `@iso25010_2011`, `(Boser et al. 1992)`) stehen am Ende des Satzes, nicht inmitten des Fließtextes.
+11. **Doppelpunkt nur vor Listen oder innerhalb von Listeneinträgen nach der Überschrift:** Ein Doppelpunkt steht entweder als Einleitung einer Aufzählung/Liste oder innerhalb eines Listeneintrags direkt nach einer beschreibenden Wortgruppe (z.B. `*Form* beeinflusst Interpretierbarkeit: Erklärung …`). Im normalen Fließtext zur Anbindung weiterer Aussagen ist er nicht zulässig. Statt „Zunächst gilt X: Es muss Y." → „Zunächst gilt X. Y muss …".
+12. **Schlagwort-Listen als Typst-Termlisten:** Inhaltliche Listen mit fettem Schlagwort und nachfolgendem Erklärtext werden im Quelltext als Typst-Termliste geschrieben: `/ Schlagwort: Erklärungstext`. Der bisherige Markdown-Stil `- *Schlagwort:* Text` ist nicht mehr zu verwenden. Das Rendering (Schlagwort fett auf eigener Zeile, Erklärtext darunter, vertikale Trennung zwischen Einträgen) ist zentral in `masterarbeit_style.typ` über `#show terms.item` und `#set terms` festgelegt und muss nicht im Fließtext nachgebaut werden. Nummerierte Listen bleiben in der Form `1. *Titel:* Text` erhalten.
 
 ## 2. Strukturbausteine pro Dokumenttyp
 

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

masterarbeit_style.typ

@@ -59,14 +59,16 @@
   #content
 ]
 
-#let body_show() = [
+#let body_show() = []
+
+#let body_content(children) = [
   #set page(
     paper: "a4",
     margin: (top: 25mm, bottom: 25mm, inside: 30mm, outside: 20mm),
-    numbering: "1"
+    numbering: "1",
   )
   #set text(font: "Times New Roman", size: 11pt)
-  #set par(justify: true, leading: 14pt, first-line-indent: 5mm)
+  #set par(justify: true)
   #set list(indent: 6mm, spacing: 2mm)
   #set enum(numbering: "a)")
   #set heading(numbering: "1.1.1", depth: 3)
@@ -82,10 +84,15 @@
     #set text(size: 12pt, weight: "semibold")
     #it
   ]
-
+  #set terms(separator: [], hanging-indent: 0pt, tight: false)
-]
+  #show terms.item: it => block(below: 0.8em, [
-
+    #strong(it.term) \
-#let body_content(children) = [
+    #it.description
+  ])
+  #show terms: it => {
+    it
+    v(2cm)
+  }
   // Markdown-like styling for fenced code blocks.
   #show raw: set text(font: "DejaVu Sans Mono", size: 9.5pt, fill: luma(20))
   #show raw.where(block: true): it => block(