Commit

.gitignore

@@ -0,0 +1 @@
+

Kapitel/00_abstract.typ

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

Kapitel/01_einleitung.typ

@@ -1,20 +1,22 @@
 #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.
+In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre Produkte neu zu bewerten. Betroffen sind vor allem Systeme die über lange Jahre nur in Windows-Umgebungen vertrieben wurden. Diese stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen und fallen in der technologischen Schuld immer weiter Zurück. Eine technologische Weiterentwicklung ist nicht möglich und an einer Neuentwicklung führt oft kein Weg vorbei. Dokumentierte Anforderungen und Code sind allerdings selten. Das meiste Wissen steckt implizit im Code oder in der Köpfen der verlbeibenden Entwickler.
 
-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.
+Die c-entron GmbH in Ulm ist von diesem Szenario voll Betroffen. 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 erwarten zwischenzeitlich aber plattformunabhängige Oberflächen, Self-Service-Funktionen und flexible Betriebsmodelle wie z.B. SaaS (Software as a Service). Die bestehende Anwendung ist aber in ihrer Skalierung, Deployment und Abrechnung limitiert. Eine Migration auf eine webbasierte Plattform ist somit zwingend erforderlich. 
 
-Parallel dazu hat sich ein neues Instrumentarium etabliert. Large Language Models wie Chat GPT-5 oder Claude.ai können große durch agentische CLIs (Codex, Claude Code) große Mengen an 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.
+Eine einfache Neuimplementierung auf Basis vorhandener Anfoderungs oder Code Dokumentation ist aber aus oben geschilderten Gründen nicht einfach möglich. Die Herausforderung die sich stellt ist mit möglichst geringem Aufwand eine vollständige Beschreibung für ein vollständiges ERP System zu erarbeiten. Eine Manuelle auswertung des Codes oder Obfläche auf Funktionalitäten ist aufgrund der extremen Komplexität, geschuldet der langjährgien Weiterententwicklung, nur mit sehr hohem Personalaufwand möglich und daher nicht realsierbar.
+
+In den letzen Jahren hat sich hierzu nun ein neues Instrumentarium etabliert. Large Language Models wie Chat GPT-5 oder Claude.ai können durch agentische CLIs (Codex, Claude Code) große Mengen an Quellcode analysieren, Anforderungen erarbeiten 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. Diese Arbeit adressiert dies und untersucht, wie KI-gestützte Verfahren für eine systematische Anforderunganalyse eingesetzt werden können.
 
 #heading(level: 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 das ERP Software Produkt der c-entron fehlen strukturierte und dokumentierte Requirements. Die Analyse der bestehenden Codebasis ist zeitintensiv, ressourcenintensiv und anfällig für Insel- und Metawissen. Daraus ergeben sich mehrere Risiken:
 
-- **Re-Implementationsfehler:** Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration.
+- **Re-Implementationsfehler:** Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration. Zeitgleich sind Workaround of Symptom einer mangelhaften Erfassung der Anfoderungen bei originalen Implementierung und ein zeichen fehlender Weitsicht.
-- **Technische Schuld:** Entwickler:innen investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen.
+- **Technische Schuld:** Entwickler investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen. Neue Mitarbeiter sind auch nicht bewandt in alten technolgien und es fehlt das Verständnis für historische Zwänge und Zusammenhänge.
-- **Implizites Wissen:** Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen.
+- **Implizites Wissen:** Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen. Gleichzeitig führt die langjährige arbeit mit dem bestehenden System zu eingeschränkter Offenheit beim design neuer Lösungen ("Das haben wir schon immer so umgestzt").
 - **Komplexität der Codebasis:** Verschachtelte Abhängigkeiten, unterschiedliche Stile und technologiebedingte Zwänge erschweren eine modulare Anforderungsableitung.
-- **Fehlende Traceability:** Ohne Zuordnung zwischen Code und Geschäftsprozess fehlt die Grundlage für Priorisierung, Testkonzeption und spätere Wartung.
+- **Fehlende Traceability:** Ohne Zuordnung zwischen Code und Geschäftsprozess fehlt die Grundlage für Priorisierung, Testkonzeption und spätere Wartung. Große Teile des Codes sind auch generisch und lassen sich nicht einer konkreten Anforderung zuordnen, wie zum Beispiel das anzeigen eine Tabelle. Konkrete Datenflüsse lassen sich hier nur am laufenden System beobachten was die Analyse nochmal um eine Größenordnung Resourcenintensiver macht.
 
 Eine rein manuelle Rekonstruktion aller Anforderungen wäre wirtschaftlich kaum tragbar. Deshalb soll geprüft werden, ob KI-gestützte Verfahren Requirements so extrahieren können, dass sie als belastbare Basis für die Modernisierung dienen.
 
@@ -23,29 +25,28 @@ Diese Arbeit verfolgt das Ziel, ein vollständiges Vorgehen für KI-gestütztes
 
 - Entwicklung eines Prozessmodells, das Vorbereitung, Analyse, Validierung und Übergabe strukturiert.
 - Evaluation aktueller LLMs hinsichtlich Kontextfenster, Codeverständnis, Steuerbarkeit, Kosten und Datenschutz.
-- Durchführung und Vergleich von drei Claude-Code-basierten Versuchen (V01-V03) mit unterschiedlicher Tooling-Tiefe (Prompt-only, Agenten, Agenten+MCP).
+- Durchführung und Vergleich von drei Claude-Code basierten Versuchen mit unterschiedlicher Tooling-Tiefe (Prompt-only, Agenten, Agenten+MCP).
-- 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).
-- Formulierung konkreter Handlungsempfehlungen für die c-entron GmbH sowie Übertragbarkeit auf ähnliche Unternehmen.
+- Integration von Stakeholder-Wissen durch Interviews, um die Qualität der KI ergebnisse zu bewerten und nicht direkt aus dem Code ableitbare Anforderungen zu ergänzen .
+
 
 #heading(level: 2)[Forschungsleitfragen]
 Die Zielsetzung wird über vier Forschungsleitfragen strukturiert:
 
-- **F1 - Einsatz von LLMs im Reverse Requirements Engineering:** Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?
+1. ***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?
+2. ***Kombination von KI-Analyse und Stakeholder-Input:*** Welche funktionalen und nicht-funktionalen Anforderungen lassen sich aus Code extrahieren, und welche Informationen müssen über Interviews ergänzt werden?
-- **F3 - Qualitätsbewertung der generierten Requirements:** Wie beurteilen Fachexperten Vollständigkeit, Verständlichkeit, Nützlichkeit und Aufwandseinsparung der KI-Ergebnisse?
+3. ***Qualitätsbewertung der generierten Requirements:*** Wie beurteilen Fachexperten 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?
+4. ***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?
 
 #heading(level: 2)[Aufbau der Arbeit]
-Die Arbeit ist in acht Kapitel gegliedert und folgt dem in den Vorlagen üblichen Aufbau:
+Die Arbeit ist in acht Kapitel gegliedert:
 
-1. **Einleitung:** Kontext, Problemstellung, Ziele und Forschungsfragen.
+1. ***Einleitung:*** Kontext, Problemstellung, Ziele und Forschungsfragen.
-2. **Theoretische Grundlagen:** Requirements Engineering, Reverse Engineering, Large Language Models sowie Qualitätssicherungskriterien.
+2. ***Theoretische Grundlagen:*** Requirements Engineering, Reverse Engineering, Large Language Models sowie Qualitätssicherungskriterien.
-3. **Fallstudie c-entron GmbH:** Unternehmensprofil, Produktarchitektur, Migrationsdruck und Rahmenbedingungen.
+3. ***Fallstudie c-entron GmbH:*** Unternehmensprofil, Produktarchitektur, Migrationsdruck und Rahmenbedingungen.
-4. **Konzeption und methodisches Vorgehen:** Prozessmodell, Technologieauswahl, Stakeholder-Einbindung und Datenbasis.
+4. ***Konzeption und methodisches Vorgehen:*** Prozessmodell, Technologieauswahl, Stakeholder-Einbindung und Datenbasis.
-5. **Ergebnisse:** Vollständige Ergebnisdarstellung der drei Versuche inkl. Artefaktlisten und beispielhafter Requirements/Use Cases aus den Ergebnisverzeichnissen.
+5. ***Ergebnisse:*** Vollständige Ergebnisdarstellung der drei Versuche inkl. Artefaktlisten und beispielhafter Requirements/Use Cases aus den Ergebnisverzeichnissen.
-6. **Evaluation:** Vorgehen, Metriken, Ergebnisse und Expertenfeedback.
+6. ***Evaluation:*** Vorgehen, Metriken, Ergebnisse und Expertenfeedback.
-7. **Diskussion:** Interpretation der Resultate, Limitationen und Implikationen für Forschung und Praxis.
+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.
+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.

Kapitel/02_theoretischer_hintergrund.typ

@@ -6,24 +6,26 @@
 
 #heading(level: 1)[Theoretische Grundlagen (ca. 12 Seiten)]
 
-Dieses Kapitel beschreibt die theoretischen Grundlagen, die für die Konzeption und Bewertung eines KI-gestützten Reverse Requirements Engineering in Legacy-Umgebungen benötigt werden. Zunächst werden zentrale 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.
+Dieses Kapitel beschreibt die theoretischen Grundlagen, die für die Konzeption und Bewertung eines KI-gestützten Reverse Requirements Engineering in Legacy-Umgebungen benötigt werden. Zunächst werden zentrale Themen des Requirements Engineerings sowie die Idee des reverse Requirements Engineerings auf Basis bestehender Systeme eingeordnet. Anschließend werden Large Language Models und deren Einsatz im Software Engineering 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  einzuordnen.
 
 #heading(level: 2)[Requirements Engineering und Reverse Requirements Engineering]
 
 #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.
+der Begriff 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:
+Im Kern adressiert das Requirments Engineering zwei Themen:
 
-- **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.
+- ***Kommunikation zwischen Domäne und Technik:*** Anforderungen müssen fachlich verständlich und gleichzeitig so präzise sein, dass sich daraus eine Software-Architektur ableiten lässt, die implementiert, getestet und geändert werden kann.
-- **Umgang mit Unsicherheit und Wandel:** Anforderungen sind zu Projektbeginn selten vollständig. RE ist daher nicht nur Dokumentation, sondern ein iterativer Klärungs- und Abstimmungsprozess.
+- ***Umgang mit Unsicherheit und Wandel:*** Anforderungen sind zu Projektbeginn selten vollständig. Requriements Engingeeing ist daher nicht nur Dokumentation, sondern auch 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).
+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).
+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 scharf 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 das 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.
 

Masterarbeit_draft.typ

@@ -4,7 +4,7 @@
   "KI-gestütztes Reverse Requirements Engineering bei Legacy-Software",
   "Masterarbeit an der Hochschule Neu-Ulm",
   "Christoph Schwörer",
-  "Master of Science",
+  "Master of Business Administration",
   "Prof. Dr. Daniel Schallmo",
   "XX 2026"
 )