Reorganzied Versuche

.gitignore

@@ -0,0 +1 @@
+

.vscode/settings.json

@@ -0,0 +1 @@
+{}

Kapitel/00_abstract.typ

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

Kapitel/01_einleitung.typ

@@ -1,20 +1,22 @@
 #heading(level: 1)[Einleitung (ca. 8 Seiten)]
 
 #heading(level: 2)[Ausgangssituation und Motivation]
-In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre gewachsenen Systeme neu zu bewerten. Besonders ERP-Lösungen, die über Jahrzehnte in Windows-Umgebungen gepflegt wurden, stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen. Dokumentierte Architekturentscheidungen sind selten, implizites Wissen steckt in Source-Control-Systemen oder bei einzelnen Entwickler:innen.
+In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre Produkte neu zu bewerten. Betroffen sind vor allem Systeme, die über lange Jahre ausschließlich in Windows-Umgebungen vertrieben wurden. Diese stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen und häufen zunehmend technische Schulden an. Eine technologische Weiterentwicklung wird zusehends schwieriger, und an einer Neuentwicklung führt oft kein Weg vorbei. Dokumentierte Anforderungen oder eine systematische Code-Dokumentation sind allerdings selten. Der Großteil des Wissens steckt implizit im Code oder in den Köpfen der verbleibenden 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 unmittelbar 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 jedoch eng mit der bisherigen Client/Server-Architektur gekoppelt. Kunden erwarten inzwischen plattformunabhängige Oberflächen, Self-Service-Funktionen und flexible Betriebsmodelle wie SaaS (Software as a Service). Die bestehende Anwendung ist in Skalierung, Deployment und Abrechnung jedoch limitiert, sodass eine Migration auf eine webbasierte Plattform zwingend erforderlich wird.
 
-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 Neuimplementierung auf Basis vorhandener Anforderungs- oder Code-Dokumentation ist aus den oben genannten Gründen kaum möglich. Die Herausforderung besteht darin, mit möglichst geringem Aufwand eine vollständige Beschreibung eines komplexen ERP-Systems zu erarbeiten. Eine manuelle Auswertung von Code und Oberflächen auf Funktionalitäten ist angesichts der Komplexität, die aus der langjährigen Weiterentwicklung resultiert, nur mit sehr hohem Personalaufwand möglich und daher nicht realisierbar.
+
+In den vergangenen Jahren hat sich hierzu ein neues Instrumentarium etabliert. Large Language Models wie ChatGPT-5 oder Claude.ai können in Verbindung mit agentischen 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 setzt an dieser Stelle an und untersucht, wie KI-gestützte Verfahren für eine systematische Anforderungsanalyse 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 zeit- und ressourcenintensiv sowie 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.
-- **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.
-- **Implizites Wissen:** Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen.
-- **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.
+/ Re-Implementationsfehler: Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration. Workarounds sind zugleich Symptom einer mangelhaften Anforderungserfassung in der ursprünglichen Implementierung und Zeichen fehlender Weitsicht.
+/ 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 mit den alten Technologien nicht vertraut, und es fehlt ihnen 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. 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 umgesetzt").
+/ 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. Große Teile des Codes sind zudem generisch und lassen sich keiner konkreten Anforderung zuordnen, etwa das Anzeigen einer Tabelle. Konkrete Datenflüsse lassen sich nur am laufenden System beobachten, was die Analyse um eine weitere Größenordnung ressourcenintensiver macht.
 
 Eine rein manuelle Rekonstruktion aller Anforderungen wäre wirtschaftlich kaum tragbar. Deshalb soll geprüft werden, ob KI-gestützte Verfahren Requirements so extrahieren können, dass sie als belastbare Basis für die Modernisierung dienen.
 
@@ -23,29 +25,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?
-- **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?
-- **F3 - 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?
+1. *Einsatz von LLMs im Reverse Requirements Engineering:* Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?
+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?
+3. *Qualitätsbewertung der generierten Requirements:* Wie beurteilen Fachexperten Vollständigkeit, Verständlichkeit, Nützlichkeit und Aufwandseinsparung der KI-Ergebnisse?
+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.
-2. **Theoretische Grundlagen:** Requirements Engineering, Reverse Engineering, Large Language Models sowie Qualitätssicherungskriterien.
-3. **Fallstudie c-entron GmbH:** Unternehmensprofil, Produktarchitektur, Migrationsdruck und Rahmenbedingungen.
-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.
-6. **Evaluation:** Vorgehen, Metriken, Ergebnisse und Expertenfeedback.
-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.
+1. *Einleitung:* Kontext, Problemstellung, Ziele und Forschungsfragen.
+2. *Theoretische Grundlagen:* Requirements Engineering, Reverse Engineering, Large Language Models sowie Qualitätssicherungskriterien.
+3. *Fallstudie c-entron GmbH:* Unternehmensprofil, Produktarchitektur, Migrationsdruck und Rahmenbedingungen.
+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.
+6. *Evaluation:* Vorgehen, Metriken, Ergebnisse und Expertenfeedback.
+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.
 
-Damit entsteht eine nachvollziehbare Linie von der Ausgangssituation über das Konzept bis zur Validierung.

Kapitel/02_theoretischer_hintergrund.typ

@@ -6,368 +6,11 @@
 
 #heading(level: 1)[Theoretische Grundlagen (ca. 12 Seiten)]
 
-Dieses Kapitel beschreibt die theoretischen Grundlagen, die für die Konzeption und Bewertung eines KI-gestützten Reverse Requirements Engineering in Legacy-Umgebungen benötigt werden. Zunächst werden zentrale Begriffe des Requirements Engineering sowie die Idee der rückwärtsgerichteten Anforderungsgewinnung aus bestehenden Systemen eingeordnet. Anschließend werden Large Language Models als Werkzeugklasse im Software Engineering beschrieben, inklusive typischer Leistungsgrenzen und Absicherungsmechanismen. Abschließend werden Grundlagen der Legacy-Modernisierung sowie etablierte Migrationsstrategien zusammengefasst, um den Kontext der Fallstudie und die Zielrichtung einer webbasierten Modernisierung einzuordnen.
-
-#heading(level: 2)[Requirements Engineering und Reverse Requirements Engineering]
-
-#heading(level: 3)[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 @iso29148_2018 @ieee830_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 @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.
+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.
+
+#include "02_theoretischer_hintergrund/02_01_requirements_engineering.typ"
+#pagebreak()
+#include "02_theoretischer_hintergrund/02_02_large_language_models.typ"
+#pagebreak()
+#include "02_theoretischer_hintergrund/02_03_legacy_modernisierung.typ"
+#pagebreak()

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,272 @@
+#import "@preview/cetz:0.4.2"
+#import "@preview/cetz-plot:0.1.3": plot
+
+#set text(lang: "de")
+
+#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] <sec_re_qualitaet>
+
+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 (Vollständigkeit): Deckt die Menge der Requirements alle relevanten Prozesse und Varianten vollständig ab, ist sie in sich konsistent und frei von Doubletten? Die Vollständigkeit ist dabei die zentrale Eigenschaft, weil ein fehlendes Requirement im Migrationskontext zu Funktionsverlust führen kann, während Inkonsistenzen oder Doubletten in einem Review nachträglich aufgelöst werden können.
+/ Traceability-Qualität: Sind Belege reproduzierbar auffindbar (z. B. Dateipfad, Methode, SQL-Query), und lässt sich die Ableitung von „Beleg → Requirement" nachvollziehen?
+
+Für Legacy-Migrationen ist zudem die Fehlerkostenperspektive entscheidend. Ein fehlendes Requirement kann zu Funktionsverlust führen, ein falsches Requirement kann zu fehlerhaften Designentscheidungen führen, und ein unpräzises Requirement verursacht Review- und Nacharbeit. Daraus folgt eine pragmatische Bewertung: Requirements mit hoher Migrationskritikalität (z. B. Sicherheitsregeln, Abrechnungslogik, Berechtigungen) sollten strengere Evidenzanforderungen und intensivere Reviews erhalten als periphere Funktionen. Dieses Prinzip ist kompatibel mit der risikobasierten Priorisierung von Qualitätsanforderungen @glinz2008quality und lässt sich auf Funktionsanforderungen übertragen.
+/*
+#heading(level: 3)[Zwischenfazit zu 2.2]
+
+LLMs liefern im Software Engineering eine leistungsfähige Assistenz für Analyse, Zusammenfassung und Textproduktion, sind jedoch nicht verlässlich im Sinne formaler Korrektheit @fan2023llmse @ji2023hallucination. Für Requirements ist der entscheidende Punkt, dass die Qualität nicht an der sprachlichen Glätte, sondern an Nachvollziehbarkeit und Prüfbarkeit hängt. Daraus folgt für diese Arbeit ein designierter "Sicherheitsgurt": Evidence-First, Traceability und Human-in-the-loop sind keine Zusatzoptionen, sondern Kernelemente des Vorgehens.
+*/

Kapitel/02_theoretischer_hintergrund/02_03_legacy_modernisierung.typ

@@ -0,0 +1,59 @@
+#heading(level: 2)[Legacy-Modernisierung und Stand der Forschung]
+
+#heading(level: 3)[Charakteristika von Legacy-Systemen]
+
+Legacy-Systeme sind nicht allein durch ihr Alter, sondern durch ihren Kontext definiert. Sie tragen geschäftskritische Funktionen, sind über lange Zeit erweitert worden und weisen oft starke technische und organisatorische Abhängigkeiten auf. Typische Merkmale sind enge Kopplung, heterogene und zersplitterte Technologien, schwer austauschbare oder sogar schon abgekündigte Komponenten und unzureichende Dokumentation @bisbal1999legacy. Gerade die fehlende Dokumentation ist für Modernisierungsvorhaben problematisch, weil Entscheidungen ohne belastbare Anforderungsbasis zu Funktionsverlusten und Fehlentscheidungen führen können.
+
+Im ERP-Kontext verschärfen sich diese Merkmale häufig durch eine ausgeprägte Domänenkomplexität, da Geschäftsregeln variantenreich und teilweise kundenspezifisch sind. Hinzu kommt eine starke Datenzentrierung. Prozesse hängen stark von Datenmodellen, Stammdatenqualität und historisch gewachsenen Datenkonventionen ab. Verstärkt wird dies durch eine hohe Integrationsvielfalt, da Schnittstellen zu Drittsystemen (z. B. Buchhaltung, Shop, Dokumentenmanagement) über Jahre organisch entstanden sind.
+
+Damit wird nachvollziehbar, warum Requirements-Extraktion aus der Codebasis nicht nur ein Dokumentationsprojekt ist. Es dient zeitglich auch zur Risikoreduktion.
+
+#heading(level: 3)[Modernisierungsstrategien]
+
+Eine Modernisierung kann durch unterschiedliche Methoden umgesetz werden, von "Lift-and-Shift" bis zur vollständigen Neuimplementierung "auf der grünen Wiese". Die Literatur betont wiederholt, dass die Wahl einer Strategie von Risiko, Zielarchitektur und verfügbaren Ressourcen abhängt und daher explizit geplant werden sollte @sneed1995planning. Eine zentrale Aussage ist dabei, dass Reengineering nicht als rein technischer Umbau verstanden werden darf. Ohne fachliche Leitplanken entstehen technische Verbesserungen, die am Bedarf vorbeilaufen oder bestehende Fachlogik unabsichtlich verändern. Zudem können gewonnene fachliche Erkenntnisse ohne klare Dokumentation und Nachvollziehbarkeit nicht in die Zielarchitektur überführt werden, was zu einem erneuten Anforderungsdefizit führt.
+
+_Aus Sicht dieser Arbeit lassen sich Modernisierungsmethodiken pragmatisch entlang zweier Dimensionen einordnen: (1) Wie stark wird die bestehende Implementierung weitergenutzt? (2) Wie stark wird die Zielarchitektur verändert? Daraus ergeben sich typische Strategietypen, die in der Praxis auch kombiniert auftreten:_
+
++ *Weiterbetrieb mit Hülle (Wrapping):* Die Legacy-Logik bleibt bestehen, wird aber über neue Schnittstellen oder eine neue GUI zugänglich gemacht. Vorteil ist geringe Eingriffstiefe; Nachteil ist, dass technische Schulden und Engpässe erhalten bleiben.
++ *Schrittweise Modularisierung:* Teile der Legacy-Anwendung werden sukzessive in neue Komponenten überführt, während andere Teile weiterlaufen. Vorteil ist Risikostreuung und frühe Nutzenrealisierung; Nachteil ist erhöhte Integrationskomplexität während der Übergangsphase.
++ *Reengineering/Refactoring:* Die bestehende Logik wird strukturell überarbeitet (z. B. Entkopplung, Schichten, bessere Testbarkeit), ohne den Funktionsumfang grundsätzlich zu verändern. Vorteil ist bessere Wartbarkeit; Nachteil ist hoher Analyseaufwand, gerade ohne Requirementsbasis.
++ *Neuimplementierung mit Funktionsparität:* Die Legacy-Logik wird auf neuer Technologie nachgebaut, häufig mit dem Anspruch, zunächst funktional äquivalent zu sein. Vorteil ist saubere Zielarchitektur; Nachteil ist die hohe Abhängigkeit von vollständigen, korrekten Requirements.
+
+Für ein ERP-System ist die Wahl einer Strategie stark datengetrieben. Datenmodelle und Businesslogik definieren die Leitplanken einer Migration. Damit steigt die Wichtigkeit von Requirements, die Datenobjekte, Zustandsmodelle und Integrationspunkte ausdrücken. Besonders kritisch sind dabei Anforderungen, die in der Legacy-Implementierung als implizite Konvention existieren (z. B. Statuscodes, historische Sonderfälle, kundenspezifische Maskenlogik), weil sie ohne gezielte Extraktion und Validierung leicht verloren gehen.
+
+#heading(level: 3)[Zielarchitekturen: Web, Cloud und „Cloud-native"]
+
+Die Modernisierung vieler Legacy-Anwendungen zielt auf webbasierte, plattformunabhängige Oberflächen und auf Betriebsmodelle, die Skalierung, automatisiertes Deployment und schnelle Iteration unterstützen. Eine systematische Mapping Study fasst zusammen, welche Merkmale cloud-nativer Anwendungen in Forschung und Praxis wiederkehren @kratzke2017cloudnative. Dazu zählen typischerweise automatisierte Bereitstellung, resiliente Komponenten, horizontale Skalierung und eine stärkere Trennung von Build- und Run-Umgebungen.
+
+Im selben Zusammenhang werden Microservices häufig als Architekturstil diskutiert. Eine Analyse der Forschung zu Microservices zeigt wiederkehrende Problemfelder, unter anderem die Wahl der richtigen Servicegranularität, die erhöhte Komplexität im Betrieb und Anforderungen an Observability @pahl2016microservices. Für Migrationsprojekte ist daraus eine pragmatische Schlussfolgerung ableitbar: Modularisierung ist ein Ziel, erzeugt aber zugleich neue Anforderungen (z. B. Deployment-Pipelines, Monitoring, Sicherheitskonzepte), die im Requirements-Set sichtbar sein müssen.
+
+Für die Requirementsentwicklung bedeutet diese neue Zielarchitektur eine Verschiebung des Schwerpunktes. Während in klassischen Server/Client-Architekturen die fachliche Funktionslogik oft dominiert, rücken in Web- und Cloud-Kontexten auf den Betrieb bezogene (Deployment, Monitoring, Skalierung) und sicherheitsrelevante Qualitätsmerkmale (SaaS, Multi-Tennanting) stärker in den Vordergrund. ISO/IEC 25010:2011 bietet hierfür eine hilfreiche Taxonomie @iso25010_2011. Für Modernisierungsvorhaben lassen sich vor allem folgende Qualitätsmerkmale als wiederkehrend beobachten:
+
+/ Sicherheit: Identitäten, Rollenmodelle, Mandantenfähigkeit, Auditierbarkeit.
+/ Zuverlässigkeit: Fehlerresistenz, Wiederanlauf, Degradationsverhalten.
+/ Performance-Effizienz: Antwortzeiten, Lastverhalten, Skalierungsgrenzen.
+/ Wartbarkeit: Änderbarkeit, Testbarkeit, Modularität und technische Schuld.
+/ Kompatibilität und Interoperabilität: Schnittstellenstabilität, Integrationsfähigkeit mit Drittsystemen.
+
+Diese Merkmale sind nicht neu, ihre Sichtbarkeit im Projekt nimmt jedoch zu, weil Cloud- und Webbetrieb ein engeres Zusammenspiel von Entwicklung und Betrieb erzwingt. 
+
+_Für das Reverse Requirements Engineering im Rahmen dieser Arbeit folgt daraus, dass der Blick auf die Legacy-Codebasis systematisch um Betriebs- und Sicherheitsanforderungen ergänzt werden muss, auch wenn diese im Code nur indirekt sichtbar sind (z. B. über Deployment-Skripte, Konfigurationen, Logging-Policies oder Rechteprüfungen)._
+
+#heading(level: 3)[Stand der Forschung: KI-Unterstützung in Modernisierungsvorhaben]
+
+Die Forschung zu LLM-Unterstützung bei Moderniesierungen steh im Vergleich zu klassischen Reengineering-Ansätzen noch an den Anfängen. Die Übersichten zu LLM4SE @fan2023llmse @llm4se2024slr zeigen, dass ein Teil der Arbeiten auf Codeverständnis, Dokumentation und Artefakttransformation zielt. Spezifisch für Requirements Engineering zeigen Reviews und SLRs erste konkrete Forschungsrichtungen @marques2024chatgptre @hemmat2025directions.
+
+Aus dieser Literatur lassen sich zwei Aussagen ableiten. Zum einen sind LLMs besonders stark in der Strukturierung und sprachlichen Formulierung. Also dort, wo aus heterogenen Artefakten ein konsistenter Text entstehen muss. Zum anderen benötigen LLMs technische und organisatorische Sicherungen, wenn Ergebnisse als Entscheidungsgrundlage in Migrationen dienen sollen (z. B. Belege, Review, reproduzierbarer Prozess).
+
+_Dies ist auch die Zentrale Motivation dieser Arbeit: Eine Legacy-Modernisierung benötigt belastbare Requirements, die im Legacy-Kontext oft fehlen. LLMs sind als Assistenz zur Rekonstruktion naheliegend, müssen jedoch methodisch so eingesetzt werden, dass Verlässlichkeit und Nachvollziehbarkeit systematisch erhöht werden._
+
+/*
+#heading(level: 3)[Zwischenfazit zu 2.3]
+
+Legacy-Modernisierung ist ein sozio-technisches Vorhaben, das technische Umbauten und fachliche Zielsetzungen integrieren muss @bisbal1999legacy @sneed1995planning. Moderne Zielarchitekturen (Web/Cloud) verschieben zudem die Anforderungslandschaft, weil Betriebs- und Sicherheitsanforderungen stärker in den Vordergrund treten @kratzke2017cloudnative @security2014legacycloud. Für die vorliegende Arbeit folgt daraus, dass Requirements-Extraktion nicht nur der Funktionsrekonstruktion dient, sondern die Grundlage für Migrationsentscheidungen, Priorisierung und Qualitätssicherung bildet.
+*/
+#heading(level: 3)[Kapitelzusammenfassung und Anschluss]
+
+Die drei Themenblöcke dieses Kapitels greifen ineinander. Requirements Engineering liefert Kriterien, um Anforderungen prüfbar und nachvollziehbar zu formulieren @iso29148_2018. Reverse Requirements Engineering überträgt diese Kriterien in einen Kontext, in dem Anforderungen aus bestehenden Artefakten rekonstruiert werden müssen. Large Language Models können bei dieser Rekonstruktion unterstützen, sind aber fehleranfällig und benötigen Prozesskontrollen, vor allem gegen Halluzinationen und Überinterpretation. Legacy-Modernisierung schließlich liefert die praktische Motivation und zeigt, warum eine belastbare Anforderungsbasis migrationskritisch ist @bisbal1999legacy @sneed1995planning.
+
+

Kapitel/03_fallstudie.typ

@@ -6,96 +6,80 @@
 
 #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:
-
-- **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.
+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.
 
 #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.
-- **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.
+_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._
 
 #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.
-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.
+1. *Quellcode:* Implementierte Regeln, Berechtigungen, Statuslogik, Datenzugriffe.
+2. *Konfiguration und Parameter:* Feature-Schalter, Mandantenparameter, systemweite Defaults.
+3. *UI- und Reportartefakte:* Feldbezeichnungen, Validierungstexte, Druck- und 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.
+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.
-- **Betriebsmodell und Deployment:** Automatisierte Bereitstellung, Skalierung, Updatefähigkeit und Wartbarkeit über Releases.
-- **Integrationen und Daten:** Stabilisierung von Schnittstellen, Datenmigration und Sicherstellung konsistenter Geschäftsobjekte.
+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.
 
 #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 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.
+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.
 
 #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,400 @@
+#import "@preview/cetz:0.4.2"
+
+#set text(lang: "de")
+
 #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,
-  )
 ]
 
 #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)[Werkzeug-Grundlagen: Agentische CLIs, Agenten, MCP und lokale Inferenz]
+
+Bevor der eigentliche Versuchsaufbau beschrieben wird, werden die zentralen Werkzeug-Begriffe geklärt, an denen die spätere Versuchsreihe variiert. Sie sind nicht nur Hilfsmittel der Durchführung, sondern definieren genau die Stellschrauben, die in den Versuchen V1 bis V3 systematisch hinzugenommen werden. Die folgende Darstellung beschränkt sich auf das für diese Arbeit relevante Maß und ersetzt keine vollständige Werkzeugdokumentation. Das Zusammenspiel der vier Bausteine ist in @abb_werkzeug_grundlagen skizziert.
+
+/ Agentische CLIs: Eine LLM CLI ist ein Kommandozeilen-Werkzeug, das einem LLM den direkten Zugriff auf die lokale Arbeitsumgebung erlaubt. Es kann nicht nur online Artefakte erzeugen, sondern auch lokale Dateien lesen und bearbeiten sowie Shell-Befehle ausführen oder lokal installierte Tools aufrufen. Innerhalb einer Ausführungsschleife entscheidet das LLM selbst, welches Werkzeug es auf dem lokalen Computer aufrufen möchte. Die CLI stellt dafür lediglich die Laufzeitumgebung und den Zugriff auf die lokalen Werkzeuge bereit. In dieser Arbeit kommen Claude Code , die Codex-CLI sowie die Qwen Code CLI zum Einsatz. 
+
+/ Agenten und Agentendateien: LLM Agenten sind rollenspezialisierte Konfigurationen (Prompts), die innerhalb einer agentischen CLI als Sub-Prozesse aufgerufen werden. Sie werden typischerweise als Markdown-Dateien abgelegt und enthalten drei Bestandteile: einen Auftrag (was tut der Agent), eine eigene Systemanweisung (wie tut er es) und ein begrenztes Toolset (womit darf er es tun). Die aufrufende CLI startet einen solchen Agenten mit eigenem Kontextfenster, sodass dessen Zwischenergebnisse den Hauptkontext nicht überfluten.
+
+/ Model Context Protocol (MCP): Das Model Context Protocol ist ein 2024 von Anthropic veröffentlichter offener Standard zur Anbindung externer Werkzeuge und Datenquellen an LLM-Clients @claudecode_mcp_2026. Ein MCP-Server kapselt konkrete Fähigkeiten, etwa Symbol-Navigation im Quellcode, Datenbankzugriff oder GUI-Manipulation, hinter einer einheitlichen Schnittstelle. Ein MCP-Client wie Claude Code entdeckt die angebotenen Werkzeuge zur Laufzeit und ruft sie kontrolliert auf, um ein deterministischer Ergebnis zu erhalten, anstatt den Aufruf direkt durch das LLM zu generieren. So stellt etwa ein MCP-Server für lesenden Datenbankzugriff eine fest definierte SQL-Schnittstelle bereit, über die das LLM Tabellenstrukturen und Datensätze reproduzierbar abruft, anstatt sie aus dem allgemeinen Modellwissen zu rekonstruieren.
+
+/ Lokale Inferenz-Runtimes: Eine lokale Inferenz-Runtime ist eine Software, die LLMs auf eigener Hardware ausführt und ihre Funktion über einen OpenAI-kompatiblen HTTP-Endpunkt bereitstellt. In dieser Arbeit kommt LM Studio zum Einsatz, das Modelle wie Qwen 3.5 Coder lokal ausführen kann. 
+
+#figure(
+  cetz.canvas({
+    import cetz.draw: *
+
+    let draw-box(x, y, w, h, label) = {
+      rect(
+        (x - w/2, y - h/2),
+        (x + w/2, y + h/2),
+        stroke: black + 0.6pt, fill: luma(240),
+      )
+      content((x, y), text(size: 9pt, weight: "bold")[#label])
+    }
+
+    let draw-arrow(from, to) = {
+      line(from, to, mark: (end: ">"), stroke: black + 0.6pt)
+    }
+
+    let h-half = 0.4
+    let gap = 0.15
+
+    draw-box(0,  5,   2.6, 0.8, "Benutzer")
+    draw-box(0,  3.5, 4.0, 0.8, "Agentische CLI")
+    draw-box(5,  3.5, 4.0, 0.8, "LLM (Cloud / LM Studio)")
+    draw-box(-4, 1,   3.6, 0.8, "Agentendateien")
+    draw-box(4,  1,   3.6, 0.8, "MCP-Server")
+    draw-box(0, -1,   3.6, 0.8, "Codebasis")
+    draw-box(4, -1,   3.6, 0.8, "Datenbank")
+
+    draw-arrow((0, 5   - h-half - gap), (0,  3.5 + h-half + gap))
+    line(
+      (0 + 4.0/2 + gap, 3.5),
+      (5 - 4.0/2 - gap, 3.5),
+      mark: (start: ">", end: ">"),
+      stroke: black + 0.6pt,
+    )
+    draw-arrow((0, 3.5 - h-half - gap), (-4, 1   + h-half + gap))
+    draw-arrow((0, 3.5 - h-half - gap), (4,  1   + h-half + gap))
+    draw-arrow((0, 3.5 - h-half - gap), (0, -1   + h-half + gap))
+    draw-arrow((4, 1   - h-half - gap), (4, -1   + h-half + gap))
+  }),
+  caption: [Hierarchie der Werkzeuge. Der Anwender ruft die agentische CLI auf. Diese übergibt das initiale Prompt und das verfügbare Toolset an das LLM und erhält dessen Antworten samt Tool-Aufrufen zurück. Die CLI führt die vom LLM erbetenen Aufrufe aus. Die Codebasis ist direkt über die CLI zugänglich. Der Zugriff auf die Datenbank erfolgt ausschließlich über einen MCP-Server.],
+) <abb_werkzeug_grundlagen>
+
+#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>
+
+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.
+
+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.
+
+#heading(level: 2)[Der RRE-Prozess als Rahmen]
+
+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.
+
+1. *Scope und Domänenabgrenzung:* Auswahl relevanter Module, Datenobjekte und Prozesse.
+2. *Artefakterhebung:* Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen und Change-Historie.
+3. *Technische Analyse:* Struktur- und Abhängigkeitsanalyse sowie Identifikation von Kernkomponenten, Regeln und Integrationspunkten.
+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.
+
+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 das Vorgehen belastbar bleibt, sind in jedem Versuchsdurchlauf drei Eigenschaften sicherzustellen:
+
+/ 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.
+
+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.
+
+#heading(level: 2)[Auswahl des LLM]
+
+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.
+
+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.
+
+#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>
+
+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.
+
+#heading(level: 2)[Versuchsaufbau]
+
+Der Versuchsaufbau 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.
+
+/ 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.
+
+/ 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.
+
+/ 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.
+
+/ 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.
+
+#figure(
+  table(
+    columns: (auto, 1fr, 1.4fr),
+    align: (left + top, left + top, left + top),
+    stroke: 0.4pt,
+    [*Versuch*], [*Werkzeugkonfiguration*], [*Hypothese*],
+    [V1 Baseline],
+    [
+      - Prompt-only
+      - keine Agentendateien
+      - keine externen Tools
+    ],
+    [
+      - Formal strukturierte Spezifikation erreichbar
+      - Discovery-Breite begrenzt
+    ],
+    [V2 Agenten],
+    [
+      - Wie V1
+      - rollenspezialisierte Agentendateien
+    ],
+    [
+      - Höhere Strukturierungstiefe und Normkonformität
+      - Vergleichbare Discovery-Breite
+    ],
+    [V3 MCP-Tools],
+    [
+      - Wie V2
+      - MCP-Server für Code
+      - MCP-Server für Datenbank
+      - optional MCP-Server für GUI
+    ],
+    [
+      - Größere Discovery-Breite
+      - Höhere Steuerungskomplexität
+    ],
+    [V4 (optional)],
+    [
+      - beste Konfiguration aus V1–V3
+      - GPT-5 über Codex-CLI
+      - DeepSeek R1 über Cloud-API
+      - Qwen 3.5 Coder lokal über LM Studio
+    ],
+    [Trennung modell- gegenüber werkzeugabhängiger Effekte],
+  ),
+  caption: [Übersicht der geplanten Versuche mit Werkzeugkonfiguration und Arbeitshypothese.],
+) <tab_versuchsreihe>
+
+#heading(level: 3)[Iteratives Vorgehen innerhalb eines Versuchs]
+
+Innerhalb jedes Versuchs läuft ein iterativer Loop ab, in dem der Prompt schrittweise verfeinert wird. Der Begriff Iteration bezeichnet in dieser Arbeit ausschließlich diesen inneren Loop. Der schrittweise Aufbau über V1, V2 und V3 wird hingegen als Versuchsreihe bezeichnet.
+
+Der Ablauf folgt fünf Schritten. Ausgangspunkt ist ein Initial-Prompt. In Versuch 1 wird dieser zu Versuchsbeginn neu formuliert. In Versuch 2 und Versuch 3 wird stattdessen der finale Prompt des vorhergehenden Versuchs übernommen und vor dem ersten Lauf an die neu hinzukommende Werkzeugkomponente angepasst (Agentendateien beziehungsweise MCP-Server). Der Initial-Prompt wird gegen die Codebasis ausgeführt. Anschließend begutachtet der Autor die Ausgabe stichprobenartig auf offensichtliche Lücken, formale Probleme oder fehlende Belege. Auf Basis dieser Begutachtung wird der Prompt mit dokumentiertem Änderungsgrund angepasst und erneut ausgeführt. Der Loop wiederholt sich, bis der Autor das Ergebnis als ausreichend einstuft.
+
+Diese innere Begutachtung ersetzt nicht die Stakeholder-Validierung. Die Stakeholder-Validierung greift erst, wenn der Autor den Versuch als abgeschlossen erklärt. Ihr Urteil bezieht sich ausschließlich auf das End-Set des Versuchs. Damit fließt der Validatoren-Aufwand nicht in jede Zwischenversion ein.
+
+Jede Prompt-Version wird im Versuchsordner mit Zeitstempel und kurzer Notiz zum Änderungsgrund abgelegt, sodass die Iterations-Historie reproduzierbar bleibt und später als Lerneffekt diskutiert werden kann. Der Ablauf ist in @abb_versuchsablauf zusammengefasst.
+
+#figure(
+  cetz.canvas({
+    import cetz.draw: *
+
+    let draw-box(x, y, w, h, label, dashed: false) = {
+      rect(
+        (x - w/2, y - h/2),
+        (x + w/2, y + h/2),
+        stroke: if dashed { (dash: "dashed", thickness: 0.6pt, paint: black) } else { black + 0.6pt },
+        fill: luma(240),
+      )
+      content((x, y), text(size: 9pt, weight: "bold")[#label])
+    }
+
+    let draw-mini-box(x, y, w, h, label) = {
+      rect(
+        (x - w/2, y - h/2),
+        (x + w/2, y + h/2),
+        stroke: black + 0.4pt,
+        fill: luma(248),
+      )
+      content((x, y), text(size: 8pt)[#label])
+    }
+
+    let draw-arrow(from, to) = {
+      line(from, to, mark: (end: ">"), stroke: black + 0.6pt)
+    }
+
+    let h-half = 0.4
+    let mh-half = 0.25
+    let gap = 0.1
+
+    let top-y = 5
+    let versuche = (
+      (x: -5,   label: "V1 Baseline"),
+      (x: -1.5, label: "V2 Agenten"),
+      (x:  2,   label: "V3 MCP-Tools"),
+    )
+
+    for v in versuche {
+      draw-box(v.x, top-y, 3.0, 0.8, v.label)
+    }
+    draw-box(5.5, top-y, 3.0, 0.8, "V4 (optional)", dashed: true)
+
+    draw-arrow((-5   + 1.5, top-y), (-1.5 - 1.5, top-y))
+    draw-arrow((-1.5 + 1.5, top-y), ( 2   - 1.5, top-y))
+    line(
+      (2 + 1.5, top-y), (5.5 - 1.5, top-y),
+      mark: (end: ">"),
+      stroke: (dash: "dashed", thickness: 0.6pt, paint: black),
+    )
+
+    for v in versuche {
+      let cx = v.x
+      let py = 3.5
+      let ly = 2.5
+      let by = 1.5
+
+      draw-mini-box(cx, py, 1.7, 0.5, "Prompt")
+      draw-mini-box(cx, ly, 1.7, 0.5, "Lauf")
+      draw-mini-box(cx, by, 1.9, 0.5, "Begutachtung")
+
+      draw-arrow((cx, top-y - h-half  - gap), (cx, py + mh-half + gap))
+      draw-arrow((cx, py    - mh-half - gap), (cx, ly + mh-half + gap))
+      draw-arrow((cx, ly    - mh-half - gap), (cx, by + mh-half + gap))
+
+      let lx = cx + 1.25
+      line((cx + 0.95, by), (lx, by), stroke: black + 0.6pt)
+      line((lx, by), (lx, py),        stroke: black + 0.6pt)
+      line((lx, py), (cx + 0.85, py),
+        mark: (end: ">"), stroke: black + 0.6pt)
+      content((lx + 0.25, (py + by) / 2), text(size: 7pt, fill: luma(80))[nein])
+    }
+  }),
+  caption: [Zustandsgraph des Versuchsablaufs. Die Versuche bauen schrittweise aufeinander auf, V4 ist optional. Der finale Prompt eines Versuchs wird zu Beginn des Folgeversuchs an die neu hinzukommende Werkzeugkomponente angepasst und dient dann als Startprompt. Innerhalb jedes Versuchs verfeinert ein Iterations-Loop den Prompt: Lauf → Begutachtung durch den Autor → bei „nein" Prompt-Anpassung, bei „ja" Übergang zum nächsten Versuch.],
+) <abb_versuchsablauf>
 
-#heading(level: 2)[Claude Code als Werkzeug]
+Konstanten und Variablen sind in jedem Versuch klar dokumentiert. In Versuch 1 bis 3 umfassen die Konstanten Codebasis, Iterations-Vorgehen, Modellfamilie, Validierungsstichprobe und Bewertungskriterien. Variabel sind die Werkzeugkonfiguration und der Startprompt jedes Versuchs. Versuch 1 startet mit einem zu Versuchsbeginn neu formulierten Prompt. Versuch 2 und Versuch 3 übernehmen jeweils den finalen Prompt des vorhergehenden Versuchs und passen ihn zu Beginn an die neu hinzukommende Werkzeugkomponente an (Agentendateien in Versuch 2, MCP-Server in Versuch 3). Erst dieser angepasste Prompt bildet den Ausgangspunkt für den Iterations-Loop des Folgeversuchs. 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.
 
-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:
+#heading(level: 2)[Stakeholder-Validierung als Verifikationsverfahren]
 
-- Baseline nur mit Prompt + CLI (Versuch 01),
-- Spezialisierung ueber Agenten-Dateien (Versuch 02),
-- Erweiterung um MCP-Server fuer zusaetzliche Tool- und Datenzugriffe (Versuch 03).
+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.
 
-Technisch wurde Claude Code entlang der offiziellen Dokumentation eingesetzt:
+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 in @anh_interview_validierung im Anhang dokumentiert.
 
-- Session-Start und Ausfuehrung ueber CLI (`claude`, `claude -p`),
-- lokale IDE-Anbindung in VS Code,
-- Einbindung externer MCP-Server ueber das `claude mcp`-Konzept,
-- Nutzung des MCP-Scopes fuer projektspezifische Tool-Konfigurationen.
+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.
 
-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.
+Jede Anforderung wird entlang von sechs Dimensionen bewertet:
 
-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.
+/ Sachliche Korrektheit: Beschreibt die Anforderung das tatsächliche Systemverhalten?
+/ Vollständigkeit: Sind Akteur, Vorbedingung und Ergebnis ausreichend spezifiziert?
+/ Verständlichkeit: Lässt sich die Anforderung ohne Rückfrage interpretieren?
+/ Redundanzfreiheit: Ist die Anforderung von anderen klar abgegrenzt?
+/ Ü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.
 
-#heading(level: 2)[Versuch 01]
+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. 
 
-#heading(level: 3)[Allgemeine Beschreibung]
+Ergänzend zur itemweisen Bewertung werden mit den Validatoren halbstrukturierte Interviews geführt. Themen sind hierbei vor allem migrationsspezifische Risiken, der Konsolidierungsbedarf gegenüber der Zielarchitektur und die Nützlichkeit der KI-Ergebnisse im Vergleich zu einer hypothetischen manuellen Analyse. 
 
-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.
+Eine Requirement gilt im Sinne dieser Arbeit als belastbar, wenn drei Quellen sie stützen: ein KI generiertes Requirement, ein konkreter Artefakt-Beleg und eine Expertenbestätigung. 
 
-#heading(level: 3)[Konfiguration]
+#heading(level: 2)[Evaluationsrahmen]
 
-- Claude Code CLI lokal im Projektverzeichnis,
-- Nutzung aus VS Code (integriertes Terminal),
-- keine Agenten-Dateien,
-- keine MCP-Server.
+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 in @sec_re_qualitaet hergeleiteten Qualitätsdimensionen.
 
-#heading(level: 3)[Verwendeter Prompt]
+/ 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.
 
-```text
-Please analyze this software project and write a reuqirements specification according to modern standards.
-```
+/ Set-Qualität: Pro Versuch wird die gesamte erzeugte Anforderungsmenge als ein Set bewertet. Gemessen wird, ob sie die relevanten Prozesse und Varianten vollständig abdeckt, in sich konsistent ist und keine Doubletten enthält. Im Vordergrund steht dabei die Vollständigkeit, weil ein fehlendes Requirement im Migrationskontext zu Funktionsverlust führen kann. Die Bewertung erfolgt qualitativ durch Expertenbewertung und ergänzend durch maschinelle Konsistenzprüfungen wie doppelte IDs oder fehlende Belege.
 
-#heading(level: 3)[Tools und Artefakte]
+/ 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.\ \
 
-- Tooling: Claude Code CLI + VS Code Integration.
-- Ergebnisfokus: formale Requirements-Spezifikation (StRS/SyRS/SwRS) mit hoher Strukturierungsdichte.
+Ergänzend zur Qualitätsbewertung wird der Aufwand erhoben. Dazu werden während der KI-Läufe Indikatoren wie Tokenkosten un Bearbeitungsdauer protokolliert. Parallel wird grob abgeschätzt, wie viele Stunden ein erfahrener Analyst für dieselben Module ohne KI-Unterstützung gebraucht hätte. Beide Größen zusammen erlauben einen Vergleich der Größenordnung, nicht jedoch einen exakten Effizienzfaktor.
 
-#heading(level: 3)[Beispielhafte Ergebnisanforderungen]
+#heading(level: 2)[Reproduzierbarkeit und Risikomanagement]
 
-Quelle: `Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md`
+Reproduzierbarkeit und Risikomanagement sind als querschnittliche Aspekte angelegt. Sie betreffen alle Versuchsdurchläufe gleichermaßen und werden hier zusammengefasst.
 
-```text
-### 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.
-```
+Alle steuerungsrelevanten Artefakte werden versioniert vorgehalten. Hierzu zählen die verwendeten Prompts in ihrer Textfassung inklusive aller Iterationsversionen mit Zeitstempel und Änderungsgrund, die Agentendateien mit ihren Rollenbeschreibungen, die MCP-Server-Konfigurationen sowie die Angaben zu Modellversion 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 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.
 
-```text
-### SyR-001
-The system SHALL implement a multi-layered architecture with clear separation of concerns.
-```
+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.
 
-#heading(level: 3)[Einordnung]
+Die folgenden vier Risikokategorien werden adressiert:
 
-Die Baseline zeigt, dass bereits ohne Agenten/MCP belastbare, formal strukturierte Anforderungen erzeugbar sind. Gleichzeitig bleibt die Discovery-Breite begrenzt.
+/ 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. Da die innere Iteration zudem die Gefahr eines Autoren-Bias birgt, etwa eines unbewussten Hinsteuerns auf bestimmte Module, werden die Prompt-Änderungen pro Iteration mit Änderungsgrund dokumentiert und sind im Versuchsordner nachvollziehbar.
+/ 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.
 
-#heading(level: 2)[Versuch 02]
-
-#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
+#heading(level: 2)[Konkrete Konfigurationen der geplanten Versuche]
 
-### Core Capabilities
+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.
 
-- **N+1 Query Detection**: Identify lazy loading in loops causing performance degradation
-- **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
-
-This agent should be activated when:
-- 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:**
-- "Review this query for N+1 problems"
-- "Optimize the GetAccountContracts query"
-- "Check if this LINQ expression will work with NHibernate"
-- "Why is my query slow?"
-
-## Technology Adaptation
-
-**IMPORTANT**: This agent adapts to c-entron.NET's NHibernate configuration.
-
-**Configuration Source**: [CLAUDE.md](../../CLAUDE.md)
-
-Before beginning work, review CLAUDE.md for:
-- **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
-
-### Standard Procedure
-
-1. **Load Relevant Lessons Learned** ⚠️ **IMPORTANT**
-
-   As a review and analysis agent, start by loading past lessons:
-
-   - Use Serena MCP `list_memories` to see available memories
-   - 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**
-   - 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**
-   - 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**
-   - 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**
-   - 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]
-
-Quelle: `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.md`
-
-```text
-### 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
-**Use Case**: Track counter reading trends, detect anomalies
-Method: IAutomatedBillingLogic.GetCounterHistory(List<string> lstParam)
-```
-
-#heading(level: 3)[MCP-Server: Detaillierte Beschreibung]
-
-#heading(level: 4)[MCP-Grundprinzip]
-
-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.
+#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-Interaktion],
+    [Validierungsstichprobe], [Stratifiziert], [Stratifiziert], [Stratifiziert],
+  ),
+  caption: [Detail-Konfiguration der drei Kernversuche.],
+) <tab_versuchskonfiguration>
 
+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.
+/*
+#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/05_durchfuehrung_und_ergebnisse.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/05_prototypische_umsetzung.typ

@@ -1,177 +0,0 @@
-#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)]
-
-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.
-
-#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/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.
-
-#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.
+// TODO Variante B – Anwendung des in Kap 4.6 definierten Evaluationsrahmens auf die
+// Ergebnisse aus Kap 5. Keine Erst-Definition von Kriterien hier.

Kapitel/07_diskussion.typ

@@ -8,7 +8,7 @@
 
 #heading(level: 2)[Interpretation der Ergebnisse]
 
-Die Ergebnisse zeigen einen klaren methodischen Lerneffekt ueber die drei Iterationen. Der Verlauf von V01 ueber V02 zu V03 ist nicht als Widerspruch, sondern als komplementaere Reifung zu interpretieren:
+Die Ergebnisse zeigen einen klaren methodischen Lerneffekt ueber die drei Versuche. Der Verlauf von V01 ueber V02 zu V03 ist nicht als Widerspruch, sondern als komplementaere Reifung zu interpretieren:
 
 - V01 demonstriert, dass bereits mit einfacher Konfiguration formal strukturierte Requirements ableitbar sind.
 - V02 zeigt, dass eine agentengestuetzte ISO-Konsolidierung methodisch sauber, aber fuer den Gesamtumfang zu rigide sein kann.
@@ -36,7 +36,7 @@ Damit bestaetigt die Fallstudie, dass LLMs Requirements Engineering nicht ersetz
 
 Fuer die Praxis folgt daraus ein umsetzbarer Einfuehrungspfad:
 
-1. Iterative Versuchslogik statt einmaliger "Big-Bang"-Extraktion.
+1. Schrittweise aufeinander aufbauende Versuchsreihe statt einmaliger "Big-Bang"-Extraktion.
 2. Trennung von Discovery- und Konsolidierungsphase als Standard.
 3. Traceability als verpflichtendes Abnahmekriterium fuer LLM-Ergebnisse.
 

Kapitel/08_fazit_ausblick.typ

@@ -2,7 +2,7 @@
 
 #heading(level: 2)[Zusammenfassung und Beantwortung der Forschungsfragen]
 
-Die Arbeit zeigt, dass KI-gestuetztes Reverse Requirements Engineering im untersuchten Legacy-ERP-Kontext praktikabel ist, wenn der Prozess iterativ und kontrolliert aufgebaut wird. Die drei durchgefuehrten Versuche liefern dabei komplementaere Staerken:
+Die Arbeit zeigt, dass KI-gestuetztes Reverse Requirements Engineering im untersuchten Legacy-ERP-Kontext praktikabel ist, wenn der Prozess schrittweise und kontrolliert aufgebaut wird. Die drei durchgefuehrten Versuche liefern dabei komplementaere Staerken:
 
 - V01 liefert eine formale Baseline mit klarer Requirements-Struktur.
 - V02 konsolidiert die Erkenntnisse in eine ISO-29148-nahe, traceability-starke Spezifikation.

Kapitel/10_anhang.typ

@@ -2,6 +2,10 @@
 
 #heading(level: 2)[Interviewleitfäden]
 
+#heading(level: 3)[Stakeholder-Validierung der KI-extrahierten Anforderungen] <anh_interview_validierung>
+
+_Ausarbeitung folgt._
+
 #heading(level: 2)[Zusätzliches Datenmaterial]
 
 #heading(level: 2)[Konfigurationsdetails des Prototyps]

Kapitel/VarianteA/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/VarianteA/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/VarianteA/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

@@ -1,11 +1,13 @@
 #import "masterarbeit_style.typ": thesis
 
+#set text(lang: "de")
+
 #let meta = (thesis.meta)(
   "KI-gestütztes Reverse Requirements Engineering bei Legacy-Software",
   "Masterarbeit an der Hochschule Neu-Ulm",
   "Christoph Schwörer",
-  "Master of Science",
-  "Prof. Dr. Daniel Schallmo",
+  "Master of Business Administration",
+  "Prof. Dr. Daniel Schallmö",
   "XX 2026"
 )
 
@@ -41,8 +43,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,12 @@ 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.
+13. **Keine Semikola im Fließtext:** Halbsätze werden mit Punkt zu eigenständigen Sätzen aufgetrennt oder per Komma als Nebensatz angeschlossen. Das Semikolon wird nicht als Verbinder zwischen Hauptsätzen verwendet. Statt „X ist gegeben; Y folgt daraus." → „X ist gegeben. Y folgt daraus." oder „X ist gegeben, woraus Y folgt."
 
 ## 2. Strukturbausteine pro Dokumenttyp
 

Versuche/Versuch_01/01_Prompt.md

@@ -0,0 +1,102 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 01
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 01 (Initial-Prompt, zu Versuchsbeginn neu formuliert)
+- **Werkzeugkonfiguration:** Claude Code, keine Agentendateien, keine MCP-Server
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Modell:** Claude (Claude Code)
+- **Zeitstempel:** 2026-06-04
+- **Änderungsgrund:** Initial-Prompt für V1 Baseline (kein Vorgänger).
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung; nutze nur, was als Datei lesbar ist.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Scope und Validierung sind manuell vorgegeben):
+
+1. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen.
+2. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+3. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+4. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen.
+5. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Anforderungen ohne Beleg sind unzulässig.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Aussage:       Das System soll <...>. (klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String>
+  - [SEKUNDÄR] <...>
+  - [KONTEXT]  <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Ergebnisstruktur (im aktuellen Arbeitsverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modul-/Komponentenübersicht, abgedeckte Bereiche, bekannte Lücken)
+```
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme nicht vorhandener Tools.** Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist die Aussage als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Wenn eine Implementierung erkennbar ein historischer Workaround oder Sonderfall ist, vermerke das im Feld `Status` (`belegt; Workaround`), damit es in der späteren Validierung priorisiert geprüft werden kann.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Welche Module wurden vollständig analysiert, welche nur stichprobenhaft, welche gar nicht?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?