Überarbeitung layout und Kap 4
This commit is contained in:
@@ -1,3 +1,13 @@
|
||||
#set terms(separator: [], hanging-indent: 0pt, tight: false)
|
||||
#show terms.item: it => block(below: 0.8em, [
|
||||
#strong(it.term) \
|
||||
#it.description
|
||||
])
|
||||
#show terms: it => {
|
||||
it
|
||||
v(2cm)
|
||||
}
|
||||
|
||||
#heading(level: 1)[Einleitung (ca. 8 Seiten)]
|
||||
|
||||
#heading(level: 2)[Ausgangssituation und Motivation]
|
||||
@@ -12,11 +22,11 @@ In den letzen Jahren hat sich hierzu nun ein neues Instrumentarium etabliert. La
|
||||
#heading(level: 2)[Problemstellung]
|
||||
Für das ERP Software Produkt der c-entron fehlen strukturierte und dokumentierte Requirements. Die Analyse der bestehenden Codebasis ist zeitintensiv, ressourcenintensiv und anfällig für Insel- und Metawissen. Daraus ergeben sich mehrere Risiken:
|
||||
|
||||
- *Re-Implementationsfehler:* Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration. Zeitgleich sind Workaround of Symptom einer mangelhaften Erfassung der Anfoderungen bei originalen Implementierung und ein zeichen fehlender Weitsicht.
|
||||
- *Technische Schuld:* Entwickler investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen. Neue Mitarbeiter sind auch nicht bewandt in alten technolgien und es fehlt das Verständnis für historische Zwänge und Zusammenhänge.
|
||||
- *Implizites Wissen:* Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen. Gleichzeitig führt die langjährige arbeit mit dem bestehenden System zu eingeschränkter Offenheit beim design neuer Lösungen ("Das haben wir schon immer so umgestzt").
|
||||
- *Komplexität der Codebasis:* Verschachtelte Abhängigkeiten, unterschiedliche Stile und technologiebedingte Zwänge erschweren eine modulare Anforderungsableitung.
|
||||
- *Fehlende Traceability:* Ohne Zuordnung zwischen Code und Geschäftsprozess fehlt die Grundlage für Priorisierung, Testkonzeption und spätere Wartung. Große Teile des Codes sind auch generisch und lassen sich nicht einer konkreten Anforderung zuordnen, wie zum Beispiel das anzeigen eine Tabelle. Konkrete Datenflüsse lassen sich hier nur am laufenden System beobachten was die Analyse nochmal um eine Größenordnung Resourcenintensiver macht.
|
||||
/ Re-Implementationsfehler: Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration. Zeitgleich sind Workaround of Symptom einer mangelhaften Erfassung der Anfoderungen bei originalen Implementierung und ein zeichen fehlender Weitsicht.
|
||||
/ Technische Schuld: Entwickler investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen. Neue Mitarbeiter sind auch nicht bewandt in alten technolgien und es fehlt das Verständnis für historische Zwänge und Zusammenhänge.
|
||||
/ Implizites Wissen: Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen. Gleichzeitig führt die langjährige arbeit mit dem bestehenden System zu eingeschränkter Offenheit beim design neuer Lösungen ("Das haben wir schon immer so umgestzt").
|
||||
/ Komplexität der Codebasis: Verschachtelte Abhängigkeiten, unterschiedliche Stile und technologiebedingte Zwänge erschweren eine modulare Anforderungsableitung.
|
||||
/ Fehlende Traceability: Ohne Zuordnung zwischen Code und Geschäftsprozess fehlt die Grundlage für Priorisierung, Testkonzeption und spätere Wartung. Große Teile des Codes sind auch generisch und lassen sich nicht einer konkreten Anforderung zuordnen, wie zum Beispiel das anzeigen eine Tabelle. Konkrete Datenflüsse lassen sich hier nur am laufenden System beobachten was die Analyse nochmal um eine Größenordnung Resourcenintensiver macht.
|
||||
|
||||
Eine rein manuelle Rekonstruktion aller Anforderungen wäre wirtschaftlich kaum tragbar. Deshalb soll geprüft werden, ob KI-gestützte Verfahren Requirements so extrahieren können, dass sie als belastbare Basis für die Modernisierung dienen.
|
||||
|
||||
@@ -30,7 +40,7 @@ Diese Arbeit verfolgt das Ziel, ein vollständiges Vorgehen für KI-gestütztes
|
||||
|
||||
|
||||
#heading(level: 2)[Forschungsleitfragen]
|
||||
Die Zielsetzung wird über vier Forschungsleitfragen strukturiert:
|
||||
Diese Zielsetzung wird über vier Forschungsleitfragen strukturiert:
|
||||
|
||||
1. *Einsatz von LLMs im Reverse Requirements Engineering:* Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?
|
||||
2. *Kombination von KI-Analyse und Stakeholder-Input:* Welche funktionalen und nicht-funktionalen Anforderungen lassen sich aus Code extrahieren, und welche Informationen müssen über Interviews ergänzt werden?
|
||||
|
||||
@@ -4,6 +4,16 @@
|
||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
||||
]
|
||||
|
||||
#set terms(separator: [], hanging-indent: 0pt, tight: false)
|
||||
#show terms.item: it => block(below: 0.8em, [
|
||||
#strong(it.term) \
|
||||
#it.description
|
||||
])
|
||||
#show terms: it => {
|
||||
it
|
||||
v(2cm)
|
||||
}
|
||||
|
||||
#heading(level: 1)[Theoretische Grundlagen (ca. 12 Seiten)]
|
||||
|
||||
Dieses Kapitel beschreibt die theoretischen Grundlagen, die für die Konzeption und Bewertung eines KI-gestützten Reverse Requirements Engineering in Legacy-Umgebungen benötigt werden. Zunächst werden zentrale Themen des Requirements Engineerings sowie die Idee des reverse Requirements Engineerings auf Basis bestehender Systeme eingeordnet. Anschließend werden Large Language Models und deren Einsatz im Software Engineering 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.
|
||||
|
||||
@@ -6,9 +6,9 @@ Der Begriff Requirements Engineering (RE) umfasst die systematische Erhebung, An
|
||||
|
||||
Im Kern adressiert das Requirements Engineering zwei Themen:
|
||||
|
||||
- ***Kommunikation zwischen Domäne und Technik:*** Anforderungen müssen fachlich verständlich und gleichzeitig so präzise sein, dass sich daraus eine Software-Architektur ableiten lässt, die implementiert, getestet und geändert werden kann.
|
||||
- ***Umgang mit Unsicherheit und Wandel:*** Anforderungen sind zu Projektbeginn selten vollständig. Requirements Engineering ist daher nicht nur Dokumentation, sondern auch ein iterativer Klärungs- und Abstimmungsprozess.
|
||||
|
||||
/ Kommunikation zwischen Domäne und Technik: Anforderungen müssen fachlich verständlich und gleichzeitig so präzise sein, dass sich daraus eine Software-Architektur ableiten lässt, die implementiert, getestet und geändert werden kann.
|
||||
/ Umgang mit Unsicherheit und Wandel: Anforderungen sind zu Projektbeginn selten vollständig. Requirements Engineering ist daher nicht nur Dokumentation, sondern auch ein iterativer Klärungs- und Abstimmungsprozess.
|
||||
\
|
||||
Ein etablierter Ansatz zur Strukturierung von diversen Sichtweisen ist das Viewpoint-Konzept @kotonya1996viewpoints, bei dem Anforderungen aus unterschiedlichen Perspektiven modelliert und anschließend konsolidiert werden.
|
||||
|
||||
_Für diese Arbeit ist die Perspektivenorientierung relevant, weil implementierter Code typischerweise keine expliziten Stakeholder-Sichten enthält. Für eine Migration auf Basis eines Reverse-Engineering-Ansatzes sind diese aber relevant für die Implementierung und architekturelle Entscheidungen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben)._
|
||||
@@ -21,9 +21,9 @@ Für die Qualität einzelner Requirements gibt es etablierte Standards. @iso2914
|
||||
|
||||
Für die Bewertung von KI-extrahierten Requirements sind drei Kriterien maßgeblich relevant:
|
||||
|
||||
- *Verifizierbarkeit:* Ein Requirement ist so formuliert, dass ein Test oder eine Prüfmethode ableitbar ist (z. B. Messkriterium, Akzeptanzbedingung).
|
||||
- *Eindeutigkeit:* Formulierungen vermeiden Mehrdeutigkeiten und definieren Begriffe, die in der Domäne unterschiedlich interpretiert werden können \ (z.B. „Das System soll Aufträge schnell verarbeiten" vs. „Das System soll einen Auftrag innerhalb von 2 Sekunden validieren und bestätigen")
|
||||
- *Nachvollziehbarkeit (Traceability):* Es ist erkennbar, aus welchem Requirement das Artefakt (Code, Konfiguration, Datenbank, Ticket, Interview) abgeleitet wurde.
|
||||
/ Verifizierbarkeit: Ein Requirement ist so formuliert, dass ein Test oder eine Prüfmethode ableitbar ist (z. B. Messkriterium, Akzeptanzbedingung).
|
||||
/ Eindeutigkeit: Formulierungen vermeiden Mehrdeutigkeiten und definieren Begriffe, die in der Domäne unterschiedlich interpretiert werden können \ (z.B. „Das System soll Aufträge schnell verarbeiten" vs. „Das System soll einen Auftrag innerhalb von 2 Sekunden validieren und bestätigen")
|
||||
/ Nachvollziehbarkeit (Traceability): Es ist erkennbar, aus welchem Requirement das Artefakt (Code, Konfiguration, Datenbank, Ticket, Interview) abgeleitet wurde.
|
||||
|
||||
Nicht funktionale Anforderungen (z.B. Qualitätsanforderungen) bedürfen einer besonderen Betrachtung, weil sie über die reine Funktionsgleichheit hinaus die Zielarchitektur bestimmen. #cite(<glinz2008quality>, form: "prose") argumentiert, dass Qualitätsanforderungen risikobasiert und wertorientiert priorisiert werden sollten. Für Legacy-Migrationen ist dies nachvollziehbar: Ein „vollständiges" Requirements-Set ist praktisch schwer erreichbar, gleichzeitig sind bestimmte Non-Functional Requirements (z. B. Datenschutz, Verfügbarkeit, Rollout-Fähigkeit) hochkritisch, weil sie Architekturentscheidungen dominieren.
|
||||
|
||||
@@ -59,8 +59,8 @@ Reverse Engineering wird klassisch als Analyseprozess verstanden, der aus einem
|
||||
|
||||
Reverse Requirements Engineering (RRE) fokussiert sich dagegen auf die rückwärtsgerichtete Gewinnung von Requirements aus bestehenden Artefakten. Dabei kann das Ziel unterschiedlich interpretiert werden:
|
||||
|
||||
- *Rekonstruktion eines Soll-Zustands:* Welche fachlichen Anforderungen werden durch die aktuelle Implementierung implizit erfüllt? Was war das ursprüngliche Ziel der Implementierung?
|
||||
- *Rekonstruktion eines Ist-Zustands:* Welche Funktionen und Regeln sind dagegen tatsächlich implementiert?
|
||||
/ Rekonstruktion eines Soll-Zustands: Welche fachlichen Anforderungen werden durch die aktuelle Implementierung implizit erfüllt? Was war das ursprüngliche Ziel der Implementierung?
|
||||
/ Rekonstruktion eines Ist-Zustands: Welche Funktionen und Regeln sind dagegen tatsächlich implementiert?
|
||||
|
||||
Gerade im Legacy-Umfeld ist diese Unterscheidung entscheidend. Die Codebasis enthält oft historisch entstandene Workarounds oder kundenspezifische Anpassungen. Ohne zusätzliche Validierung besteht das Risiko, dass RRE den Ist-Zustand als Soll-Zustand fehlinterpretiert.
|
||||
|
||||
@@ -68,8 +68,8 @@ Frühe Ansätze zur Brücke zwischen Reverse Engineering und Requirements liefer
|
||||
|
||||
Methodisch lassen sich dabei grob zwei Analysestränge unterscheiden:
|
||||
|
||||
- *Statische Analyse:* Ableitung von Struktur- und Datenflussinformationen aus Code und Artefakten ohne Ausführung (z. B. Abhängigkeiten, SQL-Statements, Aufrufketten). Statische Analyse skaliert gut, erkennt aber nicht zuverlässig Laufzeitbedingungen (z. B. Feature Flags, Konfigurationsvarianten).
|
||||
- *Dynamische Analyse:* Beobachtung von Laufzeitverhalten durch Logging, Tracing oder instrumentierte Tests (z. B. welche Regeln bei bestimmten Eingaben greifen). Dynamische Analyse ist näher am realen Verhalten, benötigt aber reproduzierbare Szenarien und Testdaten.
|
||||
/ Statische Analyse: Ableitung von Struktur- und Datenflussinformationen aus Code und Artefakten ohne Ausführung (z. B. Abhängigkeiten, SQL-Statements, Aufrufketten). Statische Analyse skaliert gut, erkennt aber nicht zuverlässig Laufzeitbedingungen (z. B. Feature Flags, Konfigurationsvarianten).
|
||||
/ Dynamische Analyse: Beobachtung von Laufzeitverhalten durch Logging, Tracing oder instrumentierte Tests (z. B. welche Regeln bei bestimmten Eingaben greifen). Dynamische Analyse ist näher am realen Verhalten, benötigt aber reproduzierbare Szenarien und Testdaten.
|
||||
|
||||
Reverse Requirements Engineering in einem Migrationsprojekt profitiert typischerweise von einer Kombination beider Stränge. Ohne dynamische Belege steigt das Risiko, dass nicht offensichtliche Bedingungen (z. B. kundenspezifische Schalter) übersehen werden; ohne statische Analyse bleibt die Abdeckung häufig zu gering.
|
||||
|
||||
@@ -89,9 +89,9 @@ Aus Sicht dieser Arbeit lässt sich Reverse Requirements Engineering einer Legac
|
||||
|
||||
In der Praxis unterscheiden sich Artefakte darin, wie direkt sie fachliche Aussagen stützen. Quellcode, der eine Regel hart erzwingt (z. B. „Update nur bei Status X"), ist als Beleg stärker als Kommentare oder UI-Texte, die lediglich Absichten ausdrücken. Für eine belastbare Requirementsbasis ist es daher sinnvoll, Belege zu klassifizieren und die Aussagekraft zu kennzeichnen, beispielsweise:
|
||||
|
||||
- *Primärbelege:* Durchgesetzte Regeln im Code oder in Datenbankconstraints (z. B. Statusmaschinen, Validierungslogik, Berechtigungschecks).
|
||||
- *Sekundärbelege:* Indirekte Hinweise wie UI-Labels, Fehlermeldungen, Report-Layouts, Mappingtabellen oder Konfigurationsschalter.
|
||||
- *Kontextbelege:* Ticketbeschreibungen, Commit-Messages oder Interviewaussagen, die Motivation und Ausnahmen erklären, aber nicht zwingend im Code sichtbar sind.
|
||||
/ Primärbelege: Durchgesetzte Regeln im Code oder in Datenbankconstraints (z. B. Statusmaschinen, Validierungslogik, Berechtigungschecks).
|
||||
/ Sekundärbelege: Indirekte Hinweise wie UI-Labels, Fehlermeldungen, Report-Layouts, Mappingtabellen oder Konfigurationsschalter.
|
||||
/ Kontextbelege: Ticketbeschreibungen, Commit-Messages oder Interviewaussagen, die Motivation und Ausnahmen erklären, aber nicht zwingend im Code sichtbar sind.
|
||||
|
||||
Diese Einteilung dient der Risikobewertung: Requirements, die überwiegend auf Sekundär- oder Kontextbelegen beruhen, sind anfälliger für Fehlinterpretation und sollten priorisiert validiert werden. Datenbankschemata und SQL-Statements sind häufig besonders aussagekräftig, weil sie Domänenobjekte, Kardinalitäten und Geschäftsregeln (z. B. referentielle Integrität, historisierte Tabellen) abbilden.
|
||||
|
||||
|
||||
@@ -197,9 +197,9 @@ LLMs werden typischerweise in mehreren Phasen entwickelt. In einer Vortrainingsp
|
||||
|
||||
Im Engineering-Kontext ist der Prompt damit nicht nur Eingabe, sondern auch ein Steuerungsinstrument.\ Für diese Arbeit sind vor allem folgende Hebel relevant:
|
||||
|
||||
- *Aufgabe:* Ziel, gewünschtes Artefaktformat, Definition von Begriffen und Abgrenzung (z. B. „Requirement" vs. „Designentscheidung").
|
||||
- *Kontextwahl:* Welche Code- und Textartefakte werden bereitgestellt, und welche Teile werden bewusst ausgeblendet, um Überinterpretation zu begrenzen?
|
||||
- *KI Leitplanken:* Belegpflicht, Kennzeichnung unsicherer Aussagen, feste Templates, DOs and DONTs.
|
||||
/ Aufgabe: Ziel, gewünschtes Artefaktformat, Definition von Begriffen und Abgrenzung (z. B. „Requirement" vs. „Designentscheidung").
|
||||
/ Kontextwahl: Welche Code- und Textartefakte werden bereitgestellt, und welche Teile werden bewusst ausgeblendet, um Überinterpretation zu begrenzen?
|
||||
/ KI Leitplanken: Belegpflicht, Kennzeichnung unsicherer Aussagen, feste Templates, DOs and DONTs.
|
||||
|
||||
Da LLMs ein begrenztes Kontextfenster besitzen, wird in Forschung und Praxis häufig Retrieval-Augmented Generation (RAG) eingesetzt: Relevante Textstellen werden zunächst über Suche/Retrieval ausgewählt und anschließend als Kontext in die Generierung eingebracht. #cite(<lewis2020rag>, form: "prose") beschreiben dieses Grundprinzip für wissensintensive Aufgaben. Für Requirements-Extraktion aus Legacy-Code ist RAG naheliegend, weil relevante Regeln, Konfigurationen und UI-Strings über große Repositories verteilt sind und eine „Alles in den Prompt"-Strategie nicht skaliert.
|
||||
|
||||
@@ -221,8 +221,8 @@ Halluzinationen bezeichnen Ausgaben, die syntaktisch korrekt und plausibel wirke
|
||||
|
||||
Zusätzlich zu Halluzinationen sind zwei weitere Verlässlichkeitsthemen relevant:
|
||||
|
||||
- *Daten- und Domänenbias:* Modelle spiegeln Verteilungen und Annahmen aus Trainingsdaten wider @bender2021stochastic. Taucht eine falsche Aussage in Trainingsdaten häufig auf, wird sie vom Modell übernommen und als Wahrheit ausgegeben.
|
||||
- *Reproduzierbarkeit:* Kleine Promptänderungen oder Parameterunterschiede können zu unterschiedlichen Ergebnissen führen. Für einen engineeringfähigen Prozess sind daher Leitplanken (z. B. feste Templates, deterministische Einstellungen, versionierte Prompts) notwendig.
|
||||
/ Daten- und Domänenbias: Modelle spiegeln Verteilungen und Annahmen aus Trainingsdaten wider @bender2021stochastic. Taucht eine falsche Aussage in Trainingsdaten häufig auf, wird sie vom Modell übernommen und als Wahrheit ausgegeben.
|
||||
/ Reproduzierbarkeit: Kleine Promptänderungen oder Parameterunterschiede können zu unterschiedlichen Ergebnissen führen. Für einen engineeringfähigen Prozess sind daher Leitplanken (z. B. feste Templates, deterministische Einstellungen, versionierte Prompts) notwendig.
|
||||
|
||||
_Für diese Arbeit folgt daraus, dass LLM-Ausgaben im Requirements-Kontext nicht als Wahrheit", sondern als Vorschlag zu behandeln sind. Erst durch Traceability (Belege) und Validierung (Expertenreview, Laufzeitchecks) wird aus einer Hypothese eine belastbare Anforderung._
|
||||
|
||||
@@ -234,10 +234,10 @@ Eine systematische Übersicht ordnet die LLM-Nutzung im RE dabei entlang klassis
|
||||
|
||||
Dabei lassen sich aktuelle LLM-Arbeiten grob folgenden Themen zusammenfassen:
|
||||
|
||||
- *Strukturierung und (Re-)Formulierung von Requirements:* Untersucht wird, wie LLMs natürlichsprachliche Anforderungen in strukturiertere Formen überführen können @norheim2024structuring, sowie die automatische Umstrukturierung von Software Requirements Specifications mit dem Ziel, Standardkonformität zu erhöhen @okamoto2025restructuring.
|
||||
- *Qualitätsunterstützung und Analyse:* ChatGPT wurde für die Inkonsistenzdetektion in naturalsprachlichen Requirements evaluiert @fantechi2023inconsistency; weitere Arbeiten untersuchen LLM-gestützte Assistenz zur Verbesserung der Requirements-Vollständigkeit @luitel2024completeness.
|
||||
- *Anforderungserhebung (Elicitation) und Perspektivenwechsel:* LLMs können zur Generierung wertorientierter User Stories als "Inspirationsimpulse" eingesetzt werden @marczak2023humanvalue. Diese Richtung ist für Reverse Requirements Engineering insofern relevant, weil sie zeigt, wie LLMs fehlende Stakeholder-Sichten ergänzen können, ohne den Code als Primärbeleg zu ersetzen.
|
||||
- *Domänenspezifische Requirements (Safety/Compliance):* Betrachtet wurden LLMs bei der Engineering-Unterstützung von Safety Requirements im Kontext autonomen Fahrens @nouri2024safety sowie für rechtliche Compliance- und Regulationsanalyse @hassani2024legal. Solche Arbeiten verdeutlichen, dass LLMs nicht nur Text umformulieren, sondern auch regulatorische Anforderugen (Normen, Regeln) einbinden können.
|
||||
/ Strukturierung und (Re-)Formulierung von Requirements: Untersucht wird, wie LLMs natürlichsprachliche Anforderungen in strukturiertere Formen überführen können @norheim2024structuring, sowie die automatische Umstrukturierung von Software Requirements Specifications mit dem Ziel, Standardkonformität zu erhöhen @okamoto2025restructuring.
|
||||
/ Qualitätsunterstützung und Analyse: ChatGPT wurde für die Inkonsistenzdetektion in naturalsprachlichen Requirements evaluiert @fantechi2023inconsistency; weitere Arbeiten untersuchen LLM-gestützte Assistenz zur Verbesserung der Requirements-Vollständigkeit @luitel2024completeness.
|
||||
/ Anforderungserhebung (Elicitation) und Perspektivenwechsel: LLMs können zur Generierung wertorientierter User Stories als "Inspirationsimpulse" eingesetzt werden @marczak2023humanvalue. Diese Richtung ist für Reverse Requirements Engineering insofern relevant, weil sie zeigt, wie LLMs fehlende Stakeholder-Sichten ergänzen können, ohne den Code als Primärbeleg zu ersetzen.
|
||||
/ Domänenspezifische Requirements (Safety/Compliance): Betrachtet wurden LLMs bei der Engineering-Unterstützung von Safety Requirements im Kontext autonomen Fahrens @nouri2024safety sowie für rechtliche Compliance- und Regulationsanalyse @hassani2024legal. Solche Arbeiten verdeutlichen, dass LLMs nicht nur Text umformulieren, sondern auch regulatorische Anforderugen (Normen, Regeln) einbinden können.
|
||||
|
||||
Insgesamt ist die Studienlage bisher uneinheitlich. Viele Arbeiten sind kurze Workshopbeiträge oder erste Vorstudien mit kleinen Datensätzen, die automatische Messungen mit Experteneinschätzungen mischen. Auch die verwendeten Prompts, Modellversionen und Einstellungen sind selten einheitlich dokumentiert, wodurch sich Ergebnisse schwer wiederholen lassen @fan2023llmse @hemmat2025directions.
|
||||
|
||||
@@ -247,10 +247,10 @@ Für Reverse Requirements Engineering lässt sich der Nutzen damit präzisieren:
|
||||
|
||||
Die Literatur legt nahe, dass LLMs im Software Engineering dann robust eingesetzt werden können, wenn sie in einen Prozess eingebettet sind, der Fehler systematisch begrenzt @fan2023llmse @hemmat2025directions. Für die Requirements-Extraktion aus Legacy-Code sind folgende Kontrollen praxisnah:
|
||||
|
||||
- *Belegpflicht (Evidence-First):* Jedes generierte Requirement erhält mindestens einen konkreten Beleg (Datei/Komponente/Query/GUI-String) sowie eine kurze Begründung, warum der Beleg die Aussage trägt.
|
||||
- *Trennung von Fakt und Interpretation:* Technische Fakten (z. B. „Status = 'Closed' verhindert Update") werden getrennt von fachlicher Interpretation (z. B. „Abgeschlossene Aufträge sind schreibgeschützt") dokumentiert.
|
||||
- *Mehrstufige Validierung:* Automatische Checks (z. B. Linting auf Verbformen, Konsistenzregeln) werden mit Expertenreview kombiniert.
|
||||
- *Reproduzierbarkeit:* Versionierung von Promptvorlagen, Modellversionen und Kontextzuschnitten, um Ergebnisse vergleichbar zu machen.
|
||||
/ Belegpflicht (Evidence-First): Jedes generierte Requirement erhält mindestens einen konkreten Beleg (Datei/Komponente/Query/GUI-String) sowie eine kurze Begründung, warum der Beleg die Aussage trägt.
|
||||
/ Trennung von Fakt und Interpretation: Technische Fakten (z. B. „Status = 'Closed' verhindert Update") werden getrennt von fachlicher Interpretation (z. B. „Abgeschlossene Aufträge sind schreibgeschützt") dokumentiert.
|
||||
/ Mehrstufige Validierung: Automatische Checks (z. B. Linting auf Verbformen, Konsistenzregeln) werden mit Expertenreview kombiniert.
|
||||
/ Reproduzierbarkeit: Versionierung von Promptvorlagen, Modellversionen und Kontextzuschnitten, um Ergebnisse vergleichbar zu machen.
|
||||
|
||||
Diese Kontrollen adressieren nicht alle Risiken, reduzieren aber die typischen Fehlerklassen (Halluzination, Überinterpretation, fehlende Konsistenz) und schaffen die Grundlage für eine belastbare Evaluation.
|
||||
|
||||
@@ -258,9 +258,9 @@ Diese Kontrollen adressieren nicht alle Risiken, reduzieren aber die typischen F
|
||||
|
||||
Die Qualität von LLM-Ergebnissen wird in vielen Arbeiten mit allgemeinen Textmetriken oder aufgabenspezifischen Benchmarks bewertet. Für die Requirements-Extraktion aus Code reichen solche Metriken nicht aus, da es hier weniger um sprachliche Ähnlichkeit geht, sondern um fachliche Korrektheit, Prüfbarkeit und Nachvollziehbarkeit @hemmat2025directions @marques2024chatgptre. Eine sinnvolle Bewertung orientiert sich daher an RE-Kriterien und unterscheidet drei Dimensionen:
|
||||
|
||||
- *Statement-Qualität:* Ist ein Requirement eindeutig, vollständig im Satzbau, frei von nicht belegten Annahmen und mit Akzeptanzkriterium bzw. Prüfidee versehen?
|
||||
- *Set-Qualität:* Ist die Menge der Requirements konsistent, nicht redundant und deckt die relevanten Prozesse und Varianten ab, ohne sich in Detailfällen zu verlieren?
|
||||
- *Traceability-Qualität:* Sind Belege reproduzierbar auffindbar (z. B. Dateipfad, Methode, SQL-Query), und lässt sich die Ableitung von „Beleg → Requirement" nachvollziehen?
|
||||
/ Statement-Qualität: Ist ein Requirement eindeutig, vollständig im Satzbau, frei von nicht belegten Annahmen und mit Akzeptanzkriterium bzw. Prüfidee versehen?
|
||||
/ Set-Qualität: Ist die Menge der Requirements konsistent, nicht redundant und deckt die relevanten Prozesse und Varianten ab, ohne sich in Detailfällen zu verlieren?
|
||||
/ Traceability-Qualität: Sind Belege reproduzierbar auffindbar (z. B. Dateipfad, Methode, SQL-Query), und lässt sich die Ableitung von „Beleg → Requirement" nachvollziehen?
|
||||
|
||||
Für Legacy-Migrationen ist zudem die Fehlerkostenperspektive entscheidend. Ein fehlendes Requirement kann zu Funktionsverlust führen, ein falsches Requirement kann zu fehlerhaften Designentscheidungen führen, und ein unpräzises Requirement verursacht Review- und Nacharbeit. Daraus folgt eine pragmatische Bewertung: Requirements mit hoher Migrationskritikalität (z. B. Sicherheitsregeln, Abrechnungslogik, Berechtigungen) sollten strengere Evidenzanforderungen und intensivere Reviews erhalten als periphere Funktionen. Dieses Prinzip ist kompatibel mit der risikobasierten Priorisierung von Qualitätsanforderungen @glinz2008quality und lässt sich auf Funktionsanforderungen übertragen.
|
||||
/*
|
||||
|
||||
@@ -29,11 +29,11 @@ Im selben Zusammenhang werden Microservices häufig als Architekturstil diskutie
|
||||
|
||||
Für die Requirementsentwicklung bedeutet diese neue Zielarchitektur eine Verschiebung des Schwerpunktes. Während in klassischen Server/Client-Architekturen die fachliche Funktionslogik oft dominiert, rücken in Web- und Cloud-Kontexten auf den Betrieb bezogene (Deployment, Monitoring, Skalierung) und sicherheitsrelevante Qualitätsmerkmale (SaaS, Multi-Tennanting) stärker in den Vordergrund. ISO/IEC 25010:2011 bietet hierfür eine hilfreiche Taxonomie @iso25010_2011. Für Modernisierungsvorhaben lassen sich vor allem folgende Qualitätsmerkmale als wiederkehrend beobachten:
|
||||
|
||||
- *Sicherheit:* Identitäten, Rollenmodelle, Mandantenfähigkeit, Auditierbarkeit.
|
||||
- *Zuverlässigkeit:* Fehlerresistenz, Wiederanlauf, Degradationsverhalten.
|
||||
- *Performance-Effizienz:* Antwortzeiten, Lastverhalten, Skalierungsgrenzen.
|
||||
- *Wartbarkeit:* Änderbarkeit, Testbarkeit, Modularität und technische Schuld.
|
||||
- *Kompatibilität und Interoperabilität:* Schnittstellenstabilität, Integrationsfähigkeit mit Drittsystemen.
|
||||
/ Sicherheit: Identitäten, Rollenmodelle, Mandantenfähigkeit, Auditierbarkeit.
|
||||
/ Zuverlässigkeit: Fehlerresistenz, Wiederanlauf, Degradationsverhalten.
|
||||
/ Performance-Effizienz: Antwortzeiten, Lastverhalten, Skalierungsgrenzen.
|
||||
/ Wartbarkeit: Änderbarkeit, Testbarkeit, Modularität und technische Schuld.
|
||||
/ Kompatibilität und Interoperabilität: Schnittstellenstabilität, Integrationsfähigkeit mit Drittsystemen.
|
||||
|
||||
Diese Merkmale sind nicht neu, ihre Sichtbarkeit im Projekt nimmt jedoch zu, weil Cloud- und Webbetrieb ein engeres Zusammenspiel von Entwicklung und Betrieb erzwingt.
|
||||
|
||||
|
||||
@@ -4,6 +4,16 @@
|
||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
||||
]
|
||||
|
||||
#set terms(separator: [], hanging-indent: 0pt, tight: false)
|
||||
#show terms.item: it => block(below: 0.8em, [
|
||||
#strong(it.term) \
|
||||
#it.description
|
||||
])
|
||||
#show terms: it => {
|
||||
it
|
||||
v(2cm)
|
||||
}
|
||||
|
||||
#heading(level: 1)[Fallstudie c-entron GmbH (ca. 6 Seiten)]
|
||||
|
||||
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.
|
||||
@@ -21,10 +31,10 @@ Für diese Arbeit ist die Software relevant, weil sie Anforderungen in einer For
|
||||
|
||||
Die ERP-Suite ist als Windows-Anwendung in klassischer Client/Server-Architektur über Jahrzehnte gewachsen. Für die Modernisierung sind nicht das Alter, sondern die Kopplung der Komponenten und die lückenhafte Dokumentation entscheidend. Folgende Merkmale sind für die Fallstudie besonders relevant:
|
||||
|
||||
- *Enge Kopplung zwischen UI, Fachlogik und Persistenz:* Geschäftsregeln sind nicht in einer Schicht isoliert, sondern verteilen sich über mehrere Komponenten. So liegen Validierungen im Frontend-Code, während weitere Regeln als Trigger in der MSSQL-Datenbank realisiert sind.
|
||||
- *Implizite Regeln in Code und Daten:* Ein Teil der Anforderungen ist nicht explizit dokumentiert, sondern ergibt sich aus Validierungen, Standardwerten und Datenmodellannahmen.
|
||||
- *Evolution über lange Zeiträume:* Funktionserweiterungen und Fehlerkorrekturen haben zu Sonderfällen und Workarounds geführt, die fachlich begründet, aber selten als Requirement festgehalten sind. Regeln zum gleichen Fachthema (z. B. Preisberechnung) werden auf unterschiedlichen Masken nicht einheitlich angewendet, was die genaue Definition der Regel erschwert.
|
||||
- *Heterogene Artefakte:* Neben Quellcode existieren Konfigurationen, UI-Texte, Reportdefinitionen sowie Import- und Exportlogiken, die Anforderungen indirekt spiegeln.
|
||||
/ Enge Kopplung zwischen UI, Fachlogik und Persistenz: Geschäftsregeln sind nicht in einer Schicht isoliert, sondern verteilen sich über mehrere Komponenten. So liegen Validierungen im Frontend-Code, während weitere Regeln als Trigger in der MSSQL-Datenbank realisiert sind.
|
||||
/ Implizite Regeln in Code und Daten: Ein Teil der Anforderungen ist nicht explizit dokumentiert, sondern ergibt sich aus Validierungen, Standardwerten und Datenmodellannahmen.
|
||||
/ Evolution über lange Zeiträume: Funktionserweiterungen und Fehlerkorrekturen haben zu Sonderfällen und Workarounds geführt, die fachlich begründet, aber selten als Requirement festgehalten sind. Regeln zum gleichen Fachthema (z. B. Preisberechnung) werden auf unterschiedlichen Masken nicht einheitlich angewendet, was die genaue Definition der Regel erschwert.
|
||||
/ Heterogene Artefakte: Neben Quellcode existieren Konfigurationen, UI-Texte, Reportdefinitionen sowie Import- und Exportlogiken, die Anforderungen indirekt spiegeln.
|
||||
|
||||
Die Software ist damit ein geeigneter Gegenstand für Reverse Requirements Engineering. Die Anforderungen liegen nicht als gesammelte Dokumentation vor, sondern müssen erst rekonstruiert werden.
|
||||
|
||||
@@ -52,13 +62,13 @@ Quellcode und Datenstrukturen liefern den belastbarsten Beleg für eine Regel, w
|
||||
|
||||
Ziel der Modernisierung ist eine webbasierte SaaS-Plattform, die sowohl Cloud- als auch On-Premise-Betrieb unterstützt. Neben der Funktionsäquivalenz zur bestehenden ERP-Suite stehen nicht-funktionale Anforderungen wie Skalierbarkeit, Mandantenfähigkeit und KI-Anbindung im Vordergrund. Konkret leiten sich für das Fallunternehmen die folgenden Anforderungen ab:
|
||||
|
||||
- *Cloud- und On-Premise-Fähigkeit:* Die Anwendung wird containerisiert ausgeliefert und ist damit unabhängig von einem bestimmten Infrastrukturanbieter. Neben dem zentralen SaaS-Betrieb bleibt eine Einzelinstallation beim Kunden möglich.
|
||||
- *Multi-Tenant-Fähigkeit:* Mehrere Mandanten teilen sich eine gemeinsame Datenbank, sodass auch kleinere Kunden ohne vollen Installationsaufwand bedient werden können. Für größere Kunden ist weiterhin eine Einzelinstallation vorgesehen.
|
||||
- *Datenbanksystem-Unabhängigkeit:* Geschäftslogik und Abfragen werden möglichst vollständig im Code abgebildet und nicht im DBMS. Damit sinken Migrationsaufwände, und im Multi-Tenant-Betrieb lassen sich günstige oder kostenlose Datenbanksysteme einsetzen.
|
||||
- *Skalierbarkeit:* Das Backend ist über Microservices und Load-Balancing horizontal skalierbar, um auch bei größeren Kunden performant zu bleiben.
|
||||
- *KI-Fähigkeit:* Schnittstellen zu KI-Systemen (z. B. MCP-Server, RAG-Embeddings) sind von Beginn an in der Architektur vorgesehen.
|
||||
- *Web-Frontend:* Eine responsive Web-Oberfläche ermöglicht die geräteherstellerunabhängige Nutzung.
|
||||
- *Zentrale Datenverwaltung:* Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Basis für weitere Produkte der Firma.
|
||||
/ Cloud- und On-Premise-Fähigkeit: Die Anwendung wird containerisiert ausgeliefert und ist damit unabhängig von einem bestimmten Infrastrukturanbieter. Neben dem zentralen SaaS-Betrieb bleibt eine Einzelinstallation beim Kunden möglich.
|
||||
/ Multi-Tenant-Fähigkeit: Mehrere Mandanten teilen sich eine gemeinsame Datenbank, sodass auch kleinere Kunden ohne vollen Installationsaufwand bedient werden können. Für größere Kunden ist weiterhin eine Einzelinstallation vorgesehen.
|
||||
/ Datenbanksystem-Unabhängigkeit: Geschäftslogik und Abfragen werden möglichst vollständig im Code abgebildet und nicht im DBMS. Damit sinken Migrationsaufwände, und im Multi-Tenant-Betrieb lassen sich günstige oder kostenlose Datenbanksysteme einsetzen.
|
||||
/ Skalierbarkeit: Das Backend ist über Microservices und Load-Balancing horizontal skalierbar, um auch bei größeren Kunden performant zu bleiben.
|
||||
/ KI-Fähigkeit: Schnittstellen zu KI-Systemen (z. B. MCP-Server, RAG-Embeddings) sind von Beginn an in der Architektur vorgesehen.
|
||||
/ Web-Frontend: Eine responsive Web-Oberfläche ermöglicht die geräteherstellerunabhängige Nutzung.
|
||||
/ Zentrale Datenverwaltung: Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Basis für weitere Produkte der Firma.
|
||||
|
||||
Als Performance-Ziel wird ein Bereich von 5 bis 100 gleichzeitigen Nutzern pro Mandant festgelegt. Kleinere Installationen mit 1 bis 5 Nutzern sowie größere Installationen oberhalb von 100 Nutzern werden ebenfalls unterstützt, bleiben aber opportunistische Ziele.
|
||||
|
||||
@@ -72,11 +82,11 @@ Schwerpunkt ist die *Rückgewinnung und Strukturierung* von Requirements aus bes
|
||||
|
||||
Aus dem Ist-Zustand ergeben sich mehrere Herausforderungen, die das Vorgehen des Reverse Requirements Engineering unmittelbar prägen:
|
||||
|
||||
- *Randfäll und Varianten:* Ein erheblicher Teil des Systemumfangs steckt in implementierten Sonderfällen und Varianten. Diese sind im Code zwar nachvollziehbar, aber selten dokumentiert und zur Laufzeit auch jeweils nur einzeln zu analysieren da sie sich oft gegenseitig ausschließen.
|
||||
- *Daten und Logische Redundanz:* Historisch wurden zusätzliche Funktionen oft inmplementiert indem Code oder Masken hinzugefügt wurden ohne alten code zu verändern. Daher kommt es vor, dass die die gleiche Anforderung auf Unterschiedlichen Masken oder Berechnungspfaden mehrfach unterschiedliche implementiert wurde.
|
||||
- *Implizite Geschäftsregeln:* Geschäftslogik ist häufig als Prüf- und Statuslogik oder über Randbediungungen in Eingabefeldern realisiert. Eine zuordung zu anderen zusammenghörigen Regeln fällt hier schwer.
|
||||
- *Kontextbasierte Logik:* Funktionalitäten und Logik sind oft nur lose über historische Zuständen verbunden. Eine Regel kann daher nur bei Betrachtung eines vollständigen historischen Datensatzes im Kontext abgeleitet werden.
|
||||
- *Nicht-funktionale Anforderungen:* Mit dem Wechsel auf einen neuen Tech-Stack ist zu prüfen, welche der bisherigen nicht-funktionalen Anforderungen weiterhin Gültigkeit haben und welche neu definiert werden müssen. Annahmen zu Performance, Sicherheit oder Verfügbarkeit gelten unter veränderten Architektur- und Betriebsbedingungen nicht automatisch weiter.
|
||||
/ Randfäll und Varianten: Ein erheblicher Teil des Systemumfangs steckt in implementierten Sonderfällen und Varianten. Diese sind im Code zwar nachvollziehbar, aber selten dokumentiert und zur Laufzeit auch jeweils nur einzeln zu analysieren da sie sich oft gegenseitig ausschließen.
|
||||
/ Daten und Logische Redundanz: Historisch wurden zusätzliche Funktionen oft inmplementiert indem Code oder Masken hinzugefügt wurden ohne alten code zu verändern. Daher kommt es vor, dass die die gleiche Anforderung auf Unterschiedlichen Masken oder Berechnungspfaden mehrfach unterschiedliche implementiert wurde.
|
||||
/ Implizite Geschäftsregeln: Geschäftslogik ist häufig als Prüf- und Statuslogik oder über Randbediungungen in Eingabefeldern realisiert. Eine zuordung zu anderen zusammenghörigen Regeln fällt hier schwer.
|
||||
/ Kontextbasierte Logik: Funktionalitäten und Logik sind oft nur lose über historische Zuständen verbunden. Eine Regel kann daher nur bei Betrachtung eines vollständigen historischen Datensatzes im Kontext abgeleitet werden.
|
||||
/ Nicht-funktionale Anforderungen: Mit dem Wechsel auf einen neuen Tech-Stack ist zu prüfen, welche der bisherigen nicht-funktionalen Anforderungen weiterhin Gültigkeit haben und welche neu definiert werden müssen. Annahmen zu Performance, Sicherheit oder Verfügbarkeit gelten unter veränderten Architektur- und Betriebsbedingungen nicht automatisch weiter.
|
||||
|
||||
|
||||
#heading(level: 3)[Konsequenzen für das Vorgehen in dieser Arbeit]
|
||||
|
||||
@@ -6,6 +6,13 @@
|
||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
||||
]
|
||||
|
||||
#set terms(separator: [], hanging-indent: 0pt, tight: false)
|
||||
#show terms.item: it => block(below: 0.8em, [
|
||||
#strong(it.term) \
|
||||
#it.description
|
||||
])
|
||||
#show terms: it => block(below: 1.6em, it)
|
||||
|
||||
#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.
|
||||
@@ -68,9 +75,9 @@ Das Vorgehen ist entlang der vier Forschungsleitfragen aus Kapitel 1 strukturier
|
||||
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.
|
||||
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 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.
|
||||
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)[Bezugsrahmen: Der RRE-Prozess als Untersuchungsgegenstand]
|
||||
|
||||
@@ -84,51 +91,50 @@ Das in dieser Arbeit untersuchte Vorgehen folgt der in Kapitel 2 hergeleiteten s
|
||||
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.
|
||||
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 jeder Iteration vier Eigenschaften sicherzustellen:
|
||||
Damit das Vorgehen belastbar bleibt, sind in jeder Iteration 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.
|
||||
- *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.
|
||||
/ 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 vier Pflicht-Eigenschaften ist der Bezugsrahmen geklärt, in dem die folgenden Abschnitte ihre Detailfragen verorten.
|
||||
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)[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.
|
||||
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, center, center, center, center),
|
||||
align: (left, left, left, left, left),
|
||||
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],
|
||||
[*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 und Kimi werden für einen optionalen LLM-Querschnitt offengehalten, sind aber nicht das primäre Werkzeug.
|
||||
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)[Untersuchungsdesign: Tooling-Ablation als kontrollierte Variation]
|
||||
#heading(level: 2)[Untersuchungsdesign: Kontrollierter Tooling-Vergleich]
|
||||
|
||||
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.
|
||||
Das Untersuchungsdesign 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 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 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 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.
|
||||
/ 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(
|
||||
@@ -139,32 +145,33 @@ Das Untersuchungsdesign folgt einer Ablation-Logik. Ausgehend von einer Baseline
|
||||
[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],
|
||||
[V4 (optional)], [Beste Konfiguration aus V1–V3, wiederholt auf GPT-5 (Codex), DeepSeek R1 (Cloud) und Qwen 3.5 Coder (lokal, LM Studio)], [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.
|
||||
Konstanten und Variablen sind in jedem Versuch klar dokumentiert. In Versuch 1 bis 3 umfassen die Konstanten Codebasis, Grundprompt, Modellfamilie, Validierungsstichprobe und Bewertungskriterien; variabel ist ausschließlich die Werkzeugkonfiguration. 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 zentrales Verifikationsverfahren]
|
||||
#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 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.
|
||||
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 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.
|
||||
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 fünf Dimensionen bewertet:
|
||||
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?
|
||||
- *Nützlichkeit:* Ist die Anforderung für die Migration verwertbar?
|
||||
/ 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. 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.
|
||||
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, der Konsolidierungsbedarf gegenüber der Zielarchitektur einschließlich der Identifikation historisch gewachsener Workarounds und Doublettenstrukturen 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.
|
||||
|
||||
@@ -174,7 +181,7 @@ Der Evaluationsrahmen wird vor der Durchführung der Versuche definiert. Damit w
|
||||
|
||||
*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.
|
||||
*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. Dabei wird zwischen output-interner Redundanzfreiheit, also dem Fehlen von Doubletten in der vom LLM erzeugten Spezifikation, und migrationsbezogenem Konsolidierungsbedarf, also legacy-bedingt getrennt geführten Strukturen mit derselben fachlichen Funktion, unterschieden. 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.
|
||||
|
||||
@@ -184,16 +191,16 @@ Ergänzend zur Qualitätsbewertung wird eine Aufwands-Kennzahl in hybrider Form
|
||||
|
||||
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.
|
||||
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. 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 wie top\_p und repeat penalty 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.
|
||||
- *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.
|
||||
/ 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]
|
||||
|
||||
|
||||
42344
Masterarbeit_draft.pdf
42344
Masterarbeit_draft.pdf
File diff suppressed because it is too large
Load Diff
@@ -26,7 +26,8 @@ Leitfaden, um den Schreibstil der in `StilVorlagen` vorhandenen Dokumente für K
|
||||
8. **Mehr Fließtext, sparsame Listen:** Bullet- und Nummernlisten nur dann, wenn die Punkte klar parallel sind (Materialien, Anforderungen, Risiken). Erklärende Inhalte und Schlussfolgerungen gehören in Fließtext.
|
||||
9. **Keine Gedankenstrich-Einschübe in Sätzen:** Sätze werden nicht über Gedankenstriche („— …, …, … —") parenthetisch erweitert. Stattdessen entweder Komma-getrennte Nebensätze, Klammer-Einschübe oder ein eigener Satz.
|
||||
10. **Referenzen am Satzende:** Quellenangaben (z.B. `@iso25010_2011`, `(Boser et al. 1992)`) stehen am Ende des Satzes, nicht inmitten des Fließtextes.
|
||||
11. **Doppelpunkt nur vor Listen oder innerhalb von Listeneinträgen nach der Überschrift:** Ein Doppelpunkt steht entweder als Einleitung einer Aufzählung/Liste oder innerhalb eines Listeneintrags direkt nach dessen Überschrift (z.B. `*Titel:* Beschreibung …` oder `*Form* beeinflusst Interpretierbarkeit: Erklärung …`). Im normalen Fließtext zur Anbindung weiterer Aussagen ist er nicht zulässig. Statt „Zunächst gilt X: Es muss Y." → „Zunächst gilt X. Y muss …".
|
||||
11. **Doppelpunkt nur vor Listen oder innerhalb von Listeneinträgen nach der Überschrift:** Ein Doppelpunkt steht entweder als Einleitung einer Aufzählung/Liste oder innerhalb eines Listeneintrags direkt nach einer beschreibenden Wortgruppe (z.B. `*Form* beeinflusst Interpretierbarkeit: Erklärung …`). Im normalen Fließtext zur Anbindung weiterer Aussagen ist er nicht zulässig. Statt „Zunächst gilt X: Es muss Y." → „Zunächst gilt X. Y muss …".
|
||||
12. **Schlagwort-Listen als Typst-Termlisten:** Inhaltliche Listen mit fettem Schlagwort und nachfolgendem Erklärtext werden im Quelltext als Typst-Termliste geschrieben: `/ Schlagwort: Erklärungstext`. Der bisherige Markdown-Stil `- *Schlagwort:* Text` ist nicht mehr zu verwenden. Das Rendering (Schlagwort fett auf eigener Zeile, Erklärtext darunter, vertikale Trennung zwischen Einträgen) ist zentral in `masterarbeit_style.typ` über `#show terms.item` und `#set terms` festgelegt und muss nicht im Fließtext nachgebaut werden. Nummerierte Listen bleiben in der Form `1. *Titel:* Text` erhalten.
|
||||
|
||||
## 2. Strukturbausteine pro Dokumenttyp
|
||||
|
||||
|
||||
@@ -59,14 +59,16 @@
|
||||
#content
|
||||
]
|
||||
|
||||
#let body_show() = [
|
||||
#let body_show() = []
|
||||
|
||||
#let body_content(children) = [
|
||||
#set page(
|
||||
paper: "a4",
|
||||
margin: (top: 25mm, bottom: 25mm, inside: 30mm, outside: 20mm),
|
||||
numbering: "1"
|
||||
numbering: "1",
|
||||
)
|
||||
#set text(font: "Times New Roman", size: 11pt)
|
||||
#set par(justify: true, leading: 14pt, first-line-indent: 5mm)
|
||||
#set par(justify: true)
|
||||
#set list(indent: 6mm, spacing: 2mm)
|
||||
#set enum(numbering: "a)")
|
||||
#set heading(numbering: "1.1.1", depth: 3)
|
||||
@@ -82,10 +84,15 @@
|
||||
#set text(size: 12pt, weight: "semibold")
|
||||
#it
|
||||
]
|
||||
|
||||
]
|
||||
|
||||
#let body_content(children) = [
|
||||
#set terms(separator: [], hanging-indent: 0pt, tight: false)
|
||||
#show terms.item: it => block(below: 0.8em, [
|
||||
#strong(it.term) \
|
||||
#it.description
|
||||
])
|
||||
#show terms: it => {
|
||||
it
|
||||
v(2cm)
|
||||
}
|
||||
// Markdown-like styling for fenced code blocks.
|
||||
#show raw: set text(font: "DejaVu Sans Mono", size: 9.5pt, fill: luma(20))
|
||||
#show raw.where(block: true): it => block(
|
||||
|
||||
Reference in New Issue
Block a user