04_einmal durch

Kapitel/01_einleitung.typ

@@ -1,22 +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 Produkte neu zu bewerten. Betroffen sind vor allem Systeme die über lange Jahre nur in Windows-Umgebungen vertrieben wurden. Diese stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen und fallen in der technologischen Schuld immer weiter Zurück. Eine technologische Weiterentwicklung ist nicht möglich und an einer Neuentwicklung führt oft kein Weg vorbei. Dokumentierte Anforderungen und Code sind allerdings selten. Das meiste Wissen steckt implizit im Code oder in der Köpfen der verlbeibenden Entwickler.
+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 ist von diesem Szenario voll Betroffen. Das Unternehmen betreibt seit über zwanzig Jahren eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung deckt Auftragsabwicklung, Lager, Fakturierung und Projektabrechnung ab, ist aber eng mit der bisherigen Client/Server-Architektur gekoppelt. Kunden erwarten zwischenzeitlich aber plattformunabhängige Oberflächen, Self-Service-Funktionen und flexible Betriebsmodelle wie z.B. SaaS (Software as a Service). Die bestehende Anwendung ist aber in ihrer Skalierung, Deployment und Abrechnung limitiert. Eine Migration auf eine webbasierte Plattform ist somit zwingend erforderlich. 
+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.
 
-Eine einfache Neuimplementierung auf Basis vorhandener Anfoderungs oder Code Dokumentation ist aber aus oben geschilderten Gründen nicht einfach möglich. Die Herausforderung die sich stellt ist mit möglichst geringem Aufwand eine vollständige Beschreibung für ein vollständiges ERP System zu erarbeiten. Eine Manuelle auswertung des Codes oder Obfläche auf Funktionalitäten ist aufgrund der extremen Komplexität, geschuldet der langjährgien Weiterententwicklung, nur mit sehr hohem Personalaufwand möglich und daher nicht realsierbar.
+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 letzen Jahren hat sich hierzu nun ein neues Instrumentarium etabliert. Large Language Models wie Chat GPT-5 oder Claude.ai können durch agentische CLIs (Codex, Claude Code) große Mengen an Quellcode analysieren, Anforderungen erarbeiten und textuell beschreiben. Damit entsteht die Chance, fehlende Anforderungsdokumentationen zumindest teilweise aus dem Code heraus zu rekonstruieren. Die praktische Nutzung dieses Potenzials ist bislang kaum erforscht. Diese Arbeit adressiert dies und untersucht, wie KI-gestützte Verfahren für eine systematische Anforderunganalyse eingesetzt werden können.
+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]
-Für das ERP Software Produkt der c-entron fehlen strukturierte und dokumentierte Requirements. Die Analyse der bestehenden Codebasis ist zeitintensiv, ressourcenintensiv und anfällig für Insel- und Metawissen. Daraus ergeben sich mehrere Risiken:
+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. Zeitgleich sind Workaround of Symptom einer mangelhaften Erfassung der Anfoderungen bei originalen Implementierung und ein zeichen fehlender Weitsicht.
+/ 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 auch nicht bewandt in alten technolgien und es fehlt das Verständnis für historische Zwänge und Zusammenhänge.
+/ 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 umgestzt").
+/ 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.
+/ 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 auch generisch und lassen sich nicht einer konkreten Anforderung zuordnen, wie zum Beispiel das anzeigen eine Tabelle. Konkrete Datenflüsse lassen sich hier nur am laufenden System beobachten was die Analyse nochmal um eine Größenordnung Resourcenintensiver macht.
+/ 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.
 
@@ -25,13 +25,12 @@ 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 mit unterschiedlicher Tooling-Tiefe (Prompt-only, Agenten, Agenten+MCP).
 - Definition eines Evaluationsrahmens mit quantitativen und qualitativen Kriterien (Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Aufwandseinsparung).
-- 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 .
+- 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:
 
 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?
@@ -45,7 +44,7 @@ Die Arbeit ist in acht Kapitel gegliedert:
 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.
+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.

Kapitel/02_theoretischer_hintergrund.typ

@@ -6,7 +6,7 @@
 
 #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 Themen des Requirements Engineerings sowie die Idee des reverse Requirements Engineerings auf Basis bestehender Systeme eingeordnet. Anschließend werden Large Language Models und deren Einsatz im Software Engineering beschrieben. Inklusive typischer Leistungsgrenzen und Absicherungsmechanismen. Abschließend werden Grundlagen der Legacy-Modernisierung sowie etablierte Migrationsstrategien zusammengefasst, um den Kontext der Fallstudie und die Zielrichtung  einzuordnen.
+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()

Kapitel/02_theoretischer_hintergrund/02_01_requirements_engineering.typ

@@ -2,16 +2,16 @@
 
 #heading(level: 3)[Begriff und Zielsetzung des Requirements Engineering]
 
-der Begriff Requirements Engineering (RE) umfasst die systematische Erhebung, Analyse, Spezifikation, Validierung und Verwaltung von Anforderungen an ein System über dessen Lebenszyklus. In Standards @iso29148_2018 @ieee830_1998 wird Reqirements Engineering als eigenständiger Prozess verstanden, der sowohl fachliche Ziele (z. B. unterstützte Geschäftsprozesse) als auch technische und organisatorische Randbedingungen (z. B. Sicherheitsvorgaben, Betriebsmodelle) in überprüfbare Aussagen überführt.
+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 Requirments Engineering zwei Themen:
+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.
+/ Kommunikation zwischen Domäne und Technik: Anforderungen müssen fachlich verständlich und gleichzeitig so präzise sein, dass sich daraus eine Software-Architektur ableiten lässt, die implementiert, getestet und geändert werden kann.
-- ***Umgang mit Unsicherheit und Wandel:*** Anforderungen sind zu Projektbeginn selten vollständig. Requriements Engingeeing ist daher nicht nur Dokumentation, sondern auch ein iterativer Klärungs- und Abstimmungsprozess.
+/ 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.
 
-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)._
-
-_Für diese Arbeit ist die Perspektivenorientierung relevant, weil implementierter Code typischerweise keine expliziten Stakeholder-Sichten enthält. Für eine Migration auf Basis eines Reverse Engeneering Ansatzes sind diese aber relevant für die implementierung und architekturlle Entscheidungen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben)._
 
 #heading(level: 3)[Arten von Requirements und Qualitätskriterien]
 
@@ -21,9 +21,9 @@ Für die Qualität einzelner Requirements gibt es etablierte Standards. @iso2914
 
 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).
+/ 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")
+/ 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.
+/ 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. 
 
@@ -35,41 +35,41 @@ _Für diese Arbeit folgt daraus, dass KI-gestütztes Reverse-Requirements-Engine
 
 #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.
+Requirements werden in unterschiedlichen Repräsentationsformen dokumentiert. Standards wie IEEE 830-1998 und ISO/IEC/IEEE 29148:2018 fokussieren auf strukturierte Spezifikationen (z. B. SRS) und definieren typische Kapitel (Zweck, Systemkontext, funktionale Anforderungen, Schnittstellen, Qualitätsanforderungen, Annahmen). Zudem existieren weniger formale Formen wie User Stories, Use-Case-Beschreibungen oder Backlog-Einträge, die in agilen Settings Verwendung finden @ieee830_1998 @iso29148_2018.
 
 Für Reverse Requirements Engineering sind zwei Punkte entscheidend:
 
 - *Form* beeinflusst Interpretierbarkeit: Eine kurze User Story („Als Nutzer möchte ich …") ist leicht verständlich, transportiert aber weniger Randbedingungen, Datenregeln oder Fehlerfälle. Eine SRS-Formulierung kann präziser sein, erfordert aber mehr Kontext und Definitionen.
 - *Grad* der Formalisierung beeinflusst Prüfbarkeit: Je stärker Requirements mit Akzeptanzkriterien, Beispielen oder Messgrößen verknüpft sind, desto einfacher sind Reviews und Tests. #cite(<pohl2010re>, form: "prose") betont Anforderungen-Validierung als eigene Disziplin.
 
-_Für diese Arbeit wir daher ein hybrider Stil gewählt: Requirements werden als kurze, klare Soll-Aussagen formuliert und jeweils um Kontext (Akteur/Prozess), Randbedingungen (Vorbedingungen, Datenobjekte) und mindestens eine Prüfidee ergänzt._
+_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 da Requirement ja aus dem Code selbst entsteht.
+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.
+In Legacy-Systemen ist die ursprüngliche Traceability typischerweise unvollständig, falls überhaupt vorhanden: Hinweise finden sich in Commit-Messages, Branch-Namen, Datenbankskripten, Konfigurationsdateien, UI-Texten oder in impliziten Konventionen. Der Anspruch dieser Arbeit besteht daher nicht darin, „perfekte" Traceability wiederherzustellen, sondern eine minimal belastbare, reproduzierbare Verknüpfung zwischen extrahierten Requirements und Artefakten zu etablieren.
 
 #heading(level: 3)[Abgrenzung von Reverse Engineering zu Reverse Requirements Engineering]
 
-Reverse Engineering wird klassisch als Analyseprozess verstanden, der aus einem bestehenden System Wissen über Struktur, Verhalten und Designentscheidungen rekonstruiert. #cite(<chikofsky1990taxonomy>, form: "prose") prägen hierfür die Bennung und grenzen Reverse Engineering von Reengineering sowie Design Recovery ab. Für Requirements-nahe Fragestellungen ist hier relevant, dass Reverse Engineering nicht automatisch auch Requirements liefert, sondern erstmal nur technische Fakten (z. B. Abhängigkeiten, Datenflüsse, Zustandsautomaten).
+Reverse 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 Imepementierung?
+/ 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?
+/ 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.
+Gerade im Legacy-Umfeld ist diese Unterscheidung entscheidend. Die Codebasis enthält oft historisch entstandene Workarounds oder kundenspezifische Anpassungen. Ohne zusätzliche Validierung besteht das Risiko, dass RRE den Ist-Zustand als Soll-Zustand fehlinterpretiert.
 
 Frühe Ansätze zur Brücke zwischen Reverse Engineering und Requirements liefern beispielsweise #cite(<yu2005retr>, form: "prose") mit „RETR: Reverse Engineering to Requirements". Der Beitrag betont, dass Requirements-Rückgewinnung eine methodische Kette aus Artefaktsichtung, Strukturierung und Validierung benötigt. 
 
 Methodisch lassen sich dabei grob zwei Analysestränge unterscheiden:
 
-- *Statische Analyse:* Ableitung von Struktur- und Datenflussinformationen aus Code und Artefakten ohne Ausführung (z. B. Abhängigkeiten, SQL-Statements, Aufrufketten). Statische Analyse ist skaliert gut, erkennt aber nicht zuverlässig Laufzeitbedingungen (z. B. Feature Flags, Konfigurationsvarianten).
+/ 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.
+/ 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.
 
@@ -89,13 +89,13 @@ Aus Sicht dieser Arbeit lässt sich Reverse Requirements Engineering einer Legac
 
 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).
+/ 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.
+/ 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.
+/ Kontextbelege: Ticketbeschreibungen, Commit-Messages oder Interviewaussagen, die Motivation und Ausnahmen erklären, aber nicht zwingend im Code sichtbar sind.
 
 Diese Einteilung dient der Risikobewertung: Requirements, die überwiegend auf Sekundär- oder Kontextbelegen beruhen, sind anfälliger für Fehlinterpretation und sollten priorisiert validiert werden. Datenbankschemata und SQL-Statements sind häufig besonders aussagekräftig, weil sie Domänenobjekte, Kardinalitäten und Geschäftsregeln (z. B. referentielle Integrität, historisierte Tabellen) abbilden.
 
-_Für diese Arbeit werden in der Schrittkette lediglich Punk 1 und 7 manuell durchgeführt, während die Schritte 2-6 durch KI-gestützte Analyse automatisiert werden sollen._
+_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]

Kapitel/02_theoretischer_hintergrund/02_02_large_language_models.typ

@@ -1,6 +1,8 @@
 #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]
@@ -197,9 +199,9 @@ LLMs werden typischerweise in mehreren Phasen entwickelt. In einer Vortrainingsp
 
 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").
+/ 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?
+/ 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.
+/ 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.
 
@@ -221,8 +223,8 @@ Halluzinationen bezeichnen Ausgaben, die syntaktisch korrekt und plausibel wirke
 
 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.
+/ 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.
+/ 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._
 
@@ -234,10 +236,10 @@ Eine systematische Übersicht ordnet die LLM-Nutzung im RE dabei entlang klassis
 
 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.
+/ 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.
+/ 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.
+/ 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.
+/ 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. 
 
@@ -247,20 +249,20 @@ Für Reverse Requirements Engineering lässt sich der Nutzen damit präzisieren:
 
 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.
+/ 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.
+/ 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.
+/ 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.
+/ 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]
+#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?
+/ 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?
+/ 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?
+/ 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.
 /*

Kapitel/02_theoretischer_hintergrund/02_03_legacy_modernisierung.typ

@@ -29,11 +29,11 @@ Im selben Zusammenhang werden Microservices häufig als Architekturstil diskutie
 
 Für die Requirementsentwicklung bedeutet diese neue Zielarchitektur eine Verschiebung des Schwerpunktes. Während in klassischen Server/Client-Architekturen die fachliche Funktionslogik oft dominiert, rücken in Web- und Cloud-Kontexten auf den Betrieb bezogene (Deployment, Monitoring, Skalierung) und sicherheitsrelevante Qualitätsmerkmale (SaaS, Multi-Tennanting) stärker in den Vordergrund. ISO/IEC 25010:2011 bietet hierfür eine hilfreiche Taxonomie @iso25010_2011. Für Modernisierungsvorhaben lassen sich vor allem folgende Qualitätsmerkmale als wiederkehrend beobachten:
 
-- *Sicherheit:* Identitäten, Rollenmodelle, Mandantenfähigkeit, Auditierbarkeit.
+/ Sicherheit: Identitäten, Rollenmodelle, Mandantenfähigkeit, Auditierbarkeit.
-- *Zuverlässigkeit:* Fehlerresistenz, Wiederanlauf, Degradationsverhalten.
+/ Zuverlässigkeit: Fehlerresistenz, Wiederanlauf, Degradationsverhalten.
-- *Performance-Effizienz:* Antwortzeiten, Lastverhalten, Skalierungsgrenzen.
+/ Performance-Effizienz: Antwortzeiten, Lastverhalten, Skalierungsgrenzen.
-- *Wartbarkeit:* Änderbarkeit, Testbarkeit, Modularität und technische Schuld.
+/ Wartbarkeit: Änderbarkeit, Testbarkeit, Modularität und technische Schuld.
-- *Kompatibilität und Interoperabilität:* Schnittstellenstabilität, Integrationsfähigkeit mit Drittsystemen.
+/ Kompatibilität und Interoperabilität: Schnittstellenstabilität, Integrationsfähigkeit mit Drittsystemen.
 
 Diese Merkmale sind nicht neu, ihre Sichtbarkeit im Projekt nimmt jedoch zu, weil Cloud- und Webbetrieb ein engeres Zusammenspiel von Entwicklung und Betrieb erzwingt. 
 

Kapitel/03_fallstudie.typ

@@ -21,10 +21,10 @@ Für diese Arbeit ist die Software relevant, weil sie Anforderungen in einer For
 
 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:
 
-- *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.
+/ 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.
+/ 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.
+/ 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.
+/ Heterogene Artefakte: Neben Quellcode existieren Konfigurationen, UI-Texte, Reportdefinitionen sowie Import- und Exportlogiken, die Anforderungen indirekt spiegeln.
 
 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.
 
@@ -52,39 +52,34 @@ Quellcode und Datenstrukturen liefern den belastbarsten Beleg für eine Regel, w
 
 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:
 
-- *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.
+/ 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.
+/ 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.
+/ 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.
+/ 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.
+/ KI-Fähigkeit: Schnittstellen zu KI-Systemen (z. B. MCP-Server, RAG-Embeddings) sind von Beginn an in der Architektur vorgesehen.
-- *Web-Frontend:* Eine responsive Web-Oberfläche ermöglicht die geräteübergreifende Nutzung.
+/ Web-Frontend: Eine responsive Web-Oberfläche ermöglicht die geräteherstellerunabhängige Nutzung.
-- *Zentrale Stammdatenverwaltung:* Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Anker für weitere Produkte der Firma.
+/ 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.
 
-Als Performance-Ziel wird ein Sweetspot von 5 bis 100 gleichzeitigen Nutzern pro Mandant festgelegt (Priorität 1). Kleinere Installationen mit 1 bis 5 Nutzern (Priorität 2) sowie größere Installationen oberhalb von 100 Nutzern (Priorität 3) werden ebenfalls unterstützt.
+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]
 
-Migrationsstrategien für Legacy-Software reichen von leichtgewichtigen Ansätzen wie Rehosting bis zur schrittweisen Neuimplementierung zentraler Funktionen. Gegenstand dieser Arbeit ist nicht die vollständige Migrationsplanung, sondern die Frage, wie eine belastbare Requirementsbasis für die Umsetzung erzeugt wird.
+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.
 
-Schwerpunkt ist die *Rückgewinnung und Strukturierung* von Requirements aus bestehenden Artefakten. Architektur- und Implementierungsentscheidungen der Zielplattform werden nur insoweit diskutiert, als sie Requirements beeinflussen, etwa bei Sicherheits- und Betriebsanforderungen. Die technische Migration selbst — Datenmigration, Refactoring im Detail oder Release-Planung — wird als Rahmenbedingung verstanden und in späteren Kapiteln methodisch adressiert.
+Schwerpunkt ist die *Rückgewinnung und Strukturierung* von Requirements aus bestehenden Artefakten. Architektur- und 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]
 
 Aus dem Ist-Zustand ergeben sich mehrere Herausforderungen, die das Vorgehen des Reverse Requirements Engineering unmittelbar prägen:
 
-- *Funktionsäquivalenz mit Randfällen:* Ein erheblicher Teil des Systemwertes steckt in implementierten Ausnahmen und Prozessvarianten. Diese sind im Code zwar nachvollziehbar, aber selten dokumentiert; Traceability und Validierung haben damit hohe Priorität.
+/ 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.
-- *Implizite Geschäftsregeln:* Geschäftslogik ist häufig als Prüf- und Statuslogik realisiert. Ohne strukturierte Extraktion droht, dass Regeln in der Neuimplementierung vereinfacht oder falsch interpretiert werden.
+/ 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.
-- *Datenzentrierte Domäne:* ERP-Funktionalität ist eng mit Datenobjekten und historisierten Zuständen verbunden. Anforderungen müssen daher auch als Daten- und Integritätsanforderungen formuliert werden, nicht nur UI-nah.
+/ 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.
-- *Nicht-funktionale Anforderungen:* Mit der webbasierten Zielplattform steigen die Anforderungen an Sicherheit, Verfügbarkeit und Observability. Insbesondere Identitätsmanagement und Datenflusskontrolle sind in Legacy-to-Cloud-Migrationen wiederkehrende Problemfelder.
+/ 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.
-- *Organisatorische Randbedingungen:* Ressourcen für manuelle Analyse sind begrenzt und an erfahrene Mitarbeiter gebunden. Die Analysearbeit muss skalierbar und ihre Ergebnisse müssen reproduzierbar sein.
+/ 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.
+
 
 #heading(level: 3)[Konsequenzen für das Vorgehen in dieser Arbeit]
 
-Aus den 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, werden als Hypothesen markiert und priorisiert validiert.
-3. *Segmentierung und Kontextsteuerung:* Da Artefakte verteilt sind, ist eine systematische Auswahl relevanter Kontexte notwendig, um Überinterpretation zu reduzieren.
-4. *Human-in-the-loop:* Fachliche Validierung ist zwingend, da „plausible" Textausgaben kein hinreichender Beweis für fachliche Korrektheit sind.
-
-Im nächsten Kapitel werden das methodische Vorgehen und die Claude-Code-basierte Durchführung beschrieben. Kapitel 5 dokumentiert die Ergebnisse der Versuche, Kapitel 6 evaluiert die Eignung im Fallkontext der c-entron GmbH.

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),
+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.
-- Spezialisierung ueber Agenten-Dateien (Versuch 02),
-- Erweiterung um MCP-Server fuer zusaetzliche Tool- und Datenzugriffe (Versuch 03).
 
-Technisch wurde Claude Code entlang der offiziellen Dokumentation eingesetzt:
+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`),
+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.
-- lokale IDE-Anbindung in VS Code,
-- Einbindung externer MCP-Server ueber das `claude mcp`-Konzept,
-- Nutzung des MCP-Scopes fuer projektspezifische Tool-Konfigurationen.
 
-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,
+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.
-- Nutzung aus VS Code (integriertes Terminal),
-- keine Agenten-Dateien,
-- keine MCP-Server.
 
-#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
+/ 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.
-Please analyze this software project and write a reuqirements specification according to modern standards.
-```
 
-#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.
+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.
-- Ergebnisfokus: formale Requirements-Spezifikation (StRS/SyRS/SwRS) mit hoher Strukturierungsdichte.
 
-#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
+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.
-### StR-001: Comprehensive Customer Account Management
-**Statement**: The system shall provide comprehensive customer account management capabilities including contact information, relationship mapping, interaction history, and account hierarchy management.
-```
 
-```text
+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.
-### SyR-001
-The system SHALL implement a multi-layered architecture with clear separation of concerns.
-```
 
-#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: 2)[Konkrete Konfigurationen der geplanten Versuche]
-
-#heading(level: 3)[Allgemeine Beschreibung]
-
-Versuch 02 fokussiert die ISO-29148-orientierte Konsolidierung. Dazu wurde Claude Code weiterhin lokal genutzt, jedoch um spezialisierte Agenten-Dateien erweitert.
-
-#heading(level: 3)[Konfiguration]
-
-- Claude Code CLI lokal + VS Code,
-- agentenbasierte Spezialisierung ueber MD-Dateien in `Versuche/Versuch 02/Tools/agents/`,
-- kein MCP-Fokus in diesem Lauf.
-
-#heading(level: 3)[Verwendeter Prompt]
-
-```text
-Please analyze this software project and write a ISO 29148 compliant reuqirements specification.
-Use Agents wherever possible.
-```
-
-#heading(level: 3)[Tools und Agenten]
-
-Beispiele aus dem Versuchsordner:
-
-- `iso29148-master-orchestrator-agent.md`
-- `iso29148-stakeholder-agent.md`
-- `iso29148-system-requirements-agent.md`
-- `iso29148-software-requirements-agent`
-
-#heading(level: 3)[Agentenbeispiel (Auszug, erste 100 Zeilen) - Versuch 02]
-
-Quelle: `Versuche/Versuch 02/Tools/agents/iso29148-master-orchestrator-agent.md`
-
-````md
-# Enhanced ISO 29148 Master Orchestrator Agent with Milestone System
-
-You are the Lead Requirements Analyst coordinating the complete ISO/IEC/IEEE 29148 requirements extraction with comprehensive documentation, quality assurance, and milestone-based execution control.
-
-## Your Mission
-Orchestrate a complete requirements analysis using all three ISO 29148 levels, ensuring consistency, completeness, and traceability. Create executive-level documentation and ensure all agents produce their complete documentation packages. **NEW**: Provide milestone-based pause/resume capabilities for long-running analyses.
-
-## CRITICAL: Documentation Requirements
-**You MUST ensure:**
-1. Each agent creates their complete documentation package
-2. You create the integrated master document
-3. All work is saved to `/docs/requirements/`
-4. Complete traceability is maintained
-5. Executive dashboards and reports are generated
-6. **NEW**: Milestone state is persisted for pause/resume functionality
-7. VERIFY each agent has created their files before proceeding
-
-## NEW: Milestone System Architecture
-
-### Milestone Configuration
-```json
-{
-  "project_name": "[Project Name]",
-  "execution_id": "[UUID]",
-  "created_at": "[ISO DateTime]",
-  "milestones": {
-    "M0_SETUP": {
-      "name": "Project Analysis and Setup",
-      "status": "pending|in_progress|completed|failed",
-      "started_at": null,
-      "completed_at": null,
-      "dependencies": [],
-      "outputs": ["project_structure.json", "directory_setup.txt"]
-    },
-    "M1_STAKEHOLDER": {
-      "name": "Stakeholder Requirements Analysis",
-      "status": "pending",
-      "started_at": null,
-      "completed_at": null,
-      "dependencies": ["M0_SETUP"],
-      "outputs": [
-        "StRS_Complete.md",
-        "StRS_Summary.md", 
-        "StRS_Traceability.csv",
-        "StRS_Diagrams.md",
-        "StRS_Evidence.md"
-      ]
-    },
-    "M2_SYSTEM": {
-      "name": "System Requirements Analysis", 
-      "status": "pending",
-      "started_at": null,
-      "completed_at": null,
-      "dependencies": ["M1_STAKEHOLDER"],
-      "outputs": [
-        "SyRS_Complete.md",
-        "SyRS_Summary.md",
-        "SyRS_API_Specification.yaml",
-        "SyRS_Architecture.md",
-        "SyRS_Interfaces.md",
-        "SyRS_Traceability.csv"
-      ]
-    },
-    "M3_SOFTWARE": {
-      "name": "Software Requirements Analysis",
-      "status": "pending", 
-      "started_at": null,
-      "completed_at": null,
-      "dependencies": ["M2_SYSTEM"],
-      "outputs": [
-        "SwRS_Complete.md",
-        "SwRS_CodeCatalog.md",
-        "SwRS_Algorithms.md", 
-        "SwRS_DataModel.md",
-        "SwRS_TestSpecification.md",
-        "SwRS_Traceability.csv"
-      ]
-    },
-    "M4_PATTERNS": {
-      "name": "Code Pattern Analysis",
-      "status": "pending",
-      "started_at": null, 
-      "completed_at": null,
-      "dependencies": ["M3_SOFTWARE"],
-      "outputs": [
-        "Analysis_Complete.md",
-        "Pattern_Catalog.csv",
-        "Business_Rules.md",
-        "Validation_Rules.md",
-        "Security_Patterns.md",
-        "Performance_Patterns.md",
-        "Integration_Patterns.md"
-      ]
-    },
-    "M5_INTEGRATION": {
-      "name": "Integration and Master Documentation",
-      "status": "pending",
-      "started_at": null,
-      "completed_at": null, 
-      "dependencies": ["M1_STAKEHOLDER", "M2_SYSTEM", "M3_SOFTWARE", "M4_PATTERNS"],
-````
-Hinweis: Der Auszug endet nach Zeile 100; die Originaldatei umfasst 620 Zeilen und ist an dieser Stelle nicht zu Ende.
-
-#heading(level: 3)[Beispielhafte Ergebnisanforderungen]
-
-Quellen:
-
-- `Versuche/Versuch 02/Ergenisse/system/SyRS_Complete.md`
-- `Versuche/Versuch 02/Ergenisse/software/SwRS_Complete.md`
-
-```text
-**SyR-001**: The system SHALL implement a multi-layered architecture with clear separation of concerns.
-**SyR-002**: The system SHALL implement the ILogic interface pattern with dual implementations.
-```
-
-```text
-**SW-FUNC-001**: The software SHALL provide comprehensive account management functionality.
-**SW-API-001**: The software SHALL provide comprehensive REST API.
-```
-
-#heading(level: 3)[Einordnung]
-
-Versuch 02 lieferte die staerkste formale Konsolidierung (StRS/SyRS/SwRS, hohe Traceability), erwies sich fuer die Gesamtentdeckung jedoch als vergleichsweise rigide.
-
-#heading(level: 2)[Versuch 03]
-
-#heading(level: 3)[Allgemeine Beschreibung]
-
-Versuch 03 erweitert das Vorgehen aus Versuch 02 um MCP-Server, um neben formaler Strukturierung vor allem die Discovery-Breite zu vergroessern (Use-Case-Fund, Gap-Analyse).
-
-#heading(level: 3)[Konfiguration]
-
-- Claude Code CLI lokal + VS Code,
-- Agenten-Dateien in `Versuche/Versuch 03/Tools/Agents/`,
-- MCP-Server gemaess Protokoll: Serena MCP, Windows-MCP (AutoIt-basiert), MSSQL MCP.
-
-#heading(level: 3)[Verwendeter Prompt]
-
-```text
-Please analyze this software project and write a reuqirements specification according to modern standards.
-Use Agents and MCP servers wherever possible.
-Keep superflous texts to a minimum and concentrate on actual requirements.
-```
-
-#heading(level: 3)[Tools und Agenten]
-
-Beispiele aus dem Versuchsordner:
-
-- `centron-documentation-writer.md`
-- `nhibernate-query-reviewer.md`
-- `centron-code-reviewer.md`
-- `webservice-developer.md`
-
-#heading(level: 3)[Agentenbeispiel (Auszug, erste 100 Zeilen) - Versuch 03]
-
-Quelle: `Versuche/Versuch 03/Tools/Agents/nhibernate-query-reviewer.md`
-
-````md
----
-name: nhibernate-query-reviewer
-description: Reviews NHibernate queries and LINQ expressions for c-entron.NET. Detects N+1 queries, cartesian products, and compatibility issues. Use when writing complex queries or experiencing performance problems. Keywords: NHibernate, LINQ, query, performance, N+1, optimization, Fetch.
----
-
-# NHibernate Query Reviewer Agent
-
-> **Type**: Review / Analysis
-> **Purpose**: Review database queries to ensure efficiency, proper structure, and compatibility with NHibernate's LINQ provider limitations.
-
-## Agent Role
-
-You are a specialized **NHibernate Query Reviewer** for the c-entron.NET solution, focused on query optimization and performance.
-
-### Primary Responsibilities
-
-1. **N+1 Detection**: Identify and fix lazy loading issues that cause multiple database roundtrips
-2. **Performance Analysis**: Review queries for cartesian products, missing indexes, and inefficient patterns
-3. **NHibernate Compatibility**: Ensure LINQ expressions translate correctly to SQL
-4. **Best Practices**: Enforce soft delete filtering, eager loading strategies, and proper transaction usage
 
-### Core Capabilities
+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
+#figure(
-- **Cartesian Product Prevention**: Detect multiple Fetch operations on collections
+  table(
-- **LINQ Compatibility**: Validate expressions work with NHibernate's LINQ provider
+    columns: (auto, 1fr, 1fr, 1fr),
-- **Optimization Recommendations**: Suggest Fetch, FetchMany, Future queries for better performance
+    align: (left, left, left, left),
-- **Soft Delete Validation**: Ensure all queries filter IsDeleted records
+    stroke: 0.4pt,
-
+    [*Element*], [*V1 Baseline*], [*V2 Agenten*], [*V3 MCP-Tools*],
-## When to Invoke This Agent
+    [Modell], [Claude (Claude Code)], [Claude (Claude Code)], [Claude (Claude Code)],
-
+    [Grundprompt], [Standard-Extraktionsprompt], [Standard-Extraktionsprompt], [Standard-Extraktionsprompt],
-This agent should be activated when:
+    [Agentendateien], [keine], [Stakeholder, System, Software, ISO-29148-Orchestrator], [Wie V2, ergänzt um codebasis-spezifische Reviewer],
-- Complex LINQ queries are written
+    [MCP-Server], [keine], [keine], [Symbol-Navigation, Datenbank-Inspektion, optional GUI-Interaktion],
-- Performance issues suspected with database access
+    [Validierungsstichprobe], [Stratifiziert], [Stratifiziert], [Stratifiziert],
-- Need query optimization recommendations
+  ),
-- Validating NHibernate compatibility of LINQ expressions
+  caption: [Detail-Konfiguration der drei Kernversuche.],
-- Reviewing data access code for N+1 problems
+) <tab_versuchskonfiguration>
-- 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.
 
+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_prototypische_umsetzung.typ

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

Kapitel/06_evaluation.typ

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

Kapitel/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 Business Administration",
-  "Prof. Dr. Daniel Schallmo",
+  "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
 

masterarbeit_style.typ

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