Requirements Engineering
Aus Absichten werden Sätze, die man abnehmen kann — mit Akzeptanzkriterien statt Adjektiven.
- User Stories
- Akzeptanz
- Priorisiert
Wie es abläuft
Anforderungen entstehen nicht in einem Dokument, sondern in Gesprächen, die dann jemand aufschreibt. Wir machen beides.
Aus Wunsch wird Satz
Wir formulieren jede Anforderung so, dass sie ein Ergebnis beschreibt und kein Gefühl. Nicht “die Suche soll schnell sein”, sondern was die Suche findet, in welcher Reihenfolge, und ab wann das Ergebnis brauchbar ist.
Akzeptanzkriterien
Zu jeder Anforderung schreiben wir, woran man erkennt, dass sie erfüllt ist. Diese Kriterien sind später die Abnahme. Sie werden vor dem Bau vereinbart, nicht danach ausgehandelt — das ist der ganze Sinn.
Sonderfälle
Wir fragen systematisch nach dem, was selten passiert. Was, wenn zwei Leute gleichzeitig bearbeiten? Wenn jemand mitten im Vorgang die App schließt? Wenn der Datensatz aus dem Altsystem unvollständig ist? Diese Fälle sind der Grund, warum Schätzungen platzen, wenn man sie erst im Bau entdeckt.
Priorisierung
Zum Schluss sortieren wir. Was muss in die erste Version, was kann warten, was streichen wir. Wir bestehen darauf, dass gestrichen wird — eine Liste, auf der alles wichtig ist, ist keine Priorisierung.
- Jemanden, der fachlich entscheidet und erreichbar ist. Rückfragen kommen täglich, nicht wöchentlich.
- Die Sonderfälle, die ihr im Kopf habt und die nie jemand aufschreibt.
- Bestehende Regeln: Preislogik, Rabatte, Fristen, Freigabewege.
Ein Anforderungskatalog aus User Stories mit Akzeptanzkriterien, priorisiert und von euch freigegeben.
Wenn man das überspringt
"Der Nutzer soll Rechnungen verwalten können" ist kein Satz, den man abnehmen kann. Ohne Kriterien wird bei der Abnahme über Absichten gestritten, und der Streit hat keinen Schiedsrichter.
Fragen zu diesem Schritt?
Ein Gespräch kostet nichts und dauert eine halbe Stunde. Danach weißt du, ob wir zusammenpassen.