ankn
a5f8fb49ab
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
112 lines
3.3 KiB
Markdown
112 lines
3.3 KiB
Markdown
# Requirements-Review (vor Implementierung)
|
|
|
|
## Ablauf bei Issue-basierter Aufgabe
|
|
|
|
Wenn die Aufgabe als GitLab Issue übergeben wird (statt Freitext):
|
|
|
|
### 1. Issue lesen und analysieren
|
|
|
|
```bash
|
|
glab issue view {issue-id} --repo {repo}
|
|
```
|
|
|
|
### 2. Anforderung kritisch reviewen
|
|
|
|
Prüfe ob folgende Fragen beantwortet sind:
|
|
|
|
**Fachlichkeit:**
|
|
- Ist die Domäne/der Fachkontext verstanden?
|
|
- Gibt es Fachbegriffe die unklar sind?
|
|
- Welche Business-Regeln gelten?
|
|
- Gibt es Abhängigkeiten zu anderen fachlichen Prozessen?
|
|
|
|
**Funktional:**
|
|
- Was genau soll das System tun?
|
|
- Wer sind die Nutzer?
|
|
- Welche Ein-/Ausgaben gibt es?
|
|
- Welche Edge Cases gibt es?
|
|
|
|
**Nicht-funktional:**
|
|
- Performance-Anforderungen (Response-Zeit, Concurrent Users)?
|
|
- Verfügbarkeit?
|
|
- Security-Anforderungen?
|
|
|
|
**Technisch:**
|
|
- Stack/Framework vorgegeben?
|
|
- Schnittstellen zu anderen Systemen?
|
|
- Deployment-Ziel?
|
|
|
|
**Akzeptanzkriterien:**
|
|
- Sind Gherkin-Szenarien vorhanden?
|
|
- Wann ist die Aufgabe "fertig"?
|
|
|
|
### 3. Offene Fragen als Kommentar am Issue
|
|
|
|
Wenn Informationen fehlen → Kommentar am Issue mit konkreten Fragen:
|
|
|
|
```bash
|
|
glab issue comment {issue-id} --repo {repo} --body "## Offene Fragen zur Anforderung
|
|
|
|
Bevor ich mit der Implementierung beginne, bitte folgende Punkte klären:
|
|
|
|
1. **Performance:** Wie viele gleichzeitige Nutzer werden erwartet? Gibt es Response-Zeit-Anforderungen?
|
|
2. **Validierung:** Welche Felder sind Pflicht? Gibt es Format-Vorgaben (z.B. PLZ nur 5-stellig)?
|
|
3. **Auth:** Soll die API authentifiziert sein oder öffentlich?
|
|
|
|
Sobald geklärt, starte ich die Implementierung."
|
|
```
|
|
|
|
### 4. Warten oder selbst entscheiden
|
|
|
|
- **Wenn Fragen kritisch sind** (Architektur-Entscheidung, unklarer Scope): Warten auf Antwort
|
|
- **Wenn Fragen nice-to-have sind** (Details die man mit Best Practices lösen kann): Selbst entscheiden und dokumentieren
|
|
|
|
### 5. Implementierung starten
|
|
|
|
Erst wenn die Anforderung klar ist:
|
|
- Alle kritischen Fragen beantwortet
|
|
- Oder: Agent hat pragmatische Defaults gewählt und dokumentiert
|
|
|
|
```bash
|
|
echo "PROGRESS: 5% - Requirements-Review abgeschlossen, starte Implementierung"
|
|
```
|
|
|
|
## Bei Freitext-Aufgabe (kein Issue)
|
|
|
|
Wenn die Aufgabe als Freitext kommt (über implement_ticket):
|
|
- Selbst ein Issue anlegen mit der Aufgabe
|
|
- Fehlende Infos mit Best Practices/Defaults füllen
|
|
- Entscheidungen als ADR dokumentieren
|
|
- Direkt implementieren (nicht warten)
|
|
|
|
## Wann sind Anforderungen klar?
|
|
|
|
- **Keine offenen Fragen** → Anforderungen klar → direkt implementieren
|
|
- **Offene Fragen** → Kommentar am Issue → warten
|
|
|
|
### Ablauf bei offenen Fragen
|
|
|
|
```bash
|
|
# 1. Fragen als Kommentar posten
|
|
glab issue comment {id} --body "## Offene Fragen ..."
|
|
|
|
# 2. Signal geben dass du wartest
|
|
echo "HELP: Warte auf Antwort zu offenen Fragen am Issue #{id}"
|
|
|
|
# 3. Warten bis Antwort kommt (via send_message vom User/Kiro)
|
|
# → Agent bekommt Nachricht: "Fragen beantwortet, siehe Issue-Kommentar"
|
|
|
|
# 4. Issue-Kommentare erneut lesen
|
|
glab issue view {id} --comments
|
|
|
|
# 5. Weiterarbeiten
|
|
echo "PROGRESS: 5% - Requirements klar, starte Implementierung"
|
|
```
|
|
|
|
### Kiro als Vermittler
|
|
|
|
Kiro sieht `needs_help: true` + `help_message: "Warte auf Antwort..."` und kann:
|
|
- Den User informieren
|
|
- Selbst die Fragen beantworten (wenn er den Kontext hat)
|
|
- Oder `send_message` an den Agent schicken: "Fragen beantwortet, siehe Kommentar"
|