Projektmanagement

Klare Anforderungen

documents

Am Ende eines erfolgreichen Projektes stehen Ergebnisse. Welche Ergebnisse das sind, wird vorab in Form von Zielen und Anforderungen beschrieben. Theoretisch jedenfalls. Obwohl also Anforderungen von so zentraler Bedeutung im Projektmanagement sind, wird in der Praxis genau in dieser zentralen Disziplin leider allzu oft nicht präzise und ordentlich gearbeitet. Warum das so ist und was Sie dagegen tun können ist Inhalt dieses etwas längeren Exkurses in die Kunst des Anforderungsmanagements.

Ziel einer Anforderungsspezifikation (…) ist es, die Anforderungen so zu formulieren, dass zwischen dem Auftraggeber und Auftragnehmer ein gemeinsames Verständnis über das zu entwickelnde System geschaffen wird.
Wikipedia

Soweit die Theorie. In der Praxis stellt sich das systematische und vollständige Erfassen, Ordnen und Verwalten von Anforderungen leider etwas schwieriger dar.

If I had asked people what they wanted, they would have said faster horses.
Henry Ford

Die Problematik

„Eh-klar“-Anforderungen

Jeder Mensch hat ein Vielzahl von Annahmen über seine Umwelt. Meistens sind uns diese gar nicht bewusst. Das Problem impliziter Annahmen im Rahmen des Anforderungsmanagements hat zwei Facetten: Einerseits fehlen solche impliziten Anforderungen schlicht im Anforderungskatalog; andererseits beschränken diese Annahmen den Lösungsraum schon in der Anforderungsdefinition. Die implizite Annahme zur Zeit Henry Fords war, dass die Fortbewegung mittels Pferd die schnellstmögliche sei.

Lösungen statt Anforderungen

Diese implizite Annahme über die möglichen Arten der Beförderung führt automatisch zu einer geistigen Beschränkung des Lösungsraums. Die eigentliche Anforderung der Menschen zur Zeit Henry Fords war es schneller als bisher von einem Ort zum anderen zum anderen zu gelangen. Anstatt aber mit einer echten Anforderung unvoreingenommen nach Lösungen zu suchen, denken wir sehr schnell in konkreten Lösungen und halten die vorgeschlagene Lösung dann für unsere Anforderung.

Unvollständige Anforderungen

Die Fachexperten kennen zwar einerseits die Anforderungen, sind aber andererseits selten in der Lage diese systematisch und vollständig zu erfassen. Insbesondere die impliziten Anforderungen werden gerne vergessen. Aber auch Anforderungen, die nicht-funktionaler Natur sind, beispielsweise die Ausfallsicherheit eines Systems, werden vergessen, weil sie nichts mit den eigentlichen Arbeit zu tun haben. Trotzdem sind gerade diese nicht-funktionalen Anforderungen äußerst wichtig für das Finden der richtigen Lösung.

Oftmals bleiben die Anforderungen auch nur deshalb unvollständig, weil nicht alle Nutzergruppen ausreichend betrachtet wurden. Gerne vergessen wird der IT-Betrieb, der die Software nach Fertigstellung betreiben soll. Zur Fehlersuche und -behebung braucht der Betreiber in der Regel Hilfsmittel wie Logging, also das Aufzeichnen von Ereignissen im System in einem Logfile o.ä., oder Monitoring, also die Möglichkeit das System live zu überwachen und die Funktionsfähigkeit zu prüfen. Ähnliches gilt für Sicherheitsanforderungen.

Arten von Anforderungen

Anforderungen lassen sich grob in zwei Kategorien einteilen. Funktionale Anforderungen beschreiben das Verhalten des Systems aus fachlicher Sicht, also was das System tun soll. Nicht-funktionale Anforderungen hingegen beschreiben wie das System sein soll, also welche Eigenschaften es aufweisen soll.

Funktionale Anforderungen

Beschreibung des Verhaltens des Systems aus Sicht eines Nutzers, beispielsweise: „Das Produkt soll den Saldo eines Kontos zu einem Stichtag berechnen.“ Die Spezifikation erfolgt in der Regel in natürlicher Sprache. Formale Spezifikationen finden nur bei sehr kritischen Teilen Anwendung deren Korrektheit mathematisch bewiesen werden soll, beispielsweise die Steuerungssoftware einer Rakete.

Da natürliche Sprache immer auch zu Missverständnissen führt, ist ein einheitliches Format für die Anforderungen unbedingt anzuraten. Bewährt in der Praxis haben sich beispielsweise User-Stories in der Form: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>.“ Das eingangs angeführte Beispiel würde als User Story etwa so lauten: „Als Kontoinhaber möchte ich den Saldo meines Kontos zu einem Stichtag sehen, um eine schnelle Übersicht meiner finanziellen Lage zu erhalten.“

Ein weiterer wichtiger Bestandteil von Anforderungen sind Akzeptanzkriterien. Sie legen fest, wie bewertet wird, inwieweit eine Anforderung erfolgreich umgesetzt wurde. Im agilen Vorgehen heißen diese Kriterien daher auch die „Definition of Done“. Teilweise werden auch Testfälle zusammen mit den Anforderungen spezifiziert. Werden diese dann als Unit-Tests eingesetzt und die Anforderung während der Programmierung ständig gegen diese Tests geprüft spricht man auch von Test-Driven-Development.

Nichtfunktionale Anforderungen

Nicht-funktionale Anforderungen beschreiben die Eigenschaften eines Systems. Diese lassen sich grob in zwei Kategorien einteilen: in Eigenschaften der Ausführung, beispielsweise Benutzbarkeit oder Antwortzeiten, und Eigenschaften der Evolution, beispielsweise die Wartbarkeit oder die Portierbarkeit. Weitere Beispiele finden sich in Wikipedia:

Methodik

Erarbeiten in Workshops

Theoretisch würde es reichen, wenn die Fach- und IT-Experten gemeinsam die funktionalen und nicht-funktionalen Anforderungen aufschrieben. Aufgrund von impliziten Annahmen, Lösungsdenken und fehlender Systematik bleiben die Ergebnisse dann aber in der Regel suboptimal. Es hat sich bewährt, wenn ein erfahrener Moderator diesen Prozess sauber führt. Hierbei ist es wichtiger, dass der Moderator die Moderation der Gruppe und die Methodik beherrscht, weniger den Fachprozess selbst. Meist ist es vom Vorteil eher fachfremd zu sein, weil es dann leichter fällt, scheinbar dumme Fragen zu stellen und intensiver nachzuhaken, um damit implizite Annahmen herauszuarbeiten. In der Regel sind mehrere Workshops notwendig, um die Anforderungen nach und nach zu verfeinern und zu vervollständigen.

Vom Groben zum Feinen

Meistens bietet sich ein Vorgehen vom Groben zum Feinen an. Zunächst identifiziert man dazu in sich abgeschlossene Bereiche der Anwendung. Eine Online-Banking Anwendung hat zum Beispiel ein Modul Reporting in dem der Nutzer sich über seinen Kontostand informieren kann; davon losgelöst gibt es ein Modul Banking in dem der Nutzer Überweisungen und Daueraufträge einrichten kann. Gegenstand des ersten Workshops sollte genau dieser grobe Überblick über die verschiedenen Module sein, quasi eine Landkarte als Übersicht. In den folgenden Workshops werden dann die Funktionen dieser Module nach und nach verfeinert. Auch dabei geht man am besten vom Groben zum Feinen.

Format

Ein einheitliches Format, beispielsweise in Form von User-Stories, ist sehr hilfreich. Hierfür braucht es unbedingt einen erfahrenen Moderator, der auf die Einhaltung achtet. Nun stellt sich die ganz praktische Frage, wie und wo diese Anforderungen am besten dokumentiert werden. Die einfachste und am häufigsten gewählte Lösung ist die sprachliche Beschreibung der vereinbarten Anforderungen in einem Textdokument. Vorteil dabei ist es, dass der zum Zeitpunkt der Abnahme dieses Dokuments gültige und (hoffentlich) konsistente Stand der Anforderungen zusammenhängend in einem Dokument beschrieben ist.

Theoretisch geht man nun davon aus, dass dieser Stand mehr oder weniger 1:1 umgesetzt wird, was praktisch so nie passiert. Die Anforderungen leben weiter, ändern sich, einige fallen weg und andere kommen hinzu. Ein solches monolithisches Dokument an diese Änderungen anzupassen ist sehr aufwändig und wird in der Praxis kaum gemacht. Stattdessen werden die Änderungen in Ergänzungsdokumenten beschrieben. Um sich nach einer Weile den gültigen Stand der Anforderungen zu erschließen, ist es dann aber notwendig beim ursprünglichen Dokument zu starten und anschließend alle Änderungsdokumente zu sichten.

Ein weiterer Nachteil eines solchen Anforderungsdokuments ist die Trennung von Ergebnis und Diskussion. Ein Dokument hält immer nur das Ergebnis fest, aber nicht die Entstehungsgeschichte einer Anforderung. Gerade wenn Anforderungen sich entwickeln und weiterentwickeln, ist die Diskussion zur Anforderung eine hilfreiche Informationsquelle.

Werkzeuge

An dieser Stelle bieten sich professionelle Tools zum Anforderungsmanagement an, die im Wesentlichen alle die Möglichkeit bieten Anforderungen fein granular zu definieren, zu gruppieren, mit einem Status zu versehen und zu jeder Anforderung eine Diskussion zu führen. Zum Zeitpunkt der ganzheitlichen Erhebung der Anforderungen erscheint ein solches Tool meist ein wenig überdimensioniert, lohnt sich aber spätestens wenn die Anforderungen über Monate und Jahre hinweg sich verändern.

Professionelle Werkzeuge zur Verwaltung von Anforderungen gibt es sehr viele. Ihr großer Vorteil ist gleichzeitig für viele ihr größter Nachteil: Diese Systeme behandeln Anforderungen als atomare Objekte, die über verschiedene Attribute (Beschreibung, Aufwand, Status, etc.) verfügen und miteinander in Beziehung stehen können (Abhängigkeiten). Menschen die monolithische Dokumente in Prosa gewohnt sind und schätzen, haben damit in der Regel Mühe. Die Vorteile eines guten Werkzeugs überwiegen aber diesen Nachteil der Umgewöhnung bei weitem:

  • Eine zentrale Ablage aller Anforderungen.
  • Durch mehrere Benutzer gleichzeitig zu bearbeiten.
  • Historisierung und Rückverfolgbarkeit: Änderungen an Anforderungen werden protokolliert; historische Versionen sind jederzeit abrufbar.
  • Zugehörige Metainformationen an gleicher Stelle: Attribute und Diskussionen / Kommentare zur jeweiligen Anforderung.
  • Anforderungen können miteinander in Beziehung gesetzt werden (A ist Voraussetzung für B)
  • Verbindung von Anforderung mit Testfällen.

Fahren auf Sicht

Es ist verführerisch, die Anforderungen vollständig spezifizieren zu wollen bevor man zur Umsetzung schreitet. Dahinter steckt immer noch der Irrglaube, dass eine vollständige und korrekte Spezifikation möglich und sinnvoll sei. Tatsächlich stellt man während der Umsetzung fest, dass viele Anforderungen unnütz, unklar oder nicht korrekt sind. Meist ist es besser und billiger auf Sicht zu fahren und nur im Detail zu spezifizieren was tatsächlich als nächstes umgesetzt werden soll.

Ein Kriterium ob es besser ist auf Sicht zu fahren oder man getrost vollständig spezifizieren kann liefert das Cynefin-Framework zur Klassifikation des Vorhabens in die folgenden Kategorien:

Simple
Beziehung zwischen Ursache und Wirkung ist für alle offensichtlich.
Complicated
Beziehung zwischen Ursache und Wirkung erfordert Analyse und/oder die Anwendung von Fachwissen.
Complex
Beziehung zwischen Ursache und Wirkung kann nur im Nachhinein wahrgenommen werden.
Chaotic
Es gibt keine Beziehung zwischen Ursache und Wirkung auf Systemebene.

Die allermeisten Vorhaben werden entweder kompliziert oder komplex sein. Sind sie kompliziert, beispielsweise die Konstruktion eines Flugzeugs oder eines Hochhauses, ist eine vollständige Spezifikation möglich und sinnvoll. Bei einem komplexen Vorhaben, beispielsweise ein neuer Service für eine unbekannte Kundengruppe, ist unbedingt ein Fahren auf Sicht angeraten.

tl;dr

Weil es so einfach und grundlegend erscheint, findet das systematische Erfassen und Ordnen der Anforderungen an die Projektergebnisse leider viel zu selten die notwendige Aufmerksamkeit. Eben Mal schnell die Anforderungen von den Fachexperten in irgendeinem Format zusammenzutragen und abzustimmen, führt zu unvollständigen, unverständlichen und schlecht handhabbaren Anforderungen. Ein fachfremder oder wenigstens fachferner professioneller Moderator kann diesen Prozess der Anforderungserhebung und des Anforderungsmanagements deutlich beschleunigen und professionalisieren. Im weiteren Projektverlauf lohnt sich die anfänglich Investition in ein professionelles Anforderungsmanagement innerhalb kürzester Zeit.

Artikelbild: Sean MacEntee bei flickr.com (CC BY 2.0)

  1. Wolfram Lührig

    Eine sehr gute Zusammenfassung der wesentlichen Probleme und des Sinn und Zwecks guten Requirements Engineering. Nachdem ich dies in einem Software Entwicklungs-Projekt nach Scrum von der Pike auf gelernt hatte, musste ich mit Erstaunen oder Erschrecken feststellen, wie wenig das in anderen Projekten berücksichtigt wird. Auch wird sehr häufig der Bereich der Anforderungsdokumentation vernachlässigt oder ignoriert, so das man die Anforderungen höchstens aus der Software oder dem Quellcode ablesen kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.