Wer Funktionen mit Nutzen verwechselt, kauft oft die falsche Software

Vor einigen Jahren saß ich in einem Workshop zur Vorbereitung einer größeren IT-Ausschreibung.

Nach kurzer Zeit füllte sich das Flipchart mit Anforderungen.

„Die Software muss einen Excel-Export haben“,
„Wir brauchen ein Dashboard“,
„Die Lösung muss mobil funktionieren“,
„KI-Unterstützung wäre ebenfalls wichtig“,
„Wir brauchen eine mobile App“

Nach etwa einer Stunde waren mehrere Flipchartbögen vollgeschrieben. Jede Fachabteilung hatte ihre Wünsche eingebracht. Der Einkauf ergänzte vergabe- und vertragsrelevante Anforderungen. Die IT diskutierte bereits über mögliche Hersteller und machte erste Überlegungen zur Umsetzung.

Ich stellte nur eine einzige Frage:

„Warum brauchen Sie eigentlich einen Excel-Export?“

Der Raum wurde plötzlich still. Nach kurzem Nachdenken antwortete schließlich jemand:

„Eigentlich wollen wir die Auswertungen nur unkompliziert an andere Abteilungen weitergeben.“

Und genau in diesem Moment hatte sich die Diskussion verändert. Plötzlich ging es nicht mehr um einen Excel-Export. Es ging darum, Informationen einfacher bereitzustellen. Zum ersten Mal diskutierten wir nicht mehr über Funktionen, sondern über den eigentlichen Bedarf.

Ob dieses Ziel später über einen Excel-Export, ein Dashboard, einen automatisierten Bericht oder eine Schnittstelle erreicht wird, spielte zunächst überhaupt keine Rolle mehr.

Das eigentliche Problem

Solche Situationen erlebe ich erstaunlich häufig. Viele Anforderungen beschreiben bereits die Lösung, bevor das eigentliche Problem ausreichend verstanden wurde.

Ein Dashboard ist keine Anforderung. Eine mobile App ist keine Anforderung. Auch künstliche Intelligenz ist zunächst keine Anforderung.

Sie alle sind mögliche Antworten auf eine Frage, die häufig noch gar nicht gestellt wurde:

Welches Problem möchten wir lösen?

KI ist dafür ein gutes Beispiel

Besonders deutlich wird dieses Phänomen derzeit beim Thema Künstliche Intelligenz. In vielen Projekten höre ich Aussagen wie:

„Wir brauchen eine KI-gestützte Suche.“
„Die neue Lösung soll einen intelligenten Chatbot besitzen.“
„Die Software muss generative KI unterstützen.“
„Die KI soll dann die Daten auswerten.“

Meine Gegenfrage lautet dann fast immer: „Welches Problem soll die KI eigentlich lösen?“

Gewünschte Funktion	Eigentlicher Nutzen
KI-gestützte Suche	Informationen innerhalb einer Minute finden
Chatbot	Standardfragen automatisiert beantworten
Generative KI	Routineaufgaben schneller erledigen
KI analysiert Daten	Entscheidungen schneller und fundierter treffen

Sollen Mitarbeitende Informationen schneller finden? Sollen Routineaufgaben automatisiert werden? Oder sollen Entscheidungen besser vorbereitet werden?

Je nachdem fällt die technische Lösung völlig unterschiedlich aus.

KI ist keine Anforderung.
KI ist eine mögliche Lösung.

Manchmal ist sie sogar die beste Lösung. Manchmal gibt es jedoch einfachere, günstigere oder robustere Alternativen. Deshalb sollte am Anfang nicht die Technologie stehen, sondern der gewünschte Nutzen.

Gute Anforderungen beginnen deshalb nicht mit Funktionen

Je länger ich Projekte begleite, desto mehr bin ich überzeugt:

Eine gute Anforderung beschreibt zuerst den gewünschten Nutzen. Die Funktion kommt erst danach. Denn nur wenn der Nutzen klar ist, können unterschiedliche Lösungswege überhaupt bewertet werden.

Vielleicht ist der Excel-Export oder der intelligente Chatbot tatsächlich die beste Lösung. Vielleicht aber auch nicht. Entscheidend ist jedoch, dass wir diese Entscheidung bewusst treffen – und nicht bereits unbewusst durch unsere Anforderungen vorwegnehmen.

Warum diese Denkweise gut begründet ist

Interessanterweise beschäftigt sich die Forschung schon seit vielen Jahren genau mit dieser Fragestellung.

Barry Boehm stellte mit seinem Konzept des Value-Based Software Engineering den Nutzen für die Stakeholder in den Mittelpunkt von Softwareprojekten.

Im Goal-Oriented Requirements Engineering werden Anforderungen aus übergeordneten Zielen abgeleitet und nicht umgekehrt.

Und Karlsson sowie Ryan zeigten bereits Ende der 1990er-Jahre, dass Anforderungen nicht nur nach ihrem Aufwand, sondern auch nach ihrem erwarteten Nutzen bewertet werden sollten.

Alle diese Ansätze verfolgen denselben Gedanken:

Nicht jede Funktion schafft automatisch Mehrwert.

Jede zusätzliche Funktion verursacht Aufwand und Kosten. Sie muss entwickelt, getestet, dokumentiert, geschult und später gewartet werden. Eine Funktion ist deshalb nur dann sinnvoll, wenn sie einen nachvollziehbaren Beitrag zum Projekterfolg leistet.

Deshalb sollte jede Anforderung eine einfache Frage beantworten können: Welchen konkreten Nutzen schafft sie?

Wenn darauf niemand eine überzeugende Antwort geben kann, lohnt sich zumindest ein zweiter Blick auf diese Anforderung.

Was bedeutet das für eine Ausschreibung?

Eine Ausschreibung sollte möglichst genau beschreiben, welches Ziel erreicht werden soll. Sie sollte jedoch nur dort eine konkrete Lösung vorgeben, wo dies tatsächlich erforderlich ist. Denn je früher wir uns auf eine bestimmte Funktion festlegen, desto kleiner wird der Lösungsraum. Und manchmal verbauen wir uns damit genau jene Innovation, die wir eigentlich gesucht haben.

Meine Erfahrung

In vielen Projekten stelle ich deshalb mittlerweile eine einfache Frage:

„Was passiert eigentlich, wenn wir diese Funktion nicht haben?“

Erst wenn darauf eine überzeugende Antwort gegeben werden kann, wird aus einer gewünschten Funktion eine wirklich begründete Anforderung.

Erstaunlich oft zeigt sich dabei, dass hinter einer Funktion ein ganz anderes Ziel steckt.

Und genau dort beginnt für mich eine gute Business Analyse und ein strukturiertes Requirements Engineering.

Fazit

Software wird nicht dadurch erfolgreich, dass sie möglichst viele Funktionen besitzt.

Deshalb werde ich in künftigen Workshops vermutlich seltener fragen: „Welche Funktionen brauchen wir?“

Stattdessen:

„Welches Problem möchten wir eigentlich lösen?“

Und danach:

„Welchen Nutzen möchten wir erreichen?“

Denn wer Funktionen mit Nutzen verwechselt, kauft oft die falsche Software.

Weiterführende Literatur

• Barry Boehm: Value-Based Software Engineering, ACM SIGSOFT Software Engineering Notes, 2003.
• Karlsson, J.; Ryan, K.: A Cost-Value Approach for Prioritizing Requirements, IEEE Software, 1997.
• Ellis-Braithwaite, M.: Goal-Oriented Requirements Engineering and the Contribution of Requirements to Business Goals, University of Toronto, 2013.
• IREB e.V.: CPRE Foundation Level – Lehrplan Requirements Engineering (Kapitel zu Stakeholdern, Zielen und lösungsneutralen Anforderungen).
• HM Treasury: The Green Book – Appraisal and Evaluation in Central Government.