Ein zusätzliches Dokument erzeugt Pflegeaufwand und wird selten geöffnet. Nutzungsanforderungen setzen sich durch, wenn sie in die Artefakte eingehen, mit denen das Team ohnehin arbeitet, vom Backlog bis zum Lastenheft. Der Beitrag beschreibt, wie diese Einarbeitung abläuft und welche Konventionen dafür nötig sind.
Ausgangslage: Der Anforderungskatalog neben dem Prozess
Am Ende einer Kontextanalyse liegt ein Dokument vor: der Katalog der Nutzungsanforderungen, oft als Tabelle oder Bericht, mit Quelle je Anforderung. Dieses Dokument ist sauber, vollständig und wird nach der Präsentation selten geöffnet. Das Team arbeitet im Ticketsystem, der Fachbereich in Confluence, die Architektur in ihrer Spezifikation. Der Katalog liegt daneben. Nach einigen Monaten weiß niemand mehr, ob er noch gilt.
Wir haben in Übergaben an Kundenteams und in der Arbeit als Interims-UX-Management wiederholt dasselbe gesehen: Anforderungen, die in einem eigenen Dokument leben, verlieren den Anschluss an die Entscheidungen. Anforderungen, die im Artefakt stehen, in dem entschieden wird, bleiben im Gebrauch. ISO 9241-210 verlangt, dass Nutzungsanforderungen dokumentiert und im Projektverlauf gepflegt werden. Wo sie dokumentiert werden, lässt die Norm offen. Die Antwort aus der Praxis lautet: dort, wo das Team ohnehin hinschaut.
Schritt 1: Die Artefakte des Teams aufnehmen
Der erste Schritt ist eine Bestandsaufnahme. Welche Artefakte benutzt das Team für Entscheidungen über den Produktumfang? In agilen Setups sind das Backlog, Story-Vorlage, Definition of Done und Testplan. In klassischen Vorgehen Lastenheft, Pflichtenheft, Abnahmeplan und Änderungsantrag. In den meisten Organisationen gibt es beides nebeneinander, etwa ein Lastenheft für die Vergabe und ein Backlog für die Umsetzung. Für jedes Artefakt wird notiert, wer es pflegt, in welchem Werkzeug es liegt und an welcher Stelle im Prozess es gelesen wird. Das Ergebnis ist eine Liste der Orte, an denen Anforderungen auftauchen müssen.
Schritt 2: Je Artefakt den Ort für die Anforderung bestimmen
Für jedes Artefakt aus der Liste wird festgelegt, wo die Nutzungsanforderung darin steht. Im Backlog: als eigener Eintragstyp mit Kennung, mit dem Stories verknüpft werden, oder als Feld in der Story, wenn das Werkzeug keinen eigenen Typ zulässt. In der Story-Vorlage: drei Zeilen für Anforderung, Quelle und Nutzungskontext. In der Definition of Done: der Satz, dass die Akzeptanzkriterien aus der verknüpften Anforderung abgeleitet sind. Im Lastenheft des klassischen Vorgehens: eine eigene Anforderungsklasse mit Nummerierung und ein Absatz im Abnahmeabschnitt. Im Testplan: die Anforderungskennung als Spalte neben dem Testfall.
Die Regel lautet: An einem Ort steht der vollständige Satz mit Quelle; alle anderen Artefakte verweisen auf die Kennung. Sonst entstehen abweichende Fassungen, und nach der ersten Änderung stimmen sie nicht mehr überein.
Schritt 3: Konventionen festlegen
Die Einarbeitung funktioniert nur mit Konventionen, die das Team kennt und einhält. Drei haben sich als notwendig erwiesen. Erstens eine Kennung je Anforderung, die in allen Artefakten gleich geschrieben wird. Zweitens ein Pflichtfeld für die Quelle: Methode, Datum, Protokollkennung; eine Anforderung ohne Quelle wird als Annahme markiert. Drittens ein Ereignis, das die Aktualisierung auslöst: nach jedem Usability-Test, nach jeder Kontextanalyse und bei jedem Änderungsantrag werden die betroffenen Anforderungen durchgesehen.
Diese Konventionen stehen in dem Dokument, in dem das Team seine Arbeitsweise festhält, etwa im Team-Handbuch oder in der Definition of Ready. Ein eigenes Konventionsdokument würde das Problem wiederholen, das dieser Beitrag beschreibt.
Schritt 4: Die Übergabe an eine benannte Rolle
Anforderungen setzen sich durch, wenn eine benannte Rolle sie pflegt. In der Einarbeitung übernehmen wir das Anlegen der Einträge und die erste Aktualisierung. Parallel wird die Rolle benannt, die das nach Projektende weiterführt: in agilen Setups meist der Product Owner oder eine UX-Rolle im Team, in klassischen Vorgehen die Person, die das Lastenheft verantwortet. Diese Rolle pflegt die Einträge vom zweiten Zyklus an selbst, mit uns daneben, und ist am Ende der Einarbeitung die Ansprechperson für jede Frage nach der Herkunft einer Anforderung.
Grenzen
Das Vorgehen setzt voraus, dass die Artefakte des Teams für Entscheidungen benutzt werden. Wo ein Anforderungsdokument nach der Vergabe niemand mehr öffnet, hilft es wenig, Anforderungen hineinzuschreiben; dann ist das Backlog der richtige Ort. Es setzt außerdem voraus, dass das Werkzeug Verknüpfungen und eigene Feldtypen zulässt. Bei Werkzeugen ohne diese Möglichkeit bleibt die Referenz im Beschreibungsfeld, mit höherem Pflegeaufwand.
Und es ersetzt nicht die Erhebung. Eine Anforderung, die aus einer Annahme stammt, wird durch die Einarbeitung ins Backlog nicht besser. Sie wird sichtbarer, und die fehlende Quelle fällt im Refinement auf.
Was danach vorliegt
Nach der Einarbeitung liegen vor: eine Liste der Artefakte mit dem Ort der Anforderung in jedem, ein Anforderungsbestand mit Kennung und Quelle an einem Ort, Referenzen in allen anderen Artefakten, drei Konventionen im Arbeitsweise-Dokument des Teams und eine benannte Rolle, die den Bestand pflegt. Der Anforderungskatalog als eigenes Dokument existiert danach nicht mehr. Sein Inhalt steht dort, wo entschieden wird.