Anforderungen erheben

Der Stand der Praxis

In der Regel beginnt ein Projekt zunächst mit einer Anforderungsanalyse. Hierzu gibt es einige Literatur, die zwar Kriterien für die Erhebung nennt (z.B. Vollständigkeit oder Konsistenz), jedoch auslässt wie diese erreicht werden können. In der daraus entstehenden Verwirrung über das konkrete Vorgehen bei der Erhebung etablieren sich meist sehr einfache Kundenbefragungen, die dann oft zu kurz greifen.

Viele haben die Konsequenzen einer solchen Kundenbefragung bereits kennengelernt – mitten im Projekt kommen Fragen auf, deren Beantwortung einen „Aha“-Effekt nach sich ziehen, der dann meist zu aufwendigen Änderungen führt.

Drei einfache Schritte

In diesem Artikel möchte ich drei einfache Schritte aufzeigen, die helfen Anforderungen so zu erheben, dass sie einen möglichst hohen Nutzen für die weiteren Projektschritte liefern.

Ich erhebe nicht den Anspruch alle Probleme der Anforderungsanalyse lösen zu wollen. Die in der Literatur geforderte Vollständigkeit oder Konsistenz lässt sich nicht durch einfache Regeln sicherstellen. Dies bedarf viel Erfahrung, eine hohe Weitsicht, eine ganzheitliche Sicht des Projektes und eine gute Portion Intuition für die Branche und den Auftraggeber.

Schritt 1: Frage den Nutzer, was er benötigt, was er sich wünscht, was ihm wichtig ist. Schreibe dir alles auf.

Schritt 2: Gehe die notierten Punkte im Anschluss alle durch und frage jeweils nach, warum er dies braucht, was er damit erreichen möchte und wie es zu der Anforderung kam. Schreibe auch diese Antworten auf – jedoch separat.

Schritt3: Wirf die Ergebnisse aus Schritt 1 weg! Nimm die Notizen aus Schritt 2 – das sind die Anforderungen.

Anforderungen sind nicht das „was“

Diese drei einfachen Schritte mit der zugegebenermaßen radikalen Anweisung die Ergebnisse aus Schritt 1 zu verwerfen dienen der Illustration, dass Anforderungen meist nicht gut sind, wenn das „was“ erfasst wird. Vielmehr muss das „warum“ geklärt werden.

Um die Gründe griffiger zu erklären, bediene ich mich seit über zehn Jahren desselben Beispiels, dass ich gerne an dieser Stelle vorstellen würde.

Wenn ein Kunde zu mir kommt und mich bittet ihm eine Leiter herzustellen, dann frage ich nicht nach Länge und Tragkraft. Ich frage ihn, was er mit dieser Leiter denn vor hat. Antwortet der Kunde dann „Um eine Mauer zu überwinden, die 3 Meter hoch ist.“, dann frage ich ihn, ob er nicht lieber eine Tür in der Mauer hätte.

Ich verwende dieses Beispiel gerne, weil es eine klassische Situation beschreibt. Der Auftraggeber hat eine sehr gute Kenntnis von seinem Problem und sieht sogar eine konkrete Lösung. Diese muss nicht zwangsläufig die einzige sein. Eventuell gibt es bessere Lösungen für sein Problem.

Anforderungen sind das „warum“ und „wozu“

Nachdem das „was“ geklärt ist, könnte ich dem zukünftigen Nutzer der Leiter die Frage stellen „Und wie kommen sie von der anderen Seite wieder zurück?“ Die Antwort könnte dann wie folgt ausfallen: „Oh, dann brauche ich noch eine zweite Leiter für den Rückweg.“ Diese Sicht ist nur allzu verständlich und naheliegend. Das das Problem ist analog. Es zeigt aber auch, dass meist nur aus der aktuellen Lage beschrieben wird. Aspekte die sich zukünftig durch die Lösung ergeben werden, konnten bisher nicht erlebt werden. Sie gehören nicht zur Erfahrungswelt des Nutzers und sind nur schwer zu erheben. Ohne die Frage nach dem „warum“, wäre eine solche Überlegung nicht möglich.

Es wäre aber auch falsch dem Nutzer statt der Leiter ungefragt eine Tür zu bauen. Er könnte diese Leiter auch früher für andere Zwecke eingeplant haben ohne zum Zeitpunkt der Befragung daran zu denken. Eine Tür könnte für diesen anderen Zweck ungeeignet sein.

Daher ist es wichtig nach dem „warum“ zu fragen. Das „was“ deckt meist nur den Lösungsvorschlag des Kunden auf. Die darunterliegenden Beweggründe können nur durch ein weiteres Hinterfragen aufgedeckt werden.

Die Anforderung war also nicht „Ich benötige eine 3 Meter lange Leiter“ (was), sondern vielmehr „Ich möchte eine 3 Meter hohe Mauer überwinden können“ (warum).

Natürlich muss man die Ergebnisse aus Schritt 1 nicht wegwerfen. Man sollte sie nur nicht unreflektiert als „die Anforderungen“ ansehen. Um Anforderungen zu erhalten ist es wichtig nach jedem „Was?“ ein „Warum? Wozu? Wieso?“ hinterherschzuschieben.