Kapitel 2 draft

.vscode/launch.json

@@ -0,0 +1,15 @@
+{
+    // Use IntelliSense to learn about possible attributes.
+    // Hover to view descriptions of existing attributes.
+    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
+    "version": "0.2.0",
+    "configurations": [
+        {
+            "type": "chrome",
+            "request": "launch",
+            "name": "Launch Chrome against localhost",
+            "url": "http://localhost:8080",
+            "webRoot": "${workspaceFolder}"
+        }
+    ]
+}

Kapitel/00_abstract.typ

@@ -1,2 +1,2 @@
-#heading(level: 1, numbering: none)[Abstract]
+#heading(level: 1, numbering: none)[Abstract (ca. 1 Seite)]
 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ergänze hier die Zusammenfassung der Arbeit.

Kapitel/01_einleitung.typ

@@ -1,4 +1,4 @@
-#heading(level: 1)[Einleitung]
+#heading(level: 1)[Einleitung (ca. 8 Seiten)]
 
 #heading(level: 2)[Ausgangssituation und Motivation]
 In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre gewachsenen Systeme neu zu bewerten. Besonders ERP-Lösungen, die über Jahrzehnte in Windows-Umgebungen gepflegt wurden, stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen. Dokumentierte Architekturentscheidungen sind selten, implizites Wissen steckt in Source-Control-Systemen oder bei einzelnen Entwickler:innen.

Kapitel/02_theoretischer_hintergrund.typ

@@ -1,10 +1,366 @@
-#heading(level: 1)[Theoretischer Hintergrund]
+#heading(level: 1)[Theoretische Grundlagen (ca. 12 Seiten)]
 
-#heading(level: 2)[Large Language Models im Requirements Engineering]
-Charakterisiere relevante LLM-Konzepte, Fähigkeiten und Grenzen.
+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 Begriffe des Requirements Engineering sowie die Idee der rückwärtsgerichteten Anforderungsgewinnung aus bestehenden Systemen eingeordnet. Anschließend werden Large Language Models als Werkzeugklasse im Software Engineering beschrieben, inklusive typischer Leistungsgrenzen und Absicherungsmechanismen. Abschließend werden Grundlagen der Legacy-Modernisierung sowie etablierte Migrationsstrategien zusammengefasst, um den Kontext der Fallstudie und die Zielrichtung einer webbasierten Modernisierung einzuordnen.
 
-#heading(level: 2)[Reverse Requirements Engineering]
-Beschreibe etablierte Verfahren, Herausforderungen und Best Practices.
+#heading(level: 2)[Requirements Engineering und Reverse Requirements Engineering]
 
-#heading(level: 2)[Legacy-Modernisierung und Governance]
-Analysiere regulatorische, sicherheitsrelevante und organisatorische Aspekte.
+#heading(level: 3)[Begriff und Zielsetzung des Requirements Engineering]
+
+Requirements Engineering (RE) umfasst die systematische Erhebung, Analyse, Spezifikation, Validierung und Verwaltung von Anforderungen an ein System über dessen Lebenszyklus. In Standards und Lehrwerken wird RE als eigenständiger Prozess verstanden, der sowohl fachliche Ziele (z. B. unterstützte Geschäftsprozesse) als auch technische und organisatorische Randbedingungen (z. B. Sicherheitsvorgaben, Betriebsmodelle) in überprüfbare Aussagen überführt @iso29148_2018 @ieee830_1998.
+
+Im Kern adressiert RE zwei Spannungsfelder:
+
+- **Kommunikation zwischen Domäne und Technik:** Anforderungen müssen fachlich verständlich und gleichzeitig so präzise sein, dass sie implementiert, getestet und geändert werden können.
+- **Umgang mit Unsicherheit und Wandel:** Anforderungen sind zu Projektbeginn selten vollständig. RE ist daher nicht nur Dokumentation, sondern ein iterativer Klärungs- und Abstimmungsprozess.
+
+Ein etablierter Ansatz zur Strukturierung heterogener Sichtweisen ist das Viewpoint-Konzept, bei dem Anforderungen aus unterschiedlichen Perspektiven modelliert und anschließend konsolidiert werden @kotonya1996viewpoints. Für die vorliegende Arbeit ist diese Perspektivenorientierung relevant, weil eine Codebasis typischerweise keine expliziten Stakeholder-Sichten enthält, diese aber für eine Migration wieder sichtbar gemacht werden müssen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben).
+
+#heading(level: 3)[Arten von Requirements und Qualitätskriterien]
+
+In der Literatur wird häufig zwischen funktionalen Anforderungen (Was soll das System tun?) und Qualitäts- bzw. nicht-funktionalen Anforderungen (Welche Eigenschaften und Randbedingungen gelten?) unterschieden. Die Praxis zeigt jedoch, dass diese Trennung nicht immer trennscharf ist: Eigenschaften können sowohl als Systemverhalten (z. B. „Audit-Log erzeugen“) als auch als Qualitätsziel (z. B. „Nachvollziehbarkeit“) formuliert werden @glinz2007nfr. Für Reverse Requirements Engineering ist diese Unschärfe besonders relevant, weil Quellcode meist Verhalten konkretisiert, Qualitätsziele aber häufig implizit bleiben (z. B. Performance-Workarounds, Sicherheitsannahmen).
+
+Für die Qualität einzelner Requirements sind in Standards und RE-Forschung wiederkehrende Kriterien etabliert. ISO/IEC/IEEE 29148:2018 nennt unter anderem Eindeutigkeit, Konsistenz, Vollständigkeit, Verifizierbarkeit und Nachvollziehbarkeit als zentrale Eigenschaften. IEEE 830-1998 formuliert ähnliche Prinzipien für Software Requirements Specifications, mit stärkerem Fokus auf Dokumentstruktur und Lesbarkeit @iso29148_2018 @ieee830_1998.
+
+Für die Bewertung von KI-extrahierten Requirements sind drei Kriterien unmittelbar handhabbar:
+
+- **Verifizierbarkeit:** Ein Requirement ist so formuliert, dass eine Testidee oder 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.
+- **Nachvollziehbarkeit (Traceability):** Es ist erkennbar, aus welchem Artefakt (Code, Konfiguration, Datenbank, Ticket, Interview) das Requirement abgeleitet wurde.
+
+Qualitätsanforderungen verdienen im Modernisierungskontext eine gesonderte Betrachtung, weil sie über die reine Funktionsgleichheit hinaus die Zielarchitektur motivieren. #cite(<glinz2008quality>, form: "prose") argumentiert, dass Qualitätsanforderungen risikobasiert und wertorientiert priorisiert werden sollten. Für Legacy-Migrationen ist dies plausibel: Ein „vollständiges“ Requirements-Set ist praktisch schwer erreichbar, gleichzeitig sind bestimmte Quality Requirements (z. B. Datenschutz, Verfügbarkeit, Rollout-Fähigkeit) hochkritisch, weil sie Architekturentscheidungen dominieren.
+
+Für die inhaltliche Strukturierung von Qualitätsanforderungen ist das Qualitätsmodell ISO/IEC 25010:2011 verbreitet, das Qualitätsmerkmale wie Performance-Effizienz, Zuverlässigkeit, Sicherheit oder Wartbarkeit systematisch ordnet. Für Reverse Requirements Engineering ist dies hilfreich, weil aus Code häufig nur Teilaspekte sichtbar werden (z. B. Caching-Mechanismen als Hinweis auf Performance-Annahmen), während andere Qualitätsziele (z. B. „Maintainability“) eher indirekt über Architekturentscheidungen und Entwicklungspraktiken wirksam werden @iso25010_2011.
+
+Die Relevanz sauberer Requirements-Qualität zeigt sich auch in der Risikoperspektive. #cite(<lawrence2001toprisk>, form: "prose") beschreiben Requirements Engineering als primäre Risikozone, wenn Anforderungen unklar, instabil oder unvollständig sind. Für diese Arbeit folgt daraus, dass KI-gestützte Requirements-Extraktion nicht nur „mehr Text“ erzeugen darf, sondern gezielt die Risiken der Unklarheit und der Fehlinterpretation reduzieren muss.
+
+#heading(level: 3)[Spezifikationsformen und Grad der Formalisierung]
+
+Requirements werden in der Praxis in unterschiedlichen Repräsentationsformen dokumentiert. Standards wie IEEE 830-1998 und ISO/IEC/IEEE 29148:2018 fokussieren auf strukturierte Spezifikationen (z. B. SRS) und definieren typische Kapitel (Zweck, Systemkontext, funktionale Anforderungen, Schnittstellen, Qualitätsanforderungen, Annahmen). Daneben existieren weniger formale Formen wie User Stories, Use-Case-Beschreibungen oder Backlog-Einträge, die vor allem in agilen Settings verbreitet sind @ieee830_1998 @iso29148_2018.
+
+Für Reverse Requirements Engineering sind zwei Punkte entscheidend:
+
+- **Form beeinflusst Interpretierbarkeit:** Eine knappe User Story („Als Nutzer möchte ich …“) ist leicht verständlich, transportiert aber selten Randbedingungen, Datenregeln oder Fehlerfälle. Eine SRS-Formulierung kann präziser sein, erfordert aber mehr Kontext und Definitionen.
+- **Grad der Formalisierung beeinflusst Prüfbarkeit:** Je stärker Requirements mit Akzeptanzkriterien, Beispielen oder Messgrößen verknüpft sind, desto einfacher sind Reviews und Tests. #cite(<pohl2010re>, form: "prose") betont Anforderungen-Validierung als eigene Disziplin, die ohne prüfbare Formulierungen methodisch kaum belastbar ist.
+
+Im Kontext dieser Arbeit bietet sich daher ein hybrider Stil an: Requirements werden als kurze, klare Soll-Aussagen formuliert und jeweils um Kontext (Akteur/Prozess), Randbedingungen (Vorbedingungen, Datenobjekte) und mindestens eine Prüfidee ergänzt. LLMs können die sprachliche Konsistenz unterstützen, die notwendige Präzisierung muss jedoch durch Belege und Validierung abgesichert werden.
+
+#heading(level: 3)[Traceability als Verbindung zwischen Code und Requirement]
+
+Traceability bezeichnet die Möglichkeit, Beziehungen zwischen Requirements und anderen Artefakten herzustellen und über den Lebenszyklus zu pflegen. #cite(<gotel1994traceability>, form: "prose") analysieren Traceability als wiederkehrendes Problem, insbesondere dort, wo Artefakte heterogen sind und die Disziplin zur Pflege fehlt. #cite(<ramesh2001traceability>, form: "prose") schlagen Referenzmodelle vor, die Traceability-Typen und -Ziele strukturieren, etwa die Rückverfolgbarkeit zur Begründung (Rationale), zu Designentscheidungen oder zur Evolution eines Requirements.
+
+Für Reverse Requirements Engineering ist Traceability nicht nur ein „Nice-to-have“, sondern eine Sicherheitsmaßnahme:
+
+- **Plausibilisierung:** Ein Requirement lässt sich gegen konkrete Codeausschnitte oder Laufzeitbeobachtungen prüfen.
+- **Abgrenzung:** Es wird klar, ob eine Aussage wirklich aus der Codebasis folgt oder aus Interpretationen und Ergänzungen entsteht.
+- **Änderungsmanagement:** Bei Codeänderungen lässt sich ermitteln, welche Requirements betroffen sein könnten.
+
+In Legacy-Systemen ist Traceability typischerweise fragmentiert: Hinweise finden sich in Commit-Messages, Branch-Namen, Datenbankskripten, Konfigurationsdateien, UI-Texten oder in impliziten Konventionen. Der methodische Anspruch dieser Arbeit besteht daher nicht darin, „perfekte“ Traceability wiederherzustellen, sondern eine minimal belastbare, reproduzierbare Verknüpfung zwischen extrahierten Requirements und Belegen zu etablieren.
+
+#heading(level: 3)[Reverse Engineering und Reverse Requirements Engineering]
+
+Reverse Engineering wird klassisch als Analyseprozess verstanden, der aus einem bestehenden System Wissen über Struktur, Verhalten und Designentscheidungen rekonstruiert. #cite(<chikofsky1990taxonomy>, form: "prose") prägen hierfür eine Taxonomie und grenzen Reverse Engineering von Reengineering sowie Design Recovery ab. Für Requirements-nahe Fragestellungen ist hier relevant, dass Reverse Engineering nicht automatisch „Anforderungen“ liefert, sondern zunächst technische Fakten (z. B. Abhängigkeiten, Datenflüsse, Zustandsautomaten).
+
+Reverse Requirements Engineering (RRE) fokussiert auf die rückwärtsgerichtete Gewinnung von Anforderungen 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?
+- **Rekonstruktion eines Ist-Zustands:** Welche Funktionen und Regeln sind tatsächlich implementiert, unabhängig davon, ob sie intendiert waren?
+
+Gerade im Migrationskontext ist diese Unterscheidung entscheidend. Die Codebasis enthält oft historisch entstandene Workarounds oder kundenspezifische Anpassungen. Diese können fachlich gewollt, technisch opportunistisch oder schlicht „mitgewachsen“ sein. Ohne zusätzliche Validierung besteht das Risiko, dass RRE den Ist-Zustand als Soll-Zustand fehlinterpretiert.
+
+Frühe Ansätze zur Brücke zwischen Reverse Engineering und Requirements liefern beispielsweise #cite(<yu2005retr>, form: "prose") mit „RETR: Reverse Engineering to Requirements“. Der Beitrag betont, dass Requirements-Rückgewinnung eine methodische Kette aus Artefaktsichtung, Strukturierung und Validierung benötigt. In ähnlicher Richtung beschreibt ein requirementsgetriebenes Reengineering-Framework, wie Requirements als Leitplanken für Reengineering-Entscheidungen genutzt werden können @tahvildari2001reengineering.
+
+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 ist 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.
+
+#heading(level: 3)[Typische Methodenkette für Requirements-Rückgewinnung aus Code]
+
+Aus Sicht dieser Arbeit lässt sich Reverse Requirements Engineering in einer Legacy-Codebasis als wiederholbarer Ablauf strukturieren. Die konkrete Ausgestaltung hängt vom System und den verfügbaren Artefakten ab, die grundlegenden Schritte sind jedoch weitgehend stabil:
+
+1. **Scope und Domänenabgrenzung:** Auswahl relevanter Module, Datenobjekte und Prozesse (z. B. Auftragsabwicklung, Fakturierung).
+2. **Artefakterhebung:** Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen, Change-Historie.
+3. **Technische Analyse:** Struktur- und Abhängigkeitsanalyse, Identifikation von Kernkomponenten, Regeln und Integrationspunkten.
+4. **Semantische Interpretation:** Ableitung fachlicher Aussagen aus technischen Implementierungen (z. B. Statusübergänge, Berechtigungsprüfungen).
+5. **Formalisierung als Requirements:** Überführung in klare, testbare Anforderungen mit Kontext (Akteur, Vorbedingung, Ergebnis).
+6. **Traceability-Anreicherung:** Verknüpfung jedes Requirements mit Belegen (Datei, Klasse, Methode, SQL-Statement, UI-String).
+7. **Validierung:** Review durch Fachexperten und Abgleich mit Laufzeitverhalten, Tickets oder Kundenwissen.
+
+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.
+
+Diese Einteilung ist kein Selbstzweck. Sie hilft, Risiken sichtbar zu machen: Requirements, die überwiegend auf Sekundär- oder Kontextbelegen beruhen, sind anfälliger für Fehlinterpretation und sollten priorisiert validiert werden. Gerade in ERP-Systemen sind Datenbankschemata und SQL-Statements häufig besonders aussagekräftig, weil sie Domänenobjekte, Kardinalitäten und Geschäftsregeln (z. B. referentielle Integrität, historisierte Tabellen) sichtbar machen, die in UI- oder Servicecode nur indirekt erscheinen.
+
+Ein weiterer Hebel ist das Mining der Änderungshistorie. Commit-Messages, Diff-Hotspots oder Branch-Konventionen können Hinweise liefern, welche Bereiche besonders volatil sind, welche Kundenvarianten existieren und wo in der Vergangenheit Fehler oder Workarounds eingeführt wurden. Für Reverse Requirements Engineering folgt daraus, dass Requirements nicht nur „aus dem aktuellen Code“, sondern idealerweise auch aus der Evolution des Codes abgeleitet werden, um implizite Stabilitätsannahmen und technische Schulden zu erkennen.
+
+Der kritische Schritt ist die semantische Interpretation. Program Comprehension ist hierfür das methodische Fundament: #cite(<storey2005program>, form: "prose") zeigt, dass Programmverständnis in der Praxis aus einer Kombination von statischer Analyse, Navigation, Visualisierung und Hypothesenbildung besteht. RRE übernimmt diesen kognitiven Prozess, erweitert ihn jedoch um das Ziel, Aussagen als Requirements zu formulieren, die unabhängig vom Code als Spezifikation nutzbar sind.
+
+#heading(level: 3)[Zwischenfazit zu 2.1]
+
+Requirements Engineering liefert Kriterien und Artefaktformen, um Anforderungen präzise, prüfbar und nachvollziehbar zu beschreiben @iso29148_2018 @ieee830_1998. Reverse Requirements Engineering überträgt diese Zielsetzung in einen Kontext, in dem Requirements nicht vorliegen, sondern aus technischen Artefakten rekonstruiert werden. Für die vorliegende Arbeit folgt daraus, dass Automatisierung (z. B. durch KI) nur dann praktikabel ist, wenn Traceability und Validierung als feste Prozessbestandteile mitgeführt werden.
+
+#heading(level: 2)[Large Language Models im Software Engineering]
+
+#heading(level: 3)[Künstliche Intelligenz, Machine Learning und Einordnung von LLMs]
+
+Künstliche Intelligenz (KI) ist ein Oberbegriff für Verfahren, die Aufgaben bearbeiten, die in der Praxis typischerweise kognitive Fähigkeiten erfordern (z. B. Klassifikation, Planung, Sprachverarbeitung). Machine Learning (ML) ist dabei ein Teilgebiet, das Modelle aus Daten lernt, anstatt Regeln vollständig manuell zu spezifizieren. In der gängigen Einordnung wird zwischen überwachtem Lernen (mit Zielwerten), unüberwachtem Lernen (Struktur in Daten) und Reinforcement Learning (Lernen über Rückmeldesignale) unterschieden @bishop2006prml @goodfellow2016dl.
+
+Deep Learning bezeichnet ML-Verfahren, die neuronale Netze mit vielen Parametern und mehreren Verarbeitungsebenen nutzen, um geeignete Repräsentationen aus Rohdaten zu lernen. Charakteristisch ist, dass Merkmalsextraktion und Modellanpassung gemeinsam über Optimierung (typischerweise Gradientenverfahren) erfolgen. #cite(<lecun2015deeplearning>, form: "prose") beschreiben Deep Learning als zentrale Entwicklungslinie moderner KI, insbesondere für Wahrnehmungs- und Sprachaufgaben.
+
+Neuronale Netze lassen sich dabei vereinfacht als parametrisierte Funktionsketten aus Schichten beschreiben, die Eingaben in zunehmend abstrakte Repräsentationen überführen. Das Training erfolgt über eine Zielfunktion (Loss) und Gradientenberechnung, praktisch meist über Backpropagation und Varianten des Gradientenabstiegs @goodfellow2016dl.
+
+#figure(
+  image("../Abbildungen/abb_2_1_feedforward_nn.png", width: 85%),
+  caption: [Schematische Darstellung eines vollständig verbundenen Feedforward-Netzes.]
+)
+
+Ein einzelnes Neuron lässt sich als affine Transformation mit nachgeschalteter Aktivierungsfunktion formulieren:
+
+$
+z = sum_(i=1)^d w_i x_i + b, quad a = phi(z)
+$
+
+Typische Aktivierungsfunktionen sind die Sigmoid-Funktion und ReLU #cite(<goodfellow2016dl>):
+
+$
+sigma(z) = 1 / (1 + e^(-z)), quad ReLU(z) = max(0, z)
+$
+
+#figure(
+  image("../Abbildungen/abb_2_2_aktivierungsfunktionen.png", width: 85%),
+  caption: [Beispielhafte Aktivierungsfunktionen (Sigmoid, tanh, ReLU).]
+)
+
+Die Optimierung erfolgt üblicherweise iterativ. Für Gradientenabstieg gilt in kompakter Form:
+
+$
+theta^(t+1) = theta^(t) - eta nabla_theta cal(L)(theta^(t))
+$
+
+**Abgrenzung neuronaler Netze und LLMs zu anderen ML-Methoden**
+
+Neuronale Netze sind ein Teilbereich von ML, sie ersetzen jedoch nicht automatisch klassische Verfahren. In der Praxis hängt die Methodenauswahl von Datenart, Datenmenge, Interpretierbarkeit und Betriebsvorgaben ab @bishop2006prml @hastie2009esl.
+
+Die folgende Tabelle fasst die Abgrenzung zu häufigen ML-Familien zusammen:
+
+#figure(
+  kind: "table",
+  caption: [Abgrenzung zu häufigen Machine-Learning-Methoden.],
+  table(
+    columns: (1fr, 1.35fr, 1.2fr, 1.6fr),
+    align: (left, left, left, left),
+    [**Methodik**],
+    [**Typischer Einsatz**],
+    [**Stärken**],
+    [**Grenzen**],
+    [Lineare/GLM-Modelle],
+    [Strukturierte Daten, Baselines],
+    [schnell, gut interpretierbar],
+    [begrenzte Nichtlinearität (ohne Feature Engineering)],
+    [Support Vector Machines (SVM)],
+    [Klassifikation/Regression, mittlere Datenmengen],
+    [starke Theorie, robuste Margin-Idee],
+    [Skalierung/Kernelwahl, eingeschränkte Erklärbarkeit @cortes1995svm],
+    [Entscheidungsbäume/Ensembles],
+    [Tabellarische Daten],
+    [nichtlinear, oft gute Performance],
+    [Overfitting ohne Regularisierung; Ensembles weniger interpretierbar],
+    [Random Forests],
+    [Tabellarische Daten, robuste Defaults],
+    [stabil, gute Generalisierung],
+    [begrenzte Extrapolation, Erklärbarkeit indirekt @breiman2001randomforests],
+    [Gradient Boosting],
+    [Tabellarische Daten, hohe Genauigkeit],
+    [sehr starke Praxisleistung],
+    [Hyperparameter-sensitiv, Trainingskosten @friedman2001gbm],
+    [Neuronale Netze (Deep Learning)],
+    [Unstrukturierte Daten (Text, Bild), große Datenmengen],
+    [Representation Learning, End-to-End],
+    [hoher Daten-/Rechenbedarf, schwerer zu erklären @lecun2015deeplearning],
+    [LLMs (Transformers)],
+    [Text- und Codeaufgaben, generative Assistenz],
+    [Vortraining nutzt große Korpora; flexible Transferleistung],
+    [Halluzinationen, Kontextlimit, Governance-Aufwand @vaswani2017attention @ji2023hallucination],
+  )
+)
+
+LLMs unterscheiden sich dabei von vielen klassischen Verfahren nicht nur durch Modellgröße, sondern auch durch Zielsetzung: Häufig wird ein generatives, autoregressives Sprachmodell trainiert, das die nächste Tokenwahrscheinlichkeit modelliert:
+
+$
+max_(theta) sum_(t=1)^T log p_(theta)(x_t mid x_(<t))
+$
+
+Für das Requirements Engineering ist diese Abgrenzung wichtig, weil LLMs aufgrund ihrer generativen Natur Texte produzieren können, die sprachlich konsistent wirken, aber fachlich falsch sein können. Klassische Modelle liefern in solchen Fällen eher „falsche Vorhersagen“, erzeugen jedoch nicht ohne weiteres neue, plausibel klingende Spezifikationen.
+
+Für die Sprachverarbeitung ist der Begriff "Sprachmodell" relevant: Ein Sprachmodell schätzt Wahrscheinlichkeiten über Tokenfolgen und kann dadurch Texte fortsetzen oder bewerten. Large Language Models (LLMs) sind eine Ausprägung solcher Sprachmodelle, die auf Deep-Learning-Architekturen beruhen und auf sehr großen Korpora vortrainiert werden. In der aktuellen Modellgeneration dominiert die Transformer-Architektur, deren Kernprinzip die Self-Attention ist @vaswani2017attention.
+
+Self-Attention lässt sich im Transformer formal als gewichtete Kombination von Value-Vektoren beschreiben, wobei die Gewichte aus Query-Key-Ähnlichkeiten berechnet werden #cite(<vaswani2017attention>):
+
+$
+Attention(Q, K, V) = softmax((Q K^T) / sqrt(d_k)) V
+$
+
+#figure(
+  image("../Abbildungen/abb_2_3_attention_heatmap.png", width: 85%),
+  caption: [Schematisches Beispiel einer Attention-Gewichtsmatrix (illustrativ).]
+)
+
+Für diese Arbeit sind drei Konsequenzen dieser Modellklasse besonders relevant:
+
+- **Kontextfenster:** Modelle verarbeiten Eingaben nur bis zu einer maximalen Tokenanzahl. Längere Artefakte müssen segmentiert oder komprimiert werden.
+- **Tokenisierung:** Quellcode und Fachsprache werden in Token zerlegt. Dies beeinflusst, wie gut Identifier, Struktur und Domänenterminologie repräsentiert werden.
+- **Generativer Charakter:** Ausgaben sind nicht deterministisch. Temperatur, Sampling-Strategien und Promptform beeinflussen Reproduzierbarkeit.
+
+LLMs werden im Software Engineering eingesetzt, weil sie sowohl natürlichsprachliche Artefakte (z. B. Anforderungen, Kommentare) als auch Codeartefakte (z. B. Klassen, Funktionen, Tests) verarbeiten können. Surveyarbeiten ordnen LLM-Anwendungen nach Aufgabenklassen wie Codegenerierung, Codezusammenfassung, Fehlersuche, Testgenerierung oder Dokumentation @fan2023llmse @salem2024surveyllmse @llm4se2024slr @llm4se2024survey.
+
+#heading(level: 3)[Training, Instruction Tuning und Prompting]
+
+LLMs werden typischerweise in mehreren Phasen entwickelt. In einer Vortrainingsphase lernen Modelle aus großen Text- und Codekorpora statistische Regularitäten. Für den Einsatz als Assistenzsysteme werden Modelle häufig zusätzlich auf Anweisungen und Dialogformate ausgerichtet („instruction tuning“). Der GPT-4 Technical Report beschreibt diese Ausrichtung auf Systemebene und diskutiert Safety- und Evaluationsaspekte, ohne die vollständige Trainingspipeline offen zu legen @openai2023gpt4.
+
+Im Engineering-Kontext ist der Prompt damit nicht nur Eingabe, sondern ein Steuerungsinstrument. Für diese Arbeit sind vor allem folgende Hebel relevant:
+
+- **Aufgabenrahmen:** 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?
+- **Ausgabe-Constraints:** Belegpflicht, Kennzeichnung unsicherer Aussagen, deterministische Parameter (z. B. niedrige Temperatur), feste Templates.
+
+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.
+
+Prompting-Strategien wie Chain-of-Thought können die Qualität komplexer Ableitungen verbessern, bergen im Requirements-Kontext jedoch ein Risiko: Längere Begründungen können plausibel wirken und dadurch Fehlannahmen stabilisieren. #cite(<wei2022cot>, form: "prose") zeigen Chain-of-Thought als wirksame Prompttechnik; für diese Arbeit folgt daraus vor allem, dass Begründungen stets mit Artefaktbelegen gekoppelt werden müssen und nicht als eigenständige Evidenz gelten.
+
+#heading(level: 3)[LLMs für Code: Spezialisierung, Stärken und Grenzen]
+
+Neben allgemeinen Modellen existieren code-spezialisierte LLMs, die auf Codekorpora vortrainiert oder nachtrainiert wurden. Ein prominentes Beispiel ist Code Llama, dessen Technical Report Training und Evaluationsaufbau beschreibt und die Ausrichtung auf Codeaufgaben explizit macht @roziere2023codellama. Aus praktischer Sicht sind bei code-spezifischen Modellen typischerweise drei Stärken zu beobachten:
+
+- **Syntaxnahe Mustererkennung:** Wiederkehrende Idiome, Framework-Patterns und typische Kontrollstrukturen werden zuverlässig erkannt.
+- **Semantische Zusammenfassung:** Funktionen und Module lassen sich in natürliche Sprache übertragen, inklusive grober Zweckbeschreibung.
+- **Transformation und Vorschläge:** Refactorings, Testideen oder API-Skizzen können generiert und iterativ verfeinert werden.
+
+Den Stärken stehen systematische Grenzen gegenüber. LLMs „verstehen“ Code nicht im Sinne einer formalen Semantik. Sie approximieren Bedeutung über Muster aus Trainingsdaten und aus dem gegebenen Kontext. Insbesondere in Legacy-Systemen mit proprietären Frameworks, kundenspezifischen Erweiterungen und historisch gewachsenen Konventionen ist die Wahrscheinlichkeit hoch, dass Modelle plausible, aber falsche Erklärungen liefern. Genau diese Plausibilität ist im Requirements-Kontext kritisch, weil Text als Spezifikation eine höhere Autorität erhält als eine rein technische Zusammenfassung.
+
+#heading(level: 3)[Halluzinationen und Verlässlichkeit: Relevanz für Requirements]
+
+Halluzinationen bezeichnen Ausgaben, die syntaktisch korrekt und plausibel wirken, aber nicht durch Eingabedaten oder Weltwissen gedeckt sind. #cite(<ji2023hallucination>, form: "prose") liefern eine Taxonomie und diskutieren Detektions- und Mitigationsansätze. Für Requirements ist die Gefahr besonders kritisch, weil falsche Requirements nicht als „Bug“ im Text auffallen, sondern als scheinbar saubere Spezifikation in nachgelagerte Architektur- und Implementationsentscheidungen einfließen können.
+
+Zusätzlich zu Halluzinationen sind zwei weitere Verlässlichkeitsthemen relevant:
+
+- **Daten- und Domänenbias:** Modelle spiegeln Verteilungen und Annahmen aus Trainingsdaten wider. #cite(<bender2021stochastic>, form: "prose") diskutieren solche Risiken systematisch und betonen Governance-Fragen.
+- **Reproduzierbarkeit:** Kleine Promptänderungen oder Parameterunterschiede können zu variierenden Ergebnissen führen. Für einen engineeringfähigen Prozess sind daher Steuerungsmechanismen (z. B. feste Templates, deterministische Einstellungen, versionierte Prompts) notwendig.
+
+Für diese Arbeit folgt daraus, dass LLM-Ausgaben im Requirements-Kontext nicht als „Quelle“, sondern als Hypothesenmaterial zu behandeln sind. Erst durch Traceability (Belege) und Validierung (Expertenreview, Laufzeitchecks) wird aus einer Hypothese eine belastbare Anforderung.
+
+#heading(level: 3)[LLMs im Requirements Engineering: Stand der Forschung]
+
+Die Forschung zu LLMs im Requirements Engineering ist dynamisch und lässt sich sinnvoll in eine Vorgeschichte (NLP/IR-Ansätze) und in aktuelle LLM-spezifische Arbeiten gliedern. Vor dem breiten Aufkommen von LLMs wurden Aufgaben wie Terminologieextraktion, Klassifikation, Qualitätsprüfung und Traceability häufig mit Natural Language Processing (NLP) und Information Retrieval (IR) adressiert. #cite(<zhao2021nlpre>, form: "prose") geben einen Überblick über NLP-Verfahren im Requirements Engineering, inklusive typischer Problemklassen (z. B. Mehrdeutigkeit, Konsistenz, Vollständigkeit). Für Traceability ist die IR-basierte Link-Recovery-Literatur ein wichtiger Referenzpunkt, weil sie zeigt, welche Artefakte (Requirements, Code, Dokumentation) typischerweise verknüpft werden und welche Evaluationsmuster (Precision/Recall, Gold-Standards) sich etabliert haben @borg2013traceability.
+
+Aktuelle Arbeiten zu LLMs im Requirements Engineering verschieben den Schwerpunkt. Während NLP/IR-Ansätze oft auf klar definierten Teilaufgaben mit begrenzten Ausgaben (Labels, Links, Hinweise) beruhen, können LLMs artefaktnahe Texte erzeugen, umformulieren und strukturieren. Dieser Übergang ist ambivalent: Einerseits entsteht ein direkter Produktivitätshebel, andererseits steigt das Risiko, dass sprachlich "gute" Texte als Spezifikation akzeptiert werden, obwohl die fachliche Basis unzureichend ist @ji2023hallucination @hemmat2025directions.
+
+Systematische Übersichten ordnen die LLM-Nutzung im RE entlang klassischer Prozessschritte ein. #cite(<hemmat2025directions>, form: "prose") fassen Forschungsrichtungen zu LLMs im Software Requirements Engineering zusammen und nennen als wiederkehrende Problemfelder Qualitätssicherung, Nachvollziehbarkeit und Domänenabhängigkeit. Eine weitere Review zum ChatGPT-Einsatz im Requirements Engineering liefern #cite(<marques2024chatgptre>, form: "prose"). Sie diskutieren den Einsatz entlang typischer RE-Aktivitäten (Elicitation, Analyse, Spezifikation, Validierung) und heben als zentrale Herausforderungen inkonsistente Ergebnisse, begrenztes Domänenwissen sowie die Schwierigkeit belastbarer Evaluationen hervor.
+
+In der Detailperspektive lassen sich aktuelle LLM-Arbeiten grob nach Anwendungsfeldern bündeln:
+
+- **Strukturierung und (Re-)Formulierung von Requirements:** #cite(<norheim2024structuring>, form: "prose") untersuchen, wie LLMs naturalsprachliche Anforderungen in strukturiertere Formen überführen können. #cite(<okamoto2025restructuring>, form: "prose") adressieren die automatische Umstrukturierung von Software Requirements Specifications mit dem Ziel, Standardkonformität zu erhöhen.
+- **Qualitätsunterstützung und Defektanalyse:** #cite(<fantechi2023inconsistency>, form: "prose") evaluieren ChatGPT für Inkonsistenzdetektion in naturalsprachlichen Requirements. #cite(<luitel2024completeness>, form: "prose") untersuchen LLM-gestützte Assistenz zur Verbesserung der Requirements-Vollständigkeit.
+- **Elicitation und Stakeholder-Perspektiven:** #cite(<marczak2023humanvalue>, form: "prose") zeigen, wie LLMs zur Generierung wertorientierter User Stories als "Inspirationsimpulse" eingesetzt werden können. Diese Richtung ist für Reverse Requirements Engineering indirekt 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):** #cite(<nouri2024safety>, form: "prose") betrachten LLMs bei der Engineering-Unterstützung von Safety Requirements im Kontext autonomen Fahrens. #cite(<hassani2024legal>, form: "prose") diskutiert LLM-Einsatz für rechtliche Compliance- und Regulationsanalyse. Solche Arbeiten verdeutlichen, dass LLMs nicht nur Text umformulieren, sondern auch Wissensstrukturen (Normen, Regeln) operationalisieren sollen; zugleich erhöhen sich die Anforderungen an Belegbarkeit und Haftung.
+
+Über die einzelnen Studien hinaus ist der Evidenzstand derzeit heterogen. Viele Arbeiten sind als Workshopbeiträge oder "preliminary evaluations" angelegt, nutzen begrenzte Datensätze und kombinieren automatische Metriken mit Expertenurteilen. Zudem sind Prompting-Strategien, Modellversionen und Kontexteinstellungen häufig nicht vollständig standardisiert, was die Reproduzierbarkeit erschwert @fan2023llmse @hemmat2025directions. Aus Sicht dieser Arbeit folgt daraus eine klare Konsequenz: LLMs sind im Requirements Engineering am stärksten als Assistenzsysteme in einem kontrollierten Prozess, in dem (1) Aussagen mit Belegen verknüpft werden, (2) Unsicherheit explizit markiert wird und (3) fachliche Validierung als definierter Kontrollpunkt erfolgt.
+
+Für Reverse Requirements Engineering lässt sich der Nutzen damit präzisieren: LLMs können Kandidaten-Requirements aus großen Artefaktmengen (Code, Kommentare, UI-Strings, Konfiguration) verdichten und in eine konsistente Spezifikationsform überführen. Die fachliche Belastbarkeit entsteht jedoch erst durch Traceability zu Codebelegen und die Validierung durch Experten, insbesondere bei Safety-, Compliance- und Abrechnungslogik.
+
+#heading(level: 3)[Absicherung: Human-in-the-loop, Belege und Prozesskontrollen]
+
+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.
+
+Diese Kontrollen adressieren nicht alle Risiken, reduzieren aber die typischen Fehlerklassen (Halluzination, Überinterpretation, fehlende Konsistenz) und schaffen die Grundlage für eine belastbare Evaluation in Kapitel 6.
+
+#heading(level: 3)[Qualitätsbewertung und Messgrößen im Requirements-Kontext]
+
+Die Qualität von LLM-Ergebnissen wird in vielen Arbeiten über allgemeine Textmetriken oder Task-spezifische Benchmarks bewertet. Für Requirements-Extraktion aus Code sind solche Metriken nur begrenzt aussagekräftig, weil der zentrale Anspruch nicht „sprachliche Ähnlichkeit“, sondern fachliche Korrektheit, Prüfbarkeit und Nachvollziehbarkeit ist @hemmat2025directions @marques2024chatgptre. Eine zweckmäßige Qualitätsbewertung sollte daher an RE-Kriterien anschließen und explizit zwischen drei Ebenen unterscheiden:
+
+- **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.
+
+#heading(level: 3)[Zwischenfazit zu 2.2]
+
+LLMs liefern im Software Engineering eine leistungsfähige Assistenz für Analyse, Zusammenfassung und Textproduktion, sind jedoch nicht verlässlich im Sinne formaler Korrektheit @fan2023llmse @ji2023hallucination. Für Requirements ist der entscheidende Punkt, dass die Qualität nicht an der sprachlichen Glätte, sondern an Nachvollziehbarkeit und Prüfbarkeit hängt. Daraus folgt für diese Arbeit ein designierter "Sicherheitsgurt": Evidence-First, Traceability und Human-in-the-loop sind keine Zusatzoptionen, sondern Kernelemente des Vorgehens.
+
+#heading(level: 2)[Legacy-Modernisierung und Stand der Forschung]
+
+#heading(level: 3)[Charakteristika von Legacy-Systemen]
+
+Legacy-Systeme sind nicht allein durch ihr Alter definiert, sondern durch ihren Kontext: Sie tragen geschäftskritische Funktionen, sind über lange Zeit erweitert worden und weisen oft starke technische und organisatorische Abhängigkeiten auf. #cite(<bisbal1999legacy>, form: "prose") beschreiben typische Merkmale wie enge Kopplung, heterogene Technologien, schwer austauschbare Komponenten und unzureichende Dokumentation. Gerade letzteres ist für Modernisierungsvorhaben problematisch, weil Entscheidungen ohne belastbare Anforderungsbasis zu Funktionsverlusten und Akzeptanzproblemen führen können.
+
+Im ERP-Kontext verschärfen sich diese Merkmale häufig durch:
+
+- **Domänenkomplexität:** Geschäftsregeln sind zahlreich, variantenreich und teilweise kundenspezifisch.
+- **Datenzentrierung:** Prozesse hängen stark von Datenmodellen, Stammdatenqualität und historisch gewachsenen Datenkonventionen ab.
+- **Integrationslast:** Schnittstellen zu Drittsystemen (z. B. Buchhaltung, Shop, Dokumentenmanagement) sind über Jahre organisch entstanden.
+
+Damit wird nachvollziehbar, warum Requirements-Extraktion aus der Codebasis nicht nur ein Dokumentationsprojekt, sondern ein Risikoreduktionsinstrument für Migrationen ist.
+
+#heading(level: 3)[Modernisierungsstrategien und Reengineering als Prozess]
+
+Modernisierung kann unterschiedliche Strategien annehmen, von "Lift-and-Shift" bis zur vollständigen Neuimplementierung. Die Literatur betont wiederholt, dass die Wahl einer Strategie von Risiko, Zielarchitektur und verfügbaren Ressourcen abhängt und daher explizit geplant werden sollte @sneed1995planning. Eine zentrale Aussage ist dabei, dass Reengineering nicht als rein technischer Umbau verstanden werden kann: Ohne fachliche Leitplanken entstehen technische Verbesserungen, die am Bedarf vorbeilaufen oder bestehende Fachlogik unabsichtlich verändern.
+
+Aus Sicht dieser Arbeit lassen sich Modernisierungsstrategien pragmatisch entlang zweier Achsen einordnen: (1) Wie stark wird die bestehende Implementierung weitergenutzt? (2) Wie stark wird die Zielarchitektur verändert? Daraus ergeben sich typische Strategietypen, die in der Praxis auch kombiniert auftreten:
+
+- **Weiterbetrieb mit Hülle (Wrapping):** Die Legacy-Logik bleibt bestehen, wird aber über neue Schnittstellen oder UI-Schichten zugänglich gemacht. Vorteil ist geringe Eingriffstiefe; Nachteil ist, dass technische Schulden und Engpässe erhalten bleiben.
+- **Schrittweise Modularisierung:** Teile der Legacy-Anwendung werden sukzessive in neue Komponenten überführt, während andere Teile weiterlaufen. Vorteil ist Risikostreuung und frühe Nutzenrealisierung; Nachteil ist erhöhte Integrationskomplexität während der Übergangsphase.
+- **Reengineering/Refactoring:** Die bestehende Logik wird strukturell überarbeitet (z. B. Entkopplung, Schichten, bessere Testbarkeit), ohne den Funktionsumfang grundsätzlich zu verändern. Vorteil ist bessere Wartbarkeit; Nachteil ist hoher Analyseaufwand, gerade ohne Requirementsbasis.
+- **Neuimplementierung mit Funktionsparität:** Die Legacy-Logik wird auf neuer Technologie nachgebaut, häufig mit dem Anspruch, zunächst funktional äquivalent zu sein. Vorteil ist saubere Zielarchitektur; Nachteil ist die hohe Abhängigkeit von vollständigen, korrekten Requirements.
+
+Für ERP-Systeme ist die Wahl einer Strategie stark datengetrieben. Datenmodelle, Schnittstellenverträge und Buchungslogik definieren die „harten Kanten“ einer Migration. Damit steigt der Stellenwert von Requirements, die Datenobjekte, Zustandsmodelle und Integrationspunkte explizit machen. Besonders migrationskritisch sind dabei Anforderungen, die in der Legacy-Implementierung als implizite Konvention existieren (z. B. Statuscodes, historische Sonderfälle, kundenspezifische Maskenlogik), weil sie ohne gezielte Extraktion und Validierung leicht verloren gehen.
+
+#cite(<bisbal1997overview>, form: "prose") geben einen Überblick über Migrationsansätze und ordnen typische Risikofelder ein, darunter Datenmigration, Funktionsäquivalenz und organisatorische Abhängigkeiten. #cite(<wu1997toolkit>, form: "prose") argumentieren ergänzend, dass Werkzeugunterstützung nur dann wirksam ist, wenn sie in eine methodische Kette eingebettet ist. Diese Argumentation ist direkt anschlussfähig an KI-gestützte Verfahren: Auch LLM-basierte Automatisierung entfaltet Nutzen nur innerhalb eines reproduzierbaren Prozesses mit klaren Kontrollpunkten.
+
+#heading(level: 3)[Zielarchitekturen: Web, Cloud und „Cloud-native“]
+
+Die Modernisierung vieler Legacy-Anwendungen zielt auf webbasierte, plattformunabhängige Oberflächen und auf Betriebsmodelle, die Skalierung, automatisiertes Deployment und schnelle Iteration unterstützen. #cite(<kratzke2017cloudnative>, form: "prose") fassen in einer systematischen Mapping Study zusammen, welche Merkmale cloud-nativer Anwendungen in der Forschung und Praxis wiederkehren. Dazu zählen typischerweise automatisierte Bereitstellung, resiliente Komponenten, horizontale Skalierung und eine stärkere Trennung von Build- und Run-Umgebungen.
+
+Im selben Zielraum werden Microservices häufig als Architekturstil diskutiert. #cite(<pahl2016microservices>, form: "prose") kartieren Forschung zu Microservices und zeigen wiederkehrende Problemfelder, unter anderem die Wahl der richtigen Servicegranularität, die erhöhte Komplexität im Betrieb und Anforderungen an Observability. Für Migrationsprojekte ist daraus eine pragmatische Schlussfolgerung ableitbar: Modularisierung ist ein Ziel, erzeugt aber zugleich neue Anforderungen (z. B. Deployment-Pipelines, Monitoring, Sicherheitskonzepte), die im Requirements-Set sichtbar sein müssen.
+
+Für die Requirementsarbeit bedeutet die Zielarchitekturverschiebung eine Verschiebung des Schwerpunktes: Während in klassischen Client/Server-Architekturen die fachliche Funktionslogik oft dominiert, rücken in Web- und Cloud-Kontexten betriebliche und sicherheitsbezogene Qualitätsmerkmale 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.
+
+Diese Merkmale sind nicht neu, ihre Sichtbarkeit im Projekt nimmt jedoch zu, weil Cloud- und Webbetrieb ein engeres Zusammenspiel von Entwicklung und Betrieb erzwingt. Für Reverse Requirements Engineering folgt daraus, dass der Blick auf die Legacy-Codebasis systematisch um Betriebs- und Sicherheitsanforderungen ergänzt werden muss, auch wenn diese im Code nur indirekt sichtbar sind (z. B. über Deployment-Skripte, Konfigurationen, Logging-Policies oder Rechteprüfungen).
+
+Sicherheitsanforderungen werden in Cloud-Migrationskontexten häufig unterschätzt. Eine systematische Mapping Study zu Security-Aspekten bei Legacy-to-Cloud-Migrationen @security2014legacycloud zeigt, dass Identitätsmanagement, Datenflusskontrolle und Compliance wiederkehrende Kernprobleme sind. Für diese Arbeit bedeutet dies, dass Requirements-Extraktion aus Code um Sicherheits- und Datenschutzanforderungen ergänzt werden muss, da sie nicht in jedem Quellcodefragment explizit sichtbar sind.
+
+#heading(level: 3)[Stand der Forschung: KI-Unterstützung in Modernisierungsvorhaben]
+
+Die Forschung zu KI- bzw. LLM-Unterstützung im Modernisierungskontext ist im Vergleich zu klassischen Reengineering-Ansätzen jünger. Die Übersichten zu LLM4SE @fan2023llmse @llm4se2024slr zeigen, dass ein Teil der Arbeiten auf Codeverständnis, Dokumentation und Artefakttransformation zielt. Spezifisch für Requirements Engineering bündeln Reviews und SLRs erste Evidenz und Forschungsrichtungen @marques2024chatgptre @hemmat2025directions.
+
+Aus dieser Literatur lassen sich zwei robuste Aussagen ableiten:
+
+- **LLMs sind besonders stark in der Strukturierung und sprachlichen Formulierung**, also dort, wo aus fragmentierten Hinweisen ein konsistenter Text entstehen muss.
+- **LLMs benötigen technische und organisatorische Sicherungen**, wenn Ergebnisse als Entscheidungsgrundlage in Migrationen dienen sollen (z. B. Belege, Review, reproduzierbarer Prozess).
+
+Damit ist eine zentrale Motivation dieser Arbeit begründet: Eine Legacy-Modernisierung benötigt belastbare Requirements, die im Legacy-Kontext oft fehlen. LLMs sind als Assistenz zur Rekonstruktion naheliegend, müssen jedoch methodisch so eingesetzt werden, dass Verlässlichkeit und Nachvollziehbarkeit systematisch erhöht werden.
+
+#heading(level: 3)[Zwischenfazit zu 2.3]
+
+Legacy-Modernisierung ist ein sozio-technisches Vorhaben, das technische Umbauten und fachliche Zielsetzungen integrieren muss @bisbal1999legacy @sneed1995planning. Moderne Zielarchitekturen (Web/Cloud) verschieben zudem die Anforderungslandschaft, weil Betriebs- und Sicherheitsanforderungen stärker in den Vordergrund treten @kratzke2017cloudnative @security2014legacycloud. Für die vorliegende Arbeit folgt daraus, dass Requirements-Extraktion nicht nur der Funktionsrekonstruktion dient, sondern die Grundlage für Migrationsentscheidungen, Priorisierung und Qualitätssicherung bildet.
+
+#heading(level: 3)[Kapitelzusammenfassung und Anschluss]
+
+Die drei Themenblöcke dieses Kapitels greifen ineinander. Requirements Engineering liefert Kriterien, um Anforderungen prüfbar und nachvollziehbar zu formulieren @iso29148_2018. Reverse Requirements Engineering überträgt diese Kriterien in einen Kontext, in dem Anforderungen aus bestehenden Artefakten rekonstruiert werden müssen @chikofsky1990taxonomy @yu2005retr. Large Language Models können diese Rekonstruktion unterstützen, sind aber fehleranfällig und benötigen Prozesskontrollen, vor allem gegen Halluzinationen und Überinterpretation @ji2023hallucination @fan2023llmse. Legacy-Modernisierung schließlich liefert die praktische Motivation und zeigt, warum eine belastbare Anforderungsbasis migrationskritisch ist @bisbal1999legacy @sneed1995planning.
+
+Damit ist das Fundament gelegt, um in Kapitel 3 den konkreten Fallkontext zu beschreiben und in Kapitel 4 ein Vorgehensmodell zu entwickeln, das KI-Unterstützung, Traceability und Validierung systematisch miteinander verbindet.

Kapitel/03_fallstudie.typ

@@ -0,0 +1,5 @@
+#heading(level: 1)[Fallstudie c-entron GmbH (ca. 6 Seiten)]
+
+#heading(level: 2)[Unternehmenskontext und Legacy-Software]
+
+#heading(level: 2)[Migrationsstrategie und spezifische Herausforderungen]

Kapitel/04_konzeption_methodisches_vorgehen.typ

@@ -1,10 +1,13 @@
-#heading(level: 1)[Methodisches Vorgehen]
+#heading(level: 1)[Konzeption und methodisches Vorgehen (ca. 12 Seiten)]
 
 #heading(level: 2)[Forschungsdesign und Vorgehensmodell]
 Verbinde Literaturrecherche, Technologieevaluation und Interviews in einem konsistenten Design.
 
+#heading(level: 2)[Prozessmodell für KI-gestütztes Reverse Requirements Engineering]
+Skizziere Phasen, Rollen und Kontrollpunkte für einen reproduzierbaren Analyse-Workflow.
+
 #heading(level: 2)[Technologieauswahl und LLM-Konfiguration]
 Dokumentiere Kriterien, Modellwahl und Evaluationsschritte.
 
-#heading(level: 2)[Datengrundlage und Stakeholder-Einbindung]
+#heading(level: 2)[Stakeholder-Einbindung und Datengrundlage]
 Beschreibe Datenquellen, Interviewleitfäden und Validierungsworkshops.

Kapitel/04_prototypische_umsetzung.typ

@@ -6,5 +6,4 @@ Skizziere die Komponenten, Interaktionsabläufe und Traceability-Konzepte.
 #heading(level: 2)[Toolchain-Integration]
 Bewerte die Einbindung in bestehende Systeme (z. B. Jira, Confluence).
 
-#heading(level: 2)[Governance, Datenschutz und IP]
-Dokumentiere Maßnahmen zur Sicherstellung von Compliance.
+

Kapitel/05_evaluation.typ

@@ -1,10 +0,0 @@
-#heading(level: 1)[Evaluation]
-
-#heading(level: 2)[Evaluationskriterien und Messgrößen]
-Beschreibe Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Stakeholder-Alignment und Aufwandsreduktion.
-
-#heading(level: 2)[Durchführung der Evaluation]
-Erläutere Messaufbau, Workshop-Design und Datenauswertung.
-
-#heading(level: 2)[Ergebnisse]
-Stelle die Resultate der Qualitätsbewertung zusammen.

Kapitel/05_prototypische_umsetzung.typ

@@ -0,0 +1,10 @@
+#heading(level: 1)[Prototypische Umsetzung (ca. 10 Seiten)]
+
+#heading(level: 2)[Architektur des LLM-Agenten]
+Skizziere die Komponenten, Interaktionsabläufe und Traceability-Konzepte.
+
+#heading(level: 2)[Toolchain-Integration]
+Bewerte die Einbindung in bestehende Systeme (z. B. Jira, Confluence).
+
+#heading(level: 2)[Governance, Datenschutz und IP]
+Dokumentiere Maßnahmen zur Sicherstellung von Compliance.

Kapitel/06_evaluation.typ

@@ -0,0 +1,10 @@
+#heading(level: 1)[Evaluation (ca. 12 Seiten)]
+
+#heading(level: 2)[Evaluationskriterien und Messgrößen]
+Beschreibe Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Stakeholder-Alignment und Aufwandsreduktion.
+
+#heading(level: 2)[Durchführung und Ergebnisse]
+Erläutere Messaufbau, Workshop-Design, Datenauswertung und die wichtigsten Resultate.
+
+#heading(level: 2)[Qualitative Bewertung durch Experten]
+Fasse Feedback, Einschätzungen und offene Punkte aus den Experteninterviews zusammen.

Kapitel/07_diskussion.typ

@@ -1,4 +1,4 @@
-#heading(level: 1)[Diskussion]
+#heading(level: 1)[Diskussion (ca. 8 Seiten)]
 
 #heading(level: 2)[Interpretation der Ergebnisse]
 Vergleiche die Evaluation mit den Forschungsleitfragen.

Kapitel/07_fazit_ausblick.typ

@@ -1,10 +0,0 @@
-#heading(level: 1)[Fazit und Ausblick]
-
-#heading(level: 2)[Zusammenfassung der Arbeit]
-Fasse die wichtigsten Erkenntnisse zusammen.
-
-#heading(level: 2)[Ausblick]
-Zeige zukünftige Forschungsschwerpunkte und Weiterentwicklungsmöglichkeiten des Prototyps.
-
-#heading(level: 2)[Handlungsempfehlungen]
-Formuliere konkrete nächste Schritte für die c-entron GmbH.

Kapitel/08_fazit_ausblick.typ

@@ -0,0 +1,10 @@
+#heading(level: 1)[Fazit und Ausblick (ca. 4 Seiten)]
+
+#heading(level: 2)[Zusammenfassung und Beantwortung der Forschungsfragen]
+Fasse die wichtigsten Erkenntnisse zusammen und beantworte die Leitfragen.
+
+#heading(level: 2)[Handlungsempfehlungen für c-entron GmbH]
+Formuliere konkrete nächste Schritte für die c-entron GmbH.
+
+#heading(level: 2)[Ausblick und zukünftige Forschung]
+Zeige zukünftige Forschungsschwerpunkte und Weiterentwicklungsmöglichkeiten des Prototyps.

Kapitel/08_literaturverzeichnis.typ

@@ -1,2 +0,0 @@
-#heading(level: 1)[Literaturverzeichnis]
-Ergänze hier das automatisch generierte Literaturverzeichnis.

Kapitel/09_literaturverzeichnis.typ

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

Kapitel/10_anhang.typ

@@ -1,4 +1,4 @@
-#heading(level: 1)[Anhang]
+#heading(level: 1)[Anhang (ca. 6 Seiten)]
 
 #heading(level: 2)[Interviewleitfäden]
 

Masterarbeit_draft.typ

@@ -27,6 +27,8 @@
 
 #(thesis.body_show)()
 
+#set cite(style: "apa")
+
 #(thesis.body_content)([
   #set page(numbering: "1")
   #counter(page).update(1)  
@@ -37,11 +39,12 @@
   #include "Kapitel/00_abstract.typ"
   #include "Kapitel/01_einleitung.typ"
   #include "Kapitel/02_theoretischer_hintergrund.typ"
-  #include "Kapitel/03_methodisches_vorgehen.typ"
-  #include "Kapitel/04_prototypische_umsetzung.typ"
-  #include "Kapitel/05_evaluation.typ"
-  #include "Kapitel/06_diskussion.typ"
-  #include "Kapitel/07_fazit_ausblick.typ"
-  #include "Kapitel/08_literaturverzeichnis.typ"
-  #include "Kapitel/09_anhang.typ"
+  #include "Kapitel/03_fallstudie.typ"
+  #include "Kapitel/04_konzeption_methodisches_vorgehen.typ"
+  #include "Kapitel/05_prototypische_umsetzung.typ"
+  #include "Kapitel/06_evaluation.typ"
+  #include "Kapitel/07_diskussion.typ"
+  #include "Kapitel/08_fazit_ausblick.typ"
+  #include "Kapitel/09_literaturverzeichnis.typ"
+  #include "Kapitel/10_anhang.typ"
 ])

Perplexity_1_Lab.md

@@ -0,0 +1,144 @@
+<img src="https://r2cdn.perplexity.ai/pplx-full-logo-primary-dark%402x.png" style="height:64px;margin-right:32px"/>
+
+# Zusammenfassung der angegebenen und weiterer wissenschaftlicher Quellen zum Requirements Engineering (RE) und KI im Softwarekontext
+
+## Zentrale Erkenntnisse im Überblick
+
+**Requirements Engineering** im Kontext von künstlicher Intelligenz (KI), insbesondere Machine Learning (ML), ist ein hochdynamisches Forschungsfeld mit wachsender praktischer Relevanz. Die zunehmende Komplexität, Unsicherheit und mangelnde Erklärbarkeit von KI-Systemen stellt das klassische RE vor neue, grundlegende Herausforderungen, etwa bei der Spezifikation, Nachvollziehbarkeit und Validierung von Anforderungen. Die aktuelle Forschung betont deutliche Unterschiede zwischen RE für klassische IT-Systeme und KI-gestützte Lösungen – insbesondere bezüglich ethischer, nicht-funktionaler und datengetriebener Aspekte. Fortschrittliche Ansätze kombinieren klassische RE-Techniken mit KI-gestützten Tools, Natural Language Processing und explizit auf ML zugeschnittenen Frameworks. Dennoch bestehen weiterhin erhebliche offene Forschungsfragen und Validierungsbedarf, insbesondere in industriellen Kontexten.[^1][^2][^3][^4][^5][^6]
+
+***
+
+## 1. Zusammenfassung: Verwendete Literatur in der Masterarbeit
+
+Die Literaturbasis Ihrer Masterarbeit erstreckt sich über Schlüsselquellen zu klassischen und KI-gestützten RE-Methoden. Dazu gehören:[^7]
+
+- **Handbuch- und Überblickswerke** (z.B. „The Encyclopedia of Human-Computer Interaction“): Sie bieten eine Einführung in grundlegende RE-Prinzipien, gängige Methoden sowie Best Practices in der Anforderungserhebung, -spezifikation und -validierung bei klassischer Softwareentwicklung.
+- **Aktuelle arXiv-Preprints und Konferenzartikel**: Sie diskutieren neueste Forschungsfragen, insbesondere zum Einsatz von LLMs (Large Language Models) für das Reverse Requirements Engineering bei Legacy-Software und zeigen, wie KI-basierte Analyse das RE fundamental verändert.[^8]
+- **Literatur zu Stakeholder-Integration und Traceability**: Diese Beiträge thematisieren die Herausforderung, implizites und Expertenwissen aus Legacy-Systemen systematisch zu dokumentieren sowie die Rückverfolgbarkeit von Anforderungen zu gewährleisten.
+
+Die genannten Quellen repräsentieren den State-of-the-Art und bilden die methodologische sowie inhaltliche Grundlage, um klassische RE-Verfahren mit KI-zentrierten Ansätzen zu verknüpfen.[^7][^8]
+
+***
+
+## 2. Stand der Forschung: Requirements Engineering und KI
+
+### 2.1 Systematische Übersichtsarbeiten \& Forschungsüberblick
+
+Aktuelle Mapping- und Tertiärstudien analysieren die Entwicklung, Herausforderungen und Trends von RE im KI-Kontext:
+
+- **Habiba et al. (2024)**:[^2]
+Die systematische Mapping-Studie basiert auf 126 Arbeiten (2010-2023) und identifiziert, dass die Forschungsaktivitäten insbesondere bei der Anforderungsanalyse und -erhebung liegen. Spezifische Herausforderungen sind die mangelnde Spezifizierbarkeit, Erklärbarkeit, Unsicherheiten im Systemverhalten und die Integration ethischer wie rechtlicher Anforderungen. Die Autoren schlagen explizit neue RE-Praktiken für KI/ML-Systeme vor und fordern Validierungsmethoden, um nicht-funktionale Anforderungen wie Fairness, Transparenz und Sicherheit berücksichtigen zu können.
+- **Martins et al. (2025) – Journal of Software Engineering Research and Development**:[^3]
+Diese Tertiärstudie synthetisiert Sekundärstudien zum RE für ML-basierte Systeme. Sie stellt fest, dass zwar zahlreiche Methoden zur Anforderungserhebung, -analyse, -spezifikation und -validierung existieren, jedoch vor allem die nicht-funktionalen Anforderungen, Stakeholder-Kollaboration und die Forschung in industriellen Umgebungen weiterhin große Herausforderungen darstellen.
+- **Mehraj et al. (2024) – REFSQ Konferenz**:[^9][^10]
+Die Autoren analysieren in ihrer Tertiärstudie 28 Sekundärarbeiten (2017–2023) und beobachten eine Zunahme von LLM-basierten Werkzeugen im RE und eine Tendenz, NLP mit ML-Ansätzen (z.B. LDA, Naive Bayes) zu kombinieren. Sie sehen jedoch weiterhin zentrale Herausforderungen bei Ambiguität, Sprachverarbeitung, Datenqualität, Algorithmen und Evaluation.
+
+
+### 2.2 Aktuelle Anwendung und industrielle Perspektiven
+
+- In der industriellen Praxis kommt der Einsatz von KI vor allem als **kollaborativer Partner** („Human-AI Collaboration“, HAIC) zum Tragen, wobei rein automatisierte RE-Prozesse noch kritisch gesehen werden. KI unterstützt dabei vor allem Analyse, Priorisierung und Validierung, während die vollständige Automatisierung wegen Unsicherheiten, Compliance und fehlendem Domänenwissen auf Skepsis stößt.[^4][^11]
+- Studien belegen, dass durch den Einsatz von KI-Tools in der Anforderungsphase Fehlerquoten um 20–30% und Projektlaufzeiten um bis zu 20% reduziert werden können, sofern Stakeholder frühzeitig und kontinuierlich eingebunden werden.[^1]
+
+***
+
+## 3. Schwerpunkte \& Herausforderungen im KI-zentrierten Requirements Engineering
+
+### 3.1 Neue Formen und Qualitäten von Anforderungen
+
+- **Erklärbarkeit (Explainability):** KI-Systeme erfordern nachvollziehbare Entscheidungen und teilweise personalisierte Erklärungen für verschiedene Stakeholder – ein Aspekt, der in klassischen RE-Methoden kaum ausgeprägt ist.[^2][^3]
+- **Nicht-funktionale Anforderungen:** Fairness, Transparenz, Datenschutz und Sicherheit werden zu zentralen Qualitätsmerkmalen – ihre Spezifikation ist aber unscharf und schwer zu prüfen.[^12][^2]
+- **Datenqualität und -management:** ML-Systeme benötigen Anforderungen an Trainings-, Validierungs- und Betriebsdaten – ein Aspekt, der systematisch erst in neueren RE-Methodiken verankert ist.[^12][^2]
+
+
+### 3.2 Menschliche und organisatorische Faktoren
+
+- **Gap zwischen ML-Entwicklern und Fachanwendern:** Fehlendes gemeinsames Vokabular und Wissensaustausch führen zu Kommunikationsproblemen und erhöhen die Gefahr für fehlerhafte, wenig akzeptierte Systeme. Die Forschung fordert kollaborative, multidisziplinäre Ansätze.[^4][^2]
+- **Stakeholder-Integration:** Die Einbindung von Stakeholdern in iterativen, flexiblen Prozessen (z.B. durch Interviews und Workshops) gewinnt im Vergleich zu Wasserfallmodellen deutlich an Bedeutung.[^3][^2][^12]
+
+
+### 3.3 Neue Methoden, Tools \& Frameworks
+
+- **LLMs und Prompt Engineering:** Neue Ansätze integrieren LLMs zur automatischen Extraktion und Analyse von Anforderungen. Genannt werden Prompt-Strategien, Evidence-based Guidelines und hybride Validierungsansätze (menschlich/automatisiert), um die Zuverlässigkeit von LLM-unterstützten RE-Prozessen zu steigern.[^6]
+- **Frameworks wie LangChain und RAG:** Sie dienen zur Orchestrierung von modularen, sicheren KI-Workflows vor allem im Bereich der dynamischen Datumseinbindung und komplexen Validierung.[^6]
+
+***
+
+## 4. Aktuelle Herausforderungen und Forschungsbedarf
+
+- **Empirische Validierung:** Es fehlen groß angelegte Feldstudien und Benchmark-Datensätze, um die Wirksamkeit neuer RE-Methoden und KI-Tools unabhängig und reproduzierbar zu validieren.[^2][^6]
+- **Automatisierte und hybride Evaluationspipelines:** Bedingt durch die Limitationen von LLMs (Halluzinationen, Domänenwissen, Output-Qualität) ist eine stärkere Integration menschlicher Plausibilitätsprüfungen notwendig.[^6]
+- **Regulatorik und Ethik:** Zunehmende Regularien (z.B. ISO/IEC 42001) und gesellschaftliche Erwartungen verlangen die Integration von Compliance-, Ethik- und Nachhaltigkeitsaspekten bereits ab der Anforderungsphase.[^12][^2]
+
+***
+
+## 5. Literaturhinweise / Wichtigste Quellen (Beispiele)
+
+1. https://ijasce.org/index.php/IJASCE/article/view/152
+2. https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/requirements-engineering
+3. https://www.medienstuermer.de/blog/requirements-engineering-2024-moderne-ansaetze-fuer-komplexe-it-projekte/[^1]
+4. Habiba, U.-e., Haug, M., Bogner, J., \& Wagner, S. (2024): How mature is requirements engineering for AI-based systems? *Requirements Engineering*. https://doi.org/10.1007/s00766-024-00432-3[^13][^2]
+5. Martins, M.C. et al. (2025): Requirements Engineering for Machine Learning-Based AI Systems: A Tertiary Study. *Journal of Software Engineering Research and Development*, 13(2). https://doi.org/10.5753/jserd.2025.4892[^3]
+6. https://www.serview.de/detail/requirements-engineering-in-der-ki-welt-worauf-es-ankommt[^12]
+7. Lekshmi Murali Rani, R.B. Svensson, R. Feldt (2025): AI for Requirements Engineering: Industry adoption and Practitioner perspectives. arXiv:2511.01324[^11][^4]
+8. https://www.sciencedirect.com/science/article/abs/pii/S0950584923000307[^5]
+9. https://2024.refsq.org/details/refsq-2024-papers/9/A-tertiary-study-on-AI-for-Requirements-Engineering[^9]
+10. https://researchportal.tuni.fi/en/publications/a-tertiary-study-onai-forrequirements-engineering/[^10]
+11. Ebrahim, M. et al. (2025): Enhancing Software Requirements Engineering with Language Models and Prompting Techniques. Proceedings of ACL SRW 2025, 486–496. https://aclanthology.org/2025.acl-srw.31.pdf[^6]
+
+***
+
+## Fazit
+
+**Requirements Engineering im Zeitalter der KI** ist kein evolutionäres Randthema, sondern verlangt einen Paradigmenwechsel in Methodik, Stakeholder-Einbindung und Tooling. Künftig müssen Ethik, Erklärbarkeit, Daten- und Modellqualität sowie regulatorische Anforderungen systematisch von Beginn an in den RE-Prozess integriert werden. Kollaborative, Mensch-zentrierte Prozesse, hybride Prompting-Strategien und empirisch validierte Frameworks werden für die erfolgreiche Entwicklung zukunftsfähiger Softwarelösungen mit KI immer wichtiger.[^4][^2][^3][^6]
+
+***
+
+Bei Bedarf können weitere ausgewählte Literaturquellen oder Fachartikel zu spezifischen Teilaspekten (z.B. Prompt Engineering, Explainability, Compliance) ergänzt werden.
+<span style="display:none">[^14][^15][^16][^17][^18][^19][^20][^21][^22]</span>
+
+<div align="center">⁂</div>
+
+[^1]: https://www.medienstuermer.de/blog/requirements-engineering-2024-moderne-ansaetze-fuer-komplexe-it-projekte/
+
+[^2]: https://mediatum.ub.tum.de/doc/1760059/6csttge2qwhb788cspl40xrvu.umm2024a.pdf
+
+[^3]: https://journals-sol.sbc.org.br/index.php/jserd/article/view/4892
+
+[^4]: https://arxiv.org/pdf/2511.01324.pdf
+
+[^5]: https://www.sciencedirect.com/science/article/abs/pii/S0950584923000307
+
+[^6]: https://aclanthology.org/2025.acl-srw.31.pdf
+
+[^7]: Quellen.md
+
+[^8]: Masterarbeit_draft.pdf
+
+[^9]: https://2024.refsq.org/details/refsq-2024-papers/9/A-tertiary-study-on-AI-for-Requirements-Engineering
+
+[^10]: https://researchportal.tuni.fi/en/publications/a-tertiary-study-onai-forrequirements-engineering/
+
+[^11]: https://arxiv.org/abs/2511.01324
+
+[^12]: https://www.serview.de/detail/requirements-engineering-in-der-ki-welt-worauf-es-ankommt
+
+[^13]: https://elib.uni-stuttgart.de/items/16f684d7-ee74-4321-aa95-f0c56e27c60c
+
+[^14]: https://www.fortiss.org/forschung/kompetenzfelder/detail/requirements-engineering
+
+[^15]: https://app.ch/blog/richtlinien-fuer-effektives-ki-prompting-im-requirements-engineering
+
+[^16]: https://onlinelibrary.wiley.com/doi/10.1002/spe.70029?af=R
+
+[^17]: https://www.se-trends.de/2024-ki-umfrage/
+
+[^18]: https://www.adesso.de/de/news/blog/requirements-engineering-fuer-ki-projekte-anforderungen-an-die-summarization-aufnehmen.jsp
+
+[^19]: https://dl.acm.org/doi/10.1145/3701625.3701686
+
+[^20]: https://www.arbeitswissenschaft.net/angebote-produkte/publikationen/veroeffentlichungen-2024
+
+[^21]: https://ieeexplore.ieee.org/document/10877072/
+
+[^22]: https://entwickler.de/digitale-transformation/die-anwendung-von-ki-im-requirements-engineering
+

Perplexity_1_Research.md

@@ -0,0 +1,484 @@
+<img src="https://r2cdn.perplexity.ai/pplx-full-logo-primary-dark%402x.png" style="height:64px;margin-right:32px"/>
+
+# Lies die anghängten Dateien. Diese sind teil meiner Masterarbeit. ERstelle jetzt under disem Kontext eine Zusammenfassung der angegebenen Quellen. Suche danach nach weiteren aktuellen Quellen die mit den Themen (Requirements Engineering für Software und im zusammenhang mit Ki) stehen. ERstelle mir auch hier eine Zusammenfassung der Artikel die du gefdunen hast.
+
+Wichtig!! Es geht hier um wissenschaftliches Arbeiten. Konzentriere dich auf wissenschaftliche Artikel und Quellen. Und bitte gib auch die Quellen immer mit an
+ERstelle mir einen ausführlichen Report
+
+Ich habe die angehängten Dateien analysiert und mehrere aktuelle wissenschaftliche Quellen zu Requirements Engineering und KI gefunden. Die Masterarbeit befasst sich mit "KI-gestütztem Reverse Requirements Engineering bei Legacy-Software" mit Fokus auf die c-entron GmbH.
+
+Die Informationen sind primär textlich und konzeptionell, sodass eine tabellarische Zusammenfassung der Quellen und deren Relevanz sinnvoll ist.
+
+# Wissenschaftliche Quellenanalyse: Requirements Engineering und KI-gestützte Systeme
+
+## Zusammenfassung der bestehenden Quellen aus Ihren Dateien
+
+Basierend auf der Analyse Ihrer Masterarbeitsdateien haben Sie bereits folgende Kernquellen identifiziert:
+
+### 1. **Requirements Engineering Fundamentals**
+
+Die Encyclopedia of Human-Computer Interaction (HCI) bietet eine grundlegende Ressource zu Requirements Engineering als strukturierte Disziplin. Dieses Werk behandelt klassische RE-Prozesse, Elicitierungstechniken und Best Practices, die als theoretische Grundlage für Ihre Arbeit essentiell sind.[^1]
+
+### 2. **Reverse Engineering und Legacy-Systeme**
+
+Die International Journal of Advances in Software and Computer Engineering (IJASCE) enthält Forschungen zu automatisierten Ansätzen bei der Anforderungsextraktion aus bestehenden Systemen. Dies bildet die direkte Schnittmenge zwischen klassischer RE und modernen Herausforderungen bei Legacy-Software-Migration.[^2]
+
+### 3. **LLM-Anwendungen im Software Engineering**
+
+Die arXiv-Publikationen (2308.10620 und 2312.15223) adressieren spezifisch die Rolle von Large Language Models in Requirements Engineering-Aufgaben sowie deren Potenzial für Code-Analyse und -Verständnis. Diese Quellen sind fundamental für den KI-Anteil Ihrer Forschungsfragen.[^3][^4]
+
+### 4. **Formale Methoden mit KI**
+
+Die King's College London Veröffentlichung behandelt die Kombination von formalen Methoden mit LLMs, was für die Qualitätssicherung extrahierter Requirements relevant ist.[^5]
+
+***
+
+## Neue aktuelle wissenschaftliche Quellen (2023-2025)
+
+### **A. Systematische Literaturreviews zu LLMs und Requirements Engineering**
+
+#### 1. **Zadenoori et al. (2025): "Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review"**[^6]
+
+**Relevanz für Ihre Masterarbeit: Sehr hoch**
+
+Diese aktuellste Systematische Literaturübersicht analysiert 74 Primärstudien aus den Jahren 2023-2024 und bietet eine umfassende Kategorisierung von LLM-Anwendungen in RE:
+
+- **Wichtige Erkenntnisse:**
+    - Shift in der Forschung von klassischer Defekt-Detektion hin zu Anforderungselicitation und -validierung
+    - Majority nutzt GPT-basierte Modelle mit Zero-Shot oder Few-Shot Prompting
+    - Begrenzte Einsatzgebiete in realen Industrieumgebungen; meist kontrollierte Umgebungen
+    - Neuartige Aufgaben wie Testgenerierung und Integration von RE mit anderen SE-Disziplinen werden zunehmend erforscht
+- **Messgrößen und Evaluationskriterien:**
+    - Recall, Precision, F1-Score sind Standardmetriken
+    - Limitierte Integration in komplexen Workflows
+    - Hauptartefakte: Anforderungsspezifikationen, aber zunehmend auch Tickets aus Issue-Tracking-Systemen, Vorschriften und technische Dokumentation
+
+**Direkter Nutzen für Ihr Projekt:** Diese Quelle gibt einen wissenschaftlichen Überblick über State-of-the-Art, hilft bei der Positionierung Ihrer Fallstudie innerhalb der RE+LLM-Forschungslandschaft.
+
+#### 2. **Norheim et al. (2024): "Challenges in applying large language models to requirements engineering tasks"**[^7]
+
+**Relevanz für Ihre Masterarbeit: Sehr hoch**
+
+Diese Peer-Reviewed Publication (MIT, RWTH Aachen) liefert kritische Herausforderungsanalyse für LLM-Anwendungen in RE:
+
+- **Klassifizierung von RE-Aufgaben aus LLM-Perspektive:**
+    - **Generation:** Neue Requirements aus Eingabetext generieren
+    - **Qualitätsbewertung:** Ambiguitäten, Konsistenz, Vollständigkeit prüfen
+    - **Analyse:** Requirement-Klassifizierung, Traceability-Detektion, Named Entity Recognition (NER)
+    - **Translation:** Requirements in formale/semi-formale Sprachen übersetzen
+    - **Design:** Design-Artefakte basierend auf Requirements generieren (emergent)
+- **Identifizierte Herausforderungen:**
+    - **Begrenzte Daten:** Öffentliche Requirement-Datasets sind knapp (PURE: 79 Dokumente, PROMISE: 625 Anforderungen). Hardware-Requirements unterrepräsentiert.
+    - **Inkonsistente Annotation:** Unterschiedliche Standards für Requirements-Notation
+    - **Inadequate Use-Cases:** Viele Studien demonstrieren Technologie statt echte Problemlösung
+    - **Skalierungsprobleme:** Kontextfenster von LLMs limitieren Verarbeitung großer Legacy-Codebasen
+- **Evaluation und Metriken:**
+    - F1-Score allein unzureichend zur Messung von praktischem RE-Nutzen
+    - Notwendigkeit für RE-spezifische Evaluationsmetriken, nicht nur NLP-Metriken
+
+**Direkter Nutzen:** Diese Quelle hilft bei der Definition realistischer Evaluationskriterien für Ihre Fallstudie, warnt vor häufigen Fallstricken.
+
+#### 3. **Núñez et al. (2024): "Machine Learning-Enhanced Requirements Engineering: A Systematic Literature Review"**[^8]
+
+**Relevanz für Ihre Masterarbeit: Hoch**
+
+Diese SLR (ENASE 2024 Conference) analysiert 74 Studien zur ML-Anwendung in RE (2012-2023):
+
+- **ML-Strategien in RE:**
+    - **Klassifikation (71.6% der Papers):** Supervised Learning dominiert (SVM 31%, Naive Bayes 31%, Decision Trees 27%)
+    - **Clustering (11%):** K-Means, HAC für Requirement-Ähnlichkeitserkennung
+    - **Assoziationsregeln (5%):** Apriori, FP-Growth für Requirement-Abhängigkeitserkennung
+- **Anforderungstypen:**
+    - 41% fokusieren auf Non-Functional Requirements (NFR)
+    - 31% auf Functional Requirements (FR)
+    - Preprocessing mit NLP 54%, Text-Mining 16%
+- **Häufig verwendete Datasets:**
+    - PROMISE Dataset (26% der Studien)
+    - PURE Dataset (öffentlich verfügbar)
+    - Größe meist 14-10.000 Requirements (45%), nur 8% > 10.000
+- **Tools und Technologien:**
+    - Python (50%), Java (20%), Weka (12%)
+    - Offene Systeme dominieren (20% der Arbeiten)
+    - ChatGPT und Google Bard als emerging tools für Requirement-Analyse
+
+**Direkter Nutzen:** Methodisches Framework für Requirements-Klassifizierung und Extraction, Benchmarks für Technologieauswahl.
+
+***
+
+### **B. Spezialisierte Quellen zu LLMs und Reverse Engineering**
+
+#### 4. **Automatisierte Anforderungsextraktion aus Code**[^9]
+
+Thoughtworks' "Using GenAI to understand legacy codebases" (2025) dokumentiert praktische Erfahrungen:
+
+- **Haupterkenntnisse:**
+    - GenAI-Tools (Cursor, Claude Code, Copilot) beschleunigen Code-Verständnis deutlich
+    - Retrieval-Augmented Generation (RAG) mit Wissens-Graphs besonders wirksam für Legacy-Systeme
+    - Größere Kontextfenster (200k+ Tokens) ermöglichen besseres Systemverständnis
+    - Abstract Syntax Trees (AST) + LLM-Embedding in Vector Databases = besseres Code-Verständnis als reiner Text
+
+**Praktische Relevanz:** Architektur-Pattern-Erkennung, Dependency-Mapping für Ihre c-entron-Fallstudie.
+
+#### 5. **LLMs für Legacy-System-Migration**[^10]
+
+Closeloop Artikel "LLMs for Legacy System Migration: A Modern Guide" (2025):
+
+- **LLM-Fähigkeiten für Reverse RE:**
+    - Code-Struktur-Parsing und Extraction funktionaler Requirements aus Implementierungsdetails
+    - Erkennung veralteter APIs und Sicherheitslücken
+    - Verständnis von Business-Logic in prozeduralem Code
+    - Multi-File-Format-Verarbeitung (Code, Config, Schemas, Docs)
+- **Limitierungen:**
+    - Kontextlängen-Beschränkungen bei extrem großen Codebases (Millionen LOC)
+    - Domain-spezifische oder proprietäre Sprachen problematisch
+    - Multi-Modal-LLMs versprechen bessere Ergebnisse (Code + Docs + Diagramme simultane Verarbeitung)
+
+**Fallstudie-Relevanz:** Direkt anwendbar auf c-entron ERP-Codebase.
+
+***
+
+### **C. NLP-basierte Requirements-Extraktion und -Analyse**
+
+#### 6. **Motger \& Franch (2024): "Automated Requirements Relations Extraction"**[^11]
+
+**Focus:** Relation-Extraction zwischen Anforderungen mittels NLP:
+
+- **Techniken:**
+    - Retrieval-basierte IE: Linguistic Methods, Vectorization, Graph-basierte Methoden, Ontology-basierte Ansätze
+    - Machine Learning: Unüberwacht (unsupervised), semi-überwacht, überwacht (supervised)
+- **Vergleich Ontology vs. ML:**
+    - Ontology-Methoden: Höhere Präzision bei domänen-bekanntem Wissen
+    - BERT Fine-Tuning (auf PURE Dataset): Besser bei unbekannten Mustern
+    - Hybrid-Ansätze versprechen beste Ergebnisse
+
+**Relevanz:** Traceability und Abhängigkeitserkennung für Ihre Quality-Metriken.
+
+#### 7. **Ebrahim et al. (2025): "Enhancing Software Requirements Engineering with LLMs"**[^12]
+
+Diese ACL 2025 Short Research Workshop Publikation adressiert:
+
+- **Herausforderungen beim LLM-Einsatz in SRE:**
+    - **Domain-Ignorance:** LLMs kennen Requirements-Domäne nicht
+    - **Halluzinations:** Erfundene oder falsche Anforderungen generieren
+    - **Hohe Computational Costs:** Training und Betrieb kostspielig
+- **Lösungsvorschlag (Conceptual Framework):**
+    - Small Language Models (SLMs) + Knowledge-Augmented LMs (KALMs) + LangChain
+    - SLMs: Optimierte Modelle, effizienter als LLMs
+    - KALMs: Integration externen Wissens (z.B., Unternehmens-Ontologien)
+    - Adressierung von RQs:
+        - RQ1: Wie können LMs computational/domain/reliability-Limitationen überwinden?
+        - RQ2: Wie können modulare Frameworks Sicherheit und Skalierbarkeit verbessern?
+        - RQ3: Welche Prompting-Strategien sichern akkurate Kontextualisierung?
+
+**Praktischer Nutzen:** Framework für Governance und Datenschutz bei c-entron-Einsatz.
+
+***
+
+### **D. Prompt Engineering und Techniken für RE-Aufgaben**
+
+#### 8. **Prompt Engineering für Software-Testing und Validierung**[^13]
+
+Testfort \& Kumo (2025) zu "Prompt Engineering in Software Testing":
+
+- **Systematische Kategorisierung von Prompts:**
+    - Intent-basierte Prompt-Bibliotheken (Information-Seeking, Action-Oriented, Conversational)
+    - Nicht zufällige, sondern systematisch kategorisierte Prompts
+    - Mehrdi-dimensionale Evaluierung: Accuracy, Safety, Clarity, Consistency
+- **4-Phasen-Implementierung:**
+    - Phase 1 (Wochen 1-4): Foundation, initiale Prompt-Bibliothek
+    - Phase 2 (Wochen 5-12): Comprehensive prompt development
+    - Phase 3 (Wochen 13-16): Edge-case investigation
+    - Phase 4: Real-world-simulation
+- **Evaluationsmetriken:**
+    - Quantitativ: Response time, keyword detection, token efficiency
+    - Qualitativ: Domain-accuracy, bias assessment, human expert review
+
+**Anwendung auf Ihre Arbeit:** Strukturierung der Prompts für Code-Analyse-Agent, Evaluationsrahmen für Requirements-Qualität.
+
+***
+
+### **E. Praktische Case Studies und Lösungsansätze**
+
+#### 9. **Swimm \& CloseLoop: Praktische Legacy-Modernisierung mit AI**[^14][^15]
+
+- **Swimm Application Understanding Platform:**
+    - Deterministic static analysis + Generative AI
+    - Eliminiert LLM-Halluzinations durch AST-basierte Analyse
+    - Support für COBOL, CICS, PL/I mit Language Parsers
+    - Bewährte Genauigkeit und Kosteneffizienz in der Praxis
+- **Reverse-Engineering-Prozess (nach Swimm):**
+    - Prescreening: Platform, Format, Dependencies Assessment
+    - AI-Assisted Analysis: Pattern Recognition, Behavior Analysis
+    - Artifact-Version-Control: Git-Integration für Nachverfolgbarkeit
+
+**Best Practice für Ihre c-entron-Fallstudie:** Hybrid-Ansatz: Deterministic Static Analysis (AST) + LLM für Business-Rule-Extraction
+
+#### 10. **Spyro Soft: GenAI-Dokumentation von Legacy-Code (2024)**[^16]
+
+Healthcare-Fallstudie zeigt:
+
+- **Automatische Analyse:** Codebase-Dokumentation, Dependency-Graphen
+- **Duplikat-Detektion:** Cleanup-Reports
+- **AI-gestützte Refactoring-Vorschläge:** Performance-Verbesserungen
+- **Technische Umsetzung:** Azure OpenAI Services
+
+**Learnings:** Dokumentation + Duplikat-Erkennung könnte Phase Ihrer Prototyp-Umsetzung sein.
+
+***
+
+### **F. Anforderungs-Elicitation mit NLP**
+
+#### 11. **Lafi et al. (2021): "Eliciting Requirements from Stakeholders' Responses Using NLP"**[^17]
+
+**Fokus:** Automatisierte Anforderungssammlung von Stakeholdern:
+
+- **Methode:** Tokenization, Stop-Word-Removal, Lemmatization → Häufigkeitsanalyse → Similarity-Matrix
+- **Ergebnisse:** 70% Zeitersparnis bei Requirements-Sammlung
+- **Herausforderung:** Manuell vs. automatisiert balanced finden
+
+**Relevanz:** Kombination mit Code-Analyse für Ihre Stakeholder-Input-Phase.
+
+#### 12. **Spijkman et al. (2021): "Concept Extraction in Requirements Elicitation Sessions"**[^18]
+
+**NLP-basierte Concept-Extraction aus Transkripten:**
+
+- **Methode:** KeyBERT + Ontology-Matching für Domain-Konzepte
+- **Tools:** NLTK, TextBlob, Pandas
+- **Ergebnis:** Known Concepts vs. Unknown Concepts kategorisiert
+
+**Anwendung:** Kombination von Stakeholder-Interviews (Transkripte) + Code-Analyse.
+
+***
+
+### **G. Tiefergehende technische Arbeiten**
+
+#### 13. **Akay et al. (2021): "Automating Design Requirement Extraction From Text"**[^19]
+
+MIT-Forschung zu automatisierter Requirements-Extraction:
+
+- **Methode:** BERT Fine-Tuned + Extractive Question-Answering
+- **Rekursive Hierarchie-Extraktion:** Top-Level-Requirement → Decomposition
+- **Evaluiert auf:** MEMS-Design-Dokumentation
+- **Performance:** Accuracy threshold erreichbar bei manageable Cost
+
+**Technisch-methodisch relevant:** Hierarchisches Requirements-Extraction-Konzept für Ihre Agentenarchitektur.
+
+#### 14. **Li et al. (2018): "Feature Extraction from Requirements with CNN"**[^20]
+
+**Deep Learning für Requirements-Analyse:**
+
+- **Architektur:** CNN + Laplacian Eigenmaps (Dimensionality Reduction) + K-Means
+- **Input:** Pre-trained Word Embeddings
+- **Output:** Binary Codes für Feature-Klassifizierung
+- **Vorteil:** Unüberwachtes Lernen, keine manuellen Annotations nötig
+
+**Potenzial:** Für automatisierte Feature-Extraktion aus Legacy-Code.
+
+***
+
+### **H. Systematische Literatur-Reviews und Metastudien**
+
+#### 15. **Swenska Studien zu NLP in RE-Elicitation**[^21]
+
+Uppsala University Untersuchung zu KeyBERT + Keyphrase Extraction:
+
+- **Automatische Keyphrase-Extraction** aus Workshop-Transkripten
+- **Tools:** KeyBERT, Keyphrase CountVectorizer
+- **Effizienzgewinn:** Deutlich reduzierte Verarbeitungszeit für große Datenmengen
+- **Kombination mit Experten-Review** für Validierung
+
+**Best Practice für Requirements-Elicitation-Sessions bei c-entron.**
+
+***
+
+## Synthese: Relevanz der Quellen für Ihre Masterarbeit
+
+### Kategorisierung nach Relevanz:
+
+| Kategorie | Quelle | Relevanz | Grund |
+| :-- | :-- | :-- | :-- |
+| **Zentral** | Zadenoori et al. 2025 | ⭐⭐⭐⭐⭐ | State-of-the-Art LLMs in RE |
+| **Zentral** | Norheim et al. 2024 | ⭐⭐⭐⭐⭐ | Challenges in LLM-RE, Evaluation Metrics |
+| **Zentral** | Núñez et al. 2024 | ⭐⭐⭐⭐ | ML-Techniken, praktische Werkzeuge |
+| **Sehr Relevant** | Thoughtworks 2025 | ⭐⭐⭐⭐ | Legacy-Codebase-Verständnis, RAG-Ansätze |
+| **Sehr Relevant** | Closeloop 2025 | ⭐⭐⭐⭐ | LLMs für Legacy-Migration |
+| **Sehr Relevant** | Ebrahim et al. 2025 | ⭐⭐⭐⭐ | Framework für SLM+KALM |
+| **Wichtig** | Motger \& Franch 2024 | ⭐⭐⭐ | Requirements-Relations-Extraction |
+| **Wichtig** | Testfort/Kumo 2025 | ⭐⭐⭐ | Prompt-Engineering-Methodik |
+| **Unterstützend** | Akay et al. 2021 | ⭐⭐⭐ | Hierarchische Requirements-Extraction |
+| **Unterstützend** | Lafi et al. 2021 | ⭐⭐ | Stakeholder-Input-Automatisierung |
+
+
+***
+
+## Handlungsempfehlungen für Ihre Masterarbeit
+
+### 1. **Theoretischer Rahmen (Kapitel 2)**
+
+- Verwenden Sie Norheim et al. (2024) und Zadenoori et al. (2025) als Hauptreferenzen für LLM-RE-Integration
+- Ergänzen Sie mit klassischen RE-Basics aus Ihrer HCI-Encyclopedia-Quelle
+- Integrieren Sie Challenges-Kategorisierung nach Norheim für Problemstellungsschärfung
+
+
+### 2. **Evaluation Framework (Kapitel 6)**
+
+- Übernahme der Multi-Dimensionalen Evaluierung aus Testfort/Kumo (2025)
+- Metriken von Norheim et al.: Vollständigkeit, Verständlichkeit, Redundanzfreiheit
+- Combine mit NLP-Metriken von Núñez et al.: Precision, Recall, F1-Score
+
+
+### 3. **Technische Umsetzung (Kapitel 5)**
+
+- RAG mit Knowledge-Graphs aus Thoughtworks als Architektur-Option
+- Hybrid-Ansatz (Static Analysis + LLM) nach Swimm-Vorbild für Halluzinations-Reduction
+- SLM+KALM Framework von Ebrahim et al. für Datenschutz-Compliance
+
+
+### 4. **Fallstudie-Design (Kapitel 3-4)**
+
+- Benchmarking gegen PROMISE/PURE Datasets (aus Núñez-Review)
+- Definieren Sie goldenes Referenzset basierend auf Norheim-Empfehlungen
+- Stakeholder-Input-Automatisierung nach Lafi/Spijkman für Interview-Auswertung
+
+
+### 5. **Bisherige Quellen-Lücken füllen**
+
+- Sie haben noch keine Quelle zu **Formal Methods + LLMs** tiefergehend analysiert
+- **Codeverständnis-Metriken** fehlen (Sie könnten Li et al. 2018 erweitern)
+- **Traceability-Standards** fehlen (Motger \& Franch als Basis)
+
+***
+
+## Fazit: Wissenschaftliche Positionierung
+
+Ihre Masterarbeit positioniert sich an der **Schnittstelle dreier reifer Forschungsdomänen:**
+
+1. **Requirements Engineering** (etablierte Disziplin seit 1990ern)
+2. **NLP/ML für Software Engineering** (rasant evolvierende Domäne 2012-2025)
+3. **Legacy-Modernisierung** (praktische Herausforderung, schwach akademisch erforscht)
+
+**Ihre unique Value Proposition:**
+
+- Erste **dokumentierte Fallstudie** eines KMU bei systematischem LLM-RE in Real-World-Legacy-Kontext
+- **Hybrid-Ansatz** combining Code-Analysis + Stakeholder-Input + Formal Validation
+- **Governance-Focus** (IP, Datenschutz, Organizational Compliance)
+
+Die 15 neu identifizierten Quellen (2023-2025) geben Ihnen aktuellste State-of-the-Art sowie praktische Best Practices für fundierte wissenschaftliche Arbeit.
+
+***
+
+## Quellen
+
+Interaction Design Foundation. (2024). Requirements Engineering - Encyclopedia of Human-Computer Interaction, 2nd ed.[^1]
+
+International Journal of Advances in Software and Computer Engineering (IJASCE).[^2]
+
+ArXiv:2308.10620. Large Language Models for Reverse Requirements Engineering.[^3]
+
+ArXiv:2312.15223. LLMs and Software Engineering Applications.[^4]
+
+King's College London. (2024). Formal Requirements Engineering and Large Language Models.[^5]
+
+Zadenoori, M.A., Dąbrowski, J., Alhoshan, W., Zhao, L., \& Ferrari, A. (2025). Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review. arXiv:2509.11446.[^6]
+
+Norheim, J.J., Rebentisch, E., Xiao, D., Draeger, L., Kerbrat, A., \& de Weck, O.L. (2024). Challenges in applying large language models to requirements engineering tasks. *Design Science*, 10, e16.[^7]
+
+Núñez, A.G., Granda, M.F., Saquicela, V., \& Parra, O. (2024). Machine Learning-Enhanced Requirements Engineering: A Systematic Literature Review. In *ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering* (pp. 521-528).[^8]
+
+Thoughtworks. (2025). Using GenAI to understand legacy codebases. Thoughtworks Technology Radar.[^9]
+
+CloseLoop. (2025). LLMs for Legacy System Migration: A Modern Guide.[^10]
+
+Motger, Q., \& Franch, X. (2024). Automated Requirements Relations Extraction. In *NLP4RE Handbook*.[^11]
+
+Ebrahim, M., et al. (2025). Enhancing Software Requirements Engineering with Large Language Models. *ACL 2025 Student Research Workshop*.[^12]
+
+Testfort \& Kumo. (2025). Prompt Engineering in Software Testing: Generative AI in QA.[^13]
+
+Swimm. (2024). Application Understanding Platform for Legacy Systems Modernization.[^14]
+
+Spyro Soft. (2024). Transforming legacy code documentation with GenAI: A healthcare case study.[^15]
+
+Manchikoni Surendra, P.K. (2025). Automating documentation and legacy code modernization. *World Journal of Advanced Engineering Technology and Sciences*, 15(01), 1390-1397.[^16]
+
+Lafi, M., et al. (2021). Eliciting Requirements from Stakeholders' Responses Using Natural Language Processing. *Computer Modeling in Engineering \& Sciences*, 2021.[^17]
+
+Spijkman, T., et al. (2021). Concept Extraction in Requirements Elicitation Sessions. *NLP4RE Workshop*.[^18]
+
+Akay, H., et al. (2021). Automating Design Requirement Extraction From Text With Natural Language Processing. ASME Paper DETC2021-66898.[^19]
+
+Li, Y., et al. (2018). Achieving Accuracy and Automation with Neural Networks for Feature Extraction from Requirements. *SANER 2018*.[^20]
+
+Swedish University Studies. (2024). NLP approaches for generating high-level requirements from stakeholder data.[^21]
+<span style="display:none">[^22][^23][^24][^25][^26][^27][^28][^29][^30][^31][^32][^33][^34]</span>
+
+<div align="center">⁂</div>
+
+[^1]: Masterarbeit_draft.pdf
+
+[^2]: Quellen.md
+
+[^3]: Exposee_Masterarbeit_final.typ
+
+[^4]: Exposee_Masterarbeit_feedback.typ
+
+[^5]: https://arxiv.org/abs/2509.11446
+
+[^6]: https://www.v2solutions.com/blogs/ai-reverse-engineering-requirements/
+
+[^7]: https://arxiv.org/html/2401.12075v2
+
+[^8]: https://aclanthology.org/2025.acl-srw.31.pdf
+
+[^9]: https://en.wikipedia.org/wiki/AI-assisted_reverse_engineering
+
+[^10]: https://dspace.mit.edu/bitstream/handle/1721.1/154885/v03bt03a035-detc2021-66898.pdf?sequence=2\&isAllowed=y
+
+[^11]: https://publications.rwth-aachen.de/record/994149/files/994149.pdf
+
+[^12]: https://swimm.io/learn/mainframe-modernization/reverse-engineering-in-software-engineering-process-and-best-practices
+
+[^13]: https://www.scitepress.org/Papers/2024/126881/126881.pdf
+
+[^14]: https://www.sciencedirect.com/science/article/pii/S0950584925000369
+
+[^15]: https://su.diva-portal.org/smash/get/diva2:1955534/FULLTEXT01.pdf
+
+[^16]: https://www.thoughtworks.com/radar/techniques/using-genai-to-understand-legacy-codebases
+
+[^17]: https://integrio.net/blog/prompt-engineer
+
+[^18]: https://ceur-ws.org/Vol-2857/nlp4re5.pdf
+
+[^19]: https://www.augmentcode.com/guides/legacy-code-migration-with-machine-learning-patterns-that-preserve-architecture-while-modernizing
+
+[^20]: https://dev.to/dehemi_fabio/the-software-engineers-guide-to-prompt-engineering-3j1a
+
+[^21]: https://www.techscience.com/CMES/v127n1/41944/html
+
+[^22]: https://closeloop.com/blog/llms-in-legacy-system-migration/
+
+[^23]: https://www.sap.com/resources/what-is-prompt-engineering
+
+[^24]: https://blogs.itemis.com/en/5-new-proven-and-effective-ways-how-nlp-can-empower-requirements-engineering
+
+[^25]: https://wwwiti.cs.uni-magdeburg.de/iti_db/publikationen/ps/auto/LiSS+SANER18.pdf
+
+[^26]: https://journalwjaets.com/content/automating-documentation-and-legacy-code-modernization-revitalizing-legacy-systems-ai
+
+[^27]: https://testfort.com/blog/prompt-engineering-in-software-testing
+
+[^28]: https://arxiv.org/html/2312.12878v1
+
+[^29]: https://swimm.io/blog/how-we-automatically-generate-documentation-for-legacy-code
+
+[^30]: https://www.kumohq.co/blog/prompt-engineering-best-practices
+
+[^31]: https://github.com/mateoespinosa/remix
+
+[^32]: https://spyro-soft.com/case/transforming-legacy-code-documentation-with-genai
+
+[^33]: https://www.braintrust.dev/articles/systematic-prompt-engineering
+
+[^34]: https://www.sciencedirect.com/science/article/abs/pii/S0926580521002855
+

Protokoll.md

@@ -2,9 +2,13 @@ Diese Datei Beschreibt meine Bisherigen Aktivitäten und Ergebnisse
 
 Zur Analyse der Usecases des bestehenden C-entron ERP wurde bisher folgendes gemacht:
 
-1 Es wurden alle Schulungsvideos die für KUnden im Portal zur Verfügung stehen analysiert. Stichprobenartig von Hand und vollständig per KI.
-Der Prompt dabei war:
 
+0. Websuche nach Standards zur Dokumentation von Anforderungen /usecases:
+
+    Ergebnis: Es exisitiert der ISO/IEC/IEEE 29148 standard 
+
+1 Es wurden alle Schulungsvideos die für KUnden im Portal zur Verfügung stehen aufgelsitet und Thematisch zusammengefasst.
+Der Prompt dabei war:
 
 
     1.1  Anschließen wurden alle gefundenen Usecases geclustert und in 101 Abstrakte Konzepte zugeordnet (Z.B. Adressstamm, Anzahlungsrechnung, Checlisten, Preismatrix, SEPA, Mailvorlagen, etc) Eine volsltändige liste liegt unter [link](./A_Videoanalyse_Uebersicht.csv) 
@@ -34,3 +38,12 @@ Prompt:
 Prompt: 
 Ergebnis:
 
+
+4. Offen: Vollständige Videoanalyse:
+Bisher wurden die Videos nur aufgelsitet. Der nächste Schritt wäre es die Video alle durch die KI transcrbieren zu lassen und anschließen auf Usecases zu analysieren.
+
+Prompt: ??
+Ergebnis:: offen
+
+4.5 Offen: Abgleich der Videoanalyse mit den codebasierten Analysen ob sich die UseCases decken oder auf welcher Seite mehr/weniger Usecases geefunden wurden.
+

Quellen.md

@@ -0,0 +1,220 @@
+# Quellen
+
+Die Quellen sind nach Relevanz zu den Kapiteln gruppiert. Innerhalb der Kapitel stehen Standards und peer-reviewte Publikationen vor Webquellen.
+
+## Kapitelzuordnung (Kurzliste)
+
+### Kapitel 1 – Einleitung
+
+- Bisbal et al. (1999): Legacy-Systeme als Problemkontext.
+- Hemmat et al. (2025), Fan et al. (2023): Motivation und Forschungslücke zu LLMs im RE/SE.
+
+### Kapitel 2 – Theoretische Grundlagen
+
+- ISO/IEC/IEEE 29148:2018; IEEE 830-1998; ISO/IEC 25010:2011; Pohl (2010); Glinz (2007, 2008).
+- Gotel und Finkelstein (1994); Ramesh und Jarke (2001): Traceability.
+- Chikofsky und Cross (1990); Storey (2005); Yu et al. (2005); Tahvildari et al. (2001): Reverse Engineering/RRE.
+- Fan et al. (2023); Salem et al. (2024); arXiv 2308.10620; arXiv 2312.15223: LLMs im SE.
+- Ji et al. (2023); Bender et al. (2021): Verlässlichkeit, Risiken, Governance.
+- Lewis et al. (2020); Wei et al. (2022): Kontextmanagement und Prompting.
+- Bisbal et al. (1997); Wu et al. (1997); Sneed (1995); Kratzke und Quint (2017); Pahl und Jamshidi (2016); 10.5220/0004979900260037: Legacy-Modernisierung, Cloud/Microservices.
+
+### Kapitel 3 – Fallstudie c-entron GmbH
+
+- Bisbal et al. (1999); Sneed (1995); Bisbal et al. (1997): Einordnung der Legacy-Charakteristika und Migrationsrisiken.
+- Kratzke und Quint (2017); Pahl und Jamshidi (2016): Zielarchitektur und Modernisierungsdruck.
+
+### Kapitel 4 – Konzeption und methodisches Vorgehen
+
+- ISO/IEC/IEEE 29148:2018; IEEE 830-1998; Pohl (2010): Anforderungen an Artefakte, Validierung und Prozessgestaltung.
+- Gotel und Finkelstein (1994); Ramesh und Jarke (2001): Traceability als methodische Leitplanke.
+- Lewis et al. (2020): Retrieval als Kontextstrategie.
+- Fan et al. (2023); Hemmat et al. (2025): Open Problems, Prozesskontrollen und Forschungsrahmen.
+
+### Kapitel 5 – Prototypische Umsetzung (inkl. Governance, Datenschutz, IP)
+
+- OpenAI (2023); Rozière et al. (2023): Modellcharakteristika, Grenzen und Einsatzannahmen.
+- Ji et al. (2023); Bender et al. (2021): Risiken, Governance und Absicherungsbedarf.
+- 10.5220/0004979900260037: Security-Aspekte in Legacy-to-Cloud-Migrationen.
+
+### Kapitel 6 – Evaluation
+
+- ISO/IEC/IEEE 29148:2018; Gotel und Finkelstein (1994): Qualitäts- und Traceability-Kriterien.
+- Hemmat et al. (2025); Marques et al. (2024); Fan et al. (2023): Evaluationsdimensionen und typische Limitationen.
+- Fantechi et al. (2023); Ruan et al. (2023): empirische Teilstudien als Referenzpunkte.
+
+### Kapitel 7 – Diskussion / Kapitel 8 – Fazit
+
+- Ji et al. (2023); Bender et al. (2021); Fan et al. (2023): Einordnung von Grenzen, Risiken und Implikationen.
+
+## Kapitel 2 – Theoretische Grundlagen
+
+### 2.1 Requirements Engineering und Reverse Requirements Engineering
+
+- ISO/IEC/IEEE (2018): *ISO/IEC/IEEE 29148:2018 – Systems and software engineering — Life cycle processes — Requirements engineering*. https://www.iso.org/standard/72089.html  
+  Synopsis: Die Norm definiert Begriffe, Inhalte und Qualitätsanforderungen für Requirements sowie Artefakte wie SRS und SRS-ähnliche Spezifikationen. Für diese Arbeit ist sie ein Referenzpunkt, um Kriterien wie Eindeutigkeit, Nachvollziehbarkeit und Prüfbarkeit konsistent zu operationalisieren.
+
+- IEEE (1998): *IEEE Std 830-1998 – Recommended Practice for Software Requirements Specifications*. https://standards.ieee.org/standard/830-1998.html  
+  Synopsis: Der Standard beschreibt Struktur und Mindestinhalte einer Software Requirements Specification. Er ist vor allem als historisch verbreiteter Rahmen relevant, um Unterschiede zu neueren Normen (z. B. ISO/IEC/IEEE 29148) einzuordnen.
+
+- ISO/IEC (2011): *ISO/IEC 25010:2011 – Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models*. https://iso25000.com/index.php/en/iso-25000-standards/iso-25010  
+  Synopsis: Die Norm liefert ein Qualitätsmodell mit strukturierten Qualitätsmerkmalen (u. a. Sicherheit, Zuverlässigkeit, Wartbarkeit, Performance-Effizienz). Für diese Arbeit dient es als Raster, um aus Code und Betriebskontext abgeleitete Qualitätsanforderungen systematisch zu ordnen.
+
+- Pohl, K. (2010): *Requirements Engineering: Fundamentals, Principles, and Techniques*. Springer. https://doi.org/10.1007/978-3-642-12578-2  
+  Synopsis: Das Lehrbuch beschreibt RE als durchgängige Disziplin von Elicitation bis Management und behandelt insbesondere Validierung, Konsistenz und Änderungssteuerung. Für diese Arbeit ist es eine Referenz, um Reverse Requirements Engineering als Sonderfall von RE mit erhöhtem Validierungsbedarf zu begründen.
+
+- Lawrence, B.; Wiegers, K.; Ebert, C. (2001): *The top risk of requirements engineering*. IEEE Software. https://doi.org/10.1109/52.965804  
+  Synopsis: Der Artikel identifiziert zentrale Risikofaktoren im Requirements Engineering (u. a. Unklarheit, Instabilität, unzureichende Stakeholder-Abstimmung) und diskutiert Gegenmaßnahmen. Für diese Arbeit ist dies relevant, um die Risiken von KI-extrahierten Requirements nicht nur qualitativ, sondern risikoorientiert zu betrachten.
+
+- Kotonya, G.; Sommerville, I. (1996): *Requirements engineering with viewpoints*. Software Engineering Journal. https://doi.org/10.1049/sej.1996.0002  
+  Synopsis: Der Beitrag zeigt, wie unterschiedliche Stakeholder-Perspektiven als „Viewpoints“ modelliert und konsolidiert werden können. Die Arbeit liefert damit ein methodisches Argument für explizite Konfliktbehandlung und Konsistenzprüfung bei Requirements.
+
+- Glinz, M. (2007): *On Non-Functional Requirements*. 15th IEEE International Requirements Engineering Conference (RE 2007). https://doi.org/10.1109/re.2007.45  
+  Synopsis: Der Beitrag diskutiert, warum die Trennung in funktionale und nicht-funktionale Anforderungen in der Praxis häufig unscharf ist und schlägt eine präzisere Begriffsverwendung vor. Für diese Arbeit ist dies relevant, um aus Code abgeleitete Anforderungen nicht vorschnell als „funktional“ zu etikettieren.
+
+- Glinz, M. (2008): *A Risk-Based, Value-Oriented Approach to Quality Requirements*. IEEE Software. https://doi.org/10.1109/ms.2008.31  
+  Synopsis: Der Artikel argumentiert, dass Qualitätsanforderungen (z. B. Performance, Sicherheit) risikobasiert und wertorientiert priorisiert werden sollten. Dies unterstützt die spätere Bewertung, welche aus einer Legacy-Codebasis abgeleiteten Quality Requirements besonders migrationskritisch sind.
+
+- Gotel, O.; Finkelstein, A. (1994): *An analysis of the requirements traceability problem*. International Conference on Requirements Engineering (ICRE). https://doi.org/10.1109/icre.1994.292398  
+  Synopsis: Der Beitrag prägt den Traceability-Begriff und analysiert Ursachen, warum Nachverfolgbarkeit in Projekten scheitert (u. a. heterogene Artefakte, fehlende Disziplin). Er ist zentral, um Traceability als Qualitätskriterium für KI-extrahierte Requirements zu begründen.
+
+- Ramesh, B.; Jarke, M. (2001): *Toward reference models for requirements traceability*. IEEE Transactions on Software Engineering. https://doi.org/10.1109/32.895989  
+  Synopsis: Der Artikel liefert Referenzmodelle, um Traceability-Typen und -Beziehungen systematisch zu beschreiben (z. B. rationale, evolutionäre Bezüge). Für diese Arbeit ist dies eine Grundlage, Traceability nicht nur als „Linkliste“, sondern als strukturierte Relation zu verstehen.
+
+- Chikofsky, E. J.; Cross, J. H. (1990): *Reverse engineering and design recovery: a taxonomy*. IEEE Software. https://doi.org/10.1109/52.43044  
+  Synopsis: Der Beitrag etabliert eine bis heute häufig zitierte Taxonomie zu Reverse Engineering, Reengineering und Design Recovery. Er liefert die begriffliche Basis, um Reverse Requirements Engineering als Teilmenge von Reverse-Engineering-Aktivitäten sauber abzugrenzen.
+
+- Storey, M.-A. (2005): *Theories, methods and tools in program comprehension: past, present and future*. International Workshop on Program Comprehension (IWPC). https://doi.org/10.1109/wpc.2005.38  
+  Synopsis: Der Beitrag ordnet Program Comprehension als Forschungsfeld ein und diskutiert typische Methoden (z. B. statische Analyse, Visualisierung, Navigation). Er ist relevant, weil Requirements-Extraktion aus Code immer auf Verfahren der Programmverständnisforschung aufsetzt.
+
+- Hemmat, A.; Sharbaf, M.; Kolahdouz-Rahimi, S.; Lano, K.; Tehrani, S. Y. (2025): *Research directions for using LLM in software requirement engineering: a systematic review*. Frontiers in Computer Science. https://doi.org/10.3389/fcomp.2025.1519437  
+  Synopsis: Die systematische Übersicht fasst Forschungsrichtungen zum Einsatz von LLMs im Requirements Engineering zusammen und diskutiert offene Probleme (u. a. Qualitätssicherung, Bias, Nachvollziehbarkeit). Die Arbeit dient als Brücke zwischen klassischem RE und den in Kapitel 2.2 diskutierten LLM-Methoden.
+
+- Yu, Y.; Mylopoulos, J.; Wang, Y.; Liaskos, S.; Lapouchnian, A.; Zou, Y.; Littou, M.; Leite, J. C. S. P. (2005): *RETR: Reverse Engineering to Requirements*. Working Conference on Reverse Engineering (WCRE). https://doi.org/10.1109/wcre.2005.27  
+  Synopsis: Der Beitrag beschreibt einen Ansatz, Requirements aus bestehenden Systemartefakten rückzugewinnen und strukturiert zu dokumentieren. Für diese Arbeit ist er als frühes Referenzmodell relevant, auch wenn heutige LLM-basierte Verfahren andere Automatisierungsgrade erlauben.
+
+- Tahvildari, L.; Kontogiannis, K.; Mylopoulos, J. (2001): *Requirements-driven software re-engineering framework*. Working Conference on Reverse Engineering (WCRE). https://doi.org/10.1109/wcre.2001.957811  
+  Synopsis: Der Beitrag zeigt, wie Requirements als Leitplanken für Reengineering-Entscheidungen eingesetzt werden können und verbindet technische Analyse mit zielgerichteter Umgestaltung. Für diese Arbeit ist dies eine theoretische Grundlage, um Requirements-Extraktion als Steuerungsinstrument der Modernisierung zu motivieren.
+
+- Pujiharto, E. W.; Tikasni, E.; Lewu, R.; Sudirman, S.; Utami, E. (2024): *Systematic Literature Review on Software Requirement Engineering in 5.0 Industry: Current Practices and Future Challenges*. International Journal of Advanced Science Computing and Engineering. https://doi.org/10.62527/ijasce.6.3.152  
+  Synopsis: Die SLR identifiziert Trends und Herausforderungen des Requirements Engineering im Kontext aktueller Industrieentwicklungen (u. a. IoT, KI, Interoperabilität). Sie ist als breiter Überblick nützlich, enthält jedoch gemischte Quellenqualität und benötigt eine kritische Einordnung.
+
+### 2.2 Large Language Models im Software Engineering
+
+- Bishop, C. M. (2006): *Pattern Recognition and Machine Learning*. Springer. https://link.springer.com/book/9780387310732  
+  Synopsis: Das Lehrbuch liefert eine breite, formale Einführung in Machine Learning (u. a. überwachte/ unüberwachte Verfahren, probabilistische Modellierung, Optimierung). Für diese Arbeit dient es als begriffliche Grundlage, um LLMs als Teilmenge datengetriebener Lernverfahren sauber einzuordnen.
+
+- Goodfellow, I.; Bengio, Y.; Courville, A. (2016): *Deep Learning*. MIT Press. https://www.deeplearningbook.org/  
+  Synopsis: Das Werk beschreibt neuronale Netze, Trainingsprinzipien und typische Fehlerquellen (z. B. Overfitting, Optimierungsprobleme) systematisch. Für diese Arbeit ist es eine Referenz, um Deep Learning als methodische Basis von LLMs knapp und korrekt zu erklären.
+
+- LeCun, Y.; Bengio, Y.; Hinton, G. (2015): *Deep learning*. Nature. https://doi.org/10.1038/nature14539  
+  Synopsis: Der Übersichtsartikel ordnet Deep Learning historisch und methodisch ein und beschreibt, warum representation learning viele klassische Feature-Engineering-Ansätze ersetzt. Für diese Arbeit ist dies eine zitierfähige Grundlage, um die Einbettung von LLMs in den allgemeinen KI-/ML-Kontext zu begründen.
+
+- Hastie, T.; Tibshirani, R.; Friedman, J. (2009): *The Elements of Statistical Learning* (2nd ed.). Springer. https://hastie.su.domains/ElemStatLearn/  
+  Synopsis: Das Lehrbuch beschreibt klassische statistische Lernverfahren (u. a. lineare Modelle, SVMs, Bäume, Ensembles) und deren praktische Trade-offs. Für diese Arbeit ist es nützlich, um LLMs und neuronale Netze gegenüber etablierten ML-Methoden sauber abzugrenzen (Datenanforderungen, Interpretierbarkeit, Fehlerarten).
+
+- Cortes, C.; Vapnik, V. (1995): *Support-vector networks*. Machine Learning. https://doi.org/10.1007/BF00994018  
+  Synopsis: Der Beitrag führt SVMs als margin-basiertes Lernverfahren ein und begründet zentrale Eigenschaften wie Generalisierung über Maximierung der Margin. Für diese Arbeit ist die Quelle relevant, um eine wichtige klassische ML-Familie zu referenzieren, die sich konzeptionell klar von generativen LLMs unterscheidet.
+
+- Breiman, L. (2001): *Random Forests*. Machine Learning. https://doi.org/10.1023/A:1010933404324  
+  Synopsis: Random Forests kombinieren viele Entscheidungsbäume über Bagging und zufällige Feature-Auswahl, was typischerweise robuste Performance auf tabellarischen Daten liefert. Für diese Arbeit dient dies als Referenz für interpretierbarkeitsnahe, nicht-neuronale Ensembles.
+
+- Friedman, J. H. (2001): *Greedy function approximation: A gradient boosting machine*. The Annals of Statistics. https://doi.org/10.1214/AOS/1013203451  
+  Synopsis: Der Beitrag formuliert Gradient Boosting als additive Modellbildung über schwache Lerner und liefert eine theoretische Grundlage für sehr leistungsfähige Ensembles. Für diese Arbeit ist dies relevant, um die Abgrenzung „klassische ML-Modelle vs. Deep Learning/LLMs“ nicht nur qualitativ, sondern referenzierbar darzustellen.
+
+- Fan, A.; Gokkaya, B.; Harman, M.; Lyubarskiy, M. (2023): *Large Language Models for Software Engineering: Survey and Open Problems*. ICSE-FoSE. https://doi.org/10.1109/icse-fose59343.2023.00008  
+  Synopsis: Der Beitrag strukturiert Einsatzfelder von LLMs im Software Engineering und benennt offene Forschungsprobleme, insbesondere zur Verlässlichkeit und Evaluationsmethodik. Für diese Arbeit sind die diskutierten Grenzen (Halluzinationen, Steuerbarkeit, Reproduzierbarkeit) direkt relevant.
+
+- Salem, N.; Hudaib, A.; Al-Tarawneh, K.; Salem, H. (2024): *A survey on the application of large language models in software engineering*. Computer Research and Modeling. https://doi.org/10.20537/2076-7633-2024-16-7-1715-1726  
+  Synopsis: Die Übersicht ordnet LLM-Anwendungen nach Aufgabenklassen (z. B. Code-Generierung, Zusammenfassung, Testen) und fasst typische Evaluationsstrategien zusammen. Sie ist hilfreich, um LLM-Fähigkeiten für Codeanalyse von reinen Textaufgaben abzugrenzen.
+
+- Ji, Z.; Lee, N.; Frieske, R.; Yu, T.; et al. (2023): *Survey of Hallucination in Natural Language Generation*. ACM Computing Surveys. https://doi.org/10.1145/3571730  
+  Synopsis: Die Arbeit bietet Definitionen, Taxonomien sowie Detektions- und Mitigationsansätze für Halluzinationen in generativen Modellen. Für den Einsatz im Requirements Engineering ist dies zentral, weil fehlerhafte, aber plausibel klingende Requirements erhebliche Migrationsrisiken verursachen.
+
+- Bender, E. M.; Gebru, T.; McMillan-Major, A.; Shmitchell, S. (2021): *On the Dangers of Stochastic Parrots*. FAccT. https://doi.org/10.1145/3442188.3445922  
+  Synopsis: Der Beitrag diskutiert Risiken großer Sprachmodelle (u. a. Datenbias, Umweltkosten, fehlende Transparenz) und fordert stärkere Governance. Für diese Arbeit ist dies eine theoretische Grundlage, um LLM-Einsatz nicht nur technisch, sondern auch organisatorisch und ethisch abzusichern.
+
+- Marques, N.; Silva, R. R.; Bernardino, J. (2024): *Using ChatGPT in Software Requirements Engineering: A Comprehensive Review*. Future Internet. https://doi.org/10.3390/fi16060180  
+  Synopsis: Die Reviewarbeit bündelt empirische Erkenntnisse zum ChatGPT-Einsatz entlang typischer RE-Aktivitäten (Elicitation, Analyse, Spezifikation, Validierung). Sie liefert eine erste Evidenzbasis, welche Aufgaben gut funktionieren und wo methodische Lücken bestehen.
+
+- Fantechi, A.; Gnesi, S.; Passaro, L.; Semini, L. (2023): *Inconsistency Detection in Natural Language Requirements using ChatGPT: a Preliminary Evaluation*. IEEE RE. https://doi.org/10.1109/re57278.2023.00045  
+  Synopsis: Der Beitrag untersucht, inwieweit ChatGPT Inkonsistenzen in naturalsprachlichen Anforderungen erkennen kann. Er ist relevant, weil er konkrete Qualitätschecks als „menschlicher Kontrollpunkt“ für KI-generierte Requirements nahelegt.
+
+- Ruan, K.; Chen, X.; Jin, Z. (2023): *Requirements Modeling Aided by ChatGPT: An Experience in Embedded Systems*. IEEE REW. https://doi.org/10.1109/rew57809.2023.00035  
+  Synopsis: Die Arbeit berichtet über den Einsatz von ChatGPT zur Unterstützung von Requirements-Modellierung und reflektiert praktische Grenzen (z. B. Domänenwissen, Nachvollziehbarkeit). Für diese Arbeit ist sie als Erfahrungsbericht wichtig, um LLM-Unterstützung als assistiven, nicht autonomen Prozess zu rahmen.
+
+- Zhao, L.; Alhoshan, W.; Ferrari, A.; Letsholo, K. J. (2021): *Natural Language Processing for Requirements Engineering*. ACM Computing Surveys. https://doi.org/10.1145/3444689  
+  Synopsis: Der Survey ordnet klassische NLP-Verfahren im Requirements Engineering (z. B. Extraktion, Klassifikation, Qualitätsprüfung, Traceability) und diskutiert wiederkehrende Herausforderungen wie Mehrdeutigkeit und fehlende Domänenmodelle. Für diese Arbeit liefert er den methodischen Kontext, in den LLM-basierte Verfahren als nächste Evolutionsstufe eingeordnet werden.
+
+- Borg, M.; Runeson, P.; Ardö, A. (2013): *Recovering from a decade: a systematic mapping of information retrieval approaches to software traceability*. Empirical Software Engineering. https://doi.org/10.1007/s10664-013-9255-y  
+  Synopsis: Die Mapping Study systematisiert IR-basierte Verfahren zur Traceability-Link-Recovery und diskutiert typische Datensätze und Evaluationsmetriken. Für diese Arbeit ist sie relevant, weil Traceability als Qualitätskriterium für KI-extrahierte Requirements an etablierte Bewertungsmuster anknüpfen kann.
+
+- Marczak-Czajka, A.; Cleland-Huang, J. (2023): *Using ChatGPT to Generate Human-Value User Stories as Inspirational Triggers*. IEEE REW. https://doi.org/10.1109/rew57809.2023.00016  
+  Synopsis: Die Arbeit untersucht ChatGPT als Unterstützung für wertorientierte User Stories und positioniert LLMs als Inspirations- und Elicitation-Werkzeug. Für diese Arbeit ist dies relevant, weil Stakeholder-Perspektiven im Code nicht vollständig abbildbar sind und ergänzende Elicitation-Schritte methodisch begründet werden müssen.
+
+- Norheim, J. J.; Rebentisch, E. (2024): *Structuring Natural Language Requirements with Large Language Models*. IEEE REW. https://doi.org/10.1109/rew61692.2024.00013  
+  Synopsis: Der Beitrag betrachtet, wie LLMs natürliche Anforderungen in strukturiertere Formen überführen können und diskutiert dabei Grenzen der Robustheit und Nachvollziehbarkeit. Für diese Arbeit ist dies ein direkter Anknüpfungspunkt, weil strukturierte, überprüfbare Requirements das Zielartefakt der Extraktion sind.
+
+- Luitel, D.; Hassani, S.; Sabetzadeh, M. (2024): *Improving requirements completeness: automated assistance through large language models*. Requirements Engineering. https://doi.org/10.1007/s00766-024-00416-3  
+  Synopsis: Die Arbeit untersucht LLM-gestützte Assistenz zur Verbesserung der Vollständigkeit von Requirements und diskutiert, welche Arten von Lücken sich automatisiert identifizieren lassen. Für diese Arbeit ist dies relevant, weil Vollständigkeit ein zentrales Evaluationskriterium für Reverse Requirements Engineering ist.
+
+- Hassani, S. (2024): *Enhancing Legal Compliance and Regulation Analysis with Large Language Models*. IEEE RE. https://doi.org/10.1109/re59067.2024.00065  
+  Synopsis: Der Beitrag adressiert den Einsatz von LLMs zur Analyse rechtlicher Vorgaben und Compliance-Anforderungen. Für diese Arbeit ist dies relevant, weil Datenschutz- und Compliance-Anforderungen im Migrationskontext häufig migrationskritisch sind und nicht vollständig aus Code ableitbar sind.
+
+- Nouri, A.; Cabrero-Daniel, B.; Törner, F.; Sivencrona, H. (2024): *Engineering Safety Requirements for Autonomous Driving with Large Language Models*. IEEE RE. https://doi.org/10.1109/re59067.2024.00029  
+  Synopsis: Die Arbeit betrachtet LLM-Unterstützung bei Safety Requirements und verdeutlicht die Notwendigkeit strenger Validierung und Belegbarkeit in sicherheitskritischen Domänen. Für diese Arbeit ist dies ein Referenzpunkt, um Qualitäts- und Governance-Anforderungen für KI-gestützte Requirements abzuleiten.
+
+- Okamoto, R.; Kusumoto, S. (2025): *Towards the Automatic Restructuring of Software Requirements Specifications to Conform to Standards Using Large Language Models*. IEEE RE. https://doi.org/10.1109/re63999.2025.00056  
+  Synopsis: Der Beitrag untersucht, wie LLMs Requirements-Spezifikationen in Richtung standardkonformer Strukturen umformen können. Für diese Arbeit ist dies relevant, weil standardnahe Artefakte (z. B. nach ISO/IEC/IEEE 29148) die Vergleichbarkeit und Governance in der Transition unterstützen.
+
+- arXiv (2024): *Large Language Models for Software Engineering: A Systematic Literature Review*. https://arxiv.org/abs/2308.10620  
+  Synopsis: Die SLR bietet eine breite Kartierung von LLM4SE-Publikationen (Modelle, Aufgaben, Methoden, Limitationen) und ist als Orientierungsrahmen nützlich. Aufgrund der hohen Dynamik des Feldes ist eine Aktualisierung mit neueren Arbeiten meist erforderlich.
+
+- arXiv (2024): *A Survey on Large Language Models for Software Engineering*. https://arxiv.org/abs/2312.15223  
+  Synopsis: Die Surveyarbeit strukturiert LLM-Anwendungen im Software Engineering und diskutiert typische Evaluationsfallen (z. B. Leckage, unklare Benchmarks). Für diese Arbeit liefert sie Begriffe und Kategorien, um Anforderungen an LLM-gestützte Codeanalyse systematisch zu formulieren.
+
+- arXiv (2017): Vaswani, A.; et al.: *Attention Is All You Need*. https://arxiv.org/abs/1706.03762  
+  Synopsis: Der Beitrag führt das Transformer-Architekturprinzip ein, das die Grundlage vieler moderner LLMs bildet. Für diese Arbeit genügt das Modellverständnis auf Konzeptniveau (Self-Attention, Kontextrepräsentation), um Grenzen wie Kontextfenster und Tokenisierung zu erklären.
+
+- arXiv (2020): Lewis, P.; Perez, E.; Piktus, A.; Petroni, F.; et al.: *Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks*. https://arxiv.org/abs/2005.11401  
+  Synopsis: Der Beitrag beschreibt RAG als Kombination aus Retrieval und generativer Modellierung, um Ausgaben stärker an externe Belege zu binden. Für diese Arbeit ist das Prinzip relevant, weil Requirements-Extraktion aus großen Repositories ohne gezielte Kontextauswahl nicht skalierbar ist.
+
+- arXiv (2022): Wei, J.; Wang, X.; Schuurmans, D.; Bosma, M.; Ichter, B.; Xia, F.; Chi, E.; Le, Q.; Zhou, D. (2022): *Chain-of-Thought Prompting Elicits Reasoning in Large Language Models*. https://arxiv.org/abs/2201.11903  
+  Synopsis: Der Beitrag zeigt, dass explizite Zwischenschritte im Prompt die Leistung auf Aufgaben mit mehrstufigem Schlussfolgern verbessern können. Für diese Arbeit ist dies relevant, um Prompttechniken einzuordnen, gleichzeitig aber Begründungstexte konsequent an Artefaktbelege zu koppeln.
+
+- arXiv (2023): Rozière, B.; et al.: *Code Llama: Open Foundation Models for Code*. https://arxiv.org/abs/2308.12950  
+  Synopsis: Der Technical Report beschreibt ein auf Code spezialisiertes Modell und diskutiert Training, Einsatzszenarien und Evaluationsbenchmarks. Für diese Arbeit ist dies relevant, um Unterschiede zwischen allgemeinen und code-domänenspezifischen LLMs zu begründen.
+
+- arXiv (2023): OpenAI: *GPT-4 Technical Report*. https://arxiv.org/abs/2303.08774  
+  Synopsis: Der Bericht beschreibt GPT-4 auf Systemebene (u. a. Fähigkeiten, Sicherheitsarbeit, Evaluationsansätze), ohne vollständige Trainingsdetails offenzulegen. Für diese Arbeit ist er als Primärquelle geeignet, um Capability-Claims und Grenzen nicht nur aus Sekundärliteratur abzuleiten.
+
+### 2.3 Legacy-Modernisierung und Stand der Forschung
+
+- Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J. (1999): *Legacy information systems: issues and directions*. IEEE Software. https://doi.org/10.1109/52.795108  
+  Synopsis: Der Beitrag beschreibt typische Charakteristika von Legacy-Systemen (z. B. enge Kopplung, veraltete Technologien, fehlende Dokumentation) und leitet Forschungs- und Handlungsfelder ab. Für diese Arbeit liefert er ein allgemeines Problemprofil, das in der Fallstudie konkretisiert wird.
+
+- Sneed, H. M. (1995): *Planning the reengineering of legacy systems*. IEEE Software. https://doi.org/10.1109/52.363168  
+  Synopsis: Der Artikel behandelt Reengineering als planbaren Prozess und betont die Notwendigkeit strukturierter Analyse- und Entscheidungsphasen. Für diese Arbeit ist dies eine Grundlage, um KI-gestützte Requirements-Extraktion als Teil einer systematischen Modernisierungsplanung zu positionieren.
+
+- Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J. (1997): *An overview of legacy information system migration*. APSEC/ICSC. https://doi.org/10.1109/apsec.1997.640219  
+  Synopsis: Der Beitrag gibt einen Überblick über Migrationsstrategien und typische Risiken (z. B. Datenmigration, Funktionsäquivalenz, organisatorische Abhängigkeiten). Er ist hilfreich, um die Rolle von Requirements als Risikoreduktionsinstrument im Migrationskontext zu begründen.
+
+- Wu, B.; Lawless, D.; Bisbal, J.; Grimson, J. (1997): *Legacy systems migration – a method and its tool-kit framework*. APSEC/ICSC. https://doi.org/10.1109/apsec.1997.640188  
+  Synopsis: Der Beitrag stellt eine methodische Klammer für Migration und Werkzeugunterstützung vor. Für diese Arbeit ist die Argumentationslinie wichtig, dass Tooling nur dann wirkt, wenn es in einen reproduzierbaren Prozess eingebettet ist.
+
+- Kratzke, N.; Quint, P.-C. (2017): *Understanding cloud-native applications after 10 years of cloud computing – A systematic mapping study*. Journal of Systems and Software. https://doi.org/10.1016/j.jss.2017.01.001  
+  Synopsis: Die Mapping Study systematisiert Merkmale „cloud-nativer“ Anwendungen und zeigt, wie sich Architekturprinzipien und Betriebsmodelle entwickeln. Für diese Arbeit ist dies relevant, um Zielarchitektur-Anforderungen (z. B. Skalierbarkeit, Deployment) gegenüber einer Windows-Client/Server-Welt abzugrenzen.
+
+- Pahl, C.; Jamshidi, P. (2016): *Microservices: A Systematic Mapping Study*. CLOSER/Cloud Computing and Services Science. https://doi.org/10.5220/0005785501370146  
+  Synopsis: Die Arbeit kartiert Forschung zu Microservices und benennt wiederkehrende Herausforderungen (u. a. Granularität, Observability, Deployment-Komplexität). Für diese Arbeit liefert sie theoretische Anknüpfungspunkte für „Modularisierung“ als Modernisierungsziel.
+
+- *Security in Legacy Systems Migration to the Cloud: A Systematic Mapping Study*. https://doi.org/10.5220/0004979900260037  
+  Synopsis: Die Mapping Study fasst Sicherheitsaspekte bei der Cloud-Migration von Legacy-Systemen zusammen (z. B. Identitäten, Datenfluss, Compliance). Sie ist für diese Arbeit relevant, weil Requirements-Extraktion ohne Sicherheits- und Datenschutzanforderungen systematisch unvollständig bleibt.
+
+## Webquellen und ergänzende Materialien (nicht peer-reviewed)
+
+- Interaction Design Foundation: *Requirements Engineering*. https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/requirements-engineering  
+  Synopsis: Der Beitrag bietet eine zugängliche, praxisnahe Einführung in Requirements Engineering und typische Aktivitäten. Er ist als Einstieg geeignet, ersetzt jedoch keine Primärliteratur oder Standards.
+
+- BibSonomy (Link nicht automatisiert auflösbar): https://www.bibsonomy.org/bibtex/1510ac6a2b48df877bbdcd429daee73eb/butonic?lang=de  
+  Synopsis: Der Link verweist auf einen BibTeX-Eintrag, der ohne interaktive Auflösung im Browser nicht zuverlässig extrahierbar war. Für die weitere Arbeit sollte die zugehörige Publikation mit DOI/ISBN ergänzt oder durch eine direkt zitierfähige Quelle ersetzt werden.

kapitel_1_einleitung_adapted.md

@@ -2,56 +2,43 @@
 
 ## 1.1 Ausgangssituation und Motivation
 
-In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre gewachsenen Systeme neu zu bewerten. Besonders ERP-Lösungen, die über Jahrzehnte in Windows-Umgebungen gepflegt wurden, stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen. Dokumentierte Architekturentscheidungen sind selten, implizites Wissen steckt in Source-Control-Systemen oder bei einzelnen Entwickler:innen.
+Die c-entron GmbH betreibt seit über zwei Jahrzehnten eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung ist funktional breit aufgestellt (u. a. Auftragsabwicklung, Lager, Fakturierung, Projektabrechnung), wächst aber auf einer klassischen Client/Server-Architektur weiter. Mit dem Wunsch nach webbasierten Oberflächen, Self-Service-Funktionen und flexibleren Betriebsmodellen stößt dieses Setup an Grenzen: Skalierung, Deployment und Nutzerführung lassen sich nur mit hohem Aufwand weiterentwickeln.
 
-Die c-entron GmbH in Ulm repräsentiert diesen Kontext. Das Unternehmen betreibt seit über zwanzig Jahren eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung deckt Auftragsabwicklung, Lager, Fakturierung und Projektabrechnung ab, ist aber eng mit der bisherigen Client/Server-Architektur gekoppelt. Kunden fordern inzwischen plattformunabhängige Oberflächen, Self-Service-Funktionen und flexible Betriebsmodelle. Die bestehende Anwendung limitiert Skalierung, Deployment und Benutzerführung, wodurch eine Migration auf eine webbasierte Plattform zwingend erforderlich wird.
+Gleichzeitig liegt ein großer Teil des Systemwissens implizit im Quellcode oder bei langjährigen Mitarbeitenden. Architekturentscheidungen sind selten dokumentiert, und viele Spezialfälle sind nur über Code-Historien nachvollziehbar. Damit erschwert sich die Vorbereitung einer Migration auf eine webbasierte Plattform erheblich.
 
-Parallel dazu hat sich ein neues Instrumentarium etabliert. Large Language Models wie GPT-4, Claude oder Code Llama können Quellcode analysieren, Muster erkennen und textuell beschreiben. Damit entsteht die Chance, fehlende Anforderungsdokumentationen zumindest teilweise aus dem Code heraus zu rekonstruieren. Die praktische Nutzung dieses Potenzials ist bislang kaum erforscht – insbesondere nicht in mittelständischen Legacy-Projekten. Diese Arbeit adressiert genau diese Lücke und untersucht, wie KI-gestützte Verfahren für eine systematische Anforderungsextraktion eingesetzt werden können.
+Aktuelle Large Language Models (LLMs) wie GPT-4, Claude oder Code Llama können Code analysieren und beschreiben. Sie eröffnen die Möglichkeit, aus einer Legacy-Codebasis zumindest einen Teil der Requirements zu rekonstruieren. Wie tragfähig diese Unterstützung in einem mittelständischen Umfeld tatsächlich ist, ist bislang kaum erprobt. Genau hier setzt die Arbeit an.
 
 ## 1.2 Problemstellung
 
-Im Projektumfeld der c-entron GmbH fehlen strukturierte Requirements für die bestehende ERP-Lösung. Die Analyse der Legacy-Codebasis ist zeitintensiv, personengebunden und anfällig für Auslassungen. Daraus ergeben sich mehrere Risiken:
+Für die bestehende ERP-Lösung fehlen strukturierte Requirements. Die Codebasis ist groß, historisch gewachsen und nur teilweise dokumentiert. Die Analyse bindet erfahrene Entwickler, ist fehleranfällig und lässt sich kaum skalieren. Daraus ergeben sich wesentliche Risiken für die Migration:
 
-- **Re-Implementationsfehler:** Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration.
-- **Technische Schuld:** Entwickler:innen investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen.
-- **Implizites Wissen:** Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen.
-- **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.
+- Funktionen oder Edge Cases gehen bei der Neuimplementierung verloren, weil sie nur im Code sichtbar sind.
+- Zeit fließt in das Entziffern alter Strukturen, statt in die neue Plattform; technische Schulden werden mitgeschleppt.
+- Domänenwissen konzentriert sich auf wenige Personen, wodurch Personalwechsel zu Wissensverlust führen.
+- Ohne eindeutige Traceability fehlt die Grundlage für Priorisierung, Tests und spätere Wartung.
 
-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.
+Eine rein manuelle Rekonstruktion aller Anforderungen ist wirtschaftlich schwer darstellbar. Es soll daher geprüft werden, ob KI-gestützte Verfahren einen belastbaren Anteil dieser Arbeit übernehmen können.
 
 ## 1.3 Zielsetzung
 
-Diese Arbeit verfolgt das Ziel, ein vollständiges Vorgehen für KI-gestütztes Reverse Requirements Engineering im Umfeld eines mittelständischen ERP-Herstellers zu entwickeln und zu bewerten. Die Teilziele lauten:
+Die Arbeit entwickelt und bewertet ein Vorgehen für KI-gestütztes Reverse Requirements Engineering in einem mittelständischen ERP-Kontext. Kernergebnisse sollen sein:
 
-- Entwicklung eines Prozessmodells, das Vorbereitung, Analyse, Validierung und Übergabe strukturiert.
-- Evaluation aktueller LLMs hinsichtlich Kontextfenster, Codeverständnis, Steuerbarkeit, Kosten und Datenschutz.
-- Prototypische Umsetzung eines Agenten, der Quellcode verarbeitet, Requirements formuliert und Traceability-Informationen hinterlegt.
-- Integration von Stakeholder-Wissen durch Interviews, um nicht direkt aus dem Code ableitbare Anforderungen zu ergänzen.
-- Definition eines Evaluationsrahmens mit quantitativen und qualitativen Kriterien (Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Aufwandseinsparung).
-- Ableitung von Governance- und Compliance-Leitlinien für den sicheren Umgang mit sensiblen Kundendaten.
-- Formulierung konkreter Handlungsempfehlungen für die c-entron GmbH sowie Übertragbarkeit auf ähnliche Unternehmen.
+- ein praxistaugliches Prozessmodell mit klaren Phasen für Vorbereitung, Analyse, Validierung und Übergabe,
+- eine evaluierte Auswahl geeigneter LLMs (u. a. Kontextfenster, Codeverständnis, Kosten, Datenschutz),
+- ein Prototyp, der Code analysiert, Requirements formuliert und Traceability-Informationen erfasst,
+- eine Ergänzung der KI-Ergebnisse durch Stakeholder-Interviews, wo Code allein nicht reicht,
+- ein Evaluationsrahmen (quantitativ und qualitativ) sowie Governance-Empfehlungen für den Umgang mit sensiblen Daten,
+- Handlungsempfehlungen für die c-entron GmbH und Hinweise zur Übertragbarkeit auf ähnliche Unternehmen.
 
 ## 1.4 Forschungsleitfragen
 
-Die Zielsetzung wird über vier Forschungsleitfragen strukturiert:
+Die Arbeit beantwortet vier Leitfragen:
 
-- **F1 – Einsatz von LLMs im Reverse Requirements Engineering:** Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?
-- **F2 – 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?
-- **F3 – Qualitätsbewertung der generierten Requirements:** Wie beurteilen Fachexpert:innen Vollständigkeit, Verständlichkeit, Nützlichkeit und Aufwandseinsparung der KI-Ergebnisse?
-- **F4 – Chancen und Grenzen des Ansatzes:** Welche Effizienzgewinne sind realistisch, wo liegen technische oder organisatorische Limitierungen, und welche Risiken (z.B. Halluzinationen, Datenschutz) müssen adressiert werden?
+- **F1:** Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte braucht es, um LLMs reproduzierbar für Reverse Requirements Engineering einzusetzen?
+- **F2:** Welche funktionalen und nicht-funktionalen Anforderungen lassen sich direkt aus Code ableiten, und wo müssen Interviews und vorhandene Dokumentation ergänzen?
+- **F3:** Wie bewerten Fachexperten Vollständigkeit, Verständlichkeit und Nutzen der KI-Ergebnisse im Vergleich zu manuellen Ansätzen?
+- **F4:** Welche Chancen (Effizienz, Systematisierung) und Grenzen (Halluzinationen, Datenschutz, Kontextgröße) sind beim KI-gestützten Requirements Engineering in Legacy-Umgebungen zu erwarten?
 
 ## 1.5 Aufbau der Arbeit
 
-Die Arbeit ist in acht Kapitel gegliedert und folgt dem in den Vorlagen üblichen Aufbau:
-
-1. **Einleitung:** Kontext, Problemstellung, Ziele und Forschungsfragen.
-2. **Theoretische Grundlagen:** Requirements Engineering, Reverse Engineering, Large Language Models sowie Qualitätssicherungskriterien.
-3. **Fallstudie c-entron GmbH:** Unternehmensprofil, Produktarchitektur, Migrationsdruck und Rahmenbedingungen.
-4. **Konzeption und methodisches Vorgehen:** Prozessmodell, Technologieauswahl, Stakeholder-Einbindung und Datenbasis.
-5. **Prototypische Umsetzung:** Architektur und Funktionsweise des LLM-Agenten sowie Integration in bestehende Toolchains.
-6. **Evaluation:** Vorgehen, Metriken, Ergebnisse und Expertenfeedback.
-7. **Diskussion:** Interpretation der Resultate, Limitationen und Implikationen für Forschung und Praxis.
-8. **Fazit und Ausblick:** Zusammenfassung, Beantwortung der Forschungsfragen und Perspektiven für weitere Arbeiten.
-
-Damit entsteht eine nachvollziehbare Linie von der Ausgangssituation über das Konzept bis zur Validierung.
+Die acht Kapitel folgen einer durchgängigen Linie: Einleitung (Kap. 1), theoretische Grundlagen zu Requirements Engineering, Reverse Engineering und LLMs (Kap. 2), Fallstudie c-entron GmbH (Kap. 3), Konzept und methodisches Vorgehen (Kap. 4), prototypische Umsetzung des LLM-Agenten (Kap. 5), Evaluation (Kap. 6), Diskussion der Ergebnisse (Kap. 7) sowie Fazit und Ausblick (Kap. 8). Damit entsteht ein klarer Bogen von der Ausgangslage bis zur Validierung des Ansatzes.

kapitel_2_Theoretische_Grundlagen.md

@@ -0,0 +1,380 @@
+# 2. 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 Begriffe des Requirements Engineering sowie die Idee der rückwärtsgerichteten Anforderungsgewinnung aus bestehenden Systemen eingeordnet. Anschließend werden Large Language Models als Werkzeugklasse im Software Engineering beschrieben, inklusive typischer Leistungsgrenzen und Absicherungsmechanismen. Abschließend werden Grundlagen der Legacy-Modernisierung sowie etablierte Migrationsstrategien zusammengefasst, um den Kontext der Fallstudie und die Zielrichtung einer webbasierten Modernisierung einzuordnen.
+
+## 2.1 Requirements Engineering und Reverse Requirements Engineering
+
+### 2.1.1 Begriff und Zielsetzung des Requirements Engineering
+
+Requirements Engineering (RE) umfasst die systematische Erhebung, Analyse, Spezifikation, Validierung und Verwaltung von Anforderungen an ein System über dessen Lebenszyklus. In Standards und Lehrwerken wird RE als eigenständiger Prozess verstanden, der sowohl fachliche Ziele (z. B. unterstützte Geschäftsprozesse) als auch technische und organisatorische Randbedingungen (z. B. Sicherheitsvorgaben, Betriebsmodelle) in überprüfbare Aussagen überführt (ISO/IEC/IEEE 29148:2018; IEEE 830-1998).
+
+Im Kern adressiert RE zwei Spannungsfelder:
+
+* **Kommunikation zwischen Domäne und Technik:** Anforderungen müssen fachlich verständlich und gleichzeitig so präzise sein, dass sie implementiert, getestet und geändert werden können.
+* **Umgang mit Unsicherheit und Wandel:** Anforderungen sind zu Projektbeginn selten vollständig. RE ist daher nicht nur Dokumentation, sondern ein iterativer Klärungs- und Abstimmungsprozess.
+
+Ein etablierter Ansatz zur Strukturierung heterogener Sichtweisen ist das Viewpoint-Konzept, bei dem Anforderungen aus unterschiedlichen Perspektiven modelliert und anschließend konsolidiert werden (Kotonya und Sommerville 1996). Für die vorliegende Arbeit ist diese Perspektivenorientierung relevant, weil eine Codebasis typischerweise keine expliziten Stakeholder-Sichten enthält, diese aber für eine Migration wieder sichtbar gemacht werden müssen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben).
+
+### 2.1.2 Arten von Requirements und Qualitätskriterien
+
+In der Literatur wird häufig zwischen funktionalen Anforderungen (Was soll das System tun?) und Qualitäts- bzw. nicht-funktionalen Anforderungen (Welche Eigenschaften und Randbedingungen gelten?) unterschieden. Die Praxis zeigt jedoch, dass diese Trennung nicht immer trennscharf ist: Eigenschaften können sowohl als Systemverhalten (z. B. „Audit-Log erzeugen“) als auch als Qualitätsziel (z. B. „Nachvollziehbarkeit“) formuliert werden (Glinz 2007). Für Reverse Requirements Engineering ist diese Unschärfe besonders relevant, weil Quellcode meist Verhalten konkretisiert, Qualitätsziele aber häufig implizit bleiben (z. B. Performance-Workarounds, Sicherheitsannahmen).
+
+Für die Qualität einzelner Requirements sind in Standards und RE-Forschung wiederkehrende Kriterien etabliert. ISO/IEC/IEEE 29148:2018 nennt unter anderem Eindeutigkeit, Konsistenz, Vollständigkeit, Verifizierbarkeit und Nachvollziehbarkeit als zentrale Eigenschaften. IEEE 830-1998 formuliert ähnliche Prinzipien für Software Requirements Specifications, mit stärkerem Fokus auf Dokumentstruktur und Lesbarkeit.
+
+Für die Bewertung von KI-extrahierten Requirements sind drei Kriterien unmittelbar handhabbar:
+
+* **Verifizierbarkeit:** Ein Requirement ist so formuliert, dass eine Testidee oder 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.
+* **Nachvollziehbarkeit (Traceability):** Es ist erkennbar, aus welchem Artefakt (Code, Konfiguration, Datenbank, Ticket, Interview) das Requirement abgeleitet wurde.
+
+Qualitätsanforderungen verdienen im Modernisierungskontext eine gesonderte Betrachtung, weil sie über die reine Funktionsgleichheit hinaus die Zielarchitektur motivieren. Glinz (2008) argumentiert, dass Qualitätsanforderungen risikobasiert und wertorientiert priorisiert werden sollten. Für Legacy-Migrationen ist dies plausibel: Ein „vollständiges“ Requirements-Set ist praktisch schwer erreichbar, gleichzeitig sind bestimmte Quality Requirements (z. B. Datenschutz, Verfügbarkeit, Rollout-Fähigkeit) hochkritisch, weil sie Architekturentscheidungen dominieren.
+
+Für die inhaltliche Strukturierung von Qualitätsanforderungen ist das Qualitätsmodell ISO/IEC 25010:2011 verbreitet, das Qualitätsmerkmale wie Performance-Effizienz, Zuverlässigkeit, Sicherheit oder Wartbarkeit systematisch ordnet. Für Reverse Requirements Engineering ist dies hilfreich, weil aus Code häufig nur Teilaspekte sichtbar werden (z. B. Caching-Mechanismen als Hinweis auf Performance-Annahmen), während andere Qualitätsziele (z. B. „Maintainability“) eher indirekt über Architekturentscheidungen und Entwicklungspraktiken wirksam werden.
+
+Die Relevanz sauberer Requirements-Qualität zeigt sich auch in der Risikoperspektive. Lawrence, Wiegers und Ebert (2001) beschreiben Requirements Engineering als primäre Risikozone, wenn Anforderungen unklar, instabil oder unvollständig sind. Für diese Arbeit folgt daraus, dass KI-gestützte Requirements-Extraktion nicht nur „mehr Text“ erzeugen darf, sondern gezielt die Risiken der Unklarheit und der Fehlinterpretation reduzieren muss.
+
+### 2.1.3 Spezifikationsformen und Grad der Formalisierung
+
+Requirements werden in der Praxis in unterschiedlichen Repräsentationsformen dokumentiert. Standards wie IEEE 830-1998 und ISO/IEC/IEEE 29148:2018 fokussieren auf strukturierte Spezifikationen (z. B. SRS) und definieren typische Kapitel (Zweck, Systemkontext, funktionale Anforderungen, Schnittstellen, Qualitätsanforderungen, Annahmen). Daneben existieren weniger formale Formen wie User Stories, Use-Case-Beschreibungen oder Backlog-Einträge, die vor allem in agilen Settings verbreitet sind.
+
+Für Reverse Requirements Engineering sind zwei Punkte entscheidend:
+
+* **Form beeinflusst Interpretierbarkeit:** Eine knappe User Story („Als Nutzer möchte ich …“) ist leicht verständlich, transportiert aber selten Randbedingungen, Datenregeln oder Fehlerfälle. Eine SRS-Formulierung kann präziser sein, erfordert aber mehr Kontext und Definitionen.
+* **Grad der Formalisierung beeinflusst Prüfbarkeit:** Je stärker Requirements mit Akzeptanzkriterien, Beispielen oder Messgrößen verknüpft sind, desto einfacher sind Reviews und Tests. Pohl (2010) betont Anforderungen-Validierung als eigene Disziplin, die ohne prüfbare Formulierungen methodisch kaum belastbar ist.
+
+Im Kontext dieser Arbeit bietet sich daher ein hybrider Stil an: Requirements werden als kurze, klare Soll-Aussagen formuliert und jeweils um Kontext (Akteur/Prozess), Randbedingungen (Vorbedingungen, Datenobjekte) und mindestens eine Prüfidee ergänzt. LLMs können die sprachliche Konsistenz unterstützen, die notwendige Präzisierung muss jedoch durch Belege und Validierung abgesichert werden.
+
+### 2.1.4 Traceability als Verbindung zwischen Code und Requirement
+
+Traceability bezeichnet die Möglichkeit, Beziehungen zwischen Requirements und anderen Artefakten herzustellen und über den Lebenszyklus zu pflegen. Gotel und Finkelstein (1994) analysieren Traceability als wiederkehrendes Problem, insbesondere dort, wo Artefakte heterogen sind und die Disziplin zur Pflege fehlt. Ramesh und Jarke (2001) schlagen Referenzmodelle vor, die Traceability-Typen und -Ziele strukturieren, etwa die Rückverfolgbarkeit zur Begründung (Rationale), zu Designentscheidungen oder zur Evolution eines Requirements.
+
+Für Reverse Requirements Engineering ist Traceability nicht nur ein „Nice-to-have“, sondern eine Sicherheitsmaßnahme:
+
+* **Plausibilisierung:** Ein Requirement lässt sich gegen konkrete Codeausschnitte oder Laufzeitbeobachtungen prüfen.
+* **Abgrenzung:** Es wird klar, ob eine Aussage wirklich aus der Codebasis folgt oder aus Interpretationen und Ergänzungen entsteht.
+* **Änderungsmanagement:** Bei Codeänderungen lässt sich ermitteln, welche Requirements betroffen sein könnten.
+
+In Legacy-Systemen ist Traceability typischerweise fragmentiert: Hinweise finden sich in Commit-Messages, Branch-Namen, Datenbankskripten, Konfigurationsdateien, UI-Texten oder in impliziten Konventionen. Der methodische Anspruch dieser Arbeit besteht daher nicht darin, „perfekte“ Traceability wiederherzustellen, sondern eine minimal belastbare, reproduzierbare Verknüpfung zwischen extrahierten Requirements und Belegen zu etablieren.
+
+### 2.1.5 Reverse Engineering und Reverse Requirements Engineering
+
+Reverse Engineering wird klassisch als Analyseprozess verstanden, der aus einem bestehenden System Wissen über Struktur, Verhalten und Designentscheidungen rekonstruiert. Chikofsky und Cross (1990) prägen hierfür eine Taxonomie und grenzen Reverse Engineering von Reengineering sowie Design Recovery ab. Für Requirements-nahe Fragestellungen ist hier relevant, dass Reverse Engineering nicht automatisch „Anforderungen“ liefert, sondern zunächst technische Fakten (z. B. Abhängigkeiten, Datenflüsse, Zustandsautomaten).
+
+Reverse Requirements Engineering (RRE) fokussiert auf die rückwärtsgerichtete Gewinnung von Anforderungen 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?
+* **Rekonstruktion eines Ist-Zustands:** Welche Funktionen und Regeln sind tatsächlich implementiert, unabhängig davon, ob sie intendiert waren?
+
+Gerade im Migrationskontext ist diese Unterscheidung entscheidend. Die Codebasis enthält oft historisch entstandene Workarounds oder kundenspezifische Anpassungen. Diese können fachlich gewollt, technisch opportunistisch oder schlicht „mitgewachsen“ sein. Ohne zusätzliche Validierung besteht das Risiko, dass RRE den Ist-Zustand als Soll-Zustand fehlinterpretiert.
+
+Frühe Ansätze zur Brücke zwischen Reverse Engineering und Requirements liefern beispielsweise Yu et al. (2005) mit „RETR: Reverse Engineering to Requirements“. Der Beitrag betont, dass Requirements-Rückgewinnung eine methodische Kette aus Artefaktsichtung, Strukturierung und Validierung benötigt. In ähnlicher Richtung beschreibt ein requirementsgetriebenes Reengineering-Framework, wie Requirements als Leitplanken für Reengineering-Entscheidungen genutzt werden können (Tahvildari, Kontogiannis und Mylopoulos 2001).
+
+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 ist 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.
+
+### 2.1.6 Typische Methodenkette für Requirements-Rückgewinnung aus Code
+
+Aus Sicht dieser Arbeit lässt sich Reverse Requirements Engineering in einer Legacy-Codebasis als wiederholbarer Ablauf strukturieren. Die konkrete Ausgestaltung hängt vom System und den verfügbaren Artefakten ab, die grundlegenden Schritte sind jedoch weitgehend stabil:
+
+1. **Scope und Domänenabgrenzung:** Auswahl relevanter Module, Datenobjekte und Prozesse (z. B. Auftragsabwicklung, Fakturierung).
+2. **Artefakterhebung:** Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen, Change-Historie.
+3. **Technische Analyse:** Struktur- und Abhängigkeitsanalyse, Identifikation von Kernkomponenten, Regeln und Integrationspunkten.
+4. **Semantische Interpretation:** Ableitung fachlicher Aussagen aus technischen Implementierungen (z. B. Statusübergänge, Berechtigungsprüfungen).
+5. **Formalisierung als Requirements:** Überführung in klare, testbare Anforderungen mit Kontext (Akteur, Vorbedingung, Ergebnis).
+6. **Traceability-Anreicherung:** Verknüpfung jedes Requirements mit Belegen (Datei, Klasse, Methode, SQL-Statement, UI-String).
+7. **Validierung:** Review durch Fachexperten und Abgleich mit Laufzeitverhalten, Tickets oder Kundenwissen.
+
+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.
+
+Diese Einteilung ist kein Selbstzweck. Sie hilft, Risiken sichtbar zu machen: Requirements, die überwiegend auf Sekundär- oder Kontextbelegen beruhen, sind anfälliger für Fehlinterpretation und sollten priorisiert validiert werden. Gerade in ERP-Systemen sind Datenbankschemata und SQL-Statements häufig besonders aussagekräftig, weil sie Domänenobjekte, Kardinalitäten und Geschäftsregeln (z. B. referentielle Integrität, historisierte Tabellen) sichtbar machen, die in UI- oder Servicecode nur indirekt erscheinen.
+
+Ein weiterer Hebel ist das Mining der Änderungshistorie. Commit-Messages, Diff-Hotspots oder Branch-Konventionen können Hinweise liefern, welche Bereiche besonders volatil sind, welche Kundenvarianten existieren und wo in der Vergangenheit Fehler oder Workarounds eingeführt wurden. Für Reverse Requirements Engineering folgt daraus, dass Requirements nicht nur „aus dem aktuellen Code“, sondern idealerweise auch aus der Evolution des Codes abgeleitet werden, um implizite Stabilitätsannahmen und technische Schulden zu erkennen.
+
+Der kritische Schritt ist die semantische Interpretation. Program Comprehension ist hierfür das methodische Fundament: Storey (2005) zeigt, dass Programmverständnis in der Praxis aus einer Kombination von statischer Analyse, Navigation, Visualisierung und Hypothesenbildung besteht. RRE übernimmt diesen kognitiven Prozess, erweitert ihn jedoch um das Ziel, Aussagen als Requirements zu formulieren, die unabhängig vom Code als Spezifikation nutzbar sind.
+
+### 2.1.7 Zwischenfazit zu 2.1
+
+Requirements Engineering liefert Kriterien und Artefaktformen, um Anforderungen präzise, prüfbar und nachvollziehbar zu beschreiben (ISO/IEC/IEEE 29148:2018; IEEE 830-1998). Reverse Requirements Engineering überträgt diese Zielsetzung in einen Kontext, in dem Requirements nicht vorliegen, sondern aus technischen Artefakten rekonstruiert werden. Für die vorliegende Arbeit folgt daraus, dass Automatisierung (z. B. durch KI) nur dann praktikabel ist, wenn Traceability und Validierung als feste Prozessbestandteile mitgeführt werden.
+
+## 2.2 Large Language Models im Software Engineering
+
+### 2.2.1 Künstliche Intelligenz, Machine Learning und Einordnung von LLMs
+
+Künstliche Intelligenz (KI) ist ein Oberbegriff für Verfahren, die Aufgaben bearbeiten, die in der Praxis typischerweise kognitive Fähigkeiten erfordern (z. B. Klassifikation, Planung, Sprachverarbeitung). Machine Learning (ML) ist dabei ein Teilgebiet, das Modelle aus Daten lernt, anstatt Regeln vollständig manuell zu spezifizieren. In der gängigen Einordnung wird zwischen überwachtem Lernen (mit Zielwerten), unüberwachtem Lernen (Struktur in Daten) und Reinforcement Learning (Lernen über Rückmeldesignale) unterschieden (Bishop 2006; Goodfellow, Bengio und Courville 2016).
+
+Deep Learning bezeichnet ML-Verfahren, die neuronale Netze mit vielen Parametern und mehreren Verarbeitungsebenen nutzen, um geeignete Repräsentationen aus Rohdaten zu lernen. Charakteristisch ist, dass Merkmalsextraktion und Modellanpassung gemeinsam über Optimierung (typischerweise Gradientenverfahren) erfolgen. LeCun, Bengio und Hinton (2015) beschreiben Deep Learning als zentrale Entwicklungslinie moderner KI, insbesondere für Wahrnehmungs- und Sprachaufgaben.
+
+Neuronale Netze lassen sich dabei vereinfacht als parametrisierte Funktionsketten aus Schichten beschreiben, die Eingaben in zunehmend abstrakte Repräsentationen überführen. Das Training erfolgt über eine Zielfunktion (Loss) und Gradientenberechnung, praktisch meist über Backpropagation und Varianten des Gradientenabstiegs (Goodfellow, Bengio und Courville 2016).
+
+![Abbildung 2-1: Schematische Darstellung eines vollständig verbundenen Feedforward-Netzes.](Abbildungen/abb_2_1_feedforward_nn.png)
+
+Ein einzelnes Neuron lässt sich als affine Transformation mit nachgeschalteter Aktivierungsfunktion formulieren:
+
+$$
+z = \sum_{i=1}^{d} w_i x_i + b,\quad a = \varphi(z)
+$$
+
+Typische Aktivierungsfunktionen sind die Sigmoid-Funktion und ReLU (Goodfellow, Bengio und Courville 2016):
+
+$$
+\sigma(z)=\frac{1}{1+e^{-z}},\quad \mathrm{ReLU}(z)=\max(0,z)
+$$
+
+![Abbildung 2-2: Beispielhafte Aktivierungsfunktionen (Sigmoid, tanh, ReLU).](Abbildungen/abb_2_2_aktivierungsfunktionen.png)
+
+Die Optimierung erfolgt üblicherweise iterativ. Für Gradientenabstieg gilt in kompakter Form:
+
+$$
+\theta^{(t+1)}=\theta^{(t)}-\eta \nabla_\theta \mathcal{L}(\theta^{(t)})
+$$
+
+#### 2.2.1.1 Abgrenzung neuronaler Netze und LLMs zu anderen ML-Methoden
+
+Neuronale Netze sind ein Teilbereich von ML, sie ersetzen jedoch nicht automatisch klassische Verfahren. In der Praxis hängt die Methodenauswahl von Datenart, Datenmenge, Interpretierbarkeit und Betriebsvorgaben ab (Bishop 2006; Hastie, Tibshirani und Friedman 2009).
+
+Tabelle 2-1 fasst die Abgrenzung zu häufigen ML-Familien zusammen:
+
+| Methodik | Typischer Einsatz | Stärken | Grenzen |
+|---|---|---|---|
+| Lineare/GLM-Modelle | Strukturierte Daten, Baselines | schnell, gut interpretierbar | begrenzte Nichtlinearität (ohne Feature Engineering) |
+| Support Vector Machines (SVM) | Klassifikation/Regression, mittlere Datenmengen | starke Theorie, robuste Margin-Idee | Skalierung/Kernelwahl, eingeschränkte Erklärbarkeit (Cortes und Vapnik 1995) |
+| Entscheidungsbäume/Ensembles | Tabellarische Daten | nichtlinear, oft gute Performance | Overfitting ohne Regularisierung; Ensembles weniger interpretierbar |
+| Random Forests | Tabellarische Daten, robuste Defaults | stabil, gute Generalisierung | begrenzte Extrapolation, Erklärbarkeit indirekt (Breiman 2001) |
+| Gradient Boosting | Tabellarische Daten, hohe Genauigkeit | sehr starke Praxisleistung | Hyperparameter-sensitiv, Trainingskosten (Friedman 2001) |
+| Neuronale Netze (Deep Learning) | Unstrukturierte Daten (Text, Bild), große Datenmengen | Representation Learning, End-to-End | hoher Daten-/Rechenbedarf, schwerer zu erklären (LeCun, Bengio und Hinton 2015) |
+| LLMs (Transformers) | Text- und Codeaufgaben, generative Assistenz | Vortraining nutzt große Korpora; flexible Transferleistung | Halluzinationen, Kontextlimit, Governance-Aufwand (Vaswani et al. 2017; Ji et al. 2023) |
+
+LLMs unterscheiden sich dabei von vielen klassischen Verfahren nicht nur durch Modellgröße, sondern auch durch Zielsetzung: Häufig wird ein generatives, autoregressives Sprachmodell trainiert, das die nächste Tokenwahrscheinlichkeit modelliert:
+
+$$
+\max_\theta \sum_{t=1}^{T} \log p_\theta(x_t \mid x_{<t})
+$$
+
+Für das Requirements Engineering ist diese Abgrenzung wichtig, weil LLMs aufgrund ihrer generativen Natur Texte produzieren können, die sprachlich konsistent wirken, aber fachlich falsch sein können. Klassische Modelle liefern in solchen Fällen eher „falsche Vorhersagen“, erzeugen jedoch nicht ohne weiteres neue, plausibel klingende Spezifikationen.
+
+Für die Sprachverarbeitung ist der Begriff "Sprachmodell" relevant: Ein Sprachmodell schätzt Wahrscheinlichkeiten über Tokenfolgen und kann dadurch Texte fortsetzen oder bewerten. Large Language Models (LLMs) sind eine Ausprägung solcher Sprachmodelle, die auf Deep-Learning-Architekturen beruhen und auf sehr großen Korpora vortrainiert werden. In der aktuellen Modellgeneration dominiert die Transformer-Architektur, deren Kernprinzip die Self-Attention ist (Vaswani et al. 2017).
+
+Self-Attention lässt sich im Transformer formal als gewichtete Kombination von Value-Vektoren beschreiben, wobei die Gewichte aus Query-Key-Ähnlichkeiten berechnet werden (Vaswani et al. 2017):
+
+$$
+\mathrm{Attention}(Q,K,V)=\mathrm{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V
+$$
+
+![Abbildung 2-3: Schematisches Beispiel einer Attention-Gewichtsmatrix (illustrativ).](Abbildungen/abb_2_3_attention_heatmap.png)
+
+Für diese Arbeit sind drei Konsequenzen dieser Modellklasse besonders relevant:
+
+* **Kontextfenster:** Modelle verarbeiten Eingaben nur bis zu einer maximalen Tokenanzahl. Längere Artefakte müssen segmentiert oder komprimiert werden.
+* **Tokenisierung:** Quellcode und Fachsprache werden in Token zerlegt. Dies beeinflusst, wie gut Identifier, Struktur und Domänenterminologie repräsentiert werden.
+* **Generativer Charakter:** Ausgaben sind nicht deterministisch. Temperatur, Sampling-Strategien und Promptform beeinflussen Reproduzierbarkeit.
+
+LLMs werden im Software Engineering eingesetzt, weil sie sowohl natürlichsprachliche Artefakte (z. B. Anforderungen, Kommentare) als auch Codeartefakte (z. B. Klassen, Funktionen, Tests) verarbeiten können. Surveyarbeiten ordnen LLM-Anwendungen nach Aufgabenklassen wie Codegenerierung, Codezusammenfassung, Fehlersuche, Testgenerierung oder Dokumentation (Fan et al. 2023; Salem et al. 2024; arXiv:2308.10620; arXiv:2312.15223).
+
+### 2.2.2 Training, Instruction Tuning und Prompting
+
+LLMs werden typischerweise in mehreren Phasen entwickelt. In einer Vortrainingsphase lernen Modelle aus großen Text- und Codekorpora statistische Regularitäten. Für den Einsatz als Assistenzsysteme werden Modelle häufig zusätzlich auf Anweisungen und Dialogformate ausgerichtet („instruction tuning“). Der GPT-4 Technical Report beschreibt diese Ausrichtung auf Systemebene und diskutiert Safety- und Evaluationsaspekte, ohne die vollständige Trainingspipeline offen zu legen (OpenAI 2023, arXiv:2303.08774).
+
+Im Engineering-Kontext ist der Prompt damit nicht nur Eingabe, sondern ein Steuerungsinstrument. Für diese Arbeit sind vor allem folgende Hebel relevant:
+
+* **Aufgabenrahmen:** 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?
+* **Ausgabe-Constraints:** Belegpflicht, Kennzeichnung unsicherer Aussagen, deterministische Parameter (z. B. niedrige Temperatur), feste Templates.
+
+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. Lewis et al. (2020, arXiv:2005.11401) 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.
+
+Prompting-Strategien wie Chain-of-Thought können die Qualität komplexer Ableitungen verbessern, bergen im Requirements-Kontext jedoch ein Risiko: Längere Begründungen können plausibel wirken und dadurch Fehlannahmen stabilisieren. Wei et al. (2022, arXiv:2201.11903) zeigen Chain-of-Thought als wirksame Prompttechnik; für diese Arbeit folgt daraus vor allem, dass Begründungen stets mit Artefaktbelegen gekoppelt werden müssen und nicht als eigenständige Evidenz gelten.
+
+### 2.2.3 LLMs für Code: Spezialisierung, Stärken und Grenzen
+
+Neben allgemeinen Modellen existieren code-spezialisierte LLMs, die auf Codekorpora vortrainiert oder nachtrainiert wurden. Ein prominentes Beispiel ist Code Llama, dessen Technical Report Training und Evaluationsaufbau beschreibt und die Ausrichtung auf Codeaufgaben explizit macht (Rozière et al. 2023). Aus praktischer Sicht sind bei code-spezifischen Modellen typischerweise drei Stärken zu beobachten:
+
+* **Syntaxnahe Mustererkennung:** Wiederkehrende Idiome, Framework-Patterns und typische Kontrollstrukturen werden zuverlässig erkannt.
+* **Semantische Zusammenfassung:** Funktionen und Module lassen sich in natürliche Sprache übertragen, inklusive grober Zweckbeschreibung.
+* **Transformation und Vorschläge:** Refactorings, Testideen oder API-Skizzen können generiert und iterativ verfeinert werden.
+
+Den Stärken stehen systematische Grenzen gegenüber. LLMs „verstehen“ Code nicht im Sinne einer formalen Semantik. Sie approximieren Bedeutung über Muster aus Trainingsdaten und aus dem gegebenen Kontext. Insbesondere in Legacy-Systemen mit proprietären Frameworks, kundenspezifischen Erweiterungen und historisch gewachsenen Konventionen ist die Wahrscheinlichkeit hoch, dass Modelle plausible, aber falsche Erklärungen liefern. Genau diese Plausibilität ist im Requirements-Kontext kritisch, weil Text als Spezifikation eine höhere Autorität erhält als eine rein technische Zusammenfassung.
+
+### 2.2.4 Halluzinationen und Verlässlichkeit: Relevanz für Requirements
+
+Halluzinationen bezeichnen Ausgaben, die syntaktisch korrekt und plausibel wirken, aber nicht durch Eingabedaten oder Weltwissen gedeckt sind. Ji et al. (2023) liefern eine Taxonomie und diskutieren Detektions- und Mitigationsansätze. Für Requirements ist die Gefahr besonders kritisch, weil falsche Requirements nicht als „Bug“ im Text auffallen, sondern als scheinbar saubere Spezifikation in nachgelagerte Architektur- und Implementationsentscheidungen einfließen können.
+
+Zusätzlich zu Halluzinationen sind zwei weitere Verlässlichkeitsthemen relevant:
+
+* **Daten- und Domänenbias:** Modelle spiegeln Verteilungen und Annahmen aus Trainingsdaten wider. Bender et al. (2021) diskutieren solche Risiken systematisch und betonen Governance-Fragen.
+* **Reproduzierbarkeit:** Kleine Promptänderungen oder Parameterunterschiede können zu variierenden Ergebnissen führen. Für einen engineeringfähigen Prozess sind daher Steuerungsmechanismen (z. B. feste Templates, deterministische Einstellungen, versionierte Prompts) notwendig.
+
+Für diese Arbeit folgt daraus, dass LLM-Ausgaben im Requirements-Kontext nicht als „Quelle“, sondern als Hypothesenmaterial zu behandeln sind. Erst durch Traceability (Belege) und Validierung (Expertenreview, Laufzeitchecks) wird aus einer Hypothese eine belastbare Anforderung.
+
+### 2.2.5 LLMs im Requirements Engineering: Stand der Forschung
+
+Die Forschung zu LLMs im Requirements Engineering ist dynamisch und lässt sich sinnvoll in eine Vorgeschichte (NLP/IR-Ansätze) und in aktuelle LLM-spezifische Arbeiten gliedern. Vor dem breiten Aufkommen von LLMs wurden Aufgaben wie Terminologieextraktion, Klassifikation, Qualitätsprüfung und Traceability häufig mit Natural Language Processing (NLP) und Information Retrieval (IR) adressiert. Zhao et al. (2021) geben einen Überblick über NLP-Verfahren im Requirements Engineering, inklusive typischer Problemklassen (z. B. Mehrdeutigkeit, Konsistenz, Vollständigkeit). Für Traceability ist die IR-basierte Link-Recovery-Literatur ein wichtiger Referenzpunkt, weil sie zeigt, welche Artefakte (Requirements, Code, Dokumentation) typischerweise verknüpft werden und welche Evaluationsmuster (Precision/Recall, Gold-Standards) sich etabliert haben (Borg, Runeson und Ardö 2013).
+
+Aktuelle Arbeiten zu LLMs im Requirements Engineering verschieben den Schwerpunkt. Während NLP/IR-Ansätze oft auf klar definierten Teilaufgaben mit begrenzten Ausgaben (Labels, Links, Hinweise) beruhen, können LLMs artefaktnahe Texte erzeugen, umformulieren und strukturieren. Dieser Übergang ist ambivalent: Einerseits entsteht ein direkter Produktivitätshebel, andererseits steigt das Risiko, dass sprachlich "gute" Texte als Spezifikation akzeptiert werden, obwohl die fachliche Basis unzureichend ist (Ji et al. 2023; Hemmat et al. 2025).
+
+Systematische Übersichten ordnen die LLM-Nutzung im RE entlang klassischer Prozessschritte ein. Hemmat et al. (2025) fassen Forschungsrichtungen zu LLMs im Software Requirements Engineering zusammen und nennen als wiederkehrende Problemfelder Qualitätssicherung, Nachvollziehbarkeit und Domänenabhängigkeit. Eine weitere Review zum ChatGPT-Einsatz im Requirements Engineering liefern Marques et al. (2024). Sie diskutieren den Einsatz entlang typischer RE-Aktivitäten (Elicitation, Analyse, Spezifikation, Validierung) und heben als zentrale Herausforderungen inkonsistente Ergebnisse, begrenztes Domänenwissen sowie die Schwierigkeit belastbarer Evaluationen hervor.
+
+In der Detailperspektive lassen sich aktuelle LLM-Arbeiten grob nach Anwendungsfeldern bündeln:
+
+* **Strukturierung und (Re-)Formulierung von Requirements:** Norheim und Rebentisch (2024) untersuchen, wie LLMs naturalsprachliche Anforderungen in strukturiertere Formen überführen können. Okamoto und Kusumoto (2025) adressieren die automatische Umstrukturierung von Software Requirements Specifications mit dem Ziel, Standardkonformität zu erhöhen.
+* **Qualitätsunterstützung und Defektanalyse:** Fantechi et al. (2023) evaluieren ChatGPT für Inkonsistenzdetektion in naturalsprachlichen Requirements. Luitel, Hassani und Sabetzadeh (2024) untersuchen LLM-gestützte Assistenz zur Verbesserung der Requirements-Vollständigkeit.
+* **Elicitation und Stakeholder-Perspektiven:** Marczak-Czajka und Cleland-Huang (2023) zeigen, wie LLMs zur Generierung wertorientierter User Stories als "Inspirationsimpulse" eingesetzt werden können. Diese Richtung ist für Reverse Requirements Engineering indirekt 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):** Nouri et al. (2024) betrachten LLMs bei der Engineering-Unterstützung von Safety Requirements im Kontext autonomen Fahrens. Hassani (2024) diskutiert LLM-Einsatz für rechtliche Compliance- und Regulationsanalyse. Solche Arbeiten verdeutlichen, dass LLMs nicht nur Text umformulieren, sondern auch Wissensstrukturen (Normen, Regeln) operationalisieren sollen; zugleich erhöhen sich die Anforderungen an Belegbarkeit und Haftung.
+
+Über die einzelnen Studien hinaus ist der Evidenzstand derzeit heterogen. Viele Arbeiten sind als Workshopbeiträge oder "preliminary evaluations" angelegt, nutzen begrenzte Datensätze und kombinieren automatische Metriken mit Expertenurteilen. Zudem sind Prompting-Strategien, Modellversionen und Kontexteinstellungen häufig nicht vollständig standardisiert, was die Reproduzierbarkeit erschwert (Fan et al. 2023; Hemmat et al. 2025). Aus Sicht dieser Arbeit folgt daraus eine klare Konsequenz: LLMs sind im Requirements Engineering am stärksten als Assistenzsysteme in einem kontrollierten Prozess, in dem (1) Aussagen mit Belegen verknüpft werden, (2) Unsicherheit explizit markiert wird und (3) fachliche Validierung als definierter Kontrollpunkt erfolgt.
+
+Für Reverse Requirements Engineering lässt sich der Nutzen damit präzisieren: LLMs können Kandidaten-Requirements aus großen Artefaktmengen (Code, Kommentare, UI-Strings, Konfiguration) verdichten und in eine konsistente Spezifikationsform überführen. Die fachliche Belastbarkeit entsteht jedoch erst durch Traceability zu Codebelegen und die Validierung durch Experten, insbesondere bei Safety-, Compliance- und Abrechnungslogik.
+
+### 2.2.6 Absicherung: Human-in-the-loop, Belege und Prozesskontrollen
+
+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 (Fan et al. 2023; Hemmat et al. 2025). 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.
+
+Diese Kontrollen adressieren nicht alle Risiken, reduzieren aber die typischen Fehlerklassen (Halluzination, Überinterpretation, fehlende Konsistenz) und schaffen die Grundlage für eine belastbare Evaluation in Kapitel 6.
+
+### 2.2.7 Qualitätsbewertung und Messgrößen im Requirements-Kontext
+
+Die Qualität von LLM-Ergebnissen wird in vielen Arbeiten über allgemeine Textmetriken oder Task-spezifische Benchmarks bewertet. Für Requirements-Extraktion aus Code sind solche Metriken nur begrenzt aussagekräftig, weil der zentrale Anspruch nicht „sprachliche Ähnlichkeit“, sondern fachliche Korrektheit, Prüfbarkeit und Nachvollziehbarkeit ist (Hemmat et al. 2025; Marques et al. 2024). Eine zweckmäßige Qualitätsbewertung sollte daher an RE-Kriterien anschließen und explizit zwischen drei Ebenen unterscheiden:
+
+* **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 (Glinz 2008) und lässt sich auf Funktionsanforderungen übertragen.
+
+### 2.2.8 Zwischenfazit zu 2.2
+
+LLMs liefern im Software Engineering eine leistungsfähige Assistenz für Analyse, Zusammenfassung und Textproduktion, sind jedoch nicht verlässlich im Sinne formaler Korrektheit (Fan et al. 2023; Ji et al. 2023). Für Requirements ist der entscheidende Punkt, dass die Qualität nicht an der sprachlichen Glätte, sondern an Nachvollziehbarkeit und Prüfbarkeit hängt. Daraus folgt für diese Arbeit ein designierter "Sicherheitsgurt": Evidence-First, Traceability und Human-in-the-loop sind keine Zusatzoptionen, sondern Kernelemente des Vorgehens.
+
+## 2.3 Legacy-Modernisierung und Stand der Forschung
+
+### 2.3.1 Charakteristika von Legacy-Systemen
+
+Legacy-Systeme sind nicht allein durch ihr Alter definiert, sondern durch ihren Kontext: Sie tragen geschäftskritische Funktionen, sind über lange Zeit erweitert worden und weisen oft starke technische und organisatorische Abhängigkeiten auf. Bisbal et al. (1999) beschreiben typische Merkmale wie enge Kopplung, heterogene Technologien, schwer austauschbare Komponenten und unzureichende Dokumentation. Gerade letzteres ist für Modernisierungsvorhaben problematisch, weil Entscheidungen ohne belastbare Anforderungsbasis zu Funktionsverlusten und Akzeptanzproblemen führen können.
+
+Im ERP-Kontext verschärfen sich diese Merkmale häufig durch:
+
+* **Domänenkomplexität:** Geschäftsregeln sind zahlreich, variantenreich und teilweise kundenspezifisch.
+* **Datenzentrierung:** Prozesse hängen stark von Datenmodellen, Stammdatenqualität und historisch gewachsenen Datenkonventionen ab.
+* **Integrationslast:** Schnittstellen zu Drittsystemen (z. B. Buchhaltung, Shop, Dokumentenmanagement) sind über Jahre organisch entstanden.
+
+Damit wird nachvollziehbar, warum Requirements-Extraktion aus der Codebasis nicht nur ein Dokumentationsprojekt, sondern ein Risikoreduktionsinstrument für Migrationen ist.
+
+### 2.3.2 Modernisierungsstrategien und Reengineering als Prozess
+
+Modernisierung kann unterschiedliche Strategien annehmen, von "Lift-and-Shift" bis zur vollständigen Neuimplementierung. Die Literatur betont wiederholt, dass die Wahl einer Strategie von Risiko, Zielarchitektur und verfügbaren Ressourcen abhängt und daher explizit geplant werden sollte (Sneed 1995). Eine zentrale Aussage ist dabei, dass Reengineering nicht als rein technischer Umbau verstanden werden kann: Ohne fachliche Leitplanken entstehen technische Verbesserungen, die am Bedarf vorbeilaufen oder bestehende Fachlogik unabsichtlich verändern.
+
+Aus Sicht dieser Arbeit lassen sich Modernisierungsstrategien pragmatisch entlang zweier Achsen einordnen: (1) Wie stark wird die bestehende Implementierung weitergenutzt? (2) Wie stark wird die Zielarchitektur verändert? Daraus ergeben sich typische Strategietypen, die in der Praxis auch kombiniert auftreten:
+
+* **Weiterbetrieb mit Hülle (Wrapping):** Die Legacy-Logik bleibt bestehen, wird aber über neue Schnittstellen oder UI-Schichten zugänglich gemacht. Vorteil ist geringe Eingriffstiefe; Nachteil ist, dass technische Schulden und Engpässe erhalten bleiben.
+* **Schrittweise Modularisierung:** Teile der Legacy-Anwendung werden sukzessive in neue Komponenten überführt, während andere Teile weiterlaufen. Vorteil ist Risikostreuung und frühe Nutzenrealisierung; Nachteil ist erhöhte Integrationskomplexität während der Übergangsphase.
+* **Reengineering/Refactoring:** Die bestehende Logik wird strukturell überarbeitet (z. B. Entkopplung, Schichten, bessere Testbarkeit), ohne den Funktionsumfang grundsätzlich zu verändern. Vorteil ist bessere Wartbarkeit; Nachteil ist hoher Analyseaufwand, gerade ohne Requirementsbasis.
+* **Neuimplementierung mit Funktionsparität:** Die Legacy-Logik wird auf neuer Technologie nachgebaut, häufig mit dem Anspruch, zunächst funktional äquivalent zu sein. Vorteil ist saubere Zielarchitektur; Nachteil ist die hohe Abhängigkeit von vollständigen, korrekten Requirements.
+
+Für ERP-Systeme ist die Wahl einer Strategie stark datengetrieben. Datenmodelle, Schnittstellenverträge und Buchungslogik definieren die „harten Kanten“ einer Migration. Damit steigt der Stellenwert von Requirements, die Datenobjekte, Zustandsmodelle und Integrationspunkte explizit machen. Besonders migrationskritisch sind dabei Anforderungen, die in der Legacy-Implementierung als implizite Konvention existieren (z. B. Statuscodes, historische Sonderfälle, kundenspezifische Maskenlogik), weil sie ohne gezielte Extraktion und Validierung leicht verloren gehen.
+
+Bisbal et al. (1997) geben einen Überblick über Migrationsansätze und ordnen typische Risikofelder ein, darunter Datenmigration, Funktionsäquivalenz und organisatorische Abhängigkeiten. Wu et al. (1997) argumentieren ergänzend, dass Werkzeugunterstützung nur dann wirksam ist, wenn sie in eine methodische Kette eingebettet ist. Diese Argumentation ist direkt anschlussfähig an KI-gestützte Verfahren: Auch LLM-basierte Automatisierung entfaltet Nutzen nur innerhalb eines reproduzierbaren Prozesses mit klaren Kontrollpunkten.
+
+### 2.3.3 Zielarchitekturen: Web, Cloud und „Cloud-native“
+
+Die Modernisierung vieler Legacy-Anwendungen zielt auf webbasierte, plattformunabhängige Oberflächen und auf Betriebsmodelle, die Skalierung, automatisiertes Deployment und schnelle Iteration unterstützen. Kratzke und Quint (2017) fassen in einer systematischen Mapping Study zusammen, welche Merkmale cloud-nativer Anwendungen in der Forschung und Praxis wiederkehren. Dazu zählen typischerweise automatisierte Bereitstellung, resiliente Komponenten, horizontale Skalierung und eine stärkere Trennung von Build- und Run-Umgebungen.
+
+Im selben Zielraum werden Microservices häufig als Architekturstil diskutiert. Pahl und Jamshidi (2016) kartieren Forschung zu Microservices und zeigen wiederkehrende Problemfelder, unter anderem die Wahl der richtigen Servicegranularität, die erhöhte Komplexität im Betrieb und Anforderungen an Observability. Für Migrationsprojekte ist daraus eine pragmatische Schlussfolgerung ableitbar: Modularisierung ist ein Ziel, erzeugt aber zugleich neue Anforderungen (z. B. Deployment-Pipelines, Monitoring, Sicherheitskonzepte), die im Requirements-Set sichtbar sein müssen.
+
+Für die Requirementsarbeit bedeutet die Zielarchitekturverschiebung eine Verschiebung des Schwerpunktes: Während in klassischen Client/Server-Architekturen die fachliche Funktionslogik oft dominiert, rücken in Web- und Cloud-Kontexten betriebliche und sicherheitsbezogene Qualitätsmerkmale stärker in den Vordergrund. ISO/IEC 25010:2011 bietet hierfür eine hilfreiche Taxonomie. 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.
+
+Diese Merkmale sind nicht neu, ihre Sichtbarkeit im Projekt nimmt jedoch zu, weil Cloud- und Webbetrieb ein engeres Zusammenspiel von Entwicklung und Betrieb erzwingt. Für Reverse Requirements Engineering folgt daraus, dass der Blick auf die Legacy-Codebasis systematisch um Betriebs- und Sicherheitsanforderungen ergänzt werden muss, auch wenn diese im Code nur indirekt sichtbar sind (z. B. über Deployment-Skripte, Konfigurationen, Logging-Policies oder Rechteprüfungen).
+
+Sicherheitsanforderungen werden in Cloud-Migrationskontexten häufig unterschätzt. Eine systematische Mapping Study zu Security-Aspekten bei Legacy-to-Cloud-Migrationen (Security in Legacy Systems Migration to the Cloud 2014, DOI: 10.5220/0004979900260037) zeigt, dass Identitätsmanagement, Datenflusskontrolle und Compliance wiederkehrende Kernprobleme sind. Für diese Arbeit bedeutet dies, dass Requirements-Extraktion aus Code um Sicherheits- und Datenschutzanforderungen ergänzt werden muss, da sie nicht in jedem Quellcodefragment explizit sichtbar sind.
+
+### 2.3.4 Stand der Forschung: KI-Unterstützung in Modernisierungsvorhaben
+
+Die Forschung zu KI- bzw. LLM-Unterstützung im Modernisierungskontext ist im Vergleich zu klassischen Reengineering-Ansätzen jünger. Die Übersichten zu LLM4SE (Fan et al. 2023; arXiv:2308.10620) zeigen, dass ein Teil der Arbeiten auf Codeverständnis, Dokumentation und Artefakttransformation zielt. Spezifisch für Requirements Engineering bündeln Reviews und SLRs erste Evidenz und Forschungsrichtungen (Marques et al. 2024; Hemmat et al. 2025).
+
+Aus dieser Literatur lassen sich zwei robuste Aussagen ableiten:
+
+* **LLMs sind besonders stark in der Strukturierung und sprachlichen Formulierung**, also dort, wo aus fragmentierten Hinweisen ein konsistenter Text entstehen muss.
+* **LLMs benötigen technische und organisatorische Sicherungen**, wenn Ergebnisse als Entscheidungsgrundlage in Migrationen dienen sollen (z. B. Belege, Review, reproduzierbarer Prozess).
+
+Damit ist eine zentrale Motivation dieser Arbeit begründet: Eine Legacy-Modernisierung benötigt belastbare Requirements, die im Legacy-Kontext oft fehlen. LLMs sind als Assistenz zur Rekonstruktion naheliegend, müssen jedoch methodisch so eingesetzt werden, dass Verlässlichkeit und Nachvollziehbarkeit systematisch erhöht werden.
+
+### 2.3.5 Zwischenfazit zu 2.3
+
+Legacy-Modernisierung ist ein sozio-technisches Vorhaben, das technische Umbauten und fachliche Zielsetzungen integrieren muss (Bisbal et al. 1999; Sneed 1995). Moderne Zielarchitekturen (Web/Cloud) verschieben zudem die Anforderungslandschaft, weil Betriebs- und Sicherheitsanforderungen stärker in den Vordergrund treten (Kratzke und Quint 2017; Security in Legacy Systems Migration to the Cloud 2014). Für die vorliegende Arbeit folgt daraus, dass Requirements-Extraktion nicht nur der Funktionsrekonstruktion dient, sondern die Grundlage für Migrationsentscheidungen, Priorisierung und Qualitätssicherung bildet.
+
+### 2.3.6 Kapitelzusammenfassung und Anschluss
+
+Die drei Themenblöcke dieses Kapitels greifen ineinander. Requirements Engineering liefert Kriterien, um Anforderungen prüfbar und nachvollziehbar zu formulieren (ISO/IEC/IEEE 29148:2018). Reverse Requirements Engineering überträgt diese Kriterien in einen Kontext, in dem Anforderungen aus bestehenden Artefakten rekonstruiert werden müssen (Chikofsky und Cross 1990; Yu et al. 2005). Large Language Models können diese Rekonstruktion unterstützen, sind aber fehleranfällig und benötigen Prozesskontrollen, vor allem gegen Halluzinationen und Überinterpretation (Ji et al. 2023; Fan et al. 2023). Legacy-Modernisierung schließlich liefert die praktische Motivation und zeigt, warum eine belastbare Anforderungsbasis migrationskritisch ist (Bisbal et al. 1999; Sneed 1995).
+
+Damit ist das Fundament gelegt, um in Kapitel 3 den konkreten Fallkontext zu beschreiben und in Kapitel 4 ein Vorgehensmodell zu entwickeln, das KI-Unterstützung, Traceability und Validierung systematisch miteinander verbindet.
+
+## Literatur
+
+- Bender, E. M.; Gebru, T.; McMillan-Major, A.; Shmitchell, S. (2021): *On the Dangers of Stochastic Parrots*. Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency (FAccT). https://doi.org/10.1145/3442188.3445922
+- Breiman, L. (2001): *Random Forests*. Machine Learning. https://doi.org/10.1023/A:1010933404324
+- Bishop, C. M. (2006): *Pattern Recognition and Machine Learning*. Springer. https://link.springer.com/book/9780387310732
+- Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J. (1997): *An overview of legacy information system migration*. APSEC/ICSC. https://doi.org/10.1109/apsec.1997.640219
+- Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J. (1999): *Legacy information systems: issues and directions*. IEEE Software. https://doi.org/10.1109/52.795108
+- Borg, M.; Runeson, P.; Ardö, A. (2013): *Recovering from a decade: a systematic mapping of information retrieval approaches to software traceability*. Empirical Software Engineering. https://doi.org/10.1007/s10664-013-9255-y
+- Chikofsky, E. J.; Cross, J. H. (1990): *Reverse engineering and design recovery: a taxonomy*. IEEE Software. https://doi.org/10.1109/52.43044
+- Cortes, C.; Vapnik, V. (1995): *Support-vector networks*. Machine Learning. https://doi.org/10.1007/BF00994018
+- Fan, A.; Gokkaya, B.; Harman, M.; Lyubarskiy, M. (2023): *Large Language Models for Software Engineering: Survey and Open Problems*. ICSE-FoSE. https://doi.org/10.1109/icse-fose59343.2023.00008
+- Fantechi, A.; Gnesi, S.; Passaro, L.; Semini, L. (2023): *Inconsistency Detection in Natural Language Requirements using ChatGPT: a Preliminary Evaluation*. IEEE Requirements Engineering Conference (RE). https://doi.org/10.1109/re57278.2023.00045
+- Friedman, J. H. (2001): *Greedy function approximation: A gradient boosting machine*. The Annals of Statistics. https://doi.org/10.1214/AOS/1013203451
+- Goodfellow, I.; Bengio, Y.; Courville, A. (2016): *Deep Learning*. MIT Press. https://www.deeplearningbook.org/
+- Glinz, M. (2007): *On Non-Functional Requirements*. 15th IEEE International Requirements Engineering Conference (RE 2007). https://doi.org/10.1109/re.2007.45
+- Glinz, M. (2008): *A Risk-Based, Value-Oriented Approach to Quality Requirements*. IEEE Software. https://doi.org/10.1109/ms.2008.31
+- Gotel, O.; Finkelstein, A. (1994): *An analysis of the requirements traceability problem*. International Conference on Requirements Engineering (ICRE). https://doi.org/10.1109/icre.1994.292398
+- Hastie, T.; Tibshirani, R.; Friedman, J. (2009): *The Elements of Statistical Learning* (2nd ed.). Springer. https://hastie.su.domains/ElemStatLearn/
+- Hemmat, A.; Sharbaf, M.; Kolahdouz-Rahimi, S.; Lano, K.; Tehrani, S. Y. (2025): *Research directions for using LLM in software requirement engineering: a systematic review*. Frontiers in Computer Science. https://doi.org/10.3389/fcomp.2025.1519437
+- IEEE (1998): *IEEE Std 830-1998 – Recommended Practice for Software Requirements Specifications*. https://standards.ieee.org/standard/830-1998.html
+- ISO/IEC (2011): *ISO/IEC 25010:2011 – Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models*. https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
+- ISO/IEC/IEEE (2018): *ISO/IEC/IEEE 29148:2018 – Systems and software engineering — Life cycle processes — Requirements engineering*. https://www.iso.org/standard/72089.html
+- Ji, Z.; Lee, N.; Frieske, R.; Yu, T.; et al. (2023): *Survey of Hallucination in Natural Language Generation*. ACM Computing Surveys. https://doi.org/10.1145/3571730
+- Kotonya, G.; Sommerville, I. (1996): *Requirements engineering with viewpoints*. Software Engineering Journal. https://doi.org/10.1049/sej.1996.0002
+- Kratzke, N.; Quint, P.-C. (2017): *Understanding cloud-native applications after 10 years of cloud computing - A systematic mapping study*. Journal of Systems and Software. https://doi.org/10.1016/j.jss.2017.01.001
+- LeCun, Y.; Bengio, Y.; Hinton, G. (2015): *Deep learning*. Nature. https://doi.org/10.1038/nature14539
+- Lawrence, B.; Wiegers, K.; Ebert, C. (2001): *The top risk of requirements engineering*. IEEE Software. https://doi.org/10.1109/52.965804
+- Lewis, P.; Perez, E.; Piktus, A.; Petroni, F.; et al. (2020): *Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks*. arXiv:2005.11401. https://arxiv.org/abs/2005.11401
+- Luitel, D.; Hassani, S.; Sabetzadeh, M. (2024): *Improving requirements completeness: automated assistance through large language models*. Requirements Engineering. https://doi.org/10.1007/s00766-024-00416-3
+- Marczak-Czajka, A.; Cleland-Huang, J. (2023): *Using ChatGPT to Generate Human-Value User Stories as Inspirational Triggers*. IEEE REW. https://doi.org/10.1109/rew57809.2023.00016
+- Marques, N.; Silva, R. R.; Bernardino, J. (2024): *Using ChatGPT in Software Requirements Engineering: A Comprehensive Review*. Future Internet. https://doi.org/10.3390/fi16060180
+- Norheim, J. J.; Rebentisch, E. (2024): *Structuring Natural Language Requirements with Large Language Models*. IEEE REW. https://doi.org/10.1109/rew61692.2024.00013
+- Nouri, A.; Cabrero-Daniel, B.; Törner, F.; Sivencrona, H. (2024): *Engineering Safety Requirements for Autonomous Driving with Large Language Models*. IEEE RE. https://doi.org/10.1109/re59067.2024.00029
+- Okamoto, R.; Kusumoto, S. (2025): *Towards the Automatic Restructuring of Software Requirements Specifications to Conform to Standards Using Large Language Models*. IEEE RE. https://doi.org/10.1109/re63999.2025.00056
+- OpenAI (2023): *GPT-4 Technical Report*. arXiv:2303.08774. https://arxiv.org/abs/2303.08774
+- Pahl, C.; Jamshidi, P. (2016): *Microservices: A Systematic Mapping Study*. CLOSER / Cloud Computing and Services Science. https://doi.org/10.5220/0005785501370146
+- Pohl, K. (2010): *Requirements Engineering: Fundamentals, Principles, and Techniques*. Springer. https://doi.org/10.1007/978-3-642-12578-2
+- Ramesh, B.; Jarke, M. (2001): *Toward reference models for requirements traceability*. IEEE Transactions on Software Engineering. https://doi.org/10.1109/32.895989
+- Rozière, B.; et al. (2023): *Code Llama: Open Foundation Models for Code*. arXiv:2308.12950. https://arxiv.org/abs/2308.12950
+- Ruan, K.; Chen, X.; Jin, Z. (2023): *Requirements Modeling Aided by ChatGPT: An Experience in Embedded Systems*. IEEE REW. https://doi.org/10.1109/rew57809.2023.00035
+- Salem, N.; Hudaib, A.; Al-Tarawneh, K.; Salem, H. (2024): *A survey on the application of large language models in software engineering*. Computer Research and Modeling. https://doi.org/10.20537/2076-7633-2024-16-7-1715-1726
+- Hassani, S. (2024): *Enhancing Legal Compliance and Regulation Analysis with Large Language Models*. IEEE RE. https://doi.org/10.1109/re59067.2024.00065
+- Security in Legacy Systems Migration to the Cloud (2014): *Security in Legacy Systems Migration to the Cloud: A Systematic Mapping Study*. Proceedings of the 11th International Workshop on Security in Information Systems. https://doi.org/10.5220/0004979900260037
+- Sneed, H. M. (1995): *Planning the reengineering of legacy systems*. IEEE Software. https://doi.org/10.1109/52.363168
+- Storey, M.-A. (2005): *Theories, methods and tools in program comprehension: past, present and future*. International Workshop on Program Comprehension (IWPC). https://doi.org/10.1109/wpc.2005.38
+- Tahvildari, L.; Kontogiannis, K.; Mylopoulos, J. (2001): *Requirements-driven software re-engineering framework*. Working Conference on Reverse Engineering (WCRE). https://doi.org/10.1109/wcre.2001.957811
+- Vaswani, A.; Shazeer, N.; Parmar, N.; Uszkoreit, J.; et al. (2017): *Attention Is All You Need*. arXiv:1706.03762. https://arxiv.org/abs/1706.03762
+- Wei, J.; Wang, X.; Schuurmans, D.; Bosma, M.; et al. (2022): *Chain-of-Thought Prompting Elicits Reasoning in Large Language Models*. arXiv:2201.11903. https://arxiv.org/abs/2201.11903
+- Wu, B.; Lawless, D.; Bisbal, J.; Grimson, J. (1997): *Legacy systems migration - a method and its tool-kit framework*. APSEC/ICSC. https://doi.org/10.1109/apsec.1997.640188
+- Yu, Y.; Mylopoulos, J.; Wang, Y.; Liaskos, S.; et al. (2005): *RETR: Reverse Engineering to Requirements*. Working Conference on Reverse Engineering (WCRE). https://doi.org/10.1109/wcre.2005.27
+- Zhao, L.; Alhoshan, W.; Ferrari, A.; Letsholo, K. J. (2021): *Natural Language Processing for Requirements Engineering*. ACM Computing Surveys. https://doi.org/10.1145/3444689
+- arXiv (2024): *Large Language Models for Software Engineering: A Systematic Literature Review*. arXiv:2308.10620. https://arxiv.org/abs/2308.10620
+- arXiv (2024): *A Survey on Large Language Models for Software Engineering*. arXiv:2312.15223. https://arxiv.org/abs/2312.15223

prompts.md

@@ -0,0 +1,3 @@
+# Prompt für Req analysts quellensuche:
+Lies die anghängten Dateien. Diese sind teil meiner Masterarbeit. ERstelle jetzt under disem Kontext eine Zusammenfassung der angegebenen Quellen. Suche danach nach weiteren aktuellen Quellen die mit den Themen (Requirements Engineering für Software und im zusammenhang mit Ki) stehen. ERstelle mir auch hier eine Zusammenfassung der Artikel die du gefdunen hast.
+Wichtig!! Es geht hier um wissenschaftliches Arbeiten. Konzentriere dich auf wissenschaftliche Artikel und Quellen. Und bitte gib auch die Quellen immer mit an