Guidelines360° Requirement Management

360° Requirement Management

 

Wo entstehen Anforderungen?

Anforderungen entstehen in unterschiedlichen Zeiträumen. In Bezug auf ein Projekt oder die Erarbeitung eines neuen Themas kann man aber grundsätzlich die nachfolgenden drei Phasen annehmen:

Grundsätzlich kann man sagen, dass Anforderungen durch irgendetwas oder irgendwen ausgelöst werden. Irgendetwas kann z.B. ein technischer Ausfall eines Systems oder ein Bug in einem System sein. Hier ist kein Mensch der Auslöser.

Werden Anforderungen von Menschen ausgelöst, spricht man von einem „User Request“..

User Requests sind zunächst reine Anfragen, die man systematisch ablegt. Sie sind erst mal unqualifiziert, unstrukturiert und unklassifiziert. Mit der Erfassung ist noch keine Garantie der Umsetzung gegeben.

Wichtig ist, einen User Request klar zu beschreiben und sicherzustellen, dass er verständlich ist, damit auf dieser Basis eine mögliche Anforderung abgeleitet und beschrieben werden kann.

Bevor dies geschieht, ist es durchaus sinnvoll, User Requests vorher noch einmal zu bewerten, welchen Nutzen die Lösung des Requests erbringen würde. Auf dieser Basis lassen sich in der Regel gut Prioritäten ableiten, welchen User Requests der Fokus gewidment wird und welche in die nächste Stufe der Anforderungsdefinition und Aufwandsschätzung kommen darf.

Alles sind Anforderungen – 360°

Normalerweise werden nur Anforderungen (Requirements) gemanaged, die die Lösung betreffen. Damit ist Requirement der Oberbegriff über alles, was zu tun ist. Alle Aufgaben sind Requirements. In FAST betrachten wir aber auch alle Anforderungen, die die folgenden Dimensionen betreffen

  • Anforderungen an die Lösung

  • Lösungsprozess (Projekt)

  • Change

  • Operation

Um auf Ticketebene eine saubere Unterscheidung der Requirementsdimensionen zu gewährleisten, unterscheiden wir:

  • User Stories sind Requirements für die Lösung.

    • User Requests sind dabei eine Inbox für neue, noch unstrukturierte, unklassifizierte Anforderungen.

  • Tasks sind Requirements für Lösungsprozess, Change und Operation.

Anforderungen an die Lösung sind:

  • Funktionale, nicht-funktionale Anforderungen

  • Konzepte, Spezifikationen, Implementierung, Test Cases etc.

  • Ergebnisse sind nachhaltig, bleibend.

  • ca. 40 % von allen Tickets

Projektanforderungen sind:

  • Anforderungen an den Lösungsprozess nach innen gerichtet

  • Beispiele:

    • alle 3 Monate Lenkungskreis

    • Reporting ist bis zum 4. Arbeitstag abzugeben.

    • Entscheidungsvorlage muss erarbeitet werden.

    • Workshop muss organisiert werden.

    • Der Integrator benötigt VPN-Zugang.

    • Funktion X muss getestet werden.

    •  …

  • ca. 40 % von allen Tickets

Change Management-Anforderungen

  • Anforderungen an Lösungsprozess nach außen gerichtet

  • Beispiele:

    • US Markt muss im Projekt eingebunden werden.

    • Der Betriebsrat muss informiert werden.

    • ca. 20 % der Tickets

 

Operation-Anforderungen

  • Anforderungen an den Betrieb

  • Beispiele

    • Service Matrix (wer ist für was verantwortlich)

    • Monitoring

    • Support

Wer schreibt, der bleibt!

Natürlich bedeutet es Aufwand, eine Anforderung zu verschriftlichen, aber eine mündliche Überlieferung von Person zu Person funktioniert nun mal einfach nicht. Das weiß eigentlich jedes Kind aus dem Spiel „Stille Post“..

Ebenso verhält es sich, wenn Anforderungen in Workshops diskutiert, dann aber nicht dokumentiert und nochmals final abgestimmt werden. War wirklich das gemeint?

Und auch hier ist Text geduldig und kann beim Leser immer noch zu einer anderen Interpretation des geschriebenen Wortes führen. Daher ist es vor allem bei größeren Anforderungen durchaus sinnvoll, diese mehrfach zu reviewen und ggf. weiter zu konkretisieren. Und wenn nötig, natürlich auch durch andere Hilfsmittel wie Abbildungen, Bilder, Zeichnungen, Diagrammen, Charts usw. zu verdeutlichen.

Ziel ist es, so viel Klarheit für alle zu erreichen, dass ohne weitere Rückfragen transparent ist, was gemeint ist.

Hierzu existiert eine Vielzahl von Methoden, wie User Stories, Epics etc., die gut geschrieben werden können. An dieser Stelle möchten wir dies nicht vertiefen, da hierzu genügend Infos bereitstehen.

Eine Anmerkung aus unserer Erfahrung aber möchten wir mitgeben:

Wir haben gute Erfahrungen damit gemacht, über Akzeptanzkriterien den Fertig-Zustand zu spezifizieren. Also wann eine Story oder ein Task wirklich erledigt ist. Über diese Auflistung lässt sich sehr gut systematisch die Klarheit einer User Story oder eines Tasks herbeiführen.

Alle Anforderungen werden bewertet

Da sowohl User Requests, die irgendwann eventuell zu einer User Story werden, als auch Tasks Aufwand verursachen, werden auch beide bewertet. Entweder mit Aufwand oder Story Points. Erst im Zusammenspiel von „Grundbewertung für den Aufwand“ und einem möglichen Nutzen als zweite Sicht der Bewertung kann eine fundierte Entscheidung getroffen werden, ob und wenn ja mit welcher Priorität Requirements umgesetzt werden.

Vom User Request zum dokumentierten Ergebnis:

Ein typischer Bewertungsprozess könnte folgendermaßen aussehen:

Jede Anforderung durchläuft diesen Prozess 

Der Prozess kann je nach Größe oder Klarheit der Anforderung die einzelnen Phasen unterschiedlich schnell (von Minuten bis zu Wochen) durchlaufen, z.B.:

  • Ein Folgeticket muss nicht lange bewertet werden, es ist einfach zu machen.

  • Wünsche von Usern müssen unter Umständen sorgfältig geprüft werden auf Kosten/Nutzen und Auswirkungen auf Zeit, Architektur und Ressourcen.

 

Klassifizierung von Anforderungen 

Eine systematische Klassifizierung sorgt für Transparenz auch aus mehreren Perspektiven, beispielsweise:

  • Herkunft der Anforderung (User Request, technisches Issue, Kunde, Bug, …)

  • Zeitliche Einordnung, wann wird es gelöst?

  • In welches Themenfeld gehört die Anfoderung?

Da diese durchaus mehrdimensional sein kann, ergibt es Sinn, eine Übersicht analog dem nachfolgenden Beispiel zu schaffen, damit alle Beteiligten die Requirements auch richtig klassifizieren. Dies ist eine wesentliche Voraussetzung, um vor allem bei großen Vorhaben mit mehreren tausend Anforderungen eine gute Transparenz und Auskunftsfähigkeit zu gewährleisten.

 

 

Durch diese Klassifizierung gibt es auch bei agilem Projektvorgehen zu jedem Zeitpunkt

  • einen klaren Scope

  • Abschätzungen über Budget, Ressourcen und zeitliche Planung.

 

Verantwortlichkeit im Requirement-Management 

Eine wesentliche Klassifizierung von User Stories und Tasks ist die der Verantwortlichkeit. Eine fehlende Verantwortlichkeit ist in der Regel der (negative) Garant dafür, dass der Task oder die User Story entweder

  • untergeht/vergessen wird,

  • mehrfach angeschaut, diskutiert wird und damit immer wieder Aufwand verursacht,

  • mit der Zeit immer unklarer wird

    • und im Besten Fall „sich von alleine erledig“ oder

    • im schlimmsten Fall plötzlich dringlich wird und bestehende Planungen und Prioritäten zerstört.

Es ergibt somit Sinn, ein Ticket (User Story, Task) immer mit einem Verantwortlichen zu versehen. Dieser muss nicht über den gesamten Zeitraum gleich bleiben. Bei einem Wechsel ist aber dafür zu sorgen, dass die Übergabe wirklich vollzogen wird und der Nachfolger die Verantwortlichkeit auch annimmt.

 

Üblicher Fehler im Requirement-Management  

Nachfolgend die häufigsten Fehler, die im Requirement-Management gemacht werden und dazu führen, dass die Kräfte, die in einem sauberen Requirement-Management stecken, sich nicht entwickeln können.

 

Fehler

Ursache

Rein technische Sicht

Nur IT-Umsetzung im Blick

Scrum nur für Entwicklung

Andere Themen wie Management of Change laufen irgendwie nebenher.

Tunnelblick

Fokusiert auf ein Thema, z.B. Funktionen

Testing, Prozesse und Migration werden vergessen.

Schleichende Scope Erweiterung

Laufend neue (kleine) Anforderung, z.B. in Akzeptanzkriterien versteckt, Anregungen, Wünsche durch den Lenkungskreis oder aus dem Projektteam

Verfahren nicht geklärt

Requirement-Management wurde nicht mit dem Projekteam abgestimmt: Verfahren, Verantwortlichkeiten, Dokumentation