Sind funktionale Anforderungen zwecklos?

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Was sind eigentlich funktionale Anforderungen? Naheliegende Antwort: sie beschreiben die Funktionen des Systems. Na schön. Aber was sind Funktionen?  Jetzt wird es schwierig, da es zahlreiche Bedeutungen des Begriffs „Funktion“ gibt. Aber vielleicht auch nicht ganz so schwierig, denn schließlich hat sich in der Informatik eine Bedeutung als vorherrschend etabliert: Eingabe, Verarbeitung, Ausgabe. Damit scheint also klar, was funktionalen Anforderungen an ein System beschreiben: die möglichen Eingaben, deren Verarbeitung und die möglichen Ausgaben. Und dies ist zumindest eine verbreitet Auffassung.

Ist damit die Frage beantwortet, was funktionale Anforderungen sind? Vielleicht. Nur hilft das nicht wirklich weiter, wenn wir die Anforderungen an ein System herausarbeiten und verstehen wollen. Keine Frage, so lässt sich ein System vollständig beschreiben. Nur was hier gar nicht erst angesprochen wird, ist der Zweck des Systems und einzelner Anforderungen. (Interessanterweise beschreibt eine gebräuchliche Verwendung von „Funktion“ in unserer Alltagssprache den Zweck, z.B. „Die Funktion einer Uhr ist, die Zeit anzuzeigen.“)

Anforderungen an ein System zu beschreiben, ohne auf deren Zweck einzugehen, ist sicherlich üblich und erfüllt auch einen Zweck, denn im Rahmen von Festpreisverträgen lässt sich so genau beschreiben, was am Ende abzuliefern ist. Wenn das die Hauptzweck Ihrer Anforderungserhebung ist, dann sind Sie damit auf der sicheren Seite. (Und nach meiner Erfahrung, scheint das für viele wirklich das Allerwichtigste an den Anforderungen zu sein, hier für Klarheit zu sorgen.)

Wenn Sie allerdings herausbekommen wollen, wie Sie die Nutzer des Systems mit diesem bestmöglich unterstützen, dann ist es keine gute Idee, den Zweck des Systems und der einzelnen Anforderungen auszublenden. Es reicht nicht einmal, gewissermaßen als Präambel der Anforderungsbeschreibung den Zweck des Systems als Ganzes zu formulieren. (Was auch selten und noch seltener gut gemacht wird.) Letztlich werden Sie den Zweck des Systems nur dann bestmöglich erreichen, wenn Sie für jede einzelnen Anforderungen darüber nachdenken.

Genau das ist der Grund, warum Anwendungsfälle nicht nur aus Ablaufbeschreibungen bestehen, sondern immer auch aus einem angestrebten fachlichen Ergebnis. Tatsächlich ist das sogar wichtiger als die Ablaufbeschreibung. Und ebenso enthalten User Stories neben der eigentlichen Anforderung („Als Kunde möchte ich eine Lieferadresse eingeben…“) immer einen Zweck („…um die gekauften Ware an die richtige Adresse geliefert zu bekommen“). In der agilen Vorgehensweise wird der Zweck als essentiell angesehen, denn hier wird die User Story als ein „Versprechen auf ein Gespräch“ behandelt. D.h. die Anforderung kann jederzeit geändert werden, wenn sich der genannte Zweck dadurch besser erreichen lässt.

Um ein System zu entwickeln, das die Nutzer bestmöglich unterstützt und so seinen Zweck wirklich erfüllt, müssen wir also den Blick vom System auf die Nutzer wenden: Welches Ziel verfolgen diese und wo kann das System sie dabei unterstützen. Dazu betrachten wir die Abläufe, welche die Benutzer (sic!) zum von ihnen gewünschten Ziel führen, überlegen, was davon das System den Nutzern abnehmen kann und optimieren diese Abläufe.

In dieser nutzerzentrierten Sichtweise kommt eine Beschreibungen von Funktionen im informationstechnischen Sinne gar nicht vor. Natürlich ließe sich eine solche hieraus ableiten. Doch wozu sollten wir dies dann noch tun? Es bedeutet auf jeden Fall zusätzliche Arbeit und beraubt die Umsetzer der Freiheit, das System mittels ihres Wissens und ihrer Ideen besser auf den Zweck anzupassen. (Darum lässt die reine Funktionsbeschreibung  den Zweck auch gleich weg, damit niemand erst auf die Idee kommt, nachzudenken…)

Um die Eingangsfrage wieder aufzunehmen: Funktionale Anforderungen im engeren Sinne brauchen allenfalls noch diejenigen, die durch Rahmenbedingungen wie Vorgehensmodell oder Festpreis im traditionellen Sinne dazu gezwungen werden. Selbstverständlich könnten wir auch einfach sagen, unter „Funktionaler Anforderung“ verstehen wir auch so etwas wie Anwendungsfälle oder User Stories, denn am Ende ergäben sich daraus auch die Systemfunktionen im engeren Sinne – wir uns die Mühe machten, diese abzuleiten.

Doch um die Praxis in der Anforderungserhebung wirklich mehr in Richtung auf den Nutzer zu verändern, sollten wir den alten Begriff durch einen neuen ersetzen. Wie wäre es „Verwendungsanforderung“, da wir ja die Verwendung des Systems beschreiben wollen. Was ist Ihre Meinung? Vielleicht hat ja jemand von Ihnen noch eine bessere Idee?