# 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?