170 lines
13 KiB
Typst
170 lines
13 KiB
Typst
#let __is_thesis = context { query(<__thesis_document>).len() > 0 }
|
|
#if __is_thesis == false [
|
|
#set cite(style: "apa")
|
|
#hide(bibliography("../literatur.bib", style: "apa"))
|
|
]
|
|
|
|
#heading(level: 1)[Konzeption und methodisches Vorgehen (ca. 12 Seiten)]
|
|
|
|
Dieses Kapitel beschreibt das Forschungsdesign und das Vorgehensmodell der Arbeit. Ziel ist es, den Einsatz von Large Language Models (LLMs) für Reverse Requirements Engineering so zu strukturieren, dass Ergebnisse nachvollziehbar, überprüfbar und reproduzierbar sind. Hierzu wird zunächst das Forschungsdesign als Fallstudie im Unternehmenskontext eingeordnet. Anschließend wird ein Prozessmodell für KI-gestütztes Reverse Requirements Engineering entwickelt. Abschließend werden Kriterien zur Technologieauswahl, Modellkonfiguration sowie die Einbindung von Stakeholdern und die Datengrundlage beschrieben.
|
|
|
|
#heading(level: 2)[Forschungsdesign und Vorgehensmodell]
|
|
|
|
#heading(level: 3)[Einordnung als Fallstudie und Artefaktentwicklung]
|
|
|
|
Die Arbeit ist als anwendungsnahe Untersuchung im Kontext einer konkreten Legacy-Modernisierung angelegt. Der Kernbeitrag besteht nicht nur in einer Beschreibung von LLM-Fähigkeiten, sondern in der Entwicklung eines Vorgehens, das unter realistischen Randbedingungen (große Codebasis, heterogene Artefakte, begrenzte Expertenzeit) umsetzbar ist. Das Forschungsdesign kombiniert daher:
|
|
|
|
1. **Literaturbasierte Fundierung:** Ableitung von Anforderungen an Requirements-Qualität, Traceability und Qualitätskriterien @iso29148_2018 @ieee830_1998.
|
|
2. **Artefaktentwicklung:** Konzeption eines reproduzierbaren Prozessmodells für KI-gestütztes Reverse Requirements Engineering.
|
|
3. **Prototypische Umsetzung:** Implementationsnahe Ausgestaltung des Prozesses als Agenten-/Toolchain-Workflow.
|
|
4. **Fallbezogene Evaluation:** Überprüfung der Praktikabilität und der Ergebnisqualität durch Review und Abgleich mit Artefakten und Expertenwissen.
|
|
|
|
Diese Kombination ist notwendig, weil LLM-Ergebnisse im Requirements-Kontext nur dann einen belastbaren Nutzen stiften, wenn sie in einen Prozess eingebettet sind, der Belege, Unsicherheit und Validierung explizit adressiert. LLM-Ausgaben werden daher nicht als Spezifikation „an sich“ betrachtet, sondern als Zwischenartefakte, die über Belegpflicht und Review zu Requirements konsolidiert werden.
|
|
|
|
#heading(level: 3)[Datenerhebung, Artefaktanalyse und Auswertungslogik]
|
|
|
|
Die Datengrundlage der Arbeit ist artefaktzentriert. Der Ausgangspunkt ist die bestehende Legacy-Codebasis und die zugehörigen projektinternen Artefakte. Die Analyse folgt einer Logik aus (1) technischer Faktenerhebung und (2) semantischer Interpretation:
|
|
|
|
- **Faktenerhebung:** Identifikation von Komponenten, Datenobjekten, Schnittstellen und Regelstellen (z. B. Validierungen, Statuswechsel, Rechteprüfungen).
|
|
- **Semantische Interpretation:** Ableitung fachlicher Aussagen aus den Fakten (z. B. „Ein Auftrag darf nur fakturiert werden, wenn …“).
|
|
- **Formalisierung:** Überführung in Requirements mit Akteur, Vorbedingung, Ergebnis und Prüfidee.
|
|
- **Absicherung:** Zuordnung von Belegen und Review durch Domänenexperten.
|
|
|
|
Für die Auswertung ist wichtig, dass die Arbeit nicht versucht, „Vollständigkeit“ absolut zu beweisen. Stattdessen wird eine risikobasierte Perspektive gewählt: Requirements werden dort vertieft und geprüft, wo Migration, Sicherheit oder Datenintegrität besonders kritisch sind. Diese Priorisierung ist anschlussfähig an die RE-Literatur, die Qualitätsanforderungen als risikobasiert zu behandeln empfiehlt @glinz2008quality.
|
|
|
|
#heading(level: 3)[Gütekriterien: Nachvollziehbarkeit, Prüfbarkeit, Reproduzierbarkeit]
|
|
|
|
Im Requirements Engineering gelten Kriterien wie Eindeutigkeit, Konsistenz, Vollständigkeit, Verifizierbarkeit und Traceability als zentrale Qualitätsmerkmale @iso29148_2018. Für KI-gestützte Extraktion wird diese Liste operationalisiert, um überprüfbare Prozessanforderungen zu erhalten. Für die Arbeit sind besonders relevant:
|
|
|
|
- **Traceability:** Jedes extrahierte Requirement muss auf Artefakte zurückgeführt werden können (Code, Konfiguration, Datenobjekt, UI-Text). Traceability ist in der Literatur als zentrales, dauerhaftes Problemfeld beschrieben und wird als Voraussetzung für belastbare Weiterentwicklung betrachtet @gotel1994traceability @ramesh2001traceability.
|
|
- **Prüfbarkeit:** Requirements werden so formuliert, dass eine Testidee oder ein Abnahmekriterium ableitbar ist.
|
|
- **Reproduzierbarkeit:** Prompting-Strategien, Kontextauswahl und Parameter werden dokumentiert, sodass Analysen unter gleichen Bedingungen wiederholbar sind.
|
|
|
|
LLMs erzeugen nicht-deterministische Ausgaben. Deshalb wird im Vorgehensmodell eine „Kontrollspur“ vorgesehen: Kontextquellen, Promptversionen und Resultate werden versioniert, und Unsicherheit wird explizit markiert, um spätere Überprüfung zu ermöglichen. Der Umgang mit Halluzinationen ist dabei ein zentrales Risiko, da plausible Texte fachlich falsch sein können @ji2023hallucination.
|
|
|
|
#heading(level: 2)[Prozessmodell für KI-gestütztes Reverse Requirements Engineering]
|
|
|
|
#heading(level: 3)[Prozessüberblick und Rollen]
|
|
|
|
Das Prozessmodell strukturiert die Arbeit in Phasen, die wiederholbar durchlaufen werden können. Es unterscheidet technische und fachliche Rollen:
|
|
|
|
- **Analyseverantwortlicher:** Steuert Scope, Artefaktauswahl und Toolchain.
|
|
- **Domänenexperte:** Validiert fachliche Bedeutung, Ausnahmen und Prioritäten.
|
|
- **Entwicklung/Architektur:** Nutzt konsolidierte Requirements als Basis für Zielarchitektur und Umsetzung.
|
|
|
|
Der Prozess besteht aus sieben Phasen, die iterativ angewendet werden:
|
|
|
|
1. **Scope und Domänenabgrenzung**
|
|
2. **Artefakterhebung und Kontextaufbereitung**
|
|
3. **Technische Analyse (Struktur, Daten, Schnittstellen)**
|
|
4. **Retrieval und Kontextsteuerung (RAG)**
|
|
5. **Requirements-Extraktion und Strukturierung**
|
|
6. **Traceability-Anreicherung und Unsicherheitsmarkierung**
|
|
7. **Review, Konsolidierung und Übergabe**
|
|
|
|
#heading(level: 3)[Artefaktpipeline: Sammeln, Normalisieren, Indexieren]
|
|
|
|
Die zentrale technische Voraussetzung ist eine Artefaktpipeline, die die Codebasis und flankierende Quellen in eine Form überführt, die sowohl maschinell suchbar als auch für LLMs nutzbar ist. Die Pipeline umfasst:
|
|
|
|
- **Sammeln:** Repository, Konfigurationen, UI-Texte, Datenbankschemata, Tickets, Release Notes.
|
|
- **Normalisieren:** Extraktion von Metadaten (Pfad, Modul, Änderungsdatum), Entfernen von Rauschen (Build-Artefakte), Vereinheitlichung von Encodings.
|
|
- **Segmentieren:** Zerlegung großer Dateien in semantische Chunks (z. B. pro Klasse, Methode, SQL-Statement).
|
|
- **Indexieren:** Aufbau eines Suchindex (klassisch oder embeddings-basiert) zur späteren Kontextauswahl.
|
|
|
|
Die Segmentierung ist entscheidend, weil LLMs nur ein begrenztes Kontextfenster besitzen. Eine „Alles-in-einen-Prompt“-Strategie skaliert nicht. Retrieval-Augmented Generation (RAG) adressiert dieses Problem, indem relevante Textstellen gezielt in den Prompt geladen werden @lewis2020rag.
|
|
|
|
#heading(level: 3)[Prompt- und Output-Templates für Requirements]
|
|
|
|
Um Ergebnisse konsistent auszuwerten, werden Requirements in einem festen Template erzeugt. Ein zweckmäßiges Format umfasst:
|
|
|
|
- **ID**
|
|
- **Titel**
|
|
- **Akteur/Rolle**
|
|
- **Vorbedingungen**
|
|
- **Beschreibung des Verhaltens**
|
|
- **Akzeptanzkriterien**
|
|
- **Belege (Artefaktverweise)**
|
|
- **Unsicherheitsmarker / offene Fragen**
|
|
|
|
Dieses Template reduziert Interpretationsspielraum und macht Reviews effizienter. Es adressiert zudem ein zentrales Risiko: LLMs können sprachlich „glatte“ Requirements erzeugen, die jedoch ohne Belege und Akzeptanzkriterien nicht belastbar sind. Der Prozess erzwingt daher eine Belegpflicht und die Ableitung von Prüfkriterien als Standardausgabe.
|
|
|
|
#heading(level: 3)[Kontrollpunkte und Fehlerbegrenzung]
|
|
|
|
Die Prozesskontrollen sind so gewählt, dass typische LLM-Fehlermuster begrenzt werden:
|
|
|
|
- **Belegpflicht:** Keine Requirements ohne Artefaktbezug.
|
|
- **Konfliktprüfung:** Abgleich widersprüchlicher Aussagen über mehrere Belegstellen.
|
|
- **Unsicherheitskennzeichnung:** Hypothesen werden explizit markiert und priorisiert geprüft.
|
|
- **Human-in-the-loop:** Fachliche Validierung als fester Schritt, nicht als optionales „Nachlesen“.
|
|
|
|
Diese Kontrollen sind notwendig, weil Halluzinationen und Bias-Risiken in der LLM-Literatur als strukturelle Probleme beschrieben werden @bender2021stochastic @ji2023hallucination. Für Requirements bedeutet dies, dass Prozessqualität und Governance nicht nachgelagert, sondern integraler Bestandteil sein müssen.
|
|
|
|
#heading(level: 2)[Technologieauswahl und LLM-Konfiguration]
|
|
|
|
#heading(level: 3)[Auswahlkriterien für Modelle und Betriebsform]
|
|
|
|
Die Auswahl eines LLMs im Unternehmenskontext folgt nicht nur der Modellqualität, sondern auch Randbedingungen. Für diese Arbeit werden die folgenden Kriterien als handlungsleitend betrachtet:
|
|
|
|
- **Kontextfenster und Eingabekosten:** Große Artefakte erfordern Segmentierung; zu kleine Kontextfenster erhöhen den Retrieval-Aufwand.
|
|
- **Codefähigkeit:** Verständnis von Identifiern, Kontrollfluss, Datenzugriffsmustern und typischen Framework-Idiomen.
|
|
- **Steuerbarkeit:** Möglichkeiten zur Formatsteuerung (z. B. JSON-Outputs), deterministische Parameter, Prompt-Constraints.
|
|
- **Betriebs- und Datenschutzanforderungen:** Umgang mit Quellcode als potenziell vertraulichem Material.
|
|
- **Reproduzierbarkeit:** Versionierung von Modell, Prompt, Retrieval-Konfiguration.
|
|
|
|
Survey- und SLR-Arbeiten zu LLMs im Software Engineering betonen, dass Nutzen stark davon abhängt, wie Modelle in Toolchains integriert und abgesichert werden @fan2023llmse @llm4se2024slr @llm4se2024survey. Diese Perspektive prägt die Technologieauswahl in Kapitel 5.
|
|
|
|
#heading(level: 3)[Konfiguration: Parameter und Prompting]
|
|
|
|
Da LLM-Ausgaben sensitiv auf Prompting und Sampling reagieren, wird eine konservative Konfiguration gewählt:
|
|
|
|
- **Niedrige Temperatur** zur Reduktion von Varianz.
|
|
- **Explizite Ausgabeformate** (Templatepflicht, strukturierte Felder).
|
|
- **Beleganforderungen** (z. B. „nennen Sie Datei + Funktion/SQL“).
|
|
- **Stop-Kriterien** (bei fehlenden Belegen: offene Frage statt Behauptung).
|
|
|
|
Chain-of-Thought-Strategien können die Qualität komplexer Ableitungen steigern, erhöhen im Requirements-Kontext jedoch das Risiko, dass Begründungen als Evidenz missverstanden werden. In dieser Arbeit werden Begründungen daher nur als Hilfsmittel akzeptiert, nicht als Beleg @wei2022cot.
|
|
|
|
#heading(level: 3)[Retrieval-Strategie und Kontextfenstersteuerung]
|
|
|
|
RAG wird in dieser Arbeit als zentrales Skalierungsprinzip betrachtet @lewis2020rag. Die Kontextfenstersteuerung folgt einer einfachen Heuristik:
|
|
|
|
1. Suche nach relevanten Stellen (Keywords, Identifier, Datenobjekte).
|
|
2. Ergänzung um Nachbarschaftskontext (z. B. Aufrufer, SQL-Definition, UI-String).
|
|
3. Begrenzung der Kontextmenge durch Ranking und Redundanzfilter.
|
|
|
|
Wichtig ist, dass Retrieval nicht „Wahrheit“ garantiert. Es liefert lediglich die evidenznahe Basis, an die Generierung gekoppelt wird. Daraus folgt, dass Retrieval-Konfigurationen (Chunkgröße, Overlap, Ranking) dokumentiert werden müssen, um Ergebnisse reproduzierbar zu halten.
|
|
|
|
#heading(level: 2)[Stakeholder-Einbindung und Datengrundlage]
|
|
|
|
#heading(level: 3)[Stakeholderrollen und Verantwortlichkeiten]
|
|
|
|
LLM-gestützte Requirements-Rückgewinnung ist ohne Domänenvalidierung nicht belastbar. Für die Fallstudie werden daher Stakeholderrollen unterschieden:
|
|
|
|
- **Fachexperten (Domäne/Support):** kennen Ausnahmen, Kundenvarianten und Abläufe.
|
|
- **Entwickler/Architekten:** ordnen Codeartefakte ein und bewerten technische Machbarkeit.
|
|
- **Produktverantwortliche:** priorisieren Requirements in Bezug auf Migrationsziel und Wertbeitrag.
|
|
|
|
Die Beteiligung dient nicht nur der Korrektur von Detailfragen, sondern der Abgrenzung von Soll- und Ist-Zustand. Gerade Legacy-Systeme enthalten historisch gewachsene Workarounds, die fachlich nicht zwingend gewünscht sind @bisbal1999legacy.
|
|
|
|
#heading(level: 3)[Interviewleitfaden und Workshopformat]
|
|
|
|
Die Stakeholder-Einbindung wird als Kombination aus Interviews und Validierungsworkshops strukturiert. Ein schlanker Leitfaden fokussiert auf:
|
|
|
|
- kritische Geschäftsobjekte und Statusmodelle,
|
|
- typische Fehlerfälle und Ausnahmen,
|
|
- Sicherheits- und Complianceanforderungen,
|
|
- Integrationen und Schnittstellen,
|
|
- Kriterien für „Done“ in der Migration (Abnahmelogik).
|
|
|
|
Workshops dienen der Konsolidierung: Requirements werden mit Belegen präsentiert, offene Punkte markiert und Entscheidungen (z. B. „Ist-Übernahme“ vs. „Soll-Anpassung“) festgehalten. Dieses Vorgehen ist konsistent mit RE-Standards, die Validierung und Stakeholderabstimmung als zentrale Schritte behandeln @iso29148_2018.
|
|
|
|
#heading(level: 3)[Datengrundlage und Umgang mit sensiblen Informationen]
|
|
|
|
Die Datengrundlage umfasst Quellcode und begleitende Projektartefakte. Aus Governance-Sicht ist Quellcode als sensibel zu betrachten. Daraus folgt:
|
|
|
|
- Trennung zwischen Artefakten, die für Retrieval/Prompts verwendet werden dürfen, und solchen, die ausgeschlossen werden (z. B. Zugangsdaten).
|
|
- Protokollierung, welche Artefakte in einen Prompt eingeflossen sind.
|
|
- Minimierung von Kontext (Need-to-know), um Datenabflussrisiken zu reduzieren.
|
|
|
|
Diese Maßnahmen werden in Kapitel 5 konkretisiert, da dort die Toolchain-Integration und der Umgang mit Logging, Prompt-Historien und IP-Aspekten umgesetzt werden.
|