Die MoSCoW-Priorisierung Einzelne Anforderungen einfach priorisieren

Die MoSCoW-→ Prio­ri­sie­rung (engl. MoSCoW prio­ri­tiza­ti­on; auch MuS­CoW-Prio­sie­rung) ist eine Prio­ri­sie­rungs­tech­nik für ein­zel­ne Anfor­de­run­gen (im → Requi­re­ments Engi­nee­ring), die eine Ver­pflich­tung zur Umset­zung vor­gibt. Das Akro­nym MoSCoW steht für fol­gen­de vier unter­schied­li­che Stufen:

  • Must have / Muss: Die­se Anfor­de­rung muss unbe­dingt umge­setzt werden
  • Should have / Soll­te: Die­se Anfor­de­rung soll­te umge­setzt wer­den, könn­te aber ent­fal­len, wenn kei­ne Res­sour­cen vor­han­den sind
  • Could have / Könn­te: Die­se Anfor­de­rung könn­te umge­setzt wer­den, wenn noch Res­sour­cen dafür vor­han­den sind
  • Won’t have / Nicht not­wen­dig: Die­se Anfor­de­rung muss (der­zeit) nicht umge­setzt wer­den und ist damit “Out of Scope”

Abbil­dung 1 stellt die vier Eigen­schaf­ten zusam­men­fas­send dar.

Die vier Stufen der MoSCoW-Priorisierung (als Tabelle), (C) Peterjohann Consulting, 2021-2024

Abbil­dung 1: Die vier Stu­fen der MoSCoW-Priorisierung

Im prak­ti­schen Ein­satz wer­den die Anfor­de­run­gen (ein­zeln) nach die­sen Kri­te­ri­en über­prüft. In der Regel geschieht dies durch Abstim­mun­gen oder Abstim­mungs­run­den mit den Stake­hol­dern. Die Pro­ble­ma­tik bei der Umset­zung besteht dar­in, die Inter­es­sen der → Stake­hol­der zu berück­sich­ti­gen und gleich­zei­tig eine Ver­tei­lung für die Anfor­de­run­gen zu erhal­ten, sodass nicht alle Anfor­de­run­gen mit “Must” cha­rak­te­ri­siert sind.

Anmer­kun­gen:

  • In der Pra­xis wer­den bevor­zugt die eng­li­schen Begrif­fe verwendet
  • Auch wenn sich die MoSCoW-Prio­ri­sie­rung auf alle Arten von Anfor­de­run­gen bezieht, wird sie bevor­zugt bei → User Sto­ries im agi­len Kon­text eingesetzt
  • Die vier MoSCoW-Kri­te­ri­en fin­den sich im → Requi­re­ments Engi­nee­ring bei den → Satz­scha­blo­nen wieder
  • Zur Ermitt­lung / Ein­schät­zung kann auch das → Kano-Modell her­an­ge­zo­gen werden
  • Gene­rell könn­te auch ein wei­te­res Kri­te­ri­um für “abge­lehn­te” Anfor­de­run­gen hin­zu­ge­nom­men wer­den, wel­ches dazu dient, end­gül­tig ver­wor­fe­ne Anfor­de­run­gen zu notieren

Ähn­li­che Priorisierungsschemata:

  • Bei → Satz­scha­blo­nen wer­den ähn­li­che Prio­ri­sie­rungs­sche­ma­ta ein­ge­setzt, ist der Regel “Muss, Soll­te, Wird”
  • In tech­ni­schen Kon­text wer­den die RFC-2119-Vor­ga­ben ein­ge­setzt /#RFC2119/. Die­se ver­wen­den für Requi­re­ments vier Schlüs­sel­wör­ter, die zur Ver­deut­li­chung in Groß­buch­sta­ben geschrie­ben wer­den. Dies sind: 
    • MUST (oder auch REQUIRED oder SHALL) bezeich­net Requi­re­ments, die unbe­dingt umge­setzt wer­den müssen
    • MUST NOT (oder auch SHALL NOT) bezeich­net Requi­re­ments, die kei­nes­falls umge­setzt wer­den dürfen
    • SHOULD (oder auch RECOMMENDED) bezeich­net Requi­re­ments, deren Umset­zung zwar emp­foh­len wird, aber deren Aus­wir­kun­gen noch nicht abschlie­ßend geklärt sind
    • SHOULD NOT (oder auch NOT RECOMMENDED) bezeich­net Requi­re­ments, deren Umset­zung zwar nicht emp­foh­len wird, aber deren Aus­wir­kun­gen noch nicht abschlie­ßend geklärt sind
    • (MAY und OPTIONAL wer­den in der RFC 2119 zwar erwähnt, aber nicht beschrieben)

Web­links

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (all­ge­mein)
/*/ Ver­weis auf eine Web­site, die als Ergän­zung zu einem Buch dient
/#/ Ver­weis auf ein ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website 

Letz­te Aktua­li­sie­rung: 24.02.2022 © Peter­jo­hann Con­sul­ting, 2005–2024

Ähnliche Beiträge