Zum Inhalt springen

Dein erstes Requirement anlegen und abnehmen

In wenigen Minuten ein Requirement anlegen, an Code binden, prüfen und abnehmen.

Aktualisiert am 2026-09-08

Ein typischer Fall: dein Kunde hat zugesagt bekommen, dass Nutzer ihr Passwort selbst zurücksetzen können. Bisher steht dieser Satz in einem Protokoll. Danach steht er im Repository, ist an den Code gebunden und wird bei jedem Pull Request geprüft.

Worum es dabei geht und wann sich das lohnt, steht unter Requirements im Überblick.

1. Die Datei anlegen

Der Corpus liegt unter .codecharter/req im Repo-Root. Lege das Verzeichnis an:

mkdir -p .codecharter/req

Darin entsteht REQ-12.req.md. Der Dateiname folgt der Id, sonst meldet die Prüfung eine Warnung:

---
id: REQ-12
title: Users can reset their password themselves
priority: must
contractual: true
status: in-progress
kind: functional
section: Account management
source: Workshop-Protokoll 2026-08-14, Abschnitt 3.2
---
Ein Nutzer, der sein Passwort vergessen hat, fordert über die Anmeldeseite
einen Reset-Link an und setzt darüber ein neues Passwort. Der Link ist
einmalig verwendbar und verfällt nach 30 Minuten.

## Out of Scope

Die Anmeldung über einen externen Identity-Provider ist von diesem
Requirement nicht abgedeckt.

Die sechs Schlüssel id, title, priority, contractual, status und kind sind Pflicht, alles Weitere ist optional. Der Body ist der Text, den später ein Reviewer oder ein Prüfer liest. Schreib dort ganze Sätze, keine Stichpunkte.

2. Den Corpus prüfen

codecharter req check

Der Befehl öffnet keine Solution und braucht kein .NET SDK, er ist deshalb schnell genug für jeden Pull Request. Beim ersten Lauf bekommst du eine Warnung, weil das Requirement noch keinen Anchor hat. Das ist erwartet: bei status: in-progress ist ein fehlender Anchor eine Warnung, bei status: implemented wäre es ein Fehler.

3. Das Requirement an den Code binden

Sobald der Code existiert, benennt ein Anchor die Stelle, die die Zusage einlöst. Ergänze das Frontmatter:

anchors:
  - symbol_id: MyApp.Auth.PasswordResetService

Alternativ markierst du die umsetzende Stelle direkt im Code. Dafür brauchst du das Attribut-Paket:

dotnet add package CodeCharter.Annotations

[Satisfies("REQ-12")]
public async Task SendResetLinkAsync(string email, CancellationToken ct)

Beide Wege binden das Requirement an Code. Der Weg über das Attribut hat den Vorteil, dass die Bindung im Diff sichtbar ist und in die Requirements-Coverage einfließt.

4. Die Zusage prüfbar machen

Ein Requirement ohne Abnahmeprüfung ist eine Absichtserklärung. Ergänze ein Criterion mit genau einem Carrier, hier ein benannter Test:

criteria:
  - id: AC-1
    test: MyApp.Tests.Auth.PasswordReset_SendsSingleUseLink

Danach kannst du den Status auf implemented setzen. Prüfe jetzt zusätzlich gegen den Code:

codecharter req check --with-code

Dieser Lauf analysiert die Solution und meldet unter anderem, wenn ein verankertes Symbol nicht existiert oder der gebundene Test nicht gefunden wird.

5. Abnehmen

Die Abnahme ist ein menschlicher Akt und bewusst kein MCP-Tool, damit kein KI-Agent die eigene Arbeit freigibt:

codecharter req accept REQ-12 AC-1 --by alice

Das schreibt Freigeber, Datum und die Evidenz, auf die sich die Freigabe stützt, in das Criterion. Ändert sich der abgenommene Test später, passt der Pin nicht mehr, und das Requirement rendert als Stale, statt still als erfüllt weiterzulaufen. Dann nimmst du bewusst erneut ab.

Ohne --by sucht der Befehl die Identität in CODECHARTER_REQ_APPROVER und danach in git config user.name. Findet er nichts, bricht er ab, statt zu raten.

6. In die CI hängen

codecharter req check liefert einen CI-tauglichen Exit-Code und ist schnell, weil er ohne Codemodell auskommt:

codecharter req check --output json

Den Stand über den ganzen Corpus misst codecharter req coverage. Der Befehl ist zunächst nur ein Report und wird erst zum Gate, wenn du ihn in .codecharter/config.yml dazu machst.

Wie es weitergeht