menu Navigation
Sind funktionale Anforderungen zwecklos?

Sind funktionale Anforderungen zwecklos?

11. Mai 2016

FunktionWas 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?

3 Antworten zu “Sind funktionale Anforderungen zwecklos?”

  1. Axel Scheithauer sagt:

    Interessanter Vorschlag. Irgendwie habe ich jedoch das Gefühl, dass man nicht komplett auf die Beschreibung von Funktionen (im oben definierten Sinne) verzichten kann. Auch wenn sie erst im versprochenen Gespräch zur Sprache kommen sollten.

    PS: Es gibt schon einen Namen für „Verwendungsanforderung“. Er lautet – „Anwendungsfall“. Ein Anwendungsfall beschreibt zu welchem Zweck ein System benutzt werden kann.

    • Marcus Winteroll sagt:

      Ob man über die Funktionen nur spricht, ohne sie aufzuschreiben – wie man es im agilen Vorgehen macht -, oder sie tatsächlich niederschreibt – weil beispielsweise externe Vorschriften dies verlangen -, sie sind halt nur Mittel zum Zweck. Und dieser Zweck sollte im Mittelpunkt der Analyse stehen und auch bei der evtl. Dokumentation festgehalten werden.

      Natürlich wären Anwendungsfälle solche Verwendungsanforderungen. Diese Rolle könnten aber auch User Stories übernehmen. Wir brauchen also einen Überbegriff.

  2. Martin Pesch sagt:

    Leider findet man diese Art der „Anforderung“ auch immer wieder und immer häufiger in Prozess- und Aufgabenbeschreibungen. „Tue dies und das und berichte mir über den Stand und die nächsten Schritte.“ Ohne den großen Zusammenhang mit anderen Prozessen und Aufgaben zu sehen oder sehen zu wollen. Die User-Stories, die Gründe (RE:Rationals) werden nicht mitgegeben. Und um sich selbst nicht bewegen und verändern zu müssen ist KVP häufig auch nur ein schönes Wort. „Los, noch mehr rudern! (Boss und Leadership?!?) Ein Segel setzen? Was ist denn ein Segel?“ fällt mir dazu immer wieder ein…

Schreibe einen Kommentar zu Marcus Winteroll Antworten abbrechen

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