Zum Inhalt springen

Requirements im Überblick

Warum Requirements neben dem Code liegen, was das Werkzeug daran prüft und was nicht, wer im Team was davon hat, und wie ein Requirement von der ersten Zeile bis zur Abnahme läuft.

Aktualisiert am 2026-09-08

Diese Seite erklärt, wofür die Requirements in CodeCharter gut sind und wie sie sich im Alltag anfühlen. Das Dateiformat mit allen Feldern steht danach unter Requirements.

Das Problem

Die Anforderungen an ein Produkt stehen fast immer woanders als der Code, der sie umsetzt: in einem Lastenheft, in Confluence, in Jira-Tickets, im Protokoll eines Workshops. Am Tag der Unterschrift passt beides zusammen. Danach entwickelt sich der Code weiter, und die Verbindung zwischen der Zusage und der Stelle im Code, die sie einlöst, lebt nur noch im Gedächtnis der Beteiligten.

Das fällt an drei Stellen auf. Bei einer Abnahme muss jemand von Hand zusammentragen, welche Zusage wo erfüllt ist. Bei einem Audit oder einer Zertifizierung wird derselbe Nachweis noch einmal verlangt, diesmal schriftlich. Und ein halbes Jahr später ändert jemand eine Methode, ohne zu wissen, dass an ihr eine vertraglich zugesagte Eigenschaft hängt.

Der Ansatz

In CodeCharter ist ein Requirement eine Datei im Repository, direkt neben dem Code. Sie wird im selben Pull Request gereviewt, sie wird mit demselben git blame untersucht, und sie wandert mit demselben Branch. Ein Anchor in dieser Datei benennt die Stelle im Code, die das Requirement einlöst, und der Befehl codecharter req check meldet, wenn Datei und Code nicht mehr zusammenpassen.

Wichtig ist dabei, was das Werkzeug behauptet und was nicht. CodeCharter entscheidet nicht, ob euer Code ein Requirement inhaltlich erfüllt. Es hält fest, dass ihr das behauptet habt, wer es wann abgenommen hat und auf welche Evidenz sich diese Abnahme stützte, und es meldet, sobald diese Evidenz nicht mehr trägt.

Konkret prüft das Werkzeug die Struktur des Corpus, also doppelte Ids, ins Leere zeigende Referenzen, Criteria ohne verwertbaren Carrier und den Widerspruch, ein Requirement als umgesetzt zu führen, während seine eigene Abnahmeprüfung noch offen ist. Mit --with-code prüft es zusätzlich, ob die verankerten Symbole überhaupt noch existieren und ob eine einmal gepinnte Abnahme noch zum Code passt. Was es nicht prüft, ist der Inhalt: ob der Text des Requirements das Richtige beschreibt und ob der gebundene Test das Richtige testet, bleibt menschliches Urteil. Genau deshalb ist die Abnahme über codecharter req accept bewusst kein MCP-Tool, ein Agent kann alles vorbereiten, aber nichts abnehmen.

Wer im Team was davon hat

Entwicklerinnen und Entwickler sehen beim Ändern einer Methode, ob an ihr eine zugesagte Eigenschaft hängt. Das MCP-Tool req_context beantwortet genau diese Frage für ein Symbol, ohne dass jemand ein Lastenheft durchsuchen muss.

Reviewer bekommen die Requirement-Änderung im selben Diff wie die Codeänderung. Ein neues [Satisfies]-Attribut steht als Zeile im Diff und wird dort mitgelesen wie jede andere Codeänderung.

Projektleitung und Auftraggeber haben mit documents.yml eine Gliederung über dem Corpus, aus der sich ein Lastenheft, ein Pflichtenheft oder ein Abnahmeprotokoll zusammensetzt, und mit dem Rollup je Requirement eine Aussage darüber, was gerade hält und was nicht.

Auditoren und QA lesen nicht den Code, sondern die Abnahmen: wer hat wann welches Criterion freigegeben, auf welche Evidenz gestützt, und gilt diese Evidenz heute noch. All das steht versioniert im Repository.

KI-Coding-Agenten lesen denselben Corpus über zehn MCP-Tools, statt die Dateien selbst zu parsen. Sie dürfen recherchieren, entwerfen, binden und um Freigabe bitten, aber sie können nichts abnehmen.

Der Lebenszyklus eines Requirements

Das folgende Beispiel begleitet ein einzelnes Requirement durch alle Stufen. Es ist dasselbe, das auf den Folgeseiten wieder auftaucht.

1. Die Zusage entsteht. Im Workshop mit dem Kunden fällt der Satz, dass Nutzer ihr Passwort selbst zurücksetzen können müssen. Bisher wäre das eine Zeile im Protokoll gewesen.

2. Die Zusage bekommt eine Datei. Unter .codecharter/req entsteht REQ-12.req.md mit Id, Titel, Priorität und der Angabe, ob die Zusage vertraglich bindend ist. Der Fließtext im Body ist das, was ein Reviewer oder Auditor später liest, um das Warum zu verstehen.

3. Die Zusage wird prüfbar. Ein Requirement, das niemand nachprüfen kann, ist eine Absichtserklärung. Deshalb bekommt es Criteria, und jedes Criterion sagt über seinen Carrier, wie es verifiziert wird: durch eine Regel, durch einen benannten Test, durch einen manuellen Schritt, durch eine Integrationssuite oder durch etwas außerhalb des Repositorys.

4. Die Zusage wird an Code gebunden. Ein Anchor nennt das Symbol, das das Requirement einlöst, oder erwartet ein [Satisfies("REQ-12")] aus dem Paket CodeCharter.Annotations am umsetzenden Member. Ohne Anchor lehnt die Prüfung den Status implemented mit einem Fehler ab.

5. Die Zusage wird laufend geprüft. codecharter req check läuft in der CI mit, ohne Solution und ohne .NET SDK, und ist damit schnell genug für jeden Pull Request. Mit --with-code kommt die Prüfung gegen das analysierte Codemodell dazu.

6. Die Zusage wird abgenommen. Ein Mensch führt codecharter req accept REQ-12 AC-1 --by <name> aus. Das pinnt Freigeber, Datum und die Evidenz, auf die sich die Freigabe stützt, in die Datei.

7. Die Zusage überlebt Änderungen. Ändert sich der abgenommene Test oder die verankerte Coderegion, passt der Pin nicht mehr, und das Requirement rendert als Stale statt still weiter als erfüllt zu gelten. Die Abnahme wird dann bewusst wiederholt.

8. Der Stand wird messbar. codecharter req coverage beantwortet beide Richtungen: hält die Evidenz jedes Requirements noch, und welcher Code trägt überhaupt keine Rechtfertigung. Details unter Requirements-Coverage.

Brauchen wir das?

Der Aufwand lohnt sich, wenn mindestens einer dieser Punkte auf euch zutrifft: ihr arbeitet gegen ein Lastenheft oder einen Festpreis, jemand von außen nimmt eure Lieferung förmlich ab, ihr müsst einem Prüfer nachweisen, wo eine Eigenschaft umgesetzt ist, oder ihr lasst KI-Agenten an einer Codebasis arbeiten, in der bestimmte Zusagen nicht kaputtgehen dürfen.

Der Aufwand lohnt sich eher nicht, wenn ihr ein internes Produkt ohne förmliche Abnahme baut, eure Anforderungen ohnehin als Tickets entstehen und mit dem Merge erledigt sind, und niemand später einen Nachweis verlangt. Was in diesem Fall gegen das Werkzeug spricht, steht ausführlich unter Abgrenzung und Aufwand.

Nächste Schritte