103 lines
5.7 KiB
Markdown
103 lines
5.7 KiB
Markdown
# Versuch 01 - Baseline (Prompt-only) - Iteration 01
|
|
|
|
## Metadaten
|
|
- **Versuch:** V1 Baseline (Prompt-only)
|
|
- **Iteration:** 01 (Initial-Prompt, zu Versuchsbeginn neu formuliert)
|
|
- **Werkzeugkonfiguration:** Claude Code, keine Agentendateien, keine MCP-Server
|
|
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
|
- **Modell:** Claude (Claude Code)
|
|
- **Zeitstempel:** 2026-06-04
|
|
- **Änderungsgrund:** Initial-Prompt für V1 Baseline (kein Vorgänger).
|
|
|
|
---
|
|
|
|
## Prompt
|
|
|
|
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung; nutze nur, was als Datei lesbar ist.
|
|
|
|
### Auftrag
|
|
|
|
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
|
|
|
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
|
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
|
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
|
|
|
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
|
|
|
### Vorgehen (statische Analyse, keine Ausführung)
|
|
|
|
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Scope und Validierung sind manuell vorgegeben):
|
|
|
|
1. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen.
|
|
2. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
|
3. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
|
4. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen.
|
|
5. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
|
|
|
### Pflicht-Eigenschaften jeder Anforderung
|
|
|
|
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Anforderungen ohne Beleg sind unzulässig.
|
|
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
|
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
|
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
|
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
|
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt.
|
|
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
|
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
|
|
|
### Formatvorgabe pro Anforderung
|
|
|
|
```
|
|
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
|
Titel: <kurzer Titel>
|
|
Ebene: <StRS | SyRS | SwRS>
|
|
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
|
Akteur: <Rolle / System / Komponente>
|
|
Vorbedingung: <Zustand vor Auslösen>
|
|
Aussage: Das System soll <...>. (klare Soll-Aussage)
|
|
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
|
Belege:
|
|
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String>
|
|
- [SEKUNDÄR] <...>
|
|
- [KONTEXT] <...>
|
|
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
|
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
|
Status: <belegt | HYPOTHESE>
|
|
```
|
|
|
|
### Traceability
|
|
|
|
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
|
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
|
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
|
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
|
|
|
### Ergebnisstruktur (im aktuellen Arbeitsverzeichnis)
|
|
|
|
```
|
|
Ergebnisse/
|
|
StRS.md
|
|
SyRS.md
|
|
SwRS.md
|
|
Traceability.md (oder Traceability.csv)
|
|
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
|
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
|
Analysebericht.md (Modul-/Komponentenübersicht, abgedeckte Bereiche, bekannte Lücken)
|
|
```
|
|
|
|
### Randbedingungen
|
|
|
|
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
|
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
|
- **Keine Annahme nicht vorhandener Tools.** Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist die Aussage als `[HYPOTHESE]` zu kennzeichnen.
|
|
- **Migrationsperspektive berücksichtigen.** Wenn eine Implementierung erkennbar ein historischer Workaround oder Sonderfall ist, vermerke das im Feld `Status` (`belegt; Workaround`), damit es in der späteren Validierung priorisiert geprüft werden kann.
|
|
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
|
|
|
### Abschluss
|
|
|
|
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
|
- Welche Module wurden vollständig analysiert, welche nur stichprobenhaft, welche gar nicht?
|
|
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
|
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|