Anforderungen verlieren im Projekt ihren Grund. Das ist das eigentliche Problem.
Sie entstehen im Workshop, landen in einer Liste, wandern ins Ticketsystem – und irgendwann weiss niemand mehr, welcher fachliche Bedarf dahinterstand. TAOM hält die Verbindung zum Prozessschritt, zur Rolle und zum System, aus dem die Anforderung stammt.
Verfeinerung
Eine Anforderung wird nicht geschrieben, sie wird verfeinert
Zwischen „wir brauchen eine Prüfung» und einem gebauten Feld liegen acht Stufen. Der Streit im Projekt entsteht selten am Inhalt, sondern dort, wo unklar ist, wer die nächste Stufe verantwortet.
Der Nutzen
Die Frage, die zwei Jahre später kommt
Irgendwann fragt jemand, warum es ein bestimmtes Feld gibt, ob eine Prüfung noch nötig ist oder was passiert, wenn man eine Erweiterung entfernt.
Woran eine Anforderung hängt
Sechs Bezüge, die erhalten bleiben
Prozess
In welchem Ablauf sie gebraucht wird.
Aktivität
An welchem Schritt genau sie aufkam.
Rolle
Wer sie braucht und wer sie verantwortet.
System
Welche Anwendung sie erfüllen muss.
Geschäftsziel
Worauf sie einzahlt.
Entwicklungskontext
Was daraus gebaut wird – bis zur WRICEF-Einteilung.
Woher sie kommen
Die meisten Anforderungen sind Befunde aus der Erhebung
Was im Workshop auffällt
- 01Fehlende SystemfunktionenWas das System nicht kann und deshalb umgangen wird.
- 02BehelfslösungenDie Tabelle neben dem System, ohne die es nicht läuft.
- 03SchnittstellenlückenDaten, die von Hand übertragen werden.
- 04Auflagen und NachweiseWas jemand nebenbei erfüllt, ohne dass es dokumentiert ist.
- 05DatenproblemeFelder, denen niemand traut.
Kein Medienbruch dazwischen
Diese Befunde entstehen bei der Prozesserkennung – und bleiben an dem Schritt hängen, an dem sie aufgekommen sind.
Erhebung → Befund → Anforderung → Umsetzung ist damit ein Vorgang und nicht die Übergabe zwischen zwei Werkzeugen.
Was daraus entsteht
Bis zur Abnahme durchgezogen
- 01Fachliche AnforderungenWas das Geschäft braucht, in der Sprache des Geschäfts.
- 02Funktionale AnforderungenWas das System dafür leisten muss.
- 03WRICEF-ObjekteWorkflow, Report, Interface, Conversion, Enhancement, Form.
- 04Fach- und technische SpezifikationenVerhalten und Umsetzung, beide am selben Bezug.
- 05User StoriesFür Teams, die so arbeiten – mit demselben Ursprung.
- 06AbnahmekriterienWoran gemessen wird, ob es erfüllt ist.
Typische Anlässe
Wo das eingesetzt wird
- 01TransformationsvorhabenWenn viele Anforderungen gleichzeitig entstehen und schnell den Bezug verlieren.
- 02Fit-to-Standard-NachbereitungAus jeder Lücke wird eine Anforderung mit Begründung.
- 03Ablösung von AltsystemenHerausfinden, welche Eigenheiten fachlich nötig sind und welche nur historisch.
- 04AuditvorbereitungBelegen, warum eine Kontrolle existiert und wo sie wirkt.
- 05Übergabe an die UmsetzungSpezifikationen, die den fachlichen Grund mitliefern.
- 06Test und AbnahmeGeprüft wird gegen den Bedarf, nicht nur gegen das Dokument.
Anfangen
Mit einer Anforderung, die gerade strittig ist
Nehmen Sie eine, bei der niemand mehr genau sagen kann, warum sie so lautet. Hängen Sie sie an den Prozessschritt, aus dem sie stammt – und sehen Sie, wie viel klarer die Diskussion danach ist.