03_fertig

Kapitel/01_einleitung.typ

@@ -25,7 +25,6 @@ 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 .
 

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.
-- ***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 Engeneering Ansatzes sind diese aber relevant für die implementierung und architekturlle 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-Engineering-Ansatzes sind diese aber relevant für die Implementierung und architekturelle Entscheidungen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben)._
 
 #heading(level: 3)[Arten von Requirements und Qualitätskriterien]
 
@@ -35,40 +35,40 @@ _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?
 
-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.
 
 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.
@@ -95,7 +95,7 @@ In der Praxis unterscheiden sich Artefakte darin, wie direkt sie fachliche Aussa
 
 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/03_fallstudie.typ

@@ -57,34 +57,29 @@ Ziel der Modernisierung ist eine webbasierte SaaS-Plattform, die sowohl Cloud- a
 - *Datenbanksystem-Unabhängigkeit:* Geschäftslogik und Abfragen werden möglichst vollständig im Code abgebildet und nicht im DBMS. Damit sinken Migrationsaufwände, und im Multi-Tenant-Betrieb lassen sich günstige oder kostenlose Datenbanksysteme einsetzen.
 - *Skalierbarkeit:* Das Backend ist über Microservices und Load-Balancing horizontal skalierbar, um auch bei größeren Kunden performant zu bleiben.
 - *KI-Fähigkeit:* Schnittstellen zu KI-Systemen (z. B. MCP-Server, RAG-Embeddings) sind von Beginn an in der Architektur vorgesehen.
-- *Web-Frontend:* Eine responsive Web-Oberfläche ermöglicht die geräteübergreifende Nutzung.
-- *Zentrale Stammdatenverwaltung:* Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Anker für weitere Produkte der Firma.
+- *Web-Frontend:* Eine responsive Web-Oberfläche ermöglicht die geräteherstellerunabhängige Nutzung.
+- *Zentrale Datenverwaltung:* Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Basis für weitere Produkte der Firma.
 
-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.
-- *Implizite Geschäftsregeln:* Geschäftslogik ist häufig als Prüf- und Statuslogik realisiert. Ohne strukturierte Extraktion droht, dass Regeln in der Neuimplementierung vereinfacht oder falsch interpretiert werden.
-- *Datenzentrierte Domäne:* ERP-Funktionalität ist eng mit Datenobjekten und historisierten Zuständen verbunden. Anforderungen müssen daher auch als Daten- und Integritätsanforderungen formuliert werden, nicht nur UI-nah.
-- *Nicht-funktionale Anforderungen:* Mit der webbasierten Zielplattform steigen die Anforderungen an Sicherheit, Verfügbarkeit und Observability. Insbesondere Identitätsmanagement und Datenflusskontrolle sind in Legacy-to-Cloud-Migrationen wiederkehrende Problemfelder.
-- *Organisatorische Randbedingungen:* Ressourcen für manuelle Analyse sind begrenzt und an erfahrene Mitarbeiter gebunden. Die Analysearbeit muss skalierbar und ihre Ergebnisse müssen reproduzierbar sein.
+- *Randfäll und Varianten:* Ein erheblicher Teil des Systemumfangs steckt in implementierten Sonderfällen und Varianten. Diese sind im Code zwar nachvollziehbar, aber selten dokumentiert und zur Laufzeit auch jeweils nur einzeln zu analysieren da sie sich oft gegenseitig ausschließen.
+- *Daten und Logische Redundanz:* Historisch wurden zusätzliche Funktionen oft inmplementiert indem Code oder Masken hinzugefügt wurden ohne alten code zu verändern. Daher kommt es vor, dass die die gleiche Anforderung auf Unterschiedlichen Masken oder Berechnungspfaden mehrfach unterschiedliche implementiert wurde.
+- *Implizite Geschäftsregeln:* Geschäftslogik ist häufig als Prüf- und Statuslogik oder über Randbediungungen in Eingabefeldern realisiert. Eine zuordung zu anderen zusammenghörigen Regeln fällt hier schwer.
+- *Kontextbasierte Logik:* Funktionalitäten und Logik sind oft nur lose über  historische Zuständen verbunden. Eine Regel kann daher nur bei Betrachtung eines vollständigen historischen Datensatzes im Kontext abgeleitet werden.
+- *Nicht-funktionale Anforderungen:* Mit dem Wechsel auf einen neuen Tech-Stack ist zu prüfen, welche der bisherigen nicht-funktionalen Anforderungen weiterhin Gültigkeit haben und welche neu definiert werden müssen. Annahmen zu Performance, Sicherheit oder Verfügbarkeit gelten unter veränderten Architektur- und Betriebsbedingungen nicht automatisch weiter.
+
 
 #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.

Stilvorlage.md

@@ -23,6 +23,10 @@ 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 dessen Überschrift (z.B. `*Titel:* Beschreibung …` oder `*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 …".
 
 ## 2. Strukturbausteine pro Dokumenttyp