Conrad Schulz a959d76850 feat: requirements engineering + konsistenz-check

- git-templates/docs/requirements/REQUIREMENTS.md: persistentes Requirements-Template
  mit User Stories, ACs, NFRs, Out-of-Scope, Aenderungshistorie
- prompts/check-consistency.prompt.md: neuer /check-consistency Prompt
  (Code vs. Requirements vs. Docs, findet Widersprueche vor dem Commit)
- git-templates/hooks/pre-commit: Check 5 hinzugefuegt
  (blockiert wenn REQUIREMENTS.md unstaged Aenderungen hat)
- prompts/requirements.prompt.md: liest und schreibt jetzt docs/requirements/REQUIREMENTS.md
- copilot-instructions.md (beide): Requirements-Sektion, DoD + Before-starting erweitert
- git-templates/history/summary/PROJECT_CONTEXT.md: Requirements-Pfad erganzt

2026-06-02 17:51:41 +00:00

2.7 KiB

Raw Blame History

mode

description

tools

agent

Requirements Engineering – Requirements erarbeiten und in docs/requirements/REQUIREMENTS.md speichern

codebase

Requirements Engineering

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

Vorbereitung

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.
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

2.7 KiB Raw Blame History Unescape Escape