Anforderungsmanagement ganz pragmatisch

Anforderungen ermitteln ist in der Software-Entwicklung ein leidiges Thema, wenn nicht das leidigste Thema überhaupt. Berge von Literatur wurden zum Thema Anforderungsmanagement verfasst. Viele Projektmanagement-Methoden haben die Definition und Festlegung der Anforderungen als zentrales Thema, gerade die moderneren Ansätze wie Scrum leisten hier schon eine ganze Menge. Egal ob Kunde, Auftraggeber, Stakeholder, Projektleiter, Architekt, Produkteigener zusammen sitzen es gilt immer die Anforderungen zu sammeln und so gut wie möglich – was „gut“ auch immer bedeuten möge – zu erfassen. In die Klärung und Verfeinerung von Anforderungen lässt sich beliebig viel Zeit und Aufwand (ggf. auch aufwändige Werkzeuge) investieren und versenken. Um so mehr können einige wenige pragmatische und methodenunabhängige Merksätze helfen. Hier erst einmal die Sätze bzw. Fragen bevor ich weiter unten noch mehr schreibe:

• Ist klar, wer der Auftraggeber ist?
• Sind alle Erwartungen des Auftraggebers bekannt?
• Auf ungefragt, geäußerte Information achten!
• Auf persönliche Steckenpferde achten!
• Gibt es mehrere Anforderer?
• Gibt es widersprüchliche Anforderungen?
• Das „Was“ und das „Wie“ nicht vermischen?
• Was braucht der Kunde wirklich?

Wer ist der Auftraggeber (wahlweise Stakeholder, Produkteigner, …)? Er legt letztendlich die Ziele fest und niemand anderes. In größeren Projekten werden oft von der Seite weitere Anforderungen und Ziele ein gekippt – manchmal frei nach dem Motto, das könnt Ihr doch gleich mit erledigen. Und wenn so eine Seitenidee noch so gut erscheint und noch so gut passt, sie erhöht in der Regel den Aufwand und wenn die Idee nicht vom Auftraggeber kommt wird niemand das Budget erhöhen wenn es am Ende knapp wird.

Wenn der Auftraggeber klar ist, stellt sich die nächste Frage nach seinen Erwartungen. In den seltensten Fällen sind diese vollständig in Dokumenten zu finden. Einige werden nur mündlich formuliert, ein kleiner Teil bleibt womöglich unausgesprochen. Auch wenn die unausgesprochenen Erwartungen vertraglich wenig relevant sein mögen, so haben Sie doch großen Einfluss auf die (Un-)Zufriedenheit des Auftraggebers. Je früher solche versteckten Erwartungen – ich nenne sie auch implizite Projektziele – ans Licht geholt werden, desto geringer ist das planerische Risiko. So sicher wie das Amen in der Kirche wird ein Teil dieser versteckten Erwartungen im Laufe des Projekts in Form „seltsamer neuer“ Anforderungen auftauchen.

Im Laufe des manchmal mühseligen Prozesses genaue und klare Anforderungen zu ermitteln gibt es auch „Brocken in der Suppe“ die immer wieder von alleine auftauchen: Anforderungen, die freiwillig und ohne Nachfragen genannt werden. Das erleichtert im ersten Moment die Arbeit, dennoch sollten solche Anforderungen besonders genau unter die Lupe genommen werden. Hinter diesen Anforderungen stecken meist ein starke Interessen der jeweiligen Anforderer. Diese Interessen müssen nicht zwingend im Sinne des Projektes sein. Deshalb gilt es diese Anforderungen kritisch zu prüfen. Im Sinne dieser Prüfung sollte man sich auch fragen ob sich dahinter eventuell persönliche Steckenpferde verstecken. Ich möchte „persönliche Steckenpferde“ nicht schlecht machen, oft ist es eine große Hilfe für die Anforderungsdefinition wenn Spezialwissen gepaart mit Begeisterung für ein Thema zusammen kommen. Die Aufnahme aller persönlichen Steckenpferde kann die Anforderungsliste aber auch überfrachten. Bei der Bewertung der Anforderungen lohnt sich immer auch ein Blick darauf ob es eine einzelne Person oder mehrere Personen sind, die hinter einer formulierten Anforderung stehen. Nicht immer zählt die Masse aber es hilft bei der Steckenpferdanalyse.

Auch gut beschriebene Anforderungen können wertlos werden, wenn sie nicht genau auf Widersprüche geprüft worden sind. Wenn Zeit und Budget im Übermaß vorhanden sind lassen sich manche Widersprüche durch ein salomonisches „sowohl als auch“ lösen. In realen Projekten sind Zeit und Geld aber knapp. Eine Entscheidung welche der widersprüchlichen Anforderungen umgesetzt wird, muss so früh wie möglich gefällt werden um zum Ende des Projektes hin nicht unnötig Ärger auf der Kundenseite zu verursachen. Fällt der Widerspruch erst am Ende auf, wenn eine der Anforderungen schon umgesetzt wurde und dann doch die Entscheidung für die andere fällt wurde für den Papierkorb gearbeitet – dann ist der „worst case“ im Projektgeschäft schon eingetreten.

Die nächste Frage erscheint trivial und ist dennoch von großer Bedeutung. An einem Beispiel wird es deutlich. Die Anforderung lautet: „6 Personen aus Stuttgart müssen morgen um 10:00 Uhr in Mannheim pünktlich zu einem Termin erscheinen“. Das ist das „Was“ – eine simple Formulierung der Anforderung. Das „Wie“ ist die Frage nach dem Transportmittel, als da wären: Auto, ICE, Flugzeug. Eine vermischte Formulierung wäre „6 Personen müssen mit dem Zug nach Mannheim fahren und pünktlich zu einem Termin erscheinen“. Selbst wenn die Lösung der Anforderung wirklich die Zugfahrt ist, muss die Anforderung selbst lösungswegneutral formuliert werden. Wird dieser Grundsatz vernachlässigt, werden manche Entscheidungen vorweggenommen bzw. Entscheidungsspielräume im Projekt eingeschränkt. Besonders hartnäckige „Was-Wie“ Mischungen kommen meist im Schlepptau von technischem Halbwissen daher.

Die letzte Frage schließt den Kreis zur ersten nach dem Auftraggeber. Egal ob man diesen Auftraggeber, Stakeholder oder Kunde nennt, man sollte immer versuchen sich in den Kunden hinein zu versetzen und versuchen zu verstehen was er wirklich braucht. Nicht immer ist das was ggf. sogar sehr klar formuliert wird auch wirklich das was benötigt wird. Echte Zufriedenheit beim Kunden/Auftraggeber wird sich nur einstellen wenn er wirklich das bekommt was er braucht.