Versuche und Ergebnisse Umstrukturiert
This commit is contained in:
@@ -2,168 +2,419 @@
|
||||
#if __is_thesis == false [
|
||||
#set cite(style: "apa")
|
||||
#hide(bibliography("../literatur.bib", style: "apa"))
|
||||
// Fallback for standalone preview of this chapter (without global thesis style).
|
||||
#show raw: set text(font: "DejaVu Sans Mono", size: 9.5pt, fill: luma(20))
|
||||
#show raw.where(block: true): it => block(
|
||||
width: 100%,
|
||||
fill: luma(240),
|
||||
stroke: 0.5pt + luma(190),
|
||||
inset: 9pt,
|
||||
radius: 4pt,
|
||||
above: 0.8em,
|
||||
below: 0.8em,
|
||||
it,
|
||||
)
|
||||
]
|
||||
|
||||
#heading(level: 1)[Konzeption und methodisches Vorgehen (ca. 12 Seiten)]
|
||||
|
||||
Dieses Kapitel beschreibt das Forschungsdesign und das Vorgehensmodell der Arbeit. Ziel ist es, den Einsatz von Large Language Models (LLMs) für Reverse Requirements Engineering so zu strukturieren, dass Ergebnisse nachvollziehbar, überprüfbar und reproduzierbar sind. Hierzu wird zunächst das Forschungsdesign als Fallstudie im Unternehmenskontext eingeordnet. Anschließend wird ein Prozessmodell für KI-gestütztes Reverse Requirements Engineering entwickelt. Abschließend werden Kriterien zur Technologieauswahl, Modellkonfiguration sowie die Einbindung von Stakeholdern und die Datengrundlage beschrieben.
|
||||
Dieses Kapitel beschreibt die tatsaechlich durchgefuehrte Methodik mit Fokus auf Claude Code als zentralem Arbeitswerkzeug. Alle Informationen sind versuchsweise gebuendelt dargestellt, sodass pro Versuch die Konfiguration, die Prompts, die eingesetzten Tools und die resultierenden Artefakte geschlossen nachvollziehbar sind.
|
||||
|
||||
#heading(level: 2)[Forschungsdesign und Vorgehensmodell]
|
||||
#heading(level: 2)[Claude Code als Werkzeug]
|
||||
|
||||
#heading(level: 3)[Einordnung als Fallstudie und Artefaktentwicklung]
|
||||
Claude Code wurde in dieser Arbeit als lokales Analysewerkzeug genutzt: ueber die CLI im Projektarbeitsverzeichnis und ueber die VS-Code-Einbindung. Die Arbeitslogik folgt einem schrittweisen Ausbau:
|
||||
|
||||
Die Arbeit ist als anwendungsnahe Untersuchung im Kontext einer konkreten Legacy-Modernisierung angelegt. Der Kernbeitrag besteht nicht nur in einer Beschreibung von LLM-Fähigkeiten, sondern in der Entwicklung eines Vorgehens, das unter realistischen Randbedingungen (große Codebasis, heterogene Artefakte, begrenzte Expertenzeit) umsetzbar ist. Das Forschungsdesign kombiniert daher:
|
||||
- Baseline nur mit Prompt + CLI (Versuch 01),
|
||||
- Spezialisierung ueber Agenten-Dateien (Versuch 02),
|
||||
- Erweiterung um MCP-Server fuer zusaetzliche Tool- und Datenzugriffe (Versuch 03).
|
||||
|
||||
1. **Literaturbasierte Fundierung:** Ableitung von Anforderungen an Requirements-Qualität, Traceability und Qualitätskriterien @iso29148_2018 @ieee830_1998.
|
||||
2. **Artefaktentwicklung:** Konzeption eines reproduzierbaren Prozessmodells für KI-gestütztes Reverse Requirements Engineering.
|
||||
3. **Prototypische Umsetzung:** Implementationsnahe Ausgestaltung des Prozesses als Agenten-/Toolchain-Workflow.
|
||||
4. **Fallbezogene Evaluation:** Überprüfung der Praktikabilität und der Ergebnisqualität durch Review und Abgleich mit Artefakten und Expertenwissen.
|
||||
Technisch wurde Claude Code entlang der offiziellen Dokumentation eingesetzt:
|
||||
|
||||
Diese Kombination ist notwendig, weil LLM-Ergebnisse im Requirements-Kontext nur dann einen belastbaren Nutzen stiften, wenn sie in einen Prozess eingebettet sind, der Belege, Unsicherheit und Validierung explizit adressiert. LLM-Ausgaben werden daher nicht als Spezifikation „an sich“ betrachtet, sondern als Zwischenartefakte, die über Belegpflicht und Review zu Requirements konsolidiert werden.
|
||||
- Session-Start und Ausfuehrung ueber CLI (`claude`, `claude -p`),
|
||||
- lokale IDE-Anbindung in VS Code,
|
||||
- Einbindung externer MCP-Server ueber das `claude mcp`-Konzept,
|
||||
- Nutzung des MCP-Scopes fuer projektspezifische Tool-Konfigurationen.
|
||||
|
||||
#heading(level: 3)[Datenerhebung, Artefaktanalyse und Auswertungslogik]
|
||||
Die technische Einordnung stuetzt sich auf die offizielle Claude-Code-Dokumentation zu Quickstart, CLI-Nutzung, IDE-Integration und MCP sowie auf das Produktupdate zu Remote MCP @claudecode_quickstart_2026 @claudecode_cli_2026 @claudecode_ide_2026 @claudecode_mcp_2026 @anthropic_remote_mcp_2025.
|
||||
|
||||
Die Datengrundlage der Arbeit ist artefaktzentriert. Der Ausgangspunkt ist die bestehende Legacy-Codebasis und die zugehörigen projektinternen Artefakte. Die Analyse folgt einer Logik aus (1) technischer Faktenerhebung und (2) semantischer Interpretation:
|
||||
Damit fungiert Claude Code in dieser Arbeit nicht nur als Chat-Interface, sondern als orchestrierender Agent-Laufzeitkontext fuer Prompting, rollenbasierte Agenten und MCP-basierte Toolaufrufe.
|
||||
|
||||
- **Faktenerhebung:** Identifikation von Komponenten, Datenobjekten, Schnittstellen und Regelstellen (z. B. Validierungen, Statuswechsel, Rechteprüfungen).
|
||||
- **Semantische Interpretation:** Ableitung fachlicher Aussagen aus den Fakten (z. B. „Ein Auftrag darf nur fakturiert werden, wenn …“).
|
||||
- **Formalisierung:** Überführung in Requirements mit Akteur, Vorbedingung, Ergebnis und Prüfidee.
|
||||
- **Absicherung:** Zuordnung von Belegen und Review durch Domänenexperten.
|
||||
#heading(level: 2)[Versuch 01]
|
||||
|
||||
Für die Auswertung ist wichtig, dass die Arbeit nicht versucht, „Vollständigkeit“ absolut zu beweisen. Stattdessen wird eine risikobasierte Perspektive gewählt: Requirements werden dort vertieft und geprüft, wo Migration, Sicherheit oder Datenintegrität besonders kritisch sind. Diese Priorisierung ist anschlussfähig an die RE-Literatur, die Qualitätsanforderungen als risikobasiert zu behandeln empfiehlt @glinz2008quality.
|
||||
#heading(level: 3)[Allgemeine Beschreibung]
|
||||
|
||||
#heading(level: 3)[Gütekriterien: Nachvollziehbarkeit, Prüfbarkeit, Reproduzierbarkeit]
|
||||
Versuch 01 bildet die Baseline ohne Agenten und ohne MCP. Ziel war eine erste formale Requirements-Extraktion direkt aus der Codebasis mit minimaler Tooling-Komplexitaet.
|
||||
|
||||
Im Requirements Engineering gelten Kriterien wie Eindeutigkeit, Konsistenz, Vollständigkeit, Verifizierbarkeit und Traceability als zentrale Qualitätsmerkmale @iso29148_2018. Für KI-gestützte Extraktion wird diese Liste operationalisiert, um überprüfbare Prozessanforderungen zu erhalten. Für die Arbeit sind besonders relevant:
|
||||
#heading(level: 3)[Konfiguration]
|
||||
|
||||
- **Traceability:** Jedes extrahierte Requirement muss auf Artefakte zurückgeführt werden können (Code, Konfiguration, Datenobjekt, UI-Text). Traceability ist in der Literatur als zentrales, dauerhaftes Problemfeld beschrieben und wird als Voraussetzung für belastbare Weiterentwicklung betrachtet @gotel1994traceability @ramesh2001traceability.
|
||||
- **Prüfbarkeit:** Requirements werden so formuliert, dass eine Testidee oder ein Abnahmekriterium ableitbar ist.
|
||||
- **Reproduzierbarkeit:** Prompting-Strategien, Kontextauswahl und Parameter werden dokumentiert, sodass Analysen unter gleichen Bedingungen wiederholbar sind.
|
||||
- Claude Code CLI lokal im Projektverzeichnis,
|
||||
- Nutzung aus VS Code (integriertes Terminal),
|
||||
- keine Agenten-Dateien,
|
||||
- keine MCP-Server.
|
||||
|
||||
LLMs erzeugen nicht-deterministische Ausgaben. Deshalb wird im Vorgehensmodell eine „Kontrollspur“ vorgesehen: Kontextquellen, Promptversionen und Resultate werden versioniert, und Unsicherheit wird explizit markiert, um spätere Überprüfung zu ermöglichen. Der Umgang mit Halluzinationen ist dabei ein zentrales Risiko, da plausible Texte fachlich falsch sein können @ji2023hallucination.
|
||||
#heading(level: 3)[Verwendeter Prompt]
|
||||
|
||||
#heading(level: 2)[Prozessmodell für KI-gestütztes Reverse Requirements Engineering]
|
||||
```text
|
||||
Please analyze this software project and write a reuqirements specification according to modern standards.
|
||||
```
|
||||
|
||||
#heading(level: 3)[Prozessüberblick und Rollen]
|
||||
#heading(level: 3)[Tools und Artefakte]
|
||||
|
||||
Das Prozessmodell strukturiert die Arbeit in Phasen, die wiederholbar durchlaufen werden können. Es unterscheidet technische und fachliche Rollen:
|
||||
- Tooling: Claude Code CLI + VS Code Integration.
|
||||
- Ergebnisfokus: formale Requirements-Spezifikation (StRS/SyRS/SwRS) mit hoher Strukturierungsdichte.
|
||||
|
||||
- **Analyseverantwortlicher:** Steuert Scope, Artefaktauswahl und Toolchain.
|
||||
- **Domänenexperte:** Validiert fachliche Bedeutung, Ausnahmen und Prioritäten.
|
||||
- **Entwicklung/Architektur:** Nutzt konsolidierte Requirements als Basis für Zielarchitektur und Umsetzung.
|
||||
#heading(level: 3)[Beispielhafte Ergebnisanforderungen]
|
||||
|
||||
Der Prozess besteht aus sieben Phasen, die iterativ angewendet werden:
|
||||
Quelle: `Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md`
|
||||
|
||||
1. **Scope und Domänenabgrenzung**
|
||||
2. **Artefakterhebung und Kontextaufbereitung**
|
||||
3. **Technische Analyse (Struktur, Daten, Schnittstellen)**
|
||||
4. **Retrieval und Kontextsteuerung (RAG)**
|
||||
5. **Requirements-Extraktion und Strukturierung**
|
||||
6. **Traceability-Anreicherung und Unsicherheitsmarkierung**
|
||||
7. **Review, Konsolidierung und Übergabe**
|
||||
```text
|
||||
### StR-001: Comprehensive Customer Account Management
|
||||
**Statement**: The system shall provide comprehensive customer account management capabilities including contact information, relationship mapping, interaction history, and account hierarchy management.
|
||||
```
|
||||
|
||||
#heading(level: 3)[Artefaktpipeline: Sammeln, Normalisieren, Indexieren]
|
||||
```text
|
||||
### SyR-001
|
||||
The system SHALL implement a multi-layered architecture with clear separation of concerns.
|
||||
```
|
||||
|
||||
Die zentrale technische Voraussetzung ist eine Artefaktpipeline, die die Codebasis und flankierende Quellen in eine Form überführt, die sowohl maschinell suchbar als auch für LLMs nutzbar ist. Die Pipeline umfasst:
|
||||
#heading(level: 3)[Einordnung]
|
||||
|
||||
- **Sammeln:** Repository, Konfigurationen, UI-Texte, Datenbankschemata, Tickets, Release Notes.
|
||||
- **Normalisieren:** Extraktion von Metadaten (Pfad, Modul, Änderungsdatum), Entfernen von Rauschen (Build-Artefakte), Vereinheitlichung von Encodings.
|
||||
- **Segmentieren:** Zerlegung großer Dateien in semantische Chunks (z. B. pro Klasse, Methode, SQL-Statement).
|
||||
- **Indexieren:** Aufbau eines Suchindex (klassisch oder embeddings-basiert) zur späteren Kontextauswahl.
|
||||
Die Baseline zeigt, dass bereits ohne Agenten/MCP belastbare, formal strukturierte Anforderungen erzeugbar sind. Gleichzeitig bleibt die Discovery-Breite begrenzt.
|
||||
|
||||
Die Segmentierung ist entscheidend, weil LLMs nur ein begrenztes Kontextfenster besitzen. Eine „Alles-in-einen-Prompt“-Strategie skaliert nicht. Retrieval-Augmented Generation (RAG) adressiert dieses Problem, indem relevante Textstellen gezielt in den Prompt geladen werden @lewis2020rag.
|
||||
#heading(level: 2)[Versuch 02]
|
||||
|
||||
#heading(level: 3)[Prompt- und Output-Templates für Requirements]
|
||||
#heading(level: 3)[Allgemeine Beschreibung]
|
||||
|
||||
Um Ergebnisse konsistent auszuwerten, werden Requirements in einem festen Template erzeugt. Ein zweckmäßiges Format umfasst:
|
||||
Versuch 02 fokussiert die ISO-29148-orientierte Konsolidierung. Dazu wurde Claude Code weiterhin lokal genutzt, jedoch um spezialisierte Agenten-Dateien erweitert.
|
||||
|
||||
- **ID**
|
||||
- **Titel**
|
||||
- **Akteur/Rolle**
|
||||
- **Vorbedingungen**
|
||||
- **Beschreibung des Verhaltens**
|
||||
- **Akzeptanzkriterien**
|
||||
- **Belege (Artefaktverweise)**
|
||||
- **Unsicherheitsmarker / offene Fragen**
|
||||
#heading(level: 3)[Konfiguration]
|
||||
|
||||
Dieses Template reduziert Interpretationsspielraum und macht Reviews effizienter. Es adressiert zudem ein zentrales Risiko: LLMs können sprachlich „glatte“ Requirements erzeugen, die jedoch ohne Belege und Akzeptanzkriterien nicht belastbar sind. Der Prozess erzwingt daher eine Belegpflicht und die Ableitung von Prüfkriterien als Standardausgabe.
|
||||
- Claude Code CLI lokal + VS Code,
|
||||
- agentenbasierte Spezialisierung ueber MD-Dateien in `Versuche/Versuch 02/Tools/agents/`,
|
||||
- kein MCP-Fokus in diesem Lauf.
|
||||
|
||||
#heading(level: 3)[Kontrollpunkte und Fehlerbegrenzung]
|
||||
#heading(level: 3)[Verwendeter Prompt]
|
||||
|
||||
Die Prozesskontrollen sind so gewählt, dass typische LLM-Fehlermuster begrenzt werden:
|
||||
```text
|
||||
Please analyze this software project and write a ISO 29148 compliant reuqirements specification.
|
||||
Use Agents wherever possible.
|
||||
```
|
||||
|
||||
- **Belegpflicht:** Keine Requirements ohne Artefaktbezug.
|
||||
- **Konfliktprüfung:** Abgleich widersprüchlicher Aussagen über mehrere Belegstellen.
|
||||
- **Unsicherheitskennzeichnung:** Hypothesen werden explizit markiert und priorisiert geprüft.
|
||||
- **Human-in-the-loop:** Fachliche Validierung als fester Schritt, nicht als optionales „Nachlesen“.
|
||||
#heading(level: 3)[Tools und Agenten]
|
||||
|
||||
Diese Kontrollen sind notwendig, weil Halluzinationen und Bias-Risiken in der LLM-Literatur als strukturelle Probleme beschrieben werden @bender2021stochastic @ji2023hallucination. Für Requirements bedeutet dies, dass Prozessqualität und Governance nicht nachgelagert, sondern integraler Bestandteil sein müssen.
|
||||
Beispiele aus dem Versuchsordner:
|
||||
|
||||
#heading(level: 2)[Technologieauswahl und LLM-Konfiguration]
|
||||
- `iso29148-master-orchestrator-agent.md`
|
||||
- `iso29148-stakeholder-agent.md`
|
||||
- `iso29148-system-requirements-agent.md`
|
||||
- `iso29148-software-requirements-agent`
|
||||
|
||||
#heading(level: 3)[Auswahlkriterien für Modelle und Betriebsform]
|
||||
#heading(level: 3)[Agentenbeispiel (Auszug, erste 100 Zeilen) - Versuch 02]
|
||||
|
||||
Die Auswahl eines LLMs im Unternehmenskontext folgt nicht nur der Modellqualität, sondern auch Randbedingungen. Für diese Arbeit werden die folgenden Kriterien als handlungsleitend betrachtet:
|
||||
Quelle: `Versuche/Versuch 02/Tools/agents/iso29148-master-orchestrator-agent.md`
|
||||
|
||||
- **Kontextfenster und Eingabekosten:** Große Artefakte erfordern Segmentierung; zu kleine Kontextfenster erhöhen den Retrieval-Aufwand.
|
||||
- **Codefähigkeit:** Verständnis von Identifiern, Kontrollfluss, Datenzugriffsmustern und typischen Framework-Idiomen.
|
||||
- **Steuerbarkeit:** Möglichkeiten zur Formatsteuerung (z. B. JSON-Outputs), deterministische Parameter, Prompt-Constraints.
|
||||
- **Betriebs- und Datenschutzanforderungen:** Umgang mit Quellcode als potenziell vertraulichem Material.
|
||||
- **Reproduzierbarkeit:** Versionierung von Modell, Prompt, Retrieval-Konfiguration.
|
||||
````md
|
||||
# Enhanced ISO 29148 Master Orchestrator Agent with Milestone System
|
||||
|
||||
Survey- und SLR-Arbeiten zu LLMs im Software Engineering betonen, dass Nutzen stark davon abhängt, wie Modelle in Toolchains integriert und abgesichert werden @fan2023llmse @llm4se2024slr @llm4se2024survey. Diese Perspektive prägt die Technologieauswahl in Kapitel 5.
|
||||
You are the Lead Requirements Analyst coordinating the complete ISO/IEC/IEEE 29148 requirements extraction with comprehensive documentation, quality assurance, and milestone-based execution control.
|
||||
|
||||
#heading(level: 3)[Konfiguration: Parameter und Prompting]
|
||||
## Your Mission
|
||||
Orchestrate a complete requirements analysis using all three ISO 29148 levels, ensuring consistency, completeness, and traceability. Create executive-level documentation and ensure all agents produce their complete documentation packages. **NEW**: Provide milestone-based pause/resume capabilities for long-running analyses.
|
||||
|
||||
Da LLM-Ausgaben sensitiv auf Prompting und Sampling reagieren, wird eine konservative Konfiguration gewählt:
|
||||
## CRITICAL: Documentation Requirements
|
||||
**You MUST ensure:**
|
||||
1. Each agent creates their complete documentation package
|
||||
2. You create the integrated master document
|
||||
3. All work is saved to `/docs/requirements/`
|
||||
4. Complete traceability is maintained
|
||||
5. Executive dashboards and reports are generated
|
||||
6. **NEW**: Milestone state is persisted for pause/resume functionality
|
||||
7. VERIFY each agent has created their files before proceeding
|
||||
|
||||
- **Niedrige Temperatur** zur Reduktion von Varianz.
|
||||
- **Explizite Ausgabeformate** (Templatepflicht, strukturierte Felder).
|
||||
- **Beleganforderungen** (z. B. „nennen Sie Datei + Funktion/SQL“).
|
||||
- **Stop-Kriterien** (bei fehlenden Belegen: offene Frage statt Behauptung).
|
||||
## NEW: Milestone System Architecture
|
||||
|
||||
Chain-of-Thought-Strategien können die Qualität komplexer Ableitungen steigern, erhöhen im Requirements-Kontext jedoch das Risiko, dass Begründungen als Evidenz missverstanden werden. In dieser Arbeit werden Begründungen daher nur als Hilfsmittel akzeptiert, nicht als Beleg @wei2022cot.
|
||||
### Milestone Configuration
|
||||
```json
|
||||
{
|
||||
"project_name": "[Project Name]",
|
||||
"execution_id": "[UUID]",
|
||||
"created_at": "[ISO DateTime]",
|
||||
"milestones": {
|
||||
"M0_SETUP": {
|
||||
"name": "Project Analysis and Setup",
|
||||
"status": "pending|in_progress|completed|failed",
|
||||
"started_at": null,
|
||||
"completed_at": null,
|
||||
"dependencies": [],
|
||||
"outputs": ["project_structure.json", "directory_setup.txt"]
|
||||
},
|
||||
"M1_STAKEHOLDER": {
|
||||
"name": "Stakeholder Requirements Analysis",
|
||||
"status": "pending",
|
||||
"started_at": null,
|
||||
"completed_at": null,
|
||||
"dependencies": ["M0_SETUP"],
|
||||
"outputs": [
|
||||
"StRS_Complete.md",
|
||||
"StRS_Summary.md",
|
||||
"StRS_Traceability.csv",
|
||||
"StRS_Diagrams.md",
|
||||
"StRS_Evidence.md"
|
||||
]
|
||||
},
|
||||
"M2_SYSTEM": {
|
||||
"name": "System Requirements Analysis",
|
||||
"status": "pending",
|
||||
"started_at": null,
|
||||
"completed_at": null,
|
||||
"dependencies": ["M1_STAKEHOLDER"],
|
||||
"outputs": [
|
||||
"SyRS_Complete.md",
|
||||
"SyRS_Summary.md",
|
||||
"SyRS_API_Specification.yaml",
|
||||
"SyRS_Architecture.md",
|
||||
"SyRS_Interfaces.md",
|
||||
"SyRS_Traceability.csv"
|
||||
]
|
||||
},
|
||||
"M3_SOFTWARE": {
|
||||
"name": "Software Requirements Analysis",
|
||||
"status": "pending",
|
||||
"started_at": null,
|
||||
"completed_at": null,
|
||||
"dependencies": ["M2_SYSTEM"],
|
||||
"outputs": [
|
||||
"SwRS_Complete.md",
|
||||
"SwRS_CodeCatalog.md",
|
||||
"SwRS_Algorithms.md",
|
||||
"SwRS_DataModel.md",
|
||||
"SwRS_TestSpecification.md",
|
||||
"SwRS_Traceability.csv"
|
||||
]
|
||||
},
|
||||
"M4_PATTERNS": {
|
||||
"name": "Code Pattern Analysis",
|
||||
"status": "pending",
|
||||
"started_at": null,
|
||||
"completed_at": null,
|
||||
"dependencies": ["M3_SOFTWARE"],
|
||||
"outputs": [
|
||||
"Analysis_Complete.md",
|
||||
"Pattern_Catalog.csv",
|
||||
"Business_Rules.md",
|
||||
"Validation_Rules.md",
|
||||
"Security_Patterns.md",
|
||||
"Performance_Patterns.md",
|
||||
"Integration_Patterns.md"
|
||||
]
|
||||
},
|
||||
"M5_INTEGRATION": {
|
||||
"name": "Integration and Master Documentation",
|
||||
"status": "pending",
|
||||
"started_at": null,
|
||||
"completed_at": null,
|
||||
"dependencies": ["M1_STAKEHOLDER", "M2_SYSTEM", "M3_SOFTWARE", "M4_PATTERNS"],
|
||||
````
|
||||
Hinweis: Der Auszug endet nach Zeile 100; die Originaldatei umfasst 620 Zeilen und ist an dieser Stelle nicht zu Ende.
|
||||
|
||||
#heading(level: 3)[Retrieval-Strategie und Kontextfenstersteuerung]
|
||||
#heading(level: 3)[Beispielhafte Ergebnisanforderungen]
|
||||
|
||||
RAG wird in dieser Arbeit als zentrales Skalierungsprinzip betrachtet @lewis2020rag. Die Kontextfenstersteuerung folgt einer einfachen Heuristik:
|
||||
Quellen:
|
||||
|
||||
1. Suche nach relevanten Stellen (Keywords, Identifier, Datenobjekte).
|
||||
2. Ergänzung um Nachbarschaftskontext (z. B. Aufrufer, SQL-Definition, UI-String).
|
||||
3. Begrenzung der Kontextmenge durch Ranking und Redundanzfilter.
|
||||
- `Versuche/Versuch 02/Ergenisse/system/SyRS_Complete.md`
|
||||
- `Versuche/Versuch 02/Ergenisse/software/SwRS_Complete.md`
|
||||
|
||||
Wichtig ist, dass Retrieval nicht „Wahrheit“ garantiert. Es liefert lediglich die evidenznahe Basis, an die Generierung gekoppelt wird. Daraus folgt, dass Retrieval-Konfigurationen (Chunkgröße, Overlap, Ranking) dokumentiert werden müssen, um Ergebnisse reproduzierbar zu halten.
|
||||
```text
|
||||
**SyR-001**: The system SHALL implement a multi-layered architecture with clear separation of concerns.
|
||||
**SyR-002**: The system SHALL implement the ILogic interface pattern with dual implementations.
|
||||
```
|
||||
|
||||
#heading(level: 2)[Stakeholder-Einbindung und Datengrundlage]
|
||||
```text
|
||||
**SW-FUNC-001**: The software SHALL provide comprehensive account management functionality.
|
||||
**SW-API-001**: The software SHALL provide comprehensive REST API.
|
||||
```
|
||||
|
||||
#heading(level: 3)[Stakeholderrollen und Verantwortlichkeiten]
|
||||
#heading(level: 3)[Einordnung]
|
||||
|
||||
LLM-gestützte Requirements-Rückgewinnung ist ohne Domänenvalidierung nicht belastbar. Für die Fallstudie werden daher Stakeholderrollen unterschieden:
|
||||
Versuch 02 lieferte die staerkste formale Konsolidierung (StRS/SyRS/SwRS, hohe Traceability), erwies sich fuer die Gesamtentdeckung jedoch als vergleichsweise rigide.
|
||||
|
||||
- **Fachexperten (Domäne/Support):** kennen Ausnahmen, Kundenvarianten und Abläufe.
|
||||
- **Entwickler/Architekten:** ordnen Codeartefakte ein und bewerten technische Machbarkeit.
|
||||
- **Produktverantwortliche:** priorisieren Requirements in Bezug auf Migrationsziel und Wertbeitrag.
|
||||
#heading(level: 2)[Versuch 03]
|
||||
|
||||
Die Beteiligung dient nicht nur der Korrektur von Detailfragen, sondern der Abgrenzung von Soll- und Ist-Zustand. Gerade Legacy-Systeme enthalten historisch gewachsene Workarounds, die fachlich nicht zwingend gewünscht sind @bisbal1999legacy.
|
||||
#heading(level: 3)[Allgemeine Beschreibung]
|
||||
|
||||
#heading(level: 3)[Interviewleitfaden und Workshopformat]
|
||||
Versuch 03 erweitert das Vorgehen aus Versuch 02 um MCP-Server, um neben formaler Strukturierung vor allem die Discovery-Breite zu vergroessern (Use-Case-Fund, Gap-Analyse).
|
||||
|
||||
Die Stakeholder-Einbindung wird als Kombination aus Interviews und Validierungsworkshops strukturiert. Ein schlanker Leitfaden fokussiert auf:
|
||||
#heading(level: 3)[Konfiguration]
|
||||
|
||||
- kritische Geschäftsobjekte und Statusmodelle,
|
||||
- typische Fehlerfälle und Ausnahmen,
|
||||
- Sicherheits- und Complianceanforderungen,
|
||||
- Integrationen und Schnittstellen,
|
||||
- Kriterien für „Done“ in der Migration (Abnahmelogik).
|
||||
- Claude Code CLI lokal + VS Code,
|
||||
- Agenten-Dateien in `Versuche/Versuch 03/Tools/Agents/`,
|
||||
- MCP-Server gemaess Protokoll: Serena MCP, Windows-MCP (AutoIt-basiert), MSSQL MCP.
|
||||
|
||||
Workshops dienen der Konsolidierung: Requirements werden mit Belegen präsentiert, offene Punkte markiert und Entscheidungen (z. B. „Ist-Übernahme“ vs. „Soll-Anpassung“) festgehalten. Dieses Vorgehen ist konsistent mit RE-Standards, die Validierung und Stakeholderabstimmung als zentrale Schritte behandeln @iso29148_2018.
|
||||
#heading(level: 3)[Verwendeter Prompt]
|
||||
|
||||
#heading(level: 3)[Datengrundlage und Umgang mit sensiblen Informationen]
|
||||
```text
|
||||
Please analyze this software project and write a reuqirements specification according to modern standards.
|
||||
Use Agents and MCP servers wherever possible.
|
||||
Keep superflous texts to a minimum and concentrate on actual requirements.
|
||||
```
|
||||
|
||||
Die Datengrundlage umfasst Quellcode und begleitende Projektartefakte. Aus Governance-Sicht ist Quellcode als sensibel zu betrachten. Daraus folgt:
|
||||
#heading(level: 3)[Tools und Agenten]
|
||||
|
||||
Beispiele aus dem Versuchsordner:
|
||||
|
||||
- `centron-documentation-writer.md`
|
||||
- `nhibernate-query-reviewer.md`
|
||||
- `centron-code-reviewer.md`
|
||||
- `webservice-developer.md`
|
||||
|
||||
#heading(level: 3)[Agentenbeispiel (Auszug, erste 100 Zeilen) - Versuch 03]
|
||||
|
||||
Quelle: `Versuche/Versuch 03/Tools/Agents/nhibernate-query-reviewer.md`
|
||||
|
||||
````md
|
||||
---
|
||||
name: nhibernate-query-reviewer
|
||||
description: Reviews NHibernate queries and LINQ expressions for c-entron.NET. Detects N+1 queries, cartesian products, and compatibility issues. Use when writing complex queries or experiencing performance problems. Keywords: NHibernate, LINQ, query, performance, N+1, optimization, Fetch.
|
||||
---
|
||||
|
||||
# NHibernate Query Reviewer Agent
|
||||
|
||||
> **Type**: Review / Analysis
|
||||
> **Purpose**: Review database queries to ensure efficiency, proper structure, and compatibility with NHibernate's LINQ provider limitations.
|
||||
|
||||
## Agent Role
|
||||
|
||||
You are a specialized **NHibernate Query Reviewer** for the c-entron.NET solution, focused on query optimization and performance.
|
||||
|
||||
### Primary Responsibilities
|
||||
|
||||
1. **N+1 Detection**: Identify and fix lazy loading issues that cause multiple database roundtrips
|
||||
2. **Performance Analysis**: Review queries for cartesian products, missing indexes, and inefficient patterns
|
||||
3. **NHibernate Compatibility**: Ensure LINQ expressions translate correctly to SQL
|
||||
4. **Best Practices**: Enforce soft delete filtering, eager loading strategies, and proper transaction usage
|
||||
|
||||
### Core Capabilities
|
||||
|
||||
- **N+1 Query Detection**: Identify lazy loading in loops causing performance degradation
|
||||
- **Cartesian Product Prevention**: Detect multiple Fetch operations on collections
|
||||
- **LINQ Compatibility**: Validate expressions work with NHibernate's LINQ provider
|
||||
- **Optimization Recommendations**: Suggest Fetch, FetchMany, Future queries for better performance
|
||||
- **Soft Delete Validation**: Ensure all queries filter IsDeleted records
|
||||
|
||||
## When to Invoke This Agent
|
||||
|
||||
This agent should be activated when:
|
||||
- Complex LINQ queries are written
|
||||
- Performance issues suspected with database access
|
||||
- Need query optimization recommendations
|
||||
- Validating NHibernate compatibility of LINQ expressions
|
||||
- Reviewing data access code for N+1 problems
|
||||
- Before committing database access code
|
||||
|
||||
**Trigger examples:**
|
||||
- "Review this query for N+1 problems"
|
||||
- "Optimize the GetAccountContracts query"
|
||||
- "Check if this LINQ expression will work with NHibernate"
|
||||
- "Why is my query slow?"
|
||||
|
||||
## Technology Adaptation
|
||||
|
||||
**IMPORTANT**: This agent adapts to c-entron.NET's NHibernate configuration.
|
||||
|
||||
**Configuration Source**: [CLAUDE.md](../../CLAUDE.md)
|
||||
|
||||
Before beginning work, review CLAUDE.md for:
|
||||
- **ORM**: NHibernate 5.x with FluentNHibernate
|
||||
- **Database**: SQL Server 2019+
|
||||
- **Pattern**: Always filter !x.IsDeleted
|
||||
- **Eager Loading**: Fetch/FetchMany for navigation properties
|
||||
- **Future Queries**: Batch loading for multiple collections
|
||||
- **Transactions**: Required for all modifications
|
||||
|
||||
## Instructions & Workflow
|
||||
|
||||
### Standard Procedure
|
||||
|
||||
1. **Load Relevant Lessons Learned** ⚠️ **IMPORTANT**
|
||||
|
||||
As a review and analysis agent, start by loading past lessons:
|
||||
|
||||
- Use Serena MCP `list_memories` to see available memories
|
||||
- Use `read_memory` to load relevant past findings:
|
||||
- `"lesson-query-*"` - Query optimization lessons
|
||||
- `"pattern-nhibernate-*"` - NHibernate patterns
|
||||
- `"lesson-performance-*"` - Performance findings
|
||||
- Apply insights from past lessons throughout review
|
||||
- This prevents repeating past N+1 mistakes
|
||||
|
||||
2. **Context Gathering**
|
||||
- Review [CLAUDE.md](../../CLAUDE.md) for NHibernate patterns
|
||||
- Use Serena MCP `find_symbol` to locate query implementations
|
||||
- Use Serena MCP `find_referencing_symbols` to understand query usage
|
||||
- Identify query complexity and data access patterns
|
||||
|
||||
3. **Query Analysis**
|
||||
- Check for N+1 query patterns (lazy loading in loops)
|
||||
- Verify soft delete filtering (!x.IsDeleted)
|
||||
- Validate LINQ expression compatibility
|
||||
- Look for cartesian products (multiple Fetch on collections)
|
||||
- Check transaction usage for modifications
|
||||
- **Apply insights from loaded lessons**
|
||||
|
||||
4. **Optimization**
|
||||
- Suggest Fetch/FetchMany for eager loading
|
||||
- Recommend Future queries for multiple collections
|
||||
- Propose projection for limited data needs
|
||||
- Identify missing indexes
|
||||
- **Check recommendations against past patterns**
|
||||
|
||||
5. **Verification**
|
||||
- Estimate performance impact
|
||||
- Verify proposed optimizations don't introduce new issues
|
||||
- Use `/optimize` command for additional suggestions
|
||||
````
|
||||
Hinweis: Der Auszug endet nach Zeile 100; die Originaldatei umfasst 284 Zeilen und ist an dieser Stelle nicht zu Ende.
|
||||
|
||||
#heading(level: 3)[Beispielhafte Ergebnis-Use-Cases]
|
||||
|
||||
Quelle: `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.md`
|
||||
|
||||
```text
|
||||
### 2. Click Counter Management (Usage-Based Billing)
|
||||
**Purpose**: Retrieve current meter readings for click counter devices
|
||||
**Use Cases**: Copy machines, printers, industrial equipment with usage meters
|
||||
Method: LoadCounterAsync(List<int> contractsI3D)
|
||||
```
|
||||
|
||||
```text
|
||||
**Use Case**: Track counter reading trends, detect anomalies
|
||||
Method: IAutomatedBillingLogic.GetCounterHistory(List<string> lstParam)
|
||||
```
|
||||
|
||||
#heading(level: 3)[MCP-Server: Detaillierte Beschreibung]
|
||||
|
||||
#heading(level: 4)[MCP-Grundprinzip]
|
||||
|
||||
Model Context Protocol (MCP) definiert eine standardisierte Kopplung zwischen einem Host (hier: Claude Code), einem MCP-Client und einem oder mehreren MCP-Servern. Server stellen dabei typischerweise drei Artefaktarten bereit: `tools` (aufrufbare Funktionen), `resources` (lesbare Kontexte) und `prompts` (wiederverwendbare Prompt-Bausteine). Dieses Modell wurde in Versuch 03 genutzt, um ueber den reinen Repository-Kontext hinaus weitere Wissens- und Interaktionskanaele einzubinden @mcp_intro_2026.
|
||||
|
||||
#heading(level: 4)[Serena MCP]
|
||||
|
||||
Serena ist ein MCP-Server fuer semantische Code-Retrieval- und Editieroperationen auf Symbol-Ebene (z. B. `find_symbol`, `find_referencing_symbols`, `insert_after_symbol`). Im Unterschied zu rein textbasierter Suche werden Codeobjekte (Klassen, Methoden, Referenzen) strukturell adressiert. In Versuch 03 wurde Serena vor allem fuer gezielte Modulnavigation und die persistenten Memory-Notizen zwischen Analyseiterationen eingesetzt @serena_mcp_2026 @mcp_servers_repo_2026.
|
||||
|
||||
#heading(level: 4)[Windows-MCP (AutoIt-basiert)]
|
||||
|
||||
Der im Protokoll genannte Windows-MCP-Ansatz (AutoIt-basiert) realisiert Desktop-Automatisierung ueber MCP. Laut Projektbeschreibung kapselt der Server AutoIt-Funktionen als MCP-Tools und bietet zusaetzlich Ressourcen (Dateizugriff, Screenshots) sowie Prompt-Templates fuer typische Automationsaufgaben. Fuer die Fallstudie ist das relevant, weil GUI-basierte Pfade (Dialoge, Formulare, visuelle Workflows) nicht nur aus Quellcode, sondern auch aus Interaktionsablaeufen rekonstruiert werden koennen @windows_mcp_autoit_2026.
|
||||
|
||||
#heading(level: 4)[MSSQL MCP]
|
||||
|
||||
MSSQL MCP ermoeglicht den kontrollierten Zugriff auf Microsoft SQL Server ueber MCP. Typische Funktionen sind Tabellenauflistung, Schema-Inspektion, Lesen von Inhalten und kontrollierte SQL-Ausfuehrung. Die dokumentierten Security-Hinweise betonen Least-Privilege-Berechtigungen, restriktive Verbindungskonfigurationen und Logging. In Versuch 03 wurde dieser Zugriff fuer die funktionale Absicherung von Datenmodellen und Use-Case-Hypothesen genutzt @mssql_mcp_2026.
|
||||
|
||||
#heading(level: 3)[Einordnung]
|
||||
|
||||
Durch die MCP-Erweiterung konnte Versuch 03 die funktionale Breite deutlich steigern und einen grossen Dokumentations-Gap sichtbar machen. Gegenueber Versuch 02 sinkt dabei der formale ISO-Fokus, was fuer Discovery jedoch methodisch beabsichtigt war.
|
||||
|
||||
#heading(level: 2)[Quellenhinweis]
|
||||
|
||||
Die fuer dieses Kapitel genutzten Webquellen zu Claude Code und MCP-Servern sind im Literaturverzeichnis als Online-Quellen erfasst; die inhaltliche Referenzierung erfolgt direkt im Text der Abschnitte zu Versuch 03.
|
||||
|
||||
- Trennung zwischen Artefakten, die für Retrieval/Prompts verwendet werden dürfen, und solchen, die ausgeschlossen werden (z. B. Zugangsdaten).
|
||||
- Protokollierung, welche Artefakte in einen Prompt eingeflossen sind.
|
||||
- Minimierung von Kontext (Need-to-know), um Datenabflussrisiken zu reduzieren.
|
||||
|
||||
Diese Maßnahmen werden in Kapitel 5 konkretisiert, da dort die Toolchain-Integration und der Umgang mit Logging, Prompt-Historien und IP-Aspekten umgesetzt werden.
|
||||
|
||||
Reference in New Issue
Block a user