2026-05-29 08:19:50 +00:00
|
|
|
|
---
|
|
|
|
|
|
mode: agent
|
2026-06-02 17:51:41 +00:00
|
|
|
|
description: Requirements Engineering – Requirements erarbeiten und in docs/requirements/REQUIREMENTS.md speichern
|
2026-05-29 08:19:50 +00:00
|
|
|
|
tools:
|
|
|
|
|
|
- codebase
|
|
|
|
|
|
---
|
|
|
|
|
|
|
2026-06-02 17:51:41 +00:00
|
|
|
|
# Requirements Engineering
|
2026-05-29 08:19:50 +00:00
|
|
|
|
|
|
|
|
|
|
**Ausgangspunkt:** ${input:raw_request:Was wurde grob angefragt oder gewünscht?}
|
|
|
|
|
|
|
2026-06-02 17:51:41 +00:00
|
|
|
|
## 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`
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
2026-05-29 08:19:50 +00:00
|
|
|
|
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
|
