Kapitel 2 draft

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.