Feature-Anforderungen vorschlagen

Skill: Feature-Anforderungen vorschlagen

Zweck

Erstellen einer formellen Anforderungsspezifikation für eine Funktion unter Verwendung der EARS-Notation. Dies übersetzt das Konzept in testbare, spezifische Anforderungen.

Wann verwenden

• Funktionskonzept existiert und ist genehmigt
• Es muss genau festgelegt werden, was das System tun muss
• Bereit, funktionale und nicht-funktionale Anforderungen zu definieren

Voraussetzungen

• Funktionskonzeptdokument existiert unter docs/features/NNNN-feature-name/concept.md
• Das Konzept wurde überprüft und genehmigt
• Der Benutzer versteht den Funktionsumfang

Vorgehen

1. Überprüfen, ob das Konzept existiert

# Prüfen, ob das Konzept existiert
ls ./docs/features/NNNN-feature-name/concept.md

Falls es nicht existiert, verwenden Sie zuerst den Skill propose-feature-concept.

2. Nach Ideenverfeinerungsdokument suchen

ls ./planning/NNNN-feature-name/idea-honing.md 2>/dev/null

Falls es existiert, überprüfen Sie es auf Erkenntnisse, die die Anforderungen informieren. Die Fragen und Antworten können Randfälle und Einschränkungen aufdecken.

3. Anforderungsvorlage kopieren

cp ./docs/features/0000-templates/requirements.md ./docs/features/NNNN-feature-name/

4. Anforderungspräfix festlegen

Wählen Sie ein kurzes Präfix (2-5 Zeichen) für die Anforderungs-IDs:

• Sollte beschreibend für die Funktion sein
• Beispiele: SEM für semantische-Suche, REG für Registrierungsverwaltung
• Wird wie SEM-1, SEM-2 usw. verwendet

5. Übersicht ausfüllen

Schreiben Sie eine kurze Beschreibung, was diese Spezifikation abdeckt. Verweisen Sie auf das Konzeptdokument.

6. Funktionale Anforderungen definieren

Für jede Anforderung das EARS-Format verwenden:

**WHILE** [State oder Bedingung]
**WHEN** [Auslöser oder Ereignis]
**THEN** das System **SHALL** [erforderliches Verhalten]

Inline-Beispiele nur hinzufügen, wenn sie wirklich klein sind (1-3 Zeilen):

key = "value"

Für größere Beispiele in die Anhänge verschieben.

7. Nicht-funktionale Anforderungen definieren

Leistungs-, Benutzbarkeits-, Sicherheits- oder andere Qualitätsanforderungen hinzufügen:

**WHILE** [Betriebsbedingung]
**THEN** das System **SHALL** [Leistungsanforderung]

Skalierbarkeitsfragen (diese für jede Hauptoperation stellen):

• Was passiert, wenn es 1000x mehr Elemente gibt? 1M Dateien? 10M Zeilen?
• Soll der Speicherverbrauch mit der Datenmenge skalieren oder konstant bleiben?
• Was ist die akzeptable Latenz? Verschlechtert sie sich mit der Skalierung?

Diese Fragen decken Einschränkungen auf, die in der Entwurfsphase zu kritischen Einschränkungen werden. Wenn eine Operation O(1) Speicher oder O(log n) Zeit benötigt, hier angeben.

8. Fehlerbehandlung definieren

Festlegen, wie Fehler behandelt werden sollen:

**WHILE** [laufende Operation]
**WHERE** [Fehlerbedingung tritt ein]
**THEN** das System **SHALL** [Fehlerbehandlungsverhalten]

9. Anhänge hinzufügen

Für größere Beispiele, die die Anforderungen überladen würden:

• API-Antwortschemata
• Konfigurationsdateiformate
• Datenstrukturen
• Protokollspezifikationen

Jeder Anhang sollte klar gekennzeichnet sein:

## Anhang A: API-Antwortschema
## Anhang B: Konfigurationsdateiformat

10. Auf Vollständigkeit prüfen

Sicherstellen:

• Alle Anforderungen verwenden EARS-Schlüsselwörter
• Anforderungen sind testbar und spezifisch
• Inline-Beispiele sind wirklich klein
• Größere Beispiele befinden sich in Anhängen
• Anforderungen haben eindeutige IDs mit dem gewählten Präfix

Validierung

Das Anforderungsdokument überprüfen:

# Prüfen, ob die Datei existiert
ls ./docs/features/NNNN-feature-name/requirements.md

# Prüfen, ob sie Inhalt hat
head -50 ./docs/features/NNNN-feature-name/requirements.md

# Nach EARS-Schlüsselwörtern suchen
grep -E "WHILE|WHEN|WHERE|THEN|SHALL" ./docs/features/NNNN-feature-name/requirements.md

Häufige Probleme

Fehlende EARS-Schlüsselwörter: Jede Anforderung sollte WHILE/WHEN/WHERE/THEN/SHALL verwenden.

Zu vage: Anforderungen sollten spezifisch genug sein, um getestet zu werden.

Inline-Beispiele zu groß: Alles über 3 Zeilen in einen Anhang verschieben.

Inkonsistentes Präfix: Alle Anforderungs-IDs sollten dasselbe Präfix verwenden.

Nächste Schritte

Nach der Erstellung der Anforderungen:

1. Auf Vollständigkeit und Testbarkeit prüfen
2. Rückmeldung von Implementierenden einholen
3. Sobald die Anforderungen solide sind, mit dem Entwurf mit dem Skill propose-feature-design fortfahren