Projektmanagement (eBook)

3.2 Anforderungen und Ziele

3.2.1 Anforderungen

4.5.2 Anforderungen und Ziele / Bloom'sche Taxonomie 2 – Verstehen

„Willst du mir wohl sagen, wenn ich bitten darf, welchen Weg ich hier nehmen muss?“ fragt Alice. „Das hängt zum guten Teil davon ab, wohin du gehen willst“ sagte die Katze. „Es kommt mir nicht darauf an, wohin “, sagte Alice. „Dann kommt es auch nicht darauf an, welchen Weg du nimmst“, sagte die Katze. „Wenn ich nur irgendwo hinkomme“, fügte Alice als Erklärung hinzu [CARR69].

Dieser Ausschnitt aus dem Gespräch von Alice mit der Grinse-Katze im Buch „Alice im Wunderland“ macht das Dilemma in so manchem Projekt deutlich. Wir wissen nicht genau, wohin die Reise gehen soll, doch das erledigen wir dann höchst effizient und wundern uns, wenn am Ende die Kosten überschritten werden und die Leistung durch unseren Auftraggeber nicht abgenommen wird. Die Gründe für diese Irritationen sind vielschichtig [EBER14, HRUS14]:

• Unklare, interpretierbare Anforderungen
• falsche Anforderungen
• implizite Anforderungen
• fehlende Anforderungen
• Änderung von Anforderungen

Ohne klare und abgenommene Anforderungen lassen sich schwerlich die Leistungsziele des Projekts und ihre Messkriterien definieren. Anforderungsmanagement oder besser Requirements Engineering legt hierfür den Grundstein.

Gem. der ISO 10006 (Qualitätsmanagementsysteme – Leitfaden für QM in Projekten) ist „die Erfüllung der Anforderungen der Kunden und anderer interessierter Parteien für den Projekterfolg notwendig.“ [DIN16c] Was sind Anforderungen? Das IEEE (Institute of Electrical and Electronical Engineers) definiert eine Anforderung in der Norm ISO/IEEE 29148 als „statement which translates or expresses a need and its associated constraints and conditions.“ [IEEE11] Den Bedarf („need“) bekommen wir für unser Projekt im Idealfall mittels eines Lastenhefts. Das Lastenheft (User Requirements Specification) ist die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines (Projekt-)Auftrags.“ [DIN16a] Das heißt jedoch nicht in jedem Fall, dass in diesem Dokument tatsächlich alle Anforderungen abgebildet sind.

Für den Projektleiter und sein Projektteam gilt es, das Lastenheft gegen die sachlichen Umfeldfaktoren auf weitere, bisher nicht dokumentierte Anforderungen abzuprüfen. Ebenfalls ist das Lastenheft auf unklare bzw. interpretierbare Anforderungen „abzuklopfen“. Eine wichtige Quelle für Anforderungen sind ebenfalls die sozialen Umfeldfaktoren also die Stakeholder des Projekts. Diese repräsentieren sozusagen die „Stimme des Kunden“ (Voice of Customer, VoC). In der VoC spiegeln sich Bedürfnisse, Wünsche, Ansprüche und Erwartungen an die im Projekt zu erbringende Dienstleistung bzw. das zu erstellende Produkt [SCHM15].

Anforderungen sind somit das Bindeglied zwischen dem Auftraggeber („will etwas haben“) und dem Auftragnehmer („kann es liefern“). Dabei wird zwischen funktionalen und nichtfunktionalen Anforderungen unterschieden.

Die Anforderungen sind entsprechend aufzunehmen und zu beschreiben. Hierzu können folgende Regeln herangezogen werden [HRUS14]:

• kurze, einfache Sätze
• eine Anforderung pro Satz
• Bedürfnisse keine Lösungen beschreiben
• Abkürzungen nur wenn unbedingt notwendig
• keine Generalität (manche, viele, alle, man, ...)
• Verbindlichkeiten klar formulieren (was muss, was kann?)
• aktiv formulieren (Wer macht was?)
• Erfüllung überprüfbar (Messbarkeit, Akzeptanzkriterien)
• Priorität festlegen

Eins sollte hierbei immer berücksichtigt werden – niemals bei Unklarheiten eine eigene Annahme im Sinne „Das wird mein Interviewpartner schon so gemeint haben“ treffen. Oder um es mit den Worten von ERIC BOGOSIAN im Film „Under Siege 2: Dark Territory“ (1995) zu sagen: „Assumptions are the mother of all fuck ups!“8

Die präzisierten Requirements werden meistens in einem Pflichtenheft zusammengeführt. Das Pflichtenheft stellt das „vom Auftragnehmer erarbeitete Realisierungsvorhaben auf der Basis des vom Auftraggeber vorgegebenen Lastenhefts“ dar [DIN16a]. Es ergänzt das Lastenheft um erste Lösungsideen, Angaben zu den erwarteten Kosten und erste zeitliche Schätzungen. Das Pflichtenheft, häufig wird auch Fachkonzept oder Systembeschreibung synonym dafür verwendet, stellt somit die Sicht des Auftragnehmers dar und ist die Basis für die weiteren Schritte im Projekt. [VDI01]

3.2.2 User Story, Story Map

4.5.2 Anforderungen und Ziele / Bloom'sche Taxonomie 2 – Verstehen

4.5.3 Leistungsumfang und Lieferobjekte / Bloom'sche Taxonomie 2– Verstehen

Anforderungen können auch mittels User Stories beschrieben werden. Sie sind eine kurze, prägnante Beschreibung des gewünschten Ergebnisses. Eine User Story wird so verfasst, dass sie sowohl von kaufmännischem als auch von technischem Personal verstanden werden kann. Sie ist einfach strukturiert und wird meistens in folgendem Format ausgedrückt:

• Ich als (Rolle)
• möchte (Funktion, Ziel)
• damit ich folgenden (Nutzen, Vorteil) habe

Der letzte Teil (Nutzen, Vorteil) ist sehr wichtig, denn er stellt den Grund für die Anforderung dar und ist evtl. der Ausgangspunkt für alternative Überlegungen. [RUBI14]

Zusätzlich wird ein Akzeptanzkriterium definiert, anhand dessen überprüft werden kann, ob die Funktion erfolgreich entwickelt bzw. das Ziel erreicht wurde. Gut formulierte User Stories folgen INVEST -Kriterien. [DRÄT13] Das bedeutet, User Stories sind ...

Tabelle 8: INVEST-Kriterien

Zur Visualisierung des gesamten Vorhabens eignet sich eine Story Map. Eine Story Map stellt eine anwenderzentrierte Perspektive einer bestimmten Anzahl von User Stories dar. Die Idee dahinter ist, Benutzeraktivitäten in einen Arbeitsablauf (Thema) zu zerlegen und diesen dann in weitere detaillierte Aufgaben (User Stories). Ein Thema (engl. Theme) stellt damit eine Sammlung zusammenhängender User Stories dar. Noch eine Ebene höher lässt sich ein sog. Epic platzieren. Ein Epic ist das Synonym für eine große Anforderung, die zu einem passenden Zeitpunkt verfeinert wird. [RUBI14]

Gesammelt werden die User Stories im sog. Product Backlog.

Das Product Backlog ist eine geordnete Auflistung aller Produktfunktionalitäten die im laufenden Projekt umgesetzt werden sollen. Die einzelnen Funktionalitäten sind priorisiert und als User Story formuliert. Es ist dynamisch und wird ständig weiterentwickelt, um Anforderungen zu identifizieren, die das Produkt besser, nutzbringender und wettbewerbsfähiger machen. [FOEG16, RUBI14]

Merkmale guter Product Backlogs sind im Akronym DEEP zusammengefasst [DRÄT13]