Wie priorisiere ich Anforderungen an eine Softwarelösung?

Nahezu jedes Softwareprojekt beginnt mit der Erhebung der Anforderungen an die Softwarelösung und deren Priorisierung. Dabei wird nicht nur der Leistungsumfang für die Softwarelösung festgelegt, sondern auch die Aufwände für die Realisierung geschätzt. Gerade für agile Projekte ist eine Priorisierung wichtig, um die Sprints und Meilensteine zu planen. Auch der Auftraggeber profitiert von einer Priorisierung, da er sich rechtlich absichern kann, zu welchem Zeitpunkt welche Funktionen geliefert werden müssen.

In der Praxis kommt es allerdings sehr oft vor, dass die Stakeholder ihre eigenen Anforderungen an eine Softwarelösung als am wichtigsten betrachten. Die Priorisierung wird dadurch sehr subjektiv und der Umfang der Pflichtanforderungen viel zu groß, um in die Timeline zu passen. Für die Projektplanung ergibt sich die Herausforderung den Scope für das Projekt vernünftig zu wählen, um die Zeit und das Budget einhalten zu können. Um das gewünschte Projektergebnis zielgerichtet zu erreichen, ist eine feinere Abstufung der Anforderungen nötig. Doch wie gelingt eine gute Priorisierung?

Mit der richtigen Methode zu priorisierten Anforderungen an Softwarelösungen

Bei der Anforderungserhebung werden oft Aussagen wie „Diese Funktion brauchen wir, also ist es natürlich Prio 1“ getroffen. Als Consultants müssen wir an dieser Stelle hinterfragen, was „brauchen“ genau bedeutet. Es hat sich bewährt, bei der Priorisierung den Fokus auf den jeweiligen Business Impact, also die Auswirkungen auf das Geschäft, zu legen. Eine einfache Methode hierfür ist die MoSCoW-Methode. Sie gibt eine vierstufige Priorisierungsskala zur Bewertung von Anforderungen vor:

Die Umsetzung der Must-Anforderungen ist Mindestvoraussetzung für die Abnahme des Projekts. Diese können daher als rechtlich verbindliche Anforderungen an eine Softwarelösung angesehen werden. Ohne deren Umsetzung wird das Projekt nicht erfolgreich abgeschlossen werden können. Für die Zuordnung der Anforderungen müssen vorab Entscheidungskriterien festgelegt werden. Bewährt haben sich:

• Ist die Software ohne diese Funktion lauffähig?
• Können die Geschäftsprozesse ohne die Anforderung umgesetzt werden?
• Können die Qualitätsrichtlinien ohne diese Anforderung eingehalten werden?
• Ist auch ohne diese Funktion die Zufriedenheit der Benutzer gewährleistet?

Werden hier die meisten Fragen mit „Nein“ beantwortet, handelt es sich mit hoher Wahrscheinlichkeit um eine Must-Anforderung. Besonders wichtig ist es, auch über die Folgen und den möglichen Schaden bei Nichteinhaltung der Anforderungen nachzudenken. So können auch bewusst Funktionen zurückgestellt und Folgen oder Schäden in Kauf genommen werden, solange diese kalkulierbar und vertretbar sind. Was nicht bedeuten soll, dass dies in einem späteren Projektzyklus nicht umgesetzt wird.

Bei einer Systemablösung kann auch der Vergleich mit dem bestehenden System erfolgen, ob es das Feature im alten System auch schon gab. Wenn nicht, stellt sich die Frage, wie groß der Schmerz bei den Benutzern durch das Fehlen dieser Funktion in den letzten Jahren war. Eventuell handelt es sich dann doch nur um eine Should-Anforderung.

Die Should-Anforderungen bilden zusammen mit den Muss-Anforderungen den gesamten Leistungsumfang des Projekts und werden in der Projektplanung vollständig berücksichtigt. Das System ist ohne die Umsetzung dieser Anforderung weniger effizient/effektiv. Mögliche Fragestellungen für die Should-Anforderungen könnten sein:

• Ersetzt die Anforderung einen manuellen Workaround?
• Ermöglicht die Funktion effizientere Zugangswege zu bestehenden Informationen?
• Ermöglich das Feature neue Business-Aspekte?

Können Sie die meisten Fragen mit „Ja“ beantworten, handelt es sich mit hoher Wahrscheinlichkeit um eine Should-Anforderung.

Im Gegensatz zu den Must-Anforderungen sind diese allerdings durch Change Requests oder Verhandlungen veränderbar. Kommt es während des Projekts zu Problemen, so dass eine Realisierung innerhalb des gesetzten Budget- oder Zeitrahmens nicht möglich ist, können die Should-Anforderungen zurückgestellt werden. Die Must-Anforderungen werden dann priorisiert fertiggestellt. Eine Abnahme kann auch erfolgen,l wenn nicht alle Should-Anforderungen erfüllt sind. Diese können in Absprache mit dem Auftraggeber zu einem späteren Zeitpunkt geliefert werden oder sogar entfallen.

Diese Anforderungen werden auch als „nice-to-have“ bezeichnet und machen ein System attraktiver. Sie werden in der Regel erst umgesetzt, wenn alle Must- und Should-Anforderungen erfüllt sind und noch ausreichend Ressourcen und Zeit zur Verfügung stehen. Werden diese am Ende des Projekts knapp, sollten nur jene Funktionen umgesetzt werden, die den größten Mehrwert im Hinblick auf den Geschäftszweck des Systems bringen und im verbleibenden Zeitrahmen möglich sind. Could-Anforderungen sind üblicherweise nicht zeitkritisch, können aber durchaus wichtig sein.

Die Won’t-Anforderungen werden im Hinblick auf Termin und Budget nicht in den Leistungsumfang des aktuellen Projekts aufgenommen. Stattdessen werden sie in einem Ideenpool oder einer Anforderungsliste für das nächste Projekt gespeichert und dort umgesetzt. Die Abgrenzung hilft dabei, den Projektmitgliedern den Leistungsumfang zu verdeutlichen und weiterhin für das Projekt zu begeistern. Denn eingebrachte Anforderungen aus der initial erstellten Anforderungsliste werden nicht ersatzlos gestrichen. Zudem wird verhindert, dass Funktionen in Vergessenheit geraten und niemals umgesetzt werden.

Die Einteilung in die genannten Anforderungs-Gruppen (MoSCoW-Methode) fällt in der Praxis oft nicht leicht. Eine Orientierungshilfe ist dabei die 60 Prozent-Regel, welche erfahrungsgemäß eine vernünftige Verteilung bietet. Die Must-Anforderungen sollten dabei maximal 60 Prozent des Gesamtaufwandes umfassen. Die Should- und Could-Anforderungen bilden jeweils etwa 20 Prozent des Gesamtaufwandes ab. Die Won’t-Anforderungen gehören dabei nicht zum Umfang.

Stehen am Ende der Priorisierung mehr als die 60 Prozent an Must-Anforderungen an eine Softwarelösung fest, kann es zu Nachverhandlungen kommen, um den Projektumfang zu erweitern. Andernfalls sollte der Auftraggeber die Must-Anforderungen erneut prüfen und abwägen, ob diese wirklich alle in die Kategorie gehören. Dabei sollte ihm bewusst sein, dass die Should-Anforderungen mit hoher Wahrscheinlichkeit auch umgesetzt werden. Dieses Vorgehen erweist sich in der Praxis als gutes Instrument sowohl für Auftraggeber, als auch Auftragnehmer. Der Projektumfang wird mit den Anforderungen und dem vereinbarten Budget klar definiert und ermöglicht eine zeitliche Planung für die Umsetzung.

Bildquelle: Usability_© Olivier Le Moal – Fotolia.com_blog