Requirements Engineering – Zufriedenheit ist eine Anforderung

Lesedauer 5 Minuten

Im ersten Beitrag zum Thema Requirements Engineering wurde die Definition für den Begriff »Anforderung« gemäß IEEE Standard gegeben. Nun soll eine wesentlich einfachere und intuitivere Erläuterung dieses Begriffs folgen:

Eine Anforderung ist das, was Kunden bzw. Anwender zufrieden macht, wenn sie erfüllt wurde.

Glücklicherweise ist dem Autor dieses Beitrags keine ISO-Norm für den Begriff der Zufriedenheit geläufig. Daher wird ab sofort stillschweigend vorausgesetzt, dass wir alle das Gleiche darunter verstehen.

Zufriedenheit nach Kano

Im Jahre 1978 untersuchte Noriaki Kano (Tokio) die Zusammenhänge zwischen der Zufriedenheit von Menschen und der Erfüllung von Erwartungen an bestimmte Dienstleistungen oder Produkte. Dabei leitete er ab, dass verschiedene Arten von Merkmalen sich unterschiedlich auf die Zufriedenheit auswirkten.

Leistungsmerkmale

Leistungsmerkmale sind jene Merkmale, die ein Produkt definieren. Sie werden bewusst gefordert und gesucht. Beim Auto wäre die Frage nach Gangschaltung oder Automatik ein Beispiel für ein Leistungsmerkmal. Bei einem Webshop kann das Anbieten verschiedener Zahlungsoptionen ein Leistungsmerkmal sein, das die Zufriedenheit steigert.

Mit Leistungsmerkmalen machst du deine Kunden aktiv glücklich. Du bietest ihnen unmittelbar einen Mehrwert, der von ihnen, etwa durch gute Reviews, honoriert wird.

Begeisterungsmerkmale

Dabei handelt es sich um jene Merkmale, die über die Erwartungen hinausgehen. Das können etwa Alleinstellungsmerkmale oder Sonderausstattungen sein, die ein Produkt von der Konkurrenz abgrenzen. Umgangssprachlich lässt sich bei diesen Merkmalen auch von einem »Wow-Effekt« sprechen.

Als die ersten Mobiltelefone mit Touchscreens auf den Markt kamen, stellte die damals neue Technik einen klaren Begeisterungsfaktor dar. Es war eine Abgrenzung von den bisherigen Geräten, die mit mechanischen Tasten bedient wurden.

Basismerkmale

Basismerkmale sind jene Merkmale eines Produkts oder eines Services, die so grundlegend sind, dass erst gar nicht darüber gesprochen wird. Von ihrer Existenz wird einfach stillschweigend ausgegangen. Die Windschutzscheibe eines Autos ist ein Beispiel für ein Basismerkmal. Bei Websites hingegen wird vorausgesetzt, dass sie auf gängigen Geräten und mit den üblichen Browsern gut aussehen müssen.

Es ist leicht einzusehen, dass das Übersehen, Vergessen oder Weglassen eines Basismerkmals schlimme Auswirkungen auf ein Produkt haben kann. Denn auch wenn ihr Vorhandensein keine gesteigerte Zufriedenheit erzeugt, wirkt sich ihr Fehlen verheerend aus. Oder würdest du ein Auto fahren wollen, bei dem die Windschutzscheibe fehlt?

Darüber hinaus unterschied Kano noch zwei weitere Arten von Merkmalen (unerhebliche Merkmale und Ablehnungsmerkmale), die aber im Rahmen dieses Beitrags nicht von Bedeutung sind.)

Graphisch lässt sich der Zusammenhang zwischen den einzelnen Typen von Merkmalen und der damit erzeugten Zufriedenheit recht einfach darstellen.

Alterungsprozess

Wichtig ist auch die Erkenntnis, dass diese Aufteilung nicht für die Ewigkeit ist. Was heute ein Begeisterungsmerkmal ist, kann morgen schon zum gewöhnlichen Leistungsmerkmal degradiert werden. Und übermorgen ist es ein Basismerkmal, dessen Existenz vorausgesetzt wird. Die bereits erwähnten Touchscreens sind ein Beispiel dafür: Einst waren sie ein Alleinstellungsmerkmal, heute sind sie allgegenwärtig.

Ein anderes Beispiel wäre die Möglichkeit, mit deinem Mobiltelefon Fotos aufzunehmen. Im Jahr 2000 war das eine unglaublich großartige Sache, um die dich manche vielleicht auch beneidet hätten. Heute hingegen lockt das keinen Hund mehr hinter dem Ofen hervor. Auch hier ist das einstige Begeisterungsmerkmal nach einigen Jahren zum Leistungsmerkmal geworden – wenn es nicht sogar schon als Basismerkmal zählt.

Von Merkmalen zu Anforderungen

Die beschriebenen Typen von Merkmalen dienen im Requirements Engineering als Basis für unterschiedliche Arten von Anforderungen.

Bewusste Anforderungen

Diese Anforderungen beziehen sich auf das, was später zu den Leistungsmerkmalen wird. Dabei handelt es sich im Wesentlichen darum, was zum Beispiel in einem Pflichtenheft stehen würde: Es existiert eine klare Vorstellung davon, was ein Produkt können muss, und mit diesen Anforderungen wird ihr eine Gestalt verliehen.

Doch leider geht das, was ein Produkt leisten muss, oftmals darüber hinaus. Denn in vielen Fällen stellt sich erst später heraus, dass noch andere Dinge nötig sind, um Kunden zufriedenzustellen oder gar zu begeistern.

Unbewusste Anforderungen

Diese Anforderungen entsprechen den Begeisterungsmerkmalen. Das sind Features, an die zu Beginn noch niemand dachte oder deren Mehrwert anfangs noch nicht klar war. Sie sind, nüchtern betrachtet, eigentlich nicht nötig, um ein funktionierendes Produkt herzustellen. Doch später (nämlich dann, wenn alle sagen, sie hätten es ja schon immer gewusst) werden sie zu jenen Features, die sich von der Konkurrenz abheben.

Vor langer Zeit reichte es, die Funktionen eines Programms einfach nur über eine Menüführung oder Schaltflächen zugänglich zu machen. Laut bewusster Anforderungen war dies alles, was es brauchte. Doch dann kam jemand auf die Idee, den Anwendern zu ermöglichen, Menüs und Schaltflächen individuell zu gestalten. Das ist ein Beispiel für eine Anforderung, deren Mehrwert sich erst zeigte, als jemand sie realisierte.

Hier zeigt sich, dass sich Anforderungen ebenso altern können wie die Merkmale des Kano-Modells. Was ursprünglich eine unbewusste Anforderung war und eine klare Abgrenzung von anderen Produkten darstellte, ist heutzutage fast schon Pflicht und wird gefordert: Die unbewusste Anforderung wird zur bewussten und wandert schließlich ins Unterbewusstsein weiter.

Unterbewusste Anforderungen

Diese Anforderungen decken die Basismerkmale ab. Das sind jene grundlegenden Punkte, über die erst gar niemand spricht, weil sie ja »eh klar« sind. Sie werden – eben unterbewusst – als so selbstverständlich vorausgesetzt, dass sie im schlimmsten Fall unter den Tisch fallen.

Das Einhalten von Standards und Normen kann in diese Kategorie fallen. Menschen haben täglich damit zu tun, sodass sie ihnen bereits in Fleisch und Blut übergegangen sind. Aus der daraus resultierenden Betriebsblindheit wird leicht darauf vergessen, explizit darauf hinzuweisen, wenn ein neues Produkt in Auftrag gegeben wird.

Aber auch Fragen der Usability oder Performance können unterbewusste Anforderungen sein, die man möglicherweise stillschweigend voraussetzt, aber nicht ausdrücklich festhält. Die bloße Existenz einer bestimmten Funktion eines Programms mag in den bewussten Anforderungen enthalten sein. Doch ohne nähere Spezifizierung kann es passieren, dass diese Funktion für AnwenderInnen am Ende nur schwer zu finden ist. Ebenso ist es möglich, dass sie unter realen Bedingungen keinen Mehrwert bietet, obwohl sie mit Testdaten gut arbeitete.

Umso wichtiger ist es, solche unterbewussten Anforderungen zu identifizieren und klar festzuhalten, da sie ansonsten zu fehlenden Basismerkmalen führen. Das Resultat sind unzufriedene Anwender, aber im schlimmsten Fall kann auch ein Markteintritt verhindert werden.

Forschen vor Entwickeln

Am leichtesten lassen sich die bewussten Anforderungen ermitteln, da sie dem entsprechen, was konkret gefordert ist. Wie aber lässt sich das Unbewusste oder gar Unterbewusste feststellen?

Bei den unterbewussten Anforderungen kannst du als Requirements Engineer sogar Spaß haben. Denn in diesem Feld kannst du nur gewinnen. Hier wird nicht am Fundament gearbeitet, hier geht es um die Verzierungen. Um jene Dinge, bei denen man vielleicht sagt: »Nice to have«. Aber wenn sie fehlen, fliegt dir das Ding trotzdem nicht um die Ohren. Und im Idealfall lässt sich der eine, kleine Unterschied erarbeiten, der ein Produkt am Ende vom Rest abgrenzt.

Hier kannst du auf sogenannte Kreativ-Techniken setzen, indem du beispielsweise Workshops und Brainstormings abhältst. Dabei ist ausdrücklich das Träumen erlaubt: Nichts ist unmöglich, jede Idee ist willkommen. Erst am Ende wird ausgesiebt, was tatsächlich in die Sammlung der Anforderungen hineinsoll.

Schwieriger, weil mühsamer, sind die unterbewussten Anforderungen. Bei ihnen musst du als Requirements Engineer zum Forscher werden. Du wirst viel lesen, beispielsweise gesetzliche Vorgaben und Normen in den relevanten Bereichen. Geht es beispielsweise um den Nachfolger eines existierenden Produkts, wirst du dich damit beschäftigen. Auch die Konkurrenz kann gute Einblicke liefern, welche Grundvoraussetzungen erfüllt sein müssen, damit ein Produkt überhaupt bestehen kann.

Manchmal reicht es auch nicht, selbst Hand anzulegen, sondern du musst zum Verhaltensforscher werden. Denn auch das Beobachten von Leuten, wie sie Probleme mit vorhandenen Werkzeugen lösen, kann Einblicke liefern, was die Grundvoraussetzungen für das Kommende sind.

Halte deine Erkenntnisse fest und ergänze die schon vorhandenen Anforderungen, wo es nötig ist. Und denk immer daran: »Eh klar« gibt’s nicht.

Das könnte dich auch interessieren

Günter Gerstbrein

Günter Gerstbrein, Jahrgang 1977, studierte technische Mathematik an der TU Wien und war etwa 13 Jahre in der Software-Entwicklung tätig. Als „Texter, der aus der Technik kam“ ist es sein Ziel, komplizierte Sachverhalte leicht verständlich und ohne viel Techno-Babble zu vermitteln.

Gerstbrein textet