Vorrangregeln für Anforderungen

Wer hat Vorrang, wenn sich mehrere Verkehrsteilnehmer an einer Kreuzung treffen?

Diese Frage stellt sich im Straßenverkehr jeden Tag unzählige Male. An Kreuzungen, Einmündungen oder Engstellen müssen Autofahrer, Radfahrer und Fußgänger innerhalb von Sekunden selbst entscheiden, wer zuerst fahren oder gehen darf. Für lange Überlegungen bleibt keine Zeit.

Damit diese Entscheidungen nicht dem Zufall überlassen bleiben, gibt es ein gesetzliches Regelwerk: die Straßenverkehrsordnung (StVO). In ihr ist festgelegt, nach welchen Regeln solche Situationen grundsätzlich ablaufen und wer unter welchen Voraussetzungen Vorrang hat.

Jeder, der einen Führerschein erwerben möchte, muss diese Regeln lernen und verstehen. Millionen Menschen wenden sie täglich an, oft ganz selbstverständlich und nahezu automatisch. Gerade deshalb funktioniert der Verkehr in den meisten Fällen erstaunlich reibungslos.

Und genau hier beginnt die Parallele zum Requirements Engineering: Auch dort treffen unterschiedliche Anforderungen aufeinander. Nicht alles kann gleichzeitig umgesetzt werden, deshalb braucht es klare Regeln dafür, was zuerst behandelt wird. Diese Regeln kennen wir im Projektumfeld als Priorisierung.

Wer bekommt grünes Licht bei Anforderungen?

Priorisierung kommt immer dann ins Spiel, wenn entschieden werden muss, was am relevantesten ist oder als Erstes umgesetzt werden soll. Das ist notwendig, weil Ressourcen begrenzt sind.

Im Projektmanagement spricht man oft vom magischen Projektdreieck [1] mit den drei Eckpunkten Zeit, Budget und Scope. Alle drei hängen voneinander ab und stehen häufig in Konkurrenz zueinander. Sowohl Zeit als auch Budget sind meist äußere Rahmenbedingungen, die wir als Requirements Engineer nur begrenzt beeinflussen können. Wenn der gesamte Scope umgesetzt werden soll, setzen genau diese beiden Faktoren oft harte Grenzen. Wir müssen also mit einem vorgegebenen Budget und bis zu einer definierten Deadline liefern.

Um zu vermeiden, dass mit den verfügbaren Mitteln Funktionen umgesetzt werden, die nur einen relativ geringen Nutzen für den Kunden haben, sollte man mit den wichtigsten Anforderungen beginnen.

Im Straßenverkehr nähert man sich einer Kreuzung und muss unmittelbar entscheiden, wer zuerst fahren darf. Die Verkehrsregeln geben dafür eine klare Reihenfolge vor: Einsatzfahrzeuge zuerst, dann Schienenfahrzeuge, dann Vorrangstraßen und so weiter. Die Vorrangregeln auf der Straße sind klar definiert. Aber wie sieht das im Requirements Engineering aus?

Was im Straßenverkehr als Vorrang bekannt ist, ist im Requirements Engineering als Priorität bekannt. Laut BABOK [2] der IIBA [3] hat Priorisierung das Ziel, „Anforderungen in der Reihenfolge ihrer relativen Bedeutung zuzuordnen“. Ausgangspunkt sind bereits vorhandene und inhaltlich abgestimmte Anforderungen. Das Ergebnis ist eine nachvollziehbare Reihenfolge.

Die konkrete Form dieser Anforderungen kann unterschiedlich sein: User Storys, Features oder Epics. Entscheidend ist dabei weniger die Bezeichnung als die Granularität. Epics sind meist grob granular, User Storys deutlich feiner granular. Wichtig ist, dass man Gleiches mit Gleichem vergleicht. Man priorisiert also Epics oder Features oder Stories, aber nicht alles gleichzeitig.

Überträgt man die Logik der Straßenverkehrsordnung auf das Requirements Engineering, dann könnte man sagen:

• Die Verkehrsteilnehmer sind die Anforderungen.
• Die Straße ist das Backlog.
• Die Vorrangregeln sind die Kriterien, aus denen sich die Reihenfolge ergibt.

Genau solche Vorrangregeln für Anforderungen sehen wir uns nun an.

MoSCoW: Klarer Vorrang mit Grenzen

Eine bekannte Methode der Priorisierung ist MoSCoW. [4] Der Begriff ist ein Akronym aus den Anfangsbuchstaben von Must have, Should have, Could have und Won’t have. Ergänzt wurde er um zwei kleine „o“, damit das Wort überhaupt aussprechbar ist.

MoSCoW liefert klare Vorrangregeln: ein einfaches, aber wirkungsvolles System aus vier Kategorien, das Teams und Stakeholdern hilft, gemeinsam zu entscheiden, welche Anforderung wann „die Kreuzung passieren“ darf.

Must have: Must-have-Anforderungen haben absolute Vorfahrt. Fehlt auch nur eine davon in der aktuellen Auslieferungs-Timebox, gilt das Ergebnis als gescheitert. Sie bilden das nicht verhandelbare Minimum.

Should have: Should-have-Anforderungen sind wichtig, für die aktuelle Timebox aber nicht zwingend erforderlich. Ähnlich wie eine Vorrangstraße genießen sie im Regelfall Vorrang, können in bestimmten Situationen aber auch warten. Häufig sind diese Anforderungen genauso wertvoll wie Must-haves, jedoch weniger zeitkritisch oder durch eine Übergangslösung überbrückbar.

Could have: Could-have-Anforderungen sind wünschenswert, aber nicht notwendig. Sie verbessern die User Experience oder die Zufriedenheit der Nutzenden, ohne dass ihr Fehlen das Produkt grundlegend infrage stellt. Sie werden zuerst zurückgestellt, sobald wichtigere Themen Vorrang haben. Diese Anforderungen fließen in die Planung ein, wenn Zeit und Budget es erlauben.

Won’t have (dieses Mal): Won’t-have-Anforderungen werden im gegenseitigen Einvernehmen aller Stakeholder für diese Timebox bewusst ausgeschlossen. Die Einfahrt ist vorerst gesperrt. Das „dieses Mal“ ist entscheidend: Diese Anforderungen sind nicht dauerhaft gestrichen, sondern können in einer späteren Iteration erneut geprüft werden.

Abbildung 1: Kategorisierung von Anforderungen mit der MoSCoW-Methode

Ein großer Mehrwert von MoSCoW liegt nicht nur in den vier Kategorien selbst, sondern im Gespräch, das sie erzwingen. Wie im Straßenverkehr braucht es klare Regeln, damit alle Beteiligten wissen, wer wann fahren darf und wer noch warten muss.

MoSCoW passt besonders gut, wenn Anforderungen bereits inhaltlich abgestimmt sind, Ressourcen begrenzt sind, mehrere Stakeholder beteiligt sind und viele gleichartige Anforderungen priorisiert werden müssen. Dann bietet die Methode eine einfache und verständliche Vorgehensweise.

Allerdings hat auch MoSCoW Grenzen. Orientiert man sich ausschließlich daran, arbeitet man zuerst an den Must-haves, danach an den Should-haves und zuletzt an den Could-haves.

Sind alle Must-haves umgesetzt, könnte ein Projekt rein methodisch sogar als erfolgreich gelten, obwohl sich in der Praxis kein echter Projekterfolg einstellt. Der Grund liegt nicht in der Methode selbst, sondern darin, dass spannende oder innovative Anforderungen mit geringerer Priorität sehr lange im Backlog bleiben oder gar nie umgesetzt werden.

So können Ideen mit großem Potenzial als wichtig gelten, aber nicht als zeitkritisch. Dann landen sie in der Gruppe Should have oder Could have und fallen bei Zeit- oder Budgetengpässen am Ende weg.

Vorrangregeln nach Kano: Nicht alles wirkt gleich

Zurück auf die Straße. Stellen Sie sich vor, Sie steigen in ein neues Auto. Dass die Bremsen funktionieren, setzen Sie selbstverständlich voraus. Niemand würde das als besonderes Feature loben. Dass das Navi zuverlässig und schnell navigiert, ist ihnen besonders wichtig. Je besser es funktioniert, desto zufriedener sind Sie. Und dass das Auto beim Einparken automatisch die Musik leiser dreht? Damit hätten Sie gar nicht gerechnet und genau das begeistert Sie.

Genau diese drei Erlebnisse stehen hinter dem Kano-Modell. [5] Professor Noriaki Kano untersuchte, wie ausgelieferte Features die Zufriedenheit von Kunden beeinflussen, und kam zu einer entscheidenden Erkenntnis: Nicht alle Anforderungen wirken gleich.

Er unterscheidet drei Kategorien: Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren.

Basisfaktoren werden stillschweigend erwartet. Sind sie vorhanden, fällt das kaum auf. Fehlen sie, ist die Enttäuschung groß und das Vertrauen in das Produkt sofort beschädigt. Im Straßenverkehr entspricht das der funktionierenden Infrastruktur: intakte Straßen, lesbare Schilder, funktionierende Ampeln. Niemand lobt sie, aber ohne sie bricht das System zusammen. Im Auto sind das funktionierende Bremsen, der Sicherheitsgurt oder das eingebaute Radio.

Im Requirements Engineering sind das jene Anforderungen, die als selbstverständlich gelten. Sie müssen erfüllt sein, erzeugen für sich allein aber keine Begeisterung.

Leistungsfaktoren wirken direkt auf die Zufriedenheit: Je besser sie umgesetzt sind, desto zufriedener sind die Nutzenden. Je schlechter sie umgesetzt sind, desto größer ist die Unzufriedenheit. Im Straßenverkehr entspricht das der Qualität der Fahrbahn. Eine glatte, gut ausgebaute Straße erhöht den Fahrkomfort spürbar, Schlaglöcher stören ebenso spürbar. Im Auto sind das der Verbrauch, die Zeit für das Aufladen eines E-Fahrzeugs oder die Reichweite.

Diese Anforderungen werden von Stakeholdern meist aktiv eingefordert. Sie sind bekannt, messbar und direkt verhandelbar.

Begeisterungsfaktoren sind Features, die niemand ausdrücklich verlangt hat, die aber echte Freude auslösen, wenn sie vorhanden sind. Ihr Fehlen wird nicht negativ wahrgenommen, ihr Vorhandensein dagegen sehr positiv. Im Straßenverkehr wäre das eine Umleitung, die nicht nur den Stau umgeht, sondern zusätzlich an einem schönen Aussichtspunkt vorbeiführt. Niemand hat damit gerechnet, aber alle sind begeistert. Im Auto könnte das eine Sitzheizung sein, die separate Einstellung für den Rücken und das Gesäß kennt. 

Im Produktkontext sind das oft innovative Features, die Kunden erst schätzen, nachdem sie sie erlebt haben.

Abbildung 2: Einteilung von Anforderungen in Faktoren des Kano-Modells

Die zentrale Botschaft des Kano-Modells lautet: Ein erfolgreiches Release braucht alle drei Kategorien. Wer ausschließlich Basisfaktoren liefert, hält das Produkt am Leben, begeistert aber niemanden. Leistungsfaktoren schaffen Zufriedenheit, aber keine echte Bindung. Erst Begeisterungsfaktoren heben ein Produkt aus der Masse heraus. Die Kunst liegt darin, in jeder Iteration die richtige Mischung zu finden und regelmäßig zu prüfen, ob die eigenen Annahmen noch zur Realität der Nutzenden passen.

Vorrang mit Weitblick: MoSCow und Kano kombiniert

Wie man sieht, haben beide Methoden Vor- und Nachteile. Deshalb kann es sinnvoll sein, sie miteinander zu kombinieren. [6]

Mit MoSCoW lässt sich zunächst eine Priorisierung nach fachlichen Kriterien durchführen. Ergänzt man diese Sichtweise um das Kano-Modell, kommt zusätzlich die Wirkung auf den Benutzer bzw. Kunden hinzu. So stellt man sicher, dass notwendige Anforderungen umgesetzt werden und gleichzeitig die Erkenntnisse des Kano-Modells berücksichtigt werden.

Das kann zum Beispiel bedeuten: In der Kategorie „Must have“ befinden sich zwar alle Anforderungen, ohne die ein Projekt als gescheitert gelten würde. Innerhalb dieser Gruppe kann man jedoch zusätzlich unterscheiden, ob es sich um Basis-, Leistungs- oder Begeisterungsfaktoren handelt.

Dadurch wird eine deutlich bessere Scope-Planung für einen Release möglich.

Man kann diese Kategorisierung aber auch auf alle Anforderungen anwenden, um zu erkennen, wie sich das gesamte Backlog verteilt.

Daraus können interessante Fragen entstehen:

• Sind die Must-haves ausgewogen verteilt oder bestehen sie fast nur aus Basisfaktoren?
• Sind ausreichend Leistungs- und Begeisterungsfaktoren enthalten?
• Befinden sich in den Won’t-haves vielleicht sogar Basisfaktoren, die nochmals geprüft werden sollten?

Ein typisches Warnsignal wäre folgende Verteilung: In „Must have“ und „Should have“ liegen fast nur Basisfaktoren, während Leistungs- und Begeisterungsfaktoren überwiegend in „Could have“ und „Won’t have“ landen.

Abbildung 3: Kombination von MoSCoW und Kano mit ungünstiger Verteilung der Faktoren in den Kategorien

Würde man dann streng nach Priorität umsetzen, also zuerst „Must have“, danach „Should have“ have und erst später den Rest, hätte man zwar methodisch korrekt gearbeitet, am Ende aber dennoch ein wenig attraktives Produkt geliefert.

Um genau diesen Effekt zu vermeiden, lohnt es sich, Priorisierungsmethoden regelmäßig zu hinterfragen, zu ergänzen oder bewusst zu kombinieren. Oft lassen sich schon mit wenig Zusatzaufwand wertvolle Erkenntnisse gewinnen.

KI bei der Anforderungspriorisierung: Navi statt Autopilot

Künstliche Intelligenz ist inzwischen auch im Requirements Engineering angekommen. Damit stellt sich zwangsläufig die Frage, ob und wie sie bei der Priorisierung von Anforderungen sinnvoll eingesetzt werden kann.

Wie bei vielen Werkzeugen lautet die Antwort: Es kommt darauf an. KI kann unterstützen, beschleunigen und neue Perspektiven liefern. Sie ersetzt aber nicht die Verantwortung und Entscheidung des Teams.

Es gibt mehrere Bereiche, in denen KI einen echten Mehrwert schaffen kann:

• Bei großen Backlogs mit hunderten User Storys kann sie helfen, erste Cluster, Themenfelder oder Prioritätskategorien zu bilden. Das geht oft schneller und konsistenter als lange manuelle Workshops.
• Sie kann historische Daten auswerten und sichtbar machen, welche Features in der Vergangenheit priorisiert wurden oder den größten Mehrwert gebracht haben. Das unterstützt datenbasierte Methoden wie RICE oder WSJF.
• Außerdem kann KI menschliche Verzerrungen abschwächen, etwa HiPPO-Effekte oder die Dominanz besonders lauter Stakeholder. Zusätzlich kann sie Anforderungen nach MoSCoW, Kano-Kategorien oder anderen Frameworks vorsortieren und damit eine gute Grundlage für Diskussionen schaffen.

Genauso wichtig ist jedoch der Blick auf die Grenzen dieser Technologie:

• Priorisierung ist kein rein technisches Problem. Sie ist oft politisch, organisatorisch und kommunikativ. KI kennt interne Spannungen, strategische Ziele oder informelle Abhängigkeiten meist nicht.
• Auch strategische Entscheidungen lassen sich nur bedingt automatisieren. Warum wird Feature A vor Feature B umgesetzt? Das hängt oft von Marktstrategie, Regulierung, Wettbewerb oder Unternehmenszielen ab.
• Hinzu kommt das Thema Vertrauen: Wenn ein Team nicht nachvollziehen kann, warum KI Feature X auf Priorität 1 setzt, fehlt die Akzeptanz. Außerdem ist KI nur so gut wie die Daten, mit denen sie arbeitet. Unklare, widersprüchliche oder schlecht formulierte Anforderungen führen auch zu schwachen Ergebnissen. Und zuletzt bleibt die Verantwortung immer beim Menschen.

Darum sollte KI als Werkzeug verstanden werden, nicht als Entscheidungsträger. Der sinnvolle Einsatz sieht so aus: Künstliche Intelligenz schlägt vor, Requirements Engineering moderiert, Stakeholder entscheiden. Wie im Straßenverkehr sollte man sich auch hier nicht blind auf das Navigationsgerät verlassen. Das Navi macht Vorschläge, aber gefahren wird immer noch vom Menschen. Von echtem Autopilot sind wir auch bei der Priorisierung noch weit entfernt.

Vorrang in der Praxis

Damit Priorisierung wirklich sinnvoll verläuft und das Ergebnis für alle Beteiligten einen Mehrwert bietet, lohnt es sich, einige bewährte Grundregeln zu beachten.

• Stakeholder früh einbinden: Werden Stakeholder zu spät eingebunden, führt das oft zu Überraschungen, Widerständen oder aufwendigen Nachverhandlungen.
• Anforderungen sauber formulieren: Sind Anforderungen zu vage oder unvollständig, fehlt die Grundlage für eine sinnvolle Bewertung. Darunter leidet zwangsläufig auch das Priorisierungsergebnis.
• Den Zeithorizont festlegen: Priorisierung gilt immer für einen bestimmten Zeitraum. Eine Anforderung kann für das Gesamtprojekt sehr wichtig sein, aber nicht automatisch für den nächsten Sprint oder Release. Deshalb sollte vorab klar sein, für welchen Zeitraum priorisiert wird.
• Gleiches mit Gleichem vergleichen: Priorisierung kann auf unterschiedlichen Granularitätsebenen erfolgen, etwa für Epics, Features oder Storys. Man sollte jedoch vermeiden, diese Ebenen in einem Durchgang zu mischen. Für die Grobplanung eignen sich eher Epics, für Releases Features und für kurzfristige Umsetzung Storys.
• Priorisierung regelmäßig überprüfen: Einmal priorisieren reicht nicht. Rahmenbedingungen ändern sich, neue Erkenntnisse kommen hinzu und auch die Bedeutung einzelner Anforderungen kann sich verschieben.

Priorisierung ist keine Geheimwissenschaft. Oft reichen schon einfache Regeln, klare Kommunikation und etwas Disziplin. Wenn Sie die diese Punkte beachten, dann klappt es vermutlich nicht nur im Requirements Engineering, sondern auch im Straßenverkehr.

Hinweise:

Wenn Sie sich für weitere Informationen und Perspektiven zu Business Analyse, Modellierung oder Cloud Computing interessieren, dann lohnt sich mit Sicherheit ein Blick auf den Blog von Gottfried Szing: https://kjoo.be.

In Österreich spricht man im Kontext der Straßenverkehrsordnung von Vorrang, in Deutschland heißt es Vorfahrt und in der Schweiz und Liechtenstein Vortritt.

[1] Magisches Projektdreieck: Wie lässt sich ein Gleichgewicht herstellen?
[2] Der BABOK Guide ist ein Leitfaden für Business Analysten und beschreibt Wissensgebiete, Aufgaben, Techniken und Basiskompetenzen.
[3] Das International Institute of Business Analysis – IIBA – ist eine Organisation, die Methoden und Techniken der Business Analyse fördert.
[4] MoSCoW-Methode: Wo liegen Vor- und Nachteile?
[5] Kano-Modell: Wie funktioniert die bipolare Befragung?
[6] Es gibt noch weitere qualitative und quantitative Methoden, die auch für einen kombierten Einsatz in Frage kommen:

• Stack Ranking: einfach, aber effektiv: alle Anforderungen in eine einzige geordnete Liste bringen und der Zwang zur Entscheidung statt zu „alles ist wichtig“. Das entspricht praktisch der Sortierung von Backlog in bekannten Ticketing Tools.
• Paarweiser Vergleich (Pairwise Comparison): Jede Anforderung wird mit jeder anderen verglichen („Was ist wichtiger – A oder B?“). Ergibt eine saubere Reihenfolge, ist aber aufwändig bei vielen Items.
• Weighted Shortest Job First (WSJF): Kommt aus SAFe (Scaled Agile). Hier berechnet man „Cost of Delay / Job Duration“ und die Anforderungen mit dem höchsten Verhältniswert sind zuerst umzusetzen. Das ist besonders nützlich, wenn Verzögerungen messbare Kosten haben.

Wollen Sie als Multiplikatorin oder Meinungsführer über die Priorisierung von Anforderungen und die Kombination von Methoden diskutieren? Dann teilen Sie diesen Beitrag in Ihrem Netzwerk.

Gottfried Szing hat drei weitere Beiträge im t2informatik Blog veröffentlicht: