imported>Andreas Schikora: Die letzte Textänderung von Martin Spichiger wurde verworfen und die Version 256070856 von Hutch wiederhergestellt. Korrektur ist nicht richtig. Siehe Artikelquelle und Artikel in anderen Sprachen.

2025-07-23T13:52:55Z

Die letzte Textänderung von Martin Spichiger wurde verworfen und die Version 256070856 von Hutch wiederhergestellt. Korrektur ist nicht richtig. Siehe Artikelquelle und Artikel in anderen Sprachen.

Neue Seite

Die '''MoSCoW'''-Priorisierung ist eine Methode, die im Bereich des [[Projektmanagement]]s verwendet wird und es dem Projektmanager ermöglicht, die Umsetzung der Anforderungen anhand ihrer Wichtigkeit und ihrer Auswirkung zu priorisieren. Seinen Ursprung hat die MoSCoW-Priorisierung in der [[Agile Softwareentwicklung#Agile Methoden|agilen Methode]] [[DSDM]] und kommt heute als Priorisierungstechnik für Projektabnahme- und Qualitätskriterien u. a. in [[PRINCE2]] zum Einsatz.

''MoSCoW'' ist ein [[Akronym]] und steht für:

* M – Must have (unbedingt erforderlich)
* S – Should have (sollte umgesetzt werden, wenn alle ''Must''-Anforderungen trotzdem erfüllt werden können)
* C – Could have (kann umgesetzt werden, wenn die Erfüllung von höherwertigen Anforderungen nicht beeinträchtigt wird)
* W – Won’t have (wird diesmal nicht umgesetzt, ist aber für die Zukunft vorgemerkt).

Die kleingeschriebenen Buchstaben im Akronym sind nur zum Zweck der besseren Lesbarkeit vorhanden und haben keine weitere Funktion.

== Definition ==
=== Must ===
''Must'' bezeichnet Anforderungen, die für das Projekt essentiell wichtig und nicht verhandelbar sind. Eine ganz oder teilweise ausbleibende Umsetzung würde zum Scheitern des Projekts führen. Anforderungen dieser Art werden in der Projekt-[[Timeboxing|Timebox]] zusammengefasst. MUST ist ebenfalls ein Akronym – ''Minimal Usable SubseT'' – und steht für Minimalanforderung.

=== Should ===
Obwohl ''Should''-Anforderungen nicht erfolgskritisch für das Projekt sind, haben sie eine hohe Relevanz und sollten, soweit keine Beeinträchtigung von ''Must''-Anforderungen auftritt, mit in der Projektumsetzung berücksichtigt werden. ''Should''-Anforderungen können oft über verschiedene Wege umgesetzt werden.

=== Could ===
''Could''-Anforderungen haben eine geringe Relevanz und werden oft als ''Nice to have'' bezeichnet. Sie werden erst berücksichtigt, wenn neben der prioritären Bearbeitung von ''Must-'' und ''Should''-Anforderungen noch Kapazitäten vorhanden sind. Doch sollten ''Could''-Anforderungen nicht pauschal ignoriert werden. Oft können ein paar einfach umzusetzende ''Could''-Anforderungen einen nicht unerheblichen Mehrwert generieren, bei minimalen, zusätzlichen Entwicklungskosten.

=== Won’t ===
''Won’t''-Anforderungen sind für das aktuelle Projekt bzw. den aktuellen Planungsabschnitt von geringster Priorität. Allerdings, und das ist einer der größten Vorteile von ''MoSCoW'', zeigt die Klassifizierung als ''Won’t'', dass die Anforderung fachlich und/oder technisch wichtig, aber nicht zeitlich kritisch ist. So klassifizierte Anforderungen geraten nicht in Vergessenheit und werden für die Planung des nächsten Release erneut priorisiert.

Eine gute ''Won’t''-Liste bewirkt drei entscheidende Effekte:

# Kein [[Stakeholder]] muss für die Aufnahme von Anforderungen „kämpfen“
# Bei Überlegungen zu zukünftigen Erforderlichkeiten werden auch aktuelle neu überdacht
# Wenn die Designer die langfristige Planung sehen, können sie bei der aktuellen Umsetzung schon Vorkehrungen zur späteren Implementierung treffen

Die Vorteile der MoSCoW-Priorisierungsmethode liegen darin, dass im Gegensatz zu einer einfachen numeralen 1-bis-3-Priorisierung klar und nachvollziehbar definiert werden kann, welche Anforderungen zeitkritisch sind und den größten [[Business Impact Analyse|Business Impact]] haben. Es werden funktionale wie auch nichtfunktionale Anforderungen berücksichtigt.

== Kritikpunkte ==
{{Belege}}
Viele bezeichnen eine ''Nice-to-have''-Anforderung ''(Could)'' auch als Erweiterung oder Feinheit und plädieren dafür, dass diese definitionsgemäß somit keine Anforderung mehr ist und auch nicht mehr als eine solche eingestuft werden sollte.

Dem entgegen stehen folgende Punkte:

# Da die Prioritäten von Anforderungen oftmals recht dynamisch variieren, ist es sinnvoll, auch die ''Could''-Anforderungen weiterhin als richtige Anforderungen zu behandeln. Auch ''Could''-Anforderungen erbringen einen wichtigen Beitrag. Nur ist dieser nicht erfolgskritisch für das Projekt bzw. Produkt.
# Iterative Softwareentwicklung sorgt ebenfalls oft für eine Änderung der Prioritäten. Dadurch kommt es vor, dass ''Could''-Anforderungen zu ''Should''-Anforderungen werden.

== Quellen ==
* [https://www.coleyconsulting.co.uk/moscow.htm Coley Consulting - MoSCoW Priorisation] (englisch)

== Literatur ==
* Iris Pinkster, Bob van de Burgt, Dennis Janssen, Erik van Veenendaal: ''Successful Test Management'' 2. Aufl. Springer Verlag, 2004, ISBN 978-3-540-44735-1 / ISBN 3-540-22822-5

[[Kategorie:Anforderungsmanagement]]

MoSCoW-Priorisierung - Versionsgeschichte

imported>Andreas Schikora: Die letzte Textänderung von Martin Spichiger wurde verworfen und die Version 256070856 von Hutch wiederhergestellt. Korrektur ist nicht richtig. Siehe Artikelquelle und Artikel in anderen Sprachen.