Gowler/Masterarbeit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

04_init neu

Browse Source
This commit is contained in:
christoph.schwoerer
2026-05-26 08:43:03 +02:00
parent 7ab5d923f8
commit 2bd9646f44
8 changed files with 258 additions and 2610 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1913
Kapitel/01_einleitung.pdf
View File

File diff suppressed because it is too large Load Diff

221
Kapitel/04_konzeption_methodisches_vorgehen.typ Normal file
View File

@@ -0,0 +1,221 @@
#import "@preview/cetz:0.4.2"
#let __is_thesis = context { query(<__thesis_document>).len() > 0 }
#if __is_thesis == false [
#set cite(style: "apa")
#hide(bibliography("../literatur.bib", style: "apa"))
]
#heading(level: 1)[Konzeption und methodisches Vorgehen (ca. 12 Seiten)]
Dieses Kapitel beschreibt die Methodik, mit der die in Kapitel 1 beschriebenen Ziele und Forschungsleitfragen beantwortet werden sollen. Ausgangspunkt ist das methodische Design. Aus diesem Design leiten sich alle weiteren methodischen Entscheidungen ab. Vorausgegangene Proof-of-Concept-Läufe haben einzelne Aspekte des Vorgehens informell erprobt und das hier dargestellte Vorgehen geprägt, sie sind aber nicht Gegenstand der Auswertung. Die eigentliche Untersuchung wird in den folgenden Abschnitten geplant und in den folgenden Kapiteln durchgeführt und bewertet.
#heading(level: 2)[Methodisches Design im Überblick]
Das Vorgehen ist entlang der vier Forschungsleitfragen aus Kapitel 1 strukturiert. Diese werden im Folgenden mit Frage 1 (Steuerung und Reproduzierbarkeit), Frage 2 (KI-Extraktion und Stakeholder-Input), Frage 3 (Qualitätsbewertung) und Frage 4 (Chancen, Grenzen und Risiken) bezeichnet. Aus jeder Leitfrage folgt unmittelbar eine Datenquelle und ein Auswertungsweg. Damit ist sichergestellt, dass die methodischen Bausteine nicht nachträglich auf die Fragen abgebildet werden, sondern aus ihnen hervorgehen.
#figure(
cetz.canvas({
import cetz.draw: *
let stages = (
(y: 4.0, label: "Codebasis", q: none),
(y: 2.0, label: "KI-Extraktion", q: (num: "Frage 1", text: "Welche Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?")),
(y: 0.0, label: "Strukturierung", q: (num: "Frage 2", text: "Welche Anforderungen lassen sich aus Code extrahieren, welche müssen über Interviews ergänzt werden?")),
(y: -2.0, label: "Validierung", q: (num: "Frage 3", text: "Wie beurteilen Fachexperten Vollständigkeit, Verständlichkeit und Nützlichkeit der KI-Ergebnisse?")),
(y: -4.0, label: "Bewertung", q: (num: "Frage 4", text: "Welche Effizienzgewinne, Limitierungen und Risiken sind realistisch und müssen adressiert werden?")),
)
let box-half-w = 1.5
let box-half-h = 0.4
let stage-x = -5.0
let arrow-gap = 0.1
for s in stages {
rect(
(stage-x - box-half-w, s.y - box-half-h),
(stage-x + box-half-w, s.y + box-half-h),
stroke: black + 0.6pt, fill: luma(240),
)
content((stage-x, s.y), text(size: 9pt, weight: "bold")[#s.label])
}
for i in range(stages.len() - 1) {
let s1 = stages.at(i)
let s2 = stages.at(i + 1)
line(
(stage-x, s1.y - box-half-h - arrow-gap),
(stage-x, s2.y + box-half-h + arrow-gap),
mark: (end: ">"),
stroke: black + 0.6pt,
)
}
let q-x = stage-x + box-half-w + 0.6
for s in stages {
if s.q != none {
content(
(q-x, s.y),
anchor: "west",
box(
width: 9cm,
text(size: 9pt)[*#s.q.num:* #s.q.text],
),
)
}
}
}),
caption: [Methodisches Design im Überblick. Die vertikale Sequenz zeigt den Ablauf von der Codebasis bis zur Bewertung. Pro Phase ist die zugeordnete Forschungsleitfrage angeben.],
) <abb_forschungsdesign>
Der untersuchte Prozess folgt einer durchgehenden Kette von der Codebasis bis zur belastbaren Anforderung. 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 entlang vordefinierter Qualitätsdimensionen.
Aus diesem Ablauf ergeben sich drei methodische Bausteine, die in den folgenden Abschnitten ausgearbeitet werden. Erstens die *kontrollierte Tooling-Ablation*. 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.
#heading(level: 2)[Bezugsrahmen: Der RRE-Prozess als Untersuchungsgegenstand]
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. Damit verschiebt sich der Untersuchungsschwerpunkt nicht auf die Anforderungsbeschreibung als solche, sondern auf die zuverlässige Erzeugung dieser Beschreibung durch ein LLM.
Damit das Vorgehen belastbar bleibt, sind in jeder Iteration vier 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.
- *Segmentierung und Kontextsteuerung:* Da Artefakte über die Codebasis verteilt sind, wird der dem LLM jeweils präsentierte Kontext bewusst eingeschränkt, um Überinterpretation zu reduzieren.
- *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 vier Pflicht-Eigenschaften ist der Bezugsrahmen geklärt, in dem die folgenden Abschnitte ihre Detailfragen verorten.
#heading(level: 2)[Werkzeugbasis: 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.
In die Vorauswahl gehen vier aktuell verfügbare Optionen ein. 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. Auf lokaler Seite kommen das offen verfügbare Qwen sowie Kimi infrage, beide mit der Möglichkeit zur Ausführung ohne Cloud-Versand.
#figure(
table(
columns: (1.4fr, 1fr, 1fr, 1fr, 1fr),
align: (left, center, center, center, center),
stroke: 0.4pt,
[*Kriterium*], [*Claude (Claude Code)*], [*GPT-5 (Codex)*], [*Qwen (lokal)*], [*Kimi (lokal)*],
[Kontextfenster], [bis 1 M Tokens], [bis 400 k Tokens], [bis 128 k Tokens], [bis 200 k Tokens],
[Codeverständnis], [hoch], [hoch], [mittel], [mittel],
[Steuerbarkeit (Agenten, MCP)], [nativ], [über Codex-CLI], [eingeschränkt], [eingeschränkt],
[Kosten], [API-Abrechnung], [API-Abrechnung], [Eigenbetrieb], [Eigenbetrieb],
[Datenschutz], [Cloud-Versand], [Cloud-Versand], [On-Premise], [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 und Kimi werden für einen optionalen LLM-Querschnitt offengehalten, sind aber nicht das primäre Werkzeug.
#heading(level: 2)[Untersuchungsdesign: Tooling-Ablation als kontrollierte Variation]
Das Untersuchungsdesign folgt einer Ablation-Logik. Ausgehend von einer Baseline werden in jedem weiteren Versuch zusätzliche Werkzeugkomponenten hinzugefügt, sodass der Effekt jeder Komponente isoliert beobachtbar ist. Alle Versuche arbeiten auf derselben Codebasis und mit demselben Grundprompt. Variiert wird ausschließlich die Werkzeugkonfiguration. Drei Versuche bilden den Kern der Reihe, ein vierter Versuch ist optional vorgesehen.
*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 vergrößern.
*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 einem zweiten Modell wiederholt, beispielsweise auf einem lokal betriebenen Qwen oder Kimi. 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, left, left),
stroke: 0.4pt,
[*Versuch*], [*Werkzeugkonfiguration*], [*Hypothese*],
[V1 Baseline], [Prompt-only, ohne Agenten, ohne Tools], [Formal strukturierte Spezifikation erreichbar, Discovery-Breite begrenzt],
[V2 Agenten], [Wie V1, ergänzt um rollenspezialisierte Agentendateien], [Höhere Strukturierungstiefe und Normkonformität bei vergleichbarer Breite],
[V3 MCP-Tools], [Wie V2, ergänzt um MCP-Server für Code, Datenbank und optional GUI], [Größere Discovery-Breite, höhere Steuerungskomplexität],
[V4 (optional)], [Beste Konfiguration aus V1–V3 mit alternativem Modell], [Trennung modell- gegenüber werkzeugabhängiger Effekte],
),
caption: [Übersicht der geplanten Versuche mit Werkzeugkonfiguration und Arbeitshypothese.],
) <tab_versuchsreihe>
Konstanten und Variablen sind in jedem Versuch klar dokumentiert. Konstanten umfassen Codebasis, Grundprompt, Modellfamilie, Validierungsstichprobe und Bewertungskriterien. Variabel ist die Werkzeugkonfiguration. Damit lassen sich Unterschiede in den Ergebnissen ursächlich der Werkzeugvariation zuordnen.
#heading(level: 2)[Stakeholder-Validierung als zentrales Verifikationsverfahren]
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.
Vorgesehen sind drei bis fünf Validatoren mit jeweils mehrjähriger Erfahrung in der c-entron-Codebasis und in den fachlich abgedeckten Geschäftsprozessen. Die Auswahl orientiert sich an Modulvertrautheit, sodass alle relevanten Bereiche wie Auftragsabwicklung, Lager und Fakturierung durch mindestens einen Validator abgedeckt sind. Die Teilnehmer sind bereits identifiziert; der Interview-Leitfaden ist im Anhang dokumentiert.
Für die Validierung wird pro Versuchslauf eine stratifizierte Stichprobe gezogen. Die Stratifizierung erfolgt entlang zweier Dimensionen. Erstens nach Belegart, also nach Primär-, Sekundär- und Kontextbeleg im Sinne der in den theoretischen Grundlagen eingeführten Klassifikation. Zweitens nach Risikoklasse, wobei Abrechnungs- und Berechtigungslogik mit höherer Stichprobenrate erfasst werden als periphere Funktionen. Die Stichprobengröße wird so dimensioniert, dass je Stratum mindestens 30 Anforderungen bewertet werden.
Jede Anforderung wird entlang von fünf Dimensionen bewertet:
- *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?
- *Nützlichkeit:* Ist die Anforderung für die Migration verwertbar?
Die Bewertung erfolgt auf einer fünfstufigen Likert-Skala mit definierten Ankern an den Polen, wobei 1 für „trifft nicht zu" und 5 für „trifft voll zu" steht. Bei migrationskritischen Anforderungen ist eine doppelte Bewertung durch zwei Validatoren vorgesehen, um die Inter-Rater-Reliabilität abschätzen zu können.
Ergänzend zur itemweisen Bewertung werden mit den Validatoren halbstrukturierte Interviews geführt. Themenblöcke sind die Erkennung impliziter Regeln, fehlende Stakeholder-Sichten, migrationsspezifische Risiken sowie die Nützlichkeit der KI-Ergebnisse im Vergleich zu einer hypothetischen manuellen Analyse. Die Auswertung erfolgt über thematische Codierung und wird mit den itemweisen Bewertungen trianguliert.
Eine Anforderung gilt im Sinne dieser Arbeit als belastbar, wenn drei Quellen sie stützen: ein konkreter Code-Beleg, eine KI-Ausgabe und eine Expertenbestätigung. Diese Triangulation reduziert das Risiko, dass eine plausibel formulierte aber inhaltlich falsche LLM-Ausgabe ungeprüft in die Spezifikation übernommen wird.
#heading(level: 2)[Evaluationsrahmen]
Der Evaluationsrahmen wird vor der Durchführung der Versuche definiert. Damit wird eine nachträgliche Anpassung der Kriterien an die Ergebnisse ausgeschlossen. Die Bewertung orientiert sich an den drei Qualitätsdimensionen, die in den theoretischen Grundlagen als Standard-Kriterien für Requirements-Sätze hergeleitet wurden.
*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.
*Set-Qualität.* Pro Spezifikations-Set, also Stakeholder-, System- und Software-Requirements, wird gemessen, ob die Menge konsistent, nicht redundant und ausreichend breit ist, ohne sich in Detailfällen zu verlieren. Die Messung erfolgt qualitativ durch Expertenbewertung und ergänzend durch maschinelle Konsistenzprüfungen wie doppelte IDs oder fehlende Belege.
*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.
Ergänzend zur Qualitätsbewertung wird eine Aufwands-Kennzahl in hybrider Form erhoben. Sie kombiniert quantitative Indikatoren mit einer groben Stundenschätzung als Plausibilitätsprüfung. Indikatoren sind unter anderem Tokenkosten, Bearbeitungsdauer pro Modul und Anzahl der Validierungs-Iterationen. Die Stundenschätzung erfolgt als grobe Vergleichsangabe gegen ein hypothetisches manuelles Vorgehen, in dem ein erfahrener Analyst die gleichen Module ohne KI-Unterstützung dokumentiert hätte. Sie liefert keinen exakten Effizienzfaktor, sondern eine Größenordnung.
#heading(level: 2)[Reproduzierbarkeit und Risikomanagement]
Reproduzierbarkeit und Risikomanagement sind als querschnittliche Aspekte angelegt. Sie betreffen alle Versuchsdurchläufe gleichermaßen und werden hier zusammengefasst.
Alle steuerungsrelevanten Artefakte werden versioniert vorgehalten. Hierzu zählen die verwendeten Prompts in ihrer Textfassung, die Agentendateien mit ihren Rollenbeschreibungen, die MCP-Server-Konfigurationen sowie die Angaben zu Modellversion, Temperatur und Kontextfenstergröße. Jeder Versuchsordner enthält die vollständige Konfiguration als Single Source. Wo möglich, werden deterministische Einstellungen gewählt.
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.
Die folgenden vier Risikokategorien werden adressiert:
- *Halluzinationen:* Begegnet durch Belegpflicht und Stakeholder-Validierung. Jede Anforderung ohne nachvollziehbaren Beleg wird als Hypothese markiert.
- *Reproduzierbarkeitsverlust:* Begegnet durch versionierte Prompts und deterministische Einstellungen, soweit das Modell sie unterstützt.
- *Domänen- und Datenbias:* Begegnet durch eine Stichprobenwahl, die alle relevanten Module abdeckt und nicht nur die in der KI-Ausgabe häufig auftauchenden.
- *Datenschutzverletzungen:* Begegnet durch On-Premise-MCP, kontrollierten Versand und Logging der externen Aufrufe.
#heading(level: 2)[Konkrete Konfigurationen der geplanten Versuche]
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.
#figure(
table(
columns: (auto, 1fr, 1fr, 1fr),
align: (left, left, left, left),
stroke: 0.4pt,
[*Element*], [*V1 Baseline*], [*V2 Agenten*], [*V3 MCP-Tools*],
[Modell], [Claude (Claude Code)], [Claude (Claude Code)], [Claude (Claude Code)],
[Grundprompt], [Standard-Extraktionsprompt], [Standard-Extraktionsprompt], [Standard-Extraktionsprompt],
[Agentendateien], [keine], [Stakeholder, System, Software, ISO-29148-Orchestrator], [Wie V2, ergänzt um codebasis-spezifische Reviewer],
[MCP-Server], [keine], [keine], [Symbol-Navigation, Datenbank-Inspektion, optional GUI-Beobachtung],
[Validierungsstichprobe], [Stratifiziert], [Stratifiziert], [Stratifiziert],
),
caption: [Detail-Konfiguration der drei Kernversuche.],
) <tab_versuchskonfiguration>
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.

422
Kapitel/04_konzeption_methodisches_vorgehen_VarianteA.typ
View File

@@ -2,419 +2,17 @@
#if __is_thesis == false [ #if __is_thesis == false [
#set cite(style: "apa") #set cite(style: "apa")
#hide(bibliography("../literatur.bib", 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)] #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. // TODO Variante B – wird abschnittsweise gefüllt:
// 4.1 Forschungsdesign-Überblick
#heading(level: 2)[Claude Code als Werkzeug] // 4.2 Bezugsrahmen: Der RRE-Prozess als Untersuchungsgegenstand
// 4.3 Werkzeugbasis: LLM-Auswahl und Claude Code
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: // 4.4 Untersuchungsdesign: Tooling-Ablation als kontrollierte Variation
// 4.5 Stakeholder-Validierung als zentrales Verifikationsverfahren
- Baseline nur mit Prompt + CLI (Versuch 01), // 4.6 Evaluationsrahmen
- Spezialisierung ueber Agenten-Dateien (Versuch 02), // 4.7 Reproduzierbarkeit und Risikomanagement
- Erweiterung um MCP-Server fuer zusaetzliche Tool- und Datenzugriffe (Versuch 03). // 4.8 Konkrete Konfigurationen der drei Versuche
// 4.9 Überleitung
Technisch wurde Claude Code entlang der offiziellen Dokumentation eingesetzt:
- Session-Start und Ausfuehrung ueber CLI (`claude`, `claude -p`),
- lokale IDE-Anbindung in VS Code,
- Einbindung externer MCP-Server ueber das `claude mcp`-Konzept,
- Nutzung des MCP-Scopes fuer projektspezifische Tool-Konfigurationen.
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.
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.
#heading(level: 2)[Versuch 01]
#heading(level: 3)[Allgemeine Beschreibung]
Versuch 01 bildet die Baseline ohne Agenten und ohne MCP. Ziel war eine erste formale Requirements-Extraktion direkt aus der Codebasis mit minimaler Tooling-Komplexitaet.
#heading(level: 3)[Konfiguration]
- Claude Code CLI lokal im Projektverzeichnis,
- Nutzung aus VS Code (integriertes Terminal),
- keine Agenten-Dateien,
- keine MCP-Server.
#heading(level: 3)[Verwendeter Prompt]
```text
Please analyze this software project and write a reuqirements specification according to modern standards.
```
#heading(level: 3)[Tools und Artefakte]
- Tooling: Claude Code CLI + VS Code Integration.
- Ergebnisfokus: formale Requirements-Spezifikation (StRS/SyRS/SwRS) mit hoher Strukturierungsdichte.
#heading(level: 3)[Beispielhafte Ergebnisanforderungen]
Quelle: `Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md`
```text
### StR-001: Comprehensive Customer Account Management
**Statement**: The system shall provide comprehensive customer account management capabilities including contact information, relationship mapping, interaction history, and account hierarchy management.
```
```text
### SyR-001
The system SHALL implement a multi-layered architecture with clear separation of concerns.
```
#heading(level: 3)[Einordnung]
Die Baseline zeigt, dass bereits ohne Agenten/MCP belastbare, formal strukturierte Anforderungen erzeugbar sind. Gleichzeitig bleibt die Discovery-Breite begrenzt.
#heading(level: 2)[Versuch 02]
#heading(level: 3)[Allgemeine Beschreibung]
Versuch 02 fokussiert die ISO-29148-orientierte Konsolidierung. Dazu wurde Claude Code weiterhin lokal genutzt, jedoch um spezialisierte Agenten-Dateien erweitert.
#heading(level: 3)[Konfiguration]
- Claude Code CLI lokal + VS Code,
- agentenbasierte Spezialisierung ueber MD-Dateien in `Versuche/Versuch 02/Tools/agents/`,
- kein MCP-Fokus in diesem Lauf.
#heading(level: 3)[Verwendeter Prompt]
```text
Please analyze this software project and write a ISO 29148 compliant reuqirements specification.
Use Agents wherever possible.
```
#heading(level: 3)[Tools und Agenten]
Beispiele aus dem Versuchsordner:
- `iso29148-master-orchestrator-agent.md`
- `iso29148-stakeholder-agent.md`
- `iso29148-system-requirements-agent.md`
- `iso29148-software-requirements-agent`
#heading(level: 3)[Agentenbeispiel (Auszug, erste 100 Zeilen) - Versuch 02]
Quelle: `Versuche/Versuch 02/Tools/agents/iso29148-master-orchestrator-agent.md`
````md
# Enhanced ISO 29148 Master Orchestrator Agent with Milestone System
You are the Lead Requirements Analyst coordinating the complete ISO/IEC/IEEE 29148 requirements extraction with comprehensive documentation, quality assurance, and milestone-based execution control.
## Your Mission
Orchestrate a complete requirements analysis using all three ISO 29148 levels, ensuring consistency, completeness, and traceability. Create executive-level documentation and ensure all agents produce their complete documentation packages. **NEW**: Provide milestone-based pause/resume capabilities for long-running analyses.
## CRITICAL: Documentation Requirements
**You MUST ensure:**
1. Each agent creates their complete documentation package
2. You create the integrated master document
3. All work is saved to `/docs/requirements/`
4. Complete traceability is maintained
5. Executive dashboards and reports are generated
6. **NEW**: Milestone state is persisted for pause/resume functionality
7. VERIFY each agent has created their files before proceeding
## NEW: Milestone System Architecture
### Milestone Configuration
```json
{
"project_name": "[Project Name]",
"execution_id": "[UUID]",
"created_at": "[ISO DateTime]",
"milestones": {
"M0_SETUP": {
"name": "Project Analysis and Setup",
"status": "pending|in_progress|completed|failed",
"started_at": null,
"completed_at": null,
"dependencies": [],
"outputs": ["project_structure.json", "directory_setup.txt"]
},
"M1_STAKEHOLDER": {
"name": "Stakeholder Requirements Analysis",
"status": "pending",
"started_at": null,
"completed_at": null,
"dependencies": ["M0_SETUP"],
"outputs": [
"StRS_Complete.md",
"StRS_Summary.md",
"StRS_Traceability.csv",
"StRS_Diagrams.md",
"StRS_Evidence.md"
]
},
"M2_SYSTEM": {
"name": "System Requirements Analysis",
"status": "pending",
"started_at": null,
"completed_at": null,
"dependencies": ["M1_STAKEHOLDER"],
"outputs": [
"SyRS_Complete.md",
"SyRS_Summary.md",
"SyRS_API_Specification.yaml",
"SyRS_Architecture.md",
"SyRS_Interfaces.md",
"SyRS_Traceability.csv"
]
},
"M3_SOFTWARE": {
"name": "Software Requirements Analysis",
"status": "pending",
"started_at": null,
"completed_at": null,
"dependencies": ["M2_SYSTEM"],
"outputs": [
"SwRS_Complete.md",
"SwRS_CodeCatalog.md",
"SwRS_Algorithms.md",
"SwRS_DataModel.md",
"SwRS_TestSpecification.md",
"SwRS_Traceability.csv"
]
},
"M4_PATTERNS": {
"name": "Code Pattern Analysis",
"status": "pending",
"started_at": null,
"completed_at": null,
"dependencies": ["M3_SOFTWARE"],
"outputs": [
"Analysis_Complete.md",
"Pattern_Catalog.csv",
"Business_Rules.md",
"Validation_Rules.md",
"Security_Patterns.md",
"Performance_Patterns.md",
"Integration_Patterns.md"
]
},
"M5_INTEGRATION": {
"name": "Integration and Master Documentation",
"status": "pending",
"started_at": null,
"completed_at": null,
"dependencies": ["M1_STAKEHOLDER", "M2_SYSTEM", "M3_SOFTWARE", "M4_PATTERNS"],
````
Hinweis: Der Auszug endet nach Zeile 100; die Originaldatei umfasst 620 Zeilen und ist an dieser Stelle nicht zu Ende.
#heading(level: 3)[Beispielhafte Ergebnisanforderungen]
Quellen:
- `Versuche/Versuch 02/Ergenisse/system/SyRS_Complete.md`
- `Versuche/Versuch 02/Ergenisse/software/SwRS_Complete.md`
```text
**SyR-001**: The system SHALL implement a multi-layered architecture with clear separation of concerns.
**SyR-002**: The system SHALL implement the ILogic interface pattern with dual implementations.
```
```text
**SW-FUNC-001**: The software SHALL provide comprehensive account management functionality.
**SW-API-001**: The software SHALL provide comprehensive REST API.
```
#heading(level: 3)[Einordnung]
Versuch 02 lieferte die staerkste formale Konsolidierung (StRS/SyRS/SwRS, hohe Traceability), erwies sich fuer die Gesamtentdeckung jedoch als vergleichsweise rigide.
#heading(level: 2)[Versuch 03]
#heading(level: 3)[Allgemeine Beschreibung]
Versuch 03 erweitert das Vorgehen aus Versuch 02 um MCP-Server, um neben formaler Strukturierung vor allem die Discovery-Breite zu vergroessern (Use-Case-Fund, Gap-Analyse).
#heading(level: 3)[Konfiguration]
- Claude Code CLI lokal + VS Code,
- Agenten-Dateien in `Versuche/Versuch 03/Tools/Agents/`,
- MCP-Server gemaess Protokoll: Serena MCP, Windows-MCP (AutoIt-basiert), MSSQL MCP.
#heading(level: 3)[Verwendeter Prompt]
```text
Please analyze this software project and write a reuqirements specification according to modern standards.
Use Agents and MCP servers wherever possible.
Keep superflous texts to a minimum and concentrate on actual requirements.
```
#heading(level: 3)[Tools und Agenten]
Beispiele aus dem Versuchsordner:
- `centron-documentation-writer.md`
- `nhibernate-query-reviewer.md`
- `centron-code-reviewer.md`
- `webservice-developer.md`
#heading(level: 3)[Agentenbeispiel (Auszug, erste 100 Zeilen) - Versuch 03]
Quelle: `Versuche/Versuch 03/Tools/Agents/nhibernate-query-reviewer.md`
````md
---
name: nhibernate-query-reviewer
description: Reviews NHibernate queries and LINQ expressions for c-entron.NET. Detects N+1 queries, cartesian products, and compatibility issues. Use when writing complex queries or experiencing performance problems. Keywords: NHibernate, LINQ, query, performance, N+1, optimization, Fetch.
---
# NHibernate Query Reviewer Agent
> **Type**: Review / Analysis
> **Purpose**: Review database queries to ensure efficiency, proper structure, and compatibility with NHibernate's LINQ provider limitations.
## Agent Role
You are a specialized **NHibernate Query Reviewer** for the c-entron.NET solution, focused on query optimization and performance.
### Primary Responsibilities
1. **N+1 Detection**: Identify and fix lazy loading issues that cause multiple database roundtrips
2. **Performance Analysis**: Review queries for cartesian products, missing indexes, and inefficient patterns
3. **NHibernate Compatibility**: Ensure LINQ expressions translate correctly to SQL
4. **Best Practices**: Enforce soft delete filtering, eager loading strategies, and proper transaction usage
### Core Capabilities
- **N+1 Query Detection**: Identify lazy loading in loops causing performance degradation
- **Cartesian Product Prevention**: Detect multiple Fetch operations on collections
- **LINQ Compatibility**: Validate expressions work with NHibernate's LINQ provider
- **Optimization Recommendations**: Suggest Fetch, FetchMany, Future queries for better performance
- **Soft Delete Validation**: Ensure all queries filter IsDeleted records
## When to Invoke This Agent
This agent should be activated when:
- Complex LINQ queries are written
- Performance issues suspected with database access
- Need query optimization recommendations
- Validating NHibernate compatibility of LINQ expressions
- Reviewing data access code for N+1 problems
- Before committing database access code
**Trigger examples:**
- "Review this query for N+1 problems"
- "Optimize the GetAccountContracts query"
- "Check if this LINQ expression will work with NHibernate"
- "Why is my query slow?"
## Technology Adaptation
**IMPORTANT**: This agent adapts to c-entron.NET's NHibernate configuration.
**Configuration Source**: [CLAUDE.md](../../CLAUDE.md)
Before beginning work, review CLAUDE.md for:
- **ORM**: NHibernate 5.x with FluentNHibernate
- **Database**: SQL Server 2019+
- **Pattern**: Always filter !x.IsDeleted
- **Eager Loading**: Fetch/FetchMany for navigation properties
- **Future Queries**: Batch loading for multiple collections
- **Transactions**: Required for all modifications
## Instructions & Workflow
### Standard Procedure
1. **Load Relevant Lessons Learned** ⚠️ **IMPORTANT**
As a review and analysis agent, start by loading past lessons:
- Use Serena MCP `list_memories` to see available memories
- Use `read_memory` to load relevant past findings:
- `"lesson-query-*"` - Query optimization lessons
- `"pattern-nhibernate-*"` - NHibernate patterns
- `"lesson-performance-*"` - Performance findings
- Apply insights from past lessons throughout review
- This prevents repeating past N+1 mistakes
2. **Context Gathering**
- Review [CLAUDE.md](../../CLAUDE.md) for NHibernate patterns
- Use Serena MCP `find_symbol` to locate query implementations
- Use Serena MCP `find_referencing_symbols` to understand query usage
- Identify query complexity and data access patterns
3. **Query Analysis**
- Check for N+1 query patterns (lazy loading in loops)
- Verify soft delete filtering (!x.IsDeleted)
- Validate LINQ expression compatibility
- Look for cartesian products (multiple Fetch on collections)
- Check transaction usage for modifications
- **Apply insights from loaded lessons**
4. **Optimization**
- Suggest Fetch/FetchMany for eager loading
- Recommend Future queries for multiple collections
- Propose projection for limited data needs
- Identify missing indexes
- **Check recommendations against past patterns**
5. **Verification**
- Estimate performance impact
- Verify proposed optimizations don't introduce new issues
- Use `/optimize` command for additional suggestions
````
Hinweis: Der Auszug endet nach Zeile 100; die Originaldatei umfasst 284 Zeilen und ist an dieser Stelle nicht zu Ende.
#heading(level: 3)[Beispielhafte Ergebnis-Use-Cases]
Quelle: `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.md`
```text
### 2. Click Counter Management (Usage-Based Billing)
**Purpose**: Retrieve current meter readings for click counter devices
**Use Cases**: Copy machines, printers, industrial equipment with usage meters
Method: LoadCounterAsync(List<int> contractsI3D)
```
```text
**Use Case**: Track counter reading trends, detect anomalies
Method: IAutomatedBillingLogic.GetCounterHistory(List<string> lstParam)
```
#heading(level: 3)[MCP-Server: Detaillierte Beschreibung]
#heading(level: 4)[MCP-Grundprinzip]
Model Context Protocol (MCP) definiert eine standardisierte Kopplung zwischen einem Host (hier: Claude Code), einem MCP-Client und einem oder mehreren MCP-Servern. Server stellen dabei typischerweise drei Artefaktarten bereit: `tools` (aufrufbare Funktionen), `resources` (lesbare Kontexte) und `prompts` (wiederverwendbare Prompt-Bausteine). Dieses Modell wurde in Versuch 03 genutzt, um ueber den reinen Repository-Kontext hinaus weitere Wissens- und Interaktionskanaele einzubinden @mcp_intro_2026.
#heading(level: 4)[Serena MCP]
Serena ist ein MCP-Server fuer semantische Code-Retrieval- und Editieroperationen auf Symbol-Ebene (z. B. `find_symbol`, `find_referencing_symbols`, `insert_after_symbol`). Im Unterschied zu rein textbasierter Suche werden Codeobjekte (Klassen, Methoden, Referenzen) strukturell adressiert. In Versuch 03 wurde Serena vor allem fuer gezielte Modulnavigation und die persistenten Memory-Notizen zwischen Analyseiterationen eingesetzt @serena_mcp_2026 @mcp_servers_repo_2026.
#heading(level: 4)[Windows-MCP (AutoIt-basiert)]
Der im Protokoll genannte Windows-MCP-Ansatz (AutoIt-basiert) realisiert Desktop-Automatisierung ueber MCP. Laut Projektbeschreibung kapselt der Server AutoIt-Funktionen als MCP-Tools und bietet zusaetzlich Ressourcen (Dateizugriff, Screenshots) sowie Prompt-Templates fuer typische Automationsaufgaben. Fuer die Fallstudie ist das relevant, weil GUI-basierte Pfade (Dialoge, Formulare, visuelle Workflows) nicht nur aus Quellcode, sondern auch aus Interaktionsablaeufen rekonstruiert werden koennen @windows_mcp_autoit_2026.
#heading(level: 4)[MSSQL MCP]
MSSQL MCP ermoeglicht den kontrollierten Zugriff auf Microsoft SQL Server ueber MCP. Typische Funktionen sind Tabellenauflistung, Schema-Inspektion, Lesen von Inhalten und kontrollierte SQL-Ausfuehrung. Die dokumentierten Security-Hinweise betonen Least-Privilege-Berechtigungen, restriktive Verbindungskonfigurationen und Logging. In Versuch 03 wurde dieser Zugriff fuer die funktionale Absicherung von Datenmodellen und Use-Case-Hypothesen genutzt @mssql_mcp_2026.
#heading(level: 3)[Einordnung]
Durch die MCP-Erweiterung konnte Versuch 03 die funktionale Breite deutlich steigern und einen grossen Dokumentations-Gap sichtbar machen. Gegenueber Versuch 02 sinkt dabei der formale ISO-Fokus, was fuer Discovery jedoch methodisch beabsichtigt war.
#heading(level: 2)[Quellenhinweis]
Die fuer dieses Kapitel genutzten Webquellen zu Claude Code und MCP-Servern sind im Literaturverzeichnis als Online-Quellen erfasst; die inhaltliche Referenzierung erfolgt direkt im Text der Abschnitte zu Versuch 03.

10
Kapitel/05_prototypische_umsetzung.typ Normal file
View File

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

171
Kapitel/05_prototypische_umsetzung_VarianteA.typ
View File

@@ -6,172 +6,5 @@
#heading(level: 1)[Ergebnisse (ca. 10 Seiten)] #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).

10
Kapitel/06_evaluation.typ Normal file
View File

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

118
Kapitel/06_evaluation_VarianteA.typ
View File

@@ -6,119 +6,5 @@
#heading(level: 1)[Evaluation (ca. 12 Seiten)] #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.

3
Masterarbeit_draft.typ
View File

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