Was tut der Requirements Engineer (RE)? Er ermittelt die richtigen, wichtigen Anforderungen. Das ist leichter gesagt als getan. Denn: definiert er – oder sie – als Anforderung das, was die Stakeholder heute brauchen, bekommen sie morgen eine Lösung von gestern!
Hast Du das auch schon erlebt? Du erhebst wochenlang Anforderungen, schreibst und zeichnest, dokumentierst und priorisierst, Du kategorisierst, analysierst und präsentierst. Du erstellst ein Lastenheft oder einen Anforderungskatalog. Du lädst verschiedene Anbieter ein, Du hörst und schaust zu, notierst und diskutierst. Du vergibst Noten und Punkte, scheust keinen Aufwand, machst zuletzt noch eine Nutzwertanalyse und ermittelst die beste Lösung – und dann entscheidet sich der Geldgeber für eine andere: die mit dem poppigen, farbigen GUI oder die mit dem neuartigen Excel-Plugin-Wizard.
Du bist konsterniert. Was ist falsch gelaufen?
Während Du mit Blick gegen innen untersucht hast, wie die ideale Lösung für Deine Firma heute aussähe, hat sich die Welt ausserhalb weiterentwickelt. Auch die Anbieter betreiben Requirements Engineering. Oft wird ein Product Owner (PO) diese Rolle besetzen. Sie und ihr Team befassen sich mit dem Markt, den aktuellen Trends, mit den neusten Lösungsansätzen und dem letzten Stand der Technik. Ihre zwei Hauptziele sind:
- Ein Produkt zu schaffen, dass die Anforderungen potenzieller Kunden erfüllt und übertrifft.
- Alleinstellungsmerkmale (USPs) zu kreieren.
Letztere können funktional sein, oft technologischer Natur («cutting edge») oder den Prozess betreffend («best practise»). An dieser Stelle kann aber ein oft unterschätztes oder vernachlässigtes Element ins Spiel kommen: Design. Gerade das Design eines Produkts kann am Markt eine enorme Rolle spielen. (Beispiele, wo wir selbst nach der äusseren Erscheinung entscheiden, kann vermutlich jeder und jede von uns bei sich selbst finden.)
Das Ziel der Entwicklerin ist, Funktionen zu bauen, von denen Du noch gar nicht gewusst hast, dass Du sie brauchst. Das Ziel des Designers ist, das Produkt so zu gestalten, dass Du es willst! So etwas geschieht nicht zufällig und ist eine Disziplin für sich. In einem andern HSLU Blog habe ich die folgende Aussage eines Design Managers gefunden:
“Liefere nicht, was der Kunde will – liefere das, was er träumt und nicht äussert.”
Auf den ersten Blick scheint das im Widerspruch zu stehen zu dem, was an der Fakultät für Informatik gelehrt wird. Jetzt haben wir doch gerade Wochen und Monate damit verbracht, herauszufinden, was unsere Stakeholder wollen. Und jetzt sollen wir ihnen nicht geben, was sie wollen?!
Auf den zweiten Blick sehen wir aber, dass der Designer das Requirement Engineering einfach noch etwas weitertreibt. Er versucht, nicht genannte, oft nicht bewusste Bedürfnisse zu befriedigen. Aufgabe der geschickten Verkäuferin ist es dann, diese Bedürfnisse beim Kunden zu wecken…
Wie kann ich als RE damit umgehen? Ja, es ist meine Aufgabe, möglichst alle bekannten und unbekannten Anforderungen und Wünsche meiner Stakeholder zu ermitteln und zusammenzuführen.
Bei einer sorgfältigen Evaluation kann ich transparent machen, welche dieser Anforderungen durch welches Produkt wie gut abgedeckt werden und welchen Erfüllungsgrad welches Produkt erreicht.
Es kann aber vorkommen, dass ein Produkt in einem Abschnitt punktet, der im Anforderungskatalog fehlt. Da bin ich als RE gut beraten, den noch einzufügen und dem Anbieter dankbar zu sein. Er hat zu meinen Anforderungen von gestern ein Bedürfnis von heute hinzugefügt. Und das kann mir helfen für meine Prozesse von morgen.
Die Frage, ob ich dieses Bedürfnis hätte erkennen können, muss ich mir als RE gefallen lassen. Aber vielleicht hätte ich dafür wirklich eine Kristallkugel gebraucht.
Image Credit: Photo by Arthur Ogleznev on Unsplash
