Conrad Schulz
2a72e08c13
- Add .github/copilot-instructions.md with project-specific context - Add .github/prompts/ with 9 reusable agent prompt files - Add .vscode/extensions.json recommending copilot extensions - Update .vscode/settings.json with rulers and YAML schema - Remove tracked .DS_Store
2.1 KiB
| mode | description | tools | |
|---|---|---|---|
| agent | Requirements Engineering Workshop – User Stories, ACs und NFRs erarbeiten |
|
Requirements Engineering Workshop
Ausgangspunkt: ${input:raw_request:Was wurde grob angefragt oder gewünscht?}
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