Requirements neben dem Code sind kein Ersatz für die Werkzeuge, mit denen ihr eure Arbeit plant. Diese Seite zieht die Grenze und benennt den Preis, damit ihr entscheiden könnt, bevor ihr anfangt.
Was CodeCharter nicht ist
CodeCharter ist kein Ticket-System. Es gibt keine Zuweisung an eine Person, keinen Status-Workflow über Spalten, keine Schätzung, keinen Sprint und kein Board. Ein Requirement trägt einen Lieferstatus, aber der beschreibt den Stand der Zusage und nicht den Stand eines Arbeitspakets.
Es ist kein Backlog. Ideen, Wünsche und noch nicht entschiedene Themen gehören weiterhin dorthin, wo ihr sie heute sammelt. In den Corpus kommt ein Requirement erst, wenn es beschlossen ist und jemand später wissen will, ob sie eingelöst wurde.
Es ist keine Projektsteuerung. Termine, Abhängigkeiten zwischen Arbeitspaketen, Kapazitäten und Fortschrittsberichte bildet CodeCharter nicht ab. Die einzige Abhängigkeit, die der Corpus kennt, ist fachlicher Natur: ein Requirement verfeinert ein anderes, steht mit einem anderen im Widerspruch, oder ein Criterion wartet auf ein anderes.
Und es ist keine inhaltliche Prüfung. Ob der Text stimmt und ob der gebundene Test das Richtige testet, entscheidet ein Mensch. Das Werkzeug prüft Struktur, Bindung und Haltbarkeit der Evidenz.
Verhältnis zu Ticket-Systemen und ALM-Werkzeugen
Jira, Azure Boards, Linear und vergleichbare Werkzeuge planen Arbeit. Sie beantworten, wer woran arbeitet und was als Nächstes drankommt. Klassische Requirements- und ALM-Werkzeuge verwalten dagegen einen Anforderungsbestand mit Versionierung, Freigaben und Nachweisen, sitzen dafür aber neben dem Repository und verlangen eine eigene Pflege, damit die Verbindung zum Code aktuell bleibt.
CodeCharter besetzt weder das eine noch das andere vollständig. Es deckt den schmalen Streifen ab, an dem beide üblicherweise auseinanderlaufen: die Bindung zwischen einer beschlossenen Zusage und der Stelle im Code, die sie einlöst, geprüft von demselben Lauf, der auch eure Findings gated. Das Ticket-System behaltet ihr. Ein separates Requirements-Werkzeug kann entfallen, wenn dessen einziger verbliebener Zweck der Nachweis gegenüber Code ist.
Ein praxistaugliches Nebeneinander sieht so aus: das Ticket-System führt die
Arbeit, der Corpus führt die Zusagen, und die Ticket-Nummer steht im Feld
source des Requirements, damit der Weg zurück offen bleibt.
Ein bestehendes Lastenheft hereinholen
Der Corpus besteht aus gewöhnlichen Markdown-Dateien, deshalb ist der Weg hinein Fleißarbeit und kein Import-Projekt. Bewährt hat sich diese Reihenfolge.
Fangt mit den Anforderungen an, die wirklich nachweispflichtig sind. In einem Lastenheft mit zweihundert Sätzen sind das selten mehr als zwanzig bis dreißig. Alles andere kann später kommen oder gar nicht.
Legt für jede eine Datei <id>.req.md an und übernehmt den Originaltext in
den Body, statt ihn umzuformulieren. Der Verweis auf die Fundstelle gehört in
section und source, damit später niemand raten muss, woher der Satz kam.
Setzt den Status ehrlich. Ein Requirement, das ihr längst umgesetzt habt,
steht auf implemented und braucht dann auch einen Anchor, sonst meldet
codecharter req check einen Fehler. Genau das ist der Zweck der Übung.
Bildet die Gliederung des Originaldokuments am Ende in documents.yml nach.
Dann lässt sich aus dem Corpus wieder etwas erzeugen, das der Auftraggeber
als Lastenheft, Pflichtenheft oder Abnahmeprotokoll wiedererkennt.
Ein KI-Agent kann diese Übertragung vorbereiten. req_draft entwirft
Requirements und req_bind schlägt Criteria und Anchors vor, beides
ausdrücklich zur menschlichen Prüfung. Die Abnahme bleibt in jedem Fall bei
euch.
Was die Pflege kostet
Das Anlegen eines Requirements dauert wenige Minuten, das ehrliche Formulieren der Criteria länger, weil dabei die eigentliche Arbeit passiert: zu entscheiden, woran man erkennt, dass die Zusage eingelöst ist. Diese Zeit spart ihr nicht ein, ihr verschiebt sie nur von der Abnahme nach vorn.
Im laufenden Betrieb entstehen drei wiederkehrende Aufwände. Bei einer Codeänderung, die eine verankerte Stelle berührt, muss jemand die Abnahme erneuern. Bei einer neuen Zusage kommt eine Datei dazu. Und wenn ihr das Coverage-Gate einschaltet, wird jede neue Methode ohne Rechtfertigung zu einer Entscheidung, entweder sie zu verankern oder sie bewusst als Infrastruktur einzuordnen.
Tragen sollte den Aufwand, wer die Zusage verantwortet, in der Regel also dieselbe Person, die die Änderung schreibt, und nicht eine eigene Rolle daneben. Sobald die Pflege an eine Person delegiert wird, die den Code nicht schreibt, driftet der Corpus wieder, und dann habt ihr das Ausgangsproblem zurück, nur in einem anderen Dateiformat.
Wenn es sich nicht lohnt
Baut ihr ein internes Produkt ohne förmliche Abnahme, entstehen eure Anforderungen als Tickets und sind mit dem Merge erledigt, und verlangt niemand später einen Nachweis, dann bringt der Corpus euch wenig und kostet trotzdem Pflege. In diesem Fall bleiben die übrigen Teile von CodeCharter davon unberührt: Analyse, Regeln, Coverage und die Gates funktionieren ohne einen einzigen Requirement-Eintrag.
Nächste Schritte
- Requirements im Überblick: wofür der Corpus da ist
- Erstes Requirement: der praktische Einstieg
- Requirements: das Dateiformat mit allen Feldern