sync

Kapitel/02_theoretischer_hintergrund/02_01_requirements_engineering.typ

@@ -71,9 +71,9 @@ Methodisch lassen sich dabei grob zwei Analysestränge unterscheiden:
 / Statische Analyse: Ableitung von Struktur- und Datenflussinformationen aus Code und Artefakten ohne Ausführung (z. B. Abhängigkeiten, SQL-Statements, Aufrufketten). Statische Analyse skaliert gut, erkennt aber nicht zuverlässig Laufzeitbedingungen (z. B. Feature Flags, Konfigurationsvarianten).
 / Dynamische Analyse: Beobachtung von Laufzeitverhalten durch Logging, Tracing oder instrumentierte Tests (z. B. welche Regeln bei bestimmten Eingaben greifen). Dynamische Analyse ist näher am realen Verhalten, benötigt aber reproduzierbare Szenarien und Testdaten.
 
-Reverse Requirements Engineering in einem Migrationsprojekt profitiert typischerweise von einer Kombination beider Stränge. Ohne dynamische Belege steigt das Risiko, dass nicht offensichtliche Bedingungen (z. B. kundenspezifische Schalter) übersehen werden; ohne statische Analyse bleibt die Abdeckung häufig zu gering.
+Reverse Requirements Engineering in einem Migrationsprojekt profitiert typischerweise von einer Kombination beider Stränge. Ohne dynamische Belege steigt das Risiko, dass nicht offensichtliche Bedingungen wie kundenspezifische Schalter übersehen werden. Ohne statische Analyse bleibt die Abdeckung häufig zu gering.
 
-_Da eine Dynamische Analyse durch ein LLM mit den gegebenen technischen Möglichkeiten derzeit unpraktikabel ist, fokussiert sich diese Arbeit auf die statische Analyse von Artefakten, ergänzt manuell erstellte Artefakte zur Laufzeit (z.B. Screenshots)._
+_Eine vollständige dynamische Analyse durch ein LLM ist mit den gegebenen technischen Möglichkeiten derzeit nicht praktikabel. Diese Arbeit fokussiert sich daher auf die statische Analyse von Artefakten und ergänzt sie um manuell erstellte Laufzeit-Artefakte wie Screenshots. Mit einem MCP-Server zur GUI-Beobachtung ist darüber hinaus eine teilweise dynamische Analyse möglich. Dieser Ansatz wird im Versuchsaufbau optional vorgesehen._
 
 #heading(level: 3)[Typische Methodenkette für Requirements-Rückgewinnung aus Code]
 

Kapitel/04_konzeption_methodisches_vorgehen.typ

@@ -9,8 +9,8 @@
 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.
 
 #include "04_konzeption_methodisches_vorgehen/04_01_methodisches_design.typ"
-#pagebreak()
+
 #include "04_konzeption_methodisches_vorgehen/04_02_versuchsdesign.typ"
-#pagebreak()
+
 #include "04_konzeption_methodisches_vorgehen/04_03_evaluation_und_absicherung.typ"
-#pagebreak()
+

Kapitel/04_konzeption_methodisches_vorgehen/04_02_versuchsdesign.typ

@@ -80,7 +80,7 @@ Der Versuchsaufbau folgt einer schrittweise aufbauenden Vergleichslogik. Versuch
       - DeepSeek R1 über Cloud-API
       - Qwen 3.5 Coder lokal über LM Studio
     ],
-    [Trennung modell- gegenüber werkzeugabhängiger Effekte],
+    [- Trennung modell- gegenüber werkzeugabhängiger Effekte],
   ),
   caption: [Übersicht der geplanten Versuche mit Werkzeugkonfiguration und Arbeitshypothese.],
 ) <tab_versuchsreihe>

Kapitel/06_evaluation.typ

@@ -4,7 +4,7 @@
   #hide(bibliography("../literatur.bib", style: "apa"))
 ]
 
-#heading(level: 1)[Evaluation (ca. 12 Seiten)]
+#heading(level: 1)[Evaluation]
 
 // TODO Variante B – Anwendung des in Kap 4.6 definierten Evaluationsrahmens auf die
 // Ergebnisse aus Kap 5. Keine Erst-Definition von Kriterien hier.

Kapitel/09_literaturverzeichnis.typ

@@ -1,3 +1,3 @@
-#heading(level: 1)[Literaturverzeichnis (ca. 3 Seiten)]
+#heading(level: 1)[Literaturverzeichnis]
 
 #bibliography("../literatur.bib", style: "apa")

Kapitel/10_anhang.typ

@@ -1,11 +1,9 @@
-#heading(level: 1)[Anhang (ca. 6 Seiten)]
+#heading(level: 1)[Anhang]
 
 #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]
+#heading(level: 2)[Konfigurationsdetails]