Compare commits
3
Commits
dbd4125791
...
714dab3986
| Author | SHA1 | Date | |
|---|---|---|---|
 Gowler
|
714dab3986 | ||
|
Gowler
|
376972453b | ||
|
Gowler
|
8f204bc330 |
@@ -1,2 +0,0 @@
|
|||||||
#heading(level: 1, numbering: "0")[Abstract]
|
|
||||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ergänze hier die Zusammenfassung der Arbeit.
|
|
||||||
@@ -1,2 +1,2 @@
|
|||||||
#heading(level: 1, numbering: none)[Abstract (ca. 1 Seite)]
|
#heading(level: 1, numbering: none)[Abstract]
|
||||||
Zusammenfassung der Arbeit.
|
Zusammenfassung der Arbeit.
|
||||||
|
|||||||
@@ -1,4 +1,4 @@
|
|||||||
#heading(level: 1)[Einleitung (ca. 8 Seiten)]
|
#heading(level: 1)[Einleitung]
|
||||||
|
|
||||||
#heading(level: 2)[Ausgangssituation und Motivation]
|
#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 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.
|
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.
|
||||||
|
|||||||
@@ -4,7 +4,7 @@
|
|||||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
#hide(bibliography("../literatur.bib", style: "apa"))
|
||||||
]
|
]
|
||||||
|
|
||||||
#heading(level: 1)[Theoretische Grundlagen (ca. 12 Seiten)]
|
#heading(level: 1)[Theoretische Grundlagen]
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
|
|||||||
@@ -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).
|
/ 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.
|
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]
|
#heading(level: 3)[Typische Methodenkette für Requirements-Rückgewinnung aus Code]
|
||||||
|
|
||||||
|
|||||||
@@ -4,7 +4,7 @@
|
|||||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
#hide(bibliography("../literatur.bib", style: "apa"))
|
||||||
]
|
]
|
||||||
|
|
||||||
#heading(level: 1)[Fallstudie c-entron GmbH (ca. 6 Seiten)]
|
#heading(level: 1)[Fallstudie c-entron GmbH]
|
||||||
|
|
||||||
Dieses Kapitel beschreibt die Anwendung auf die sich diese Arbeit bezieht. Betrachtet wird die Windows-basierte ERP-Software der c-entron GmbH, die auf eine webbasierte Plattform überführt werden soll. Ziel ist es, die fachlichen und technischen Rahmenbedingungen so darzustellen, dass die Anforderungen an ein KI-gestütztes Reverse Requirements Engineering nachvollziehbar werden. Zunächst werden Unternehmenskontext und Legacy-Software eingeordnet, anschließend folgen Migrationsstrategie und spezifische Herausforderungen.
|
Dieses Kapitel beschreibt die Anwendung auf die sich diese Arbeit bezieht. Betrachtet wird die Windows-basierte ERP-Software der c-entron GmbH, die auf eine webbasierte Plattform überführt werden soll. Ziel ist es, die fachlichen und technischen Rahmenbedingungen so darzustellen, dass die Anforderungen an ein KI-gestütztes Reverse Requirements Engineering nachvollziehbar werden. Zunächst werden Unternehmenskontext und Legacy-Software eingeordnet, anschließend folgen Migrationsstrategie und spezifische Herausforderungen.
|
||||||
|
|
||||||
|
|||||||
@@ -1,400 +1,16 @@
|
|||||||
#import "@preview/cetz:0.4.2"
|
|
||||||
|
|
||||||
#set text(lang: "de")
|
|
||||||
|
|
||||||
#let __is_thesis = context { query(<__thesis_document>).len() > 0 }
|
#let __is_thesis = context { query(<__thesis_document>).len() > 0 }
|
||||||
#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"))
|
||||||
]
|
]
|
||||||
|
|
||||||
#heading(level: 1)[Konzeption und methodisches Vorgehen (ca. 12 Seiten)]
|
#heading(level: 1)[Konzeption und methodisches Vorgehen]
|
||||||
|
|
||||||
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.
|
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]
|
#include "04_konzeption_methodisches_vorgehen/04_01_methodisches_design.typ"
|
||||||
|
|
||||||
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.
|
#include "04_konzeption_methodisches_vorgehen/04_02_versuchsdesign.typ"
|
||||||
|
|
||||||
/ 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.
|
#include "04_konzeption_methodisches_vorgehen/04_03_evaluation_und_absicherung.typ"
|
||||||
|
|
||||||
/ 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>
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
#heading(level: 2)[Stakeholder-Validierung als 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 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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Jede Anforderung wird entlang von sechs 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?
|
|
||||||
/ Ü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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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: 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 in @sec_re_qualitaet hergeleiteten Qualitätsdimensionen.
|
|
||||||
|
|
||||||
/ 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 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.
|
|
||||||
|
|
||||||
/ 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 der Aufwand erhoben. Dazu werden während der KI-Läufe Indikatoren wie Tokenkosten un Bearbeitungsdauer protokolliert. Parallel wird grob abgeschätzt, wie viele Stunden ein erfahrener Analyst für dieselben Module ohne KI-Unterstützung gebraucht hätte. Beide Größen zusammen erlauben einen Vergleich der Größenordnung, nicht jedoch einen exakten Effizienzfaktor.
|
|
||||||
|
|
||||||
#heading(level: 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 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.
|
|
||||||
|
|
||||||
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. 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)[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-Interaktion],
|
|
||||||
[Validierungsstichprobe], [Stratifiziert], [Stratifiziert], [Stratifiziert],
|
|
||||||
),
|
|
||||||
caption: [Detail-Konfiguration der drei Kernversuche.],
|
|
||||||
) <tab_versuchskonfiguration>
|
|
||||||
|
|
||||||
Die Versuchsordner-Struktur folgt einer einheitlichen Konvention. Pro Versuch existiert ein Unterordner mit den Konfigurationsartefakten, ein Eingangsprotokoll mit Modell- und Werkzeugangaben, ein Ergebnis-Unterordner sowie eine Verlaufsdokumentation für die Validierungsschritte. Damit ist jeder Versuch eigenständig reproduzierbar.
|
|
||||||
/*
|
|
||||||
#heading(level: 2)[Überleitung]
|
|
||||||
|
|
||||||
Mit der vorangegangenen Methodikbeschreibung ist das Untersuchungsdesign vollständig dokumentiert. Das folgende Kapitel beschreibt die Durchführung der geplanten Versuche und stellt die erzeugten Ergebnisartefakte vor. Daran schließt sich die Anwendung des hier definierten Evaluationsrahmens auf die Ergebnisse an. Den Abschluss bildet die Diskussion der gewonnenen Erkenntnisse im Hinblick auf die vier Forschungsleitfragen.
|
|
||||||
*/
|
|
||||||
|
|||||||
@@ -0,0 +1,142 @@
|
|||||||
|
#import "@preview/cetz:0.4.2"
|
||||||
|
|
||||||
|
#set text(lang: "de")
|
||||||
|
|
||||||
|
#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.
|
||||||
@@ -0,0 +1,175 @@
|
|||||||
|
#import "@preview/cetz:0.4.2"
|
||||||
|
|
||||||
|
#set text(lang: "de")
|
||||||
|
|
||||||
|
#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>
|
||||||
|
|
||||||
|
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.
|
||||||
@@ -0,0 +1,72 @@
|
|||||||
|
#set text(lang: "de")
|
||||||
|
|
||||||
|
#heading(level: 2)[Stakeholder-Validierung als 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 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Jede Anforderung wird entlang von sechs 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?
|
||||||
|
/ Ü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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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: 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 in @sec_re_qualitaet hergeleiteten Qualitätsdimensionen.
|
||||||
|
|
||||||
|
/ 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 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.
|
||||||
|
|
||||||
|
/ 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 der Aufwand erhoben. Dazu werden während der KI-Läufe Indikatoren wie Tokenkosten un Bearbeitungsdauer protokolliert. Parallel wird grob abgeschätzt, wie viele Stunden ein erfahrener Analyst für dieselben Module ohne KI-Unterstützung gebraucht hätte. Beide Größen zusammen erlauben einen Vergleich der Größenordnung, nicht jedoch einen exakten Effizienzfaktor.
|
||||||
|
|
||||||
|
#heading(level: 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 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.
|
||||||
|
|
||||||
|
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. 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)[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)],
|
||||||
|
[Startprompt], [Zu Versuchsbeginn neu formuliert], [Finaler Prompt aus V1, angepasst an Agentendateien], [Finaler Prompt aus V2, angepasst an MCP-Server],
|
||||||
|
[Agentendateien], [keine], [Stakeholder, System, Software, ISO-29148-Orchestrator], [wie V2],
|
||||||
|
[MCP-Server], [keine], [keine], [Symbol-Navigation, Datenbank-Inspektion, optional GUI-Beobachtung],
|
||||||
|
[Validierungsstichprobe], [Zufallsstichprobe], [Zufallsstichprobe], [Zufallsstichprobe],
|
||||||
|
),
|
||||||
|
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.
|
||||||
@@ -4,7 +4,7 @@
|
|||||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
#hide(bibliography("../literatur.bib", style: "apa"))
|
||||||
]
|
]
|
||||||
|
|
||||||
#heading(level: 1)[Ergebnisse (ca. 10 Seiten)]
|
#heading(level: 1)[Durchführung und Ergebnisse]
|
||||||
|
|
||||||
// TODO Variante B – Inhalte aus 05_prototypische_umsetzung_VarianteA.typ übernehmen
|
// TODO Variante B – Inhalte aus 05_prototypische_umsetzung_VarianteA.typ übernehmen
|
||||||
// und explizit als „Ergebnisse der Versuche" strukturieren (keine Versuchs-Logbuch-Optik).
|
// und explizit als „Ergebnisse der Versuche" strukturieren (keine Versuchs-Logbuch-Optik).
|
||||||
|
|||||||
@@ -4,7 +4,7 @@
|
|||||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
#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
|
// TODO Variante B – Anwendung des in Kap 4.6 definierten Evaluationsrahmens auf die
|
||||||
// Ergebnisse aus Kap 5. Keine Erst-Definition von Kriterien hier.
|
// Ergebnisse aus Kap 5. Keine Erst-Definition von Kriterien hier.
|
||||||
|
|||||||
@@ -4,46 +4,14 @@
|
|||||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
#hide(bibliography("../literatur.bib", style: "apa"))
|
||||||
]
|
]
|
||||||
|
|
||||||
#heading(level: 1)[Diskussion (ca. 8 Seiten)]
|
#heading(level: 1)[Diskussion ]
|
||||||
|
|
||||||
#heading(level: 2)[Interpretation der Ergebnisse]
|
#heading(level: 2)[Interpretation der Ergebnisse]
|
||||||
|
|
||||||
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.
|
|
||||||
- V03 zeigt, dass die MCP-Erweiterung die funktionale Breite massiv erhoeht und Discovery-Luecken schliesst.
|
|
||||||
|
|
||||||
In Summe entsteht ein zweistufiges Zielbild fuer Reverse Requirements Engineering in Legacy-Projekten: zuerst *formal konsolidieren*, danach *gezielt in die Breite erweitern*.
|
|
||||||
|
|
||||||
#heading(level: 2)[Chancen und Grenzen]
|
#heading(level: 2)[Chancen und Grenzen]
|
||||||
|
|
||||||
Die wesentlichen Chancen des Ansatzes liegen in:
|
|
||||||
|
|
||||||
- hoher Skalierbarkeit bei grossen Legacy-Artefakten,
|
|
||||||
- schneller Sichtbarmachung undokumentierter Funktionalitaet,
|
|
||||||
- strukturierter Ueberfuehrung in reviewbare Requirements-Artefakte.
|
|
||||||
|
|
||||||
Die zentralen Grenzen bleiben:
|
|
||||||
|
|
||||||
- keine belastbare Vollstaendigkeit ohne Zusatzquellen (insbesondere Nutzungs- und Prozesssicht),
|
|
||||||
- Halluzinations- und Fehlinterpretationsrisiken ohne Beleg- und Reviewpflicht,
|
|
||||||
- hoher Konsolidierungsaufwand zwischen Discovery-Artefakten und abnahmefaehiger Spezifikation.
|
|
||||||
|
|
||||||
Damit bestaetigt die Fallstudie, dass LLMs Requirements Engineering nicht ersetzen, aber als beschleunigendes Analyseinstrument mit klaren Governance-Regeln substantiellen Mehrwert liefern.
|
|
||||||
|
|
||||||
#heading(level: 2)[Implikationen fuer Forschung und Praxis]
|
#heading(level: 2)[Implikationen fuer Forschung und Praxis]
|
||||||
|
|
||||||
Fuer die Praxis folgt daraus ein umsetzbarer Einfuehrungspfad:
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Fuer die Forschung ergeben sich drei Anschlussfragen:
|
|
||||||
|
|
||||||
1. Wie laesst sich die Triangulation aus Code-, Video- und Stakeholderdaten automatisiert zusammenfuehren?
|
|
||||||
2. Welche Metriken messen Qualitaet von Requirements-Artefakten robuster als reine Umfangszahlen?
|
|
||||||
3. Wie kann Human-in-the-loop-Validierung mit vertretbarem Aufwand skaliert werden?
|
|
||||||
|
|
||||||
Die vorliegende Arbeit liefert dafuer eine belastbare methodische Ausgangsbasis, zeigt aber zugleich, dass die letzte Meile zur fachlich finalen Spezifikation weiterhin ein kooperativer Mensch-KI-Prozess bleibt.
|
|
||||||
|
|||||||
@@ -1,35 +1,2 @@
|
|||||||
#heading(level: 1)[Fazit und Ausblick (ca. 4 Seiten)]
|
#heading(level: 1)[Fazit und Ausblick]
|
||||||
|
|
||||||
#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 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.
|
|
||||||
- V03 erweitert die Discovery-Breite per MCP und deckt einen hohen dokumentationsbezogenen Gap auf.
|
|
||||||
|
|
||||||
Damit ist F1 (prozessuale Einsetzbarkeit von LLMs) positiv beantwortet. F4 (Chancen und Grenzen) ist ebenfalls klar beantwortbar: Hohe Effizienz- und Strukturgewinne stehen einem weiterhin relevanten Validierungs- und Konsolidierungsbedarf gegenueber. F2 und F3 sind teilweise beantwortet, da video- und interviewbasierte Endvalidierung noch nicht vollstaendig abgeschlossen ist.
|
|
||||||
|
|
||||||
#heading(level: 2)[Handlungsempfehlungen fuer c-entron GmbH]
|
|
||||||
|
|
||||||
Aus den Ergebnissen lassen sich folgende priorisierte Handlungsschritte ableiten:
|
|
||||||
|
|
||||||
1. **V02 als Spezifikationsbasis verwenden:** Die 220 konsolidierten Requirements mit hoher Traceability als Arbeitsgrundlage fuer die Web-Migration etablieren.
|
|
||||||
2. **V03 als Discovery-Backlog nutzen:** Die 1720 identifizierten Faehigkeiten systematisch gegen V02 mappen, um potenzielle Luecken sichtbar zu halten.
|
|
||||||
3. **Review-Governance fest verankern:** Fachliche Freigaben und Aenderungsentscheidungen pro Requirement dokumentieren (kein unreviewter LLM-Output im Zielbacklog).
|
|
||||||
4. **Toolchain standardisieren:** Prompt-/Agentenkonfigurationen versionieren, damit Folgeanalysen reproduzierbar bleiben.
|
|
||||||
|
|
||||||
#heading(level: 2)[Ausblick und naechste Schritte]
|
|
||||||
|
|
||||||
Die naechste Arbeitsphase erweitert die bisher codezentrierte Evidenz um die noch offenen Schritte aus dem Protokoll:
|
|
||||||
|
|
||||||
1. **Vollstaendige Videoanalyse:** Alle vorhandenen Schulungsvideos KI-gestuetzt transkribieren und strukturiert auf Use Cases auswerten.
|
|
||||||
2. **Abgleich Video vs. Codeanalyse:** Systematischer Vergleich, ob und wo sich beide Sichten decken bzw. welche Use Cases nur in einer Quelle auftauchen.
|
|
||||||
3. **Clusterung in abstrakte Konzepte:** Die identifizierten Use Cases in die bereits vorbereiteten 101 abstrahierten Konzepte ueberfuehren (vgl. `A_Videoanalyse_Uebersicht.csv`).
|
|
||||||
4. **Manuelle Fachklassifikation pro Cluster:** Bewertung in die Kategorien
|
|
||||||
- **ja:** unveraenderte Uebernahme,
|
|
||||||
- **nein:** Entfall in ERP Web,
|
|
||||||
- **neu:** fachlich vorhanden, aber neu zu konzipieren,
|
|
||||||
- **TBD:** vorlaeufig offen.
|
|
||||||
|
|
||||||
Erst mit dieser finalen Triangulation aus Code, Video und Fachbewertung ist eine belastbare Vollstaendigkeitsaussage fuer die Migrationsplanung moeglich.
|
|
||||||
|
|||||||
@@ -1,3 +1,3 @@
|
|||||||
#heading(level: 1)[Literaturverzeichnis (ca. 3 Seiten)]
|
#heading(level: 1)[Literaturverzeichnis]
|
||||||
|
|
||||||
#bibliography("../literatur.bib", style: "apa")
|
#bibliography("../literatur.bib", style: "apa")
|
||||||
|
|||||||
@@ -1,11 +1,9 @@
|
|||||||
#heading(level: 1)[Anhang (ca. 6 Seiten)]
|
#heading(level: 1)[Anhang]
|
||||||
|
|
||||||
#heading(level: 2)[Interviewleitfäden]
|
#heading(level: 2)[Interviewleitfäden]
|
||||||
|
|
||||||
#heading(level: 3)[Stakeholder-Validierung der KI-extrahierten Anforderungen] <anh_interview_validierung>
|
#heading(level: 3)[Stakeholder-Validierung der KI-extrahierten Anforderungen] <anh_interview_validierung>
|
||||||
|
|
||||||
_Ausarbeitung folgt._
|
|
||||||
|
|
||||||
#heading(level: 2)[Zusätzliches Datenmaterial]
|
#heading(level: 2)[Zusätzliches Datenmaterial]
|
||||||
|
|
||||||
#heading(level: 2)[Konfigurationsdetails des Prototyps]
|
#heading(level: 2)[Konfigurationsdetails]
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
-26780
File diff suppressed because it is too large
Load Diff
@@ -7,7 +7,7 @@
|
|||||||
"Masterarbeit an der Hochschule Neu-Ulm",
|
"Masterarbeit an der Hochschule Neu-Ulm",
|
||||||
"Christoph Schwörer",
|
"Christoph Schwörer",
|
||||||
"Master of Business Administration",
|
"Master of Business Administration",
|
||||||
"Prof. Dr. Daniel Schallmö",
|
"Prof. Dr. Daniel Schallmo",
|
||||||
"XX 2026"
|
"XX 2026"
|
||||||
)
|
)
|
||||||
|
|
||||||
@@ -15,6 +15,10 @@
|
|||||||
|
|
||||||
#pagebreak()
|
#pagebreak()
|
||||||
|
|
||||||
|
#(thesis.confidentiality)(meta)
|
||||||
|
|
||||||
|
#pagebreak()
|
||||||
|
|
||||||
#(thesis.declaration)(meta)
|
#(thesis.declaration)(meta)
|
||||||
|
|
||||||
#pagebreak()
|
#pagebreak()
|
||||||
@@ -38,15 +42,15 @@
|
|||||||
#outline(depth: 2, title: "Inhaltsverzeichnis")
|
#outline(depth: 2, title: "Inhaltsverzeichnis")
|
||||||
|
|
||||||
#pagebreak()
|
#pagebreak()
|
||||||
|
|
||||||
#include "Kapitel/00_abstract.typ"
|
|
||||||
#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()
|
#pagebreak()
|
||||||
#include "Kapitel/04_konzeption_methodisches_vorgehen.typ"
|
#include "Kapitel/04_konzeption_methodisches_vorgehen.typ"
|
||||||
#pagebreak()
|
#pagebreak()
|
||||||
#include "Kapitel/05_prototypische_umsetzung.typ"
|
|
||||||
|
#include "Kapitel/05_durchfuehrung_und_ergebnisse.typ"
|
||||||
#pagebreak()
|
#pagebreak()
|
||||||
#include "Kapitel/06_evaluation.typ"
|
#include "Kapitel/06_evaluation.typ"
|
||||||
#include "Kapitel/07_diskussion.typ"
|
#include "Kapitel/07_diskussion.typ"
|
||||||
|
|||||||
Binary file not shown.
Binary file not shown.
File diff suppressed because one or more lines are too long
+1
-136
File diff suppressed because one or more lines are too long
@@ -52,6 +52,24 @@
|
|||||||
]
|
]
|
||||||
]
|
]
|
||||||
|
|
||||||
|
#let confidentiality(meta) = [
|
||||||
|
#set page(numbering: none)
|
||||||
|
#set text(font: "Times New Roman", size: 11pt)
|
||||||
|
#set par(leading: 14pt)
|
||||||
|
#heading(level: 1)[Vertraulichkeitserklärung]
|
||||||
|
|
||||||
|
Die vorliegende Masterarbeit enthält vertrauliche Informationen der c-entron GmbH, insbesondere zu Aufbau, Funktionsweise und Datenstrukturen der unternehmensinternen ERP-Software. Die Veröffentlichung, Vervielfältigung sowie die Weitergabe des Inhalts an Dritte ist auch in Auszügen ohne ausdrückliche schriftliche Zustimmung der c-entron GmbH und des Verfassers nicht gestattet.
|
||||||
|
|
||||||
|
Einsicht in diese Arbeit wird ausschließlich den Mitgliedern der Prüfungskommission der Hochschule Neu-Ulm sowie den durch den Verfasser ausdrücklich benannten Personen gewährt. Die Sperrfrist beträgt fünf Jahre ab dem Abgabedatum.
|
||||||
|
|
||||||
|
#v(2cm)
|
||||||
|
#align(left)[
|
||||||
|
#text(size: 11pt)[Neu-Ulm, #raw("______________________________")]
|
||||||
|
#v(3mm)
|
||||||
|
#text(size: 11pt)[Unterschrift: #raw("______________________________")]
|
||||||
|
]
|
||||||
|
]
|
||||||
|
|
||||||
#let abstract(content) = [
|
#let abstract(content) = [
|
||||||
#set page(numbering: "1")
|
#set page(numbering: "1")
|
||||||
#set text(font: "Times New Roman", size: 11pt)
|
#set text(font: "Times New Roman", size: 11pt)
|
||||||
@@ -84,6 +102,13 @@
|
|||||||
#set text(size: 12pt, weight: "semibold")
|
#set text(size: 12pt, weight: "semibold")
|
||||||
#it
|
#it
|
||||||
]
|
]
|
||||||
|
#show figure.caption: it => block(
|
||||||
|
width: 92%,
|
||||||
|
align(left)[
|
||||||
|
#set par(justify: true)
|
||||||
|
#it
|
||||||
|
],
|
||||||
|
)
|
||||||
#set terms(separator: [], hanging-indent: 0pt, tight: false)
|
#set terms(separator: [], hanging-indent: 0pt, tight: false)
|
||||||
#show terms.item: it => block(below: 0.8em, [
|
#show terms.item: it => block(below: 0.8em, [
|
||||||
#strong(it.term) \
|
#strong(it.term) \
|
||||||
@@ -109,6 +134,7 @@
|
|||||||
meta: thesis_meta,
|
meta: thesis_meta,
|
||||||
cover: cover,
|
cover: cover,
|
||||||
declaration: declaration,
|
declaration: declaration,
|
||||||
|
confidentiality: confidentiality,
|
||||||
abstract: abstract,
|
abstract: abstract,
|
||||||
body_show: body_show,
|
body_show: body_show,
|
||||||
body_content: body_content,
|
body_content: body_content,
|
||||||
|
|||||||
Reference in New Issue
Block a user