---
mode: agent
description: Requirements Engineering – Requirements erarbeiten und in docs/requirements/REQUIREMENTS.md speichern
tools:
  - codebase
---

# Requirements Engineering

**Ausgangspunkt:** ${input:raw_request:Was wurde grob angefragt oder gewünscht?}

## Vorbereitung

1. Prüfe ob `docs/requirements/REQUIREMENTS.md` bereits existiert.
   - Wenn ja: Lies die Datei vollständig – vorhandene Requirements kennen.
   - Wenn nein: Datei wird am Ende neu angelegt.

2. Führe den Workshop durch und erarbeite/aktualisiere Requirements.

## Ergebnis speichern

Nach dem Workshop: Schreibe das vollständige, aktualisierte Requirements-Dokument
nach `docs/requirements/REQUIREMENTS.md`. Halte das Format aus dem Template ein:
- Alle User Stories mit ACs
- NFRs
- Out of Scope
- Offene Fragen
- Änderungshistorie mit heutigem Datum aktualisieren

Dann: `git add docs/requirements/REQUIREMENTS.md`

---

Führe einen strukturierten Requirements-Workshop durch. Stelle Rückfragen wo nötig,
aber arbeite so weit wie möglich mit dem vorhandenen Kontext.

---

## 1. Problem Statement

**Problem:** Was ist das eigentliche Problem, das gelöst werden soll?
**Betroffene Nutzer:** Wer hat dieses Problem?
**Aktueller Workaround:** Wie lösen Nutzer das Problem heute?
**Impact:** Was passiert wenn wir es nicht lösen?

## 2. User Stories

Erstelle User Stories im Format:
> Als **[Rolle]** möchte ich **[Aktion/Feature]**, damit **[geschäftlicher Nutzen]**.

Identifiziere: Wer sind die Nutzer-Rollen in diesem System?

## 3. Acceptance Criteria

Für jede User Story: konkrete, testbare, unambiguöse ACs.

**Format:** `Given [Vorbedingung], When [Aktion], Then [Erwartetes Ergebnis]`

Checkliste für gute ACs:
- [ ] Eindeutig – nur eine mögliche Interpretation
- [ ] Testbar – kann automatisch oder manuell verifiziert werden
- [ ] Vollständig – Happy Path + wichtigste Error-Cases abgedeckt
- [ ] Kein "wie" – ACs beschreiben WAS, nicht WIE

## 4. Non-Functional Requirements

| Kategorie | Anforderung | Messbar? |
|---|---|---|
| Performance | z.B. Response <200ms bei 100 concurrent users | |
| Security | z.B. Auth erforderlich, keine PII in Logs | |
| Availability | z.B. 99.9% uptime, <1h RTO | |
| Scalability | z.B. skaliert bis 10.000 Einträge ohne Perf-Degradation | |
| Maintainability | z.B. neue Entwickler können in <1h onboarden | |

## 5. Out of Scope (explizit)

Was wird explizit **nicht** gebaut (jetzt):
-

## 6. Open Questions & Risiken

Offene Fragen die vor dem Start beantwortet werden müssen:
-

Bekannte Risiken:
-

## 7. Definition of Ready

Dieser Task ist ready to start wenn:
- [ ] Alle ACs klar und unambiguös
- [ ] NFRs definiert
- [ ] Scope abgegrenzt
- [ ] Open Questions geklärt
- [ ] Architektureller Ansatz skizziert