Metoda MoSCoW

Metoda MoSCoW jest techniką priorytetyzacji wykorzystywaną w analizie biznesowej i przy tworzeniu oprogramowania w celu osiągnięcia wspólnego zrozumienia pomiędzy interesariuszami co do znaczenia, jakie ma dla nich dostarczenie każdego z wymagań. Inne nazwy metody to priorytetyzacja MoSCoW lub analiza MoSCoW.

Charakterystyka

Według A Guide to the Business Analysis Body of Knowledge, wersja 2.0[1], sekcja 6.1.5.2, wyróżnia się następujące kategorie MoSCoW:

  • M – MUST (musi być): Opisuje wymaganie, które musi być spełnione w końcowym, finalnym rozwiązaniu.
  • S – SHOULD (powinien być): Reprezentuje pozycję o wysokim priorytecie, która powinna być zawarta w rozwiązaniu, jeżeli jest to możliwe.
  • C – COULD (może być): Opisuje wymaganie, które jest postrzegane jako pożądane, ale niekonieczne. Zostanie ono zawarte, jeżeli pozwolą na to czas i zasoby.
  • W – WON’T (nie będzie): Reprezentuje wymaganie, które – za zgodą interesariuszy – nie będzie implementowane w danym wydaniu, ale może być rozpatrzone w przyszłości.

Litery 'o' w słowie MoSCoW zostały dodane tylko po to, aby słowo było możliwe do wymówienia i często są one zapisywane małą literą, pełniąc wyłącznie funkcję nic nieznaczących łączników. Dopuszczalny jest zapis MOSCOW z dużymi literami 'o'.

Priorytetyzacja wymagań MoSCoW

Wszystkie wymagania są ważne, ale są im nadawane priorytety tak, aby jak najwcześniej przynosiły jak największe i najszybsze korzyści biznesowe. Developerzy początkowo będą starali się dostarczać wszystkie wymagania M, S i C, ale w przypadku gdy będzie zagrożony czas realizacji, to wymagania S i C zostaną odłożone w pierwszej kolejności.

Must have
Wymagania oznaczone jako MUST są krytyczne dla powodzenia projektu i muszą być zawarte w aktualnej fazie cyklu życia projektu, ażeby projekt mógł się powieść. Jeżeli chociażby jedno wymaganie MUST nie zostanie zawarte, projekt powinien być uznany za porażkę (notka: priorytet wymagań MUST może być obniżony za zgodą wszystkich istotnych interesariuszy, np. gdy nowe wymagania zostaną uznane za bardziej istotne). MUST może być również postrzegane jako tzw. najmniejszy użyteczny podzbiór (ang. Minimum Usable SubseT).
Should have
Wymagania SHOULD są istotne dla powodzenia projektu, ale nie są konieczne w aktualnej fazie cyklu życia projektu. Wymagania SHOULD są tak samo istotne jak MUST, chociaż często nie są one krytyczne w danym momencie. Do wymagań SHOULD mogą być tworzone obejścia, pozwalające na ich spełnienie w inny sposób tak, aby był możliwy powrót do nich w przyszłych fazach cyklu życia projektu.
Could have
Wymagania oznaczone jako COULD są mniej krytyczne i często są postrzegane jako takie, które dobrze żeby były. Kilka, łatwo spełnionych wymagań COULD w projekcie może zwiększyć zadowolenie klienta przy równoczesnym niskim koszcie ich dostarczenia.
Won’t have (Would like)
Wymagania WON’T są najmniej krytycznymi, najmniej opłacalnymi pozycjami lub nieodpowiednimi w konkretnym momencie. Z tego powodu, wymagania WON’T nie są planowane w harmonogramie cyklu życia projektu. Wymagania WON’T są albo porzucane albo ich dołączenie zostanie rozpatrzone w następnych fazach. Jednakże to nie czyni ich mniej ważnymi. Czasami są one nazywane jako Would have (mogłyby być), przez co kwestia dołączenia tych wymagań do zakresu danej dystrybucji pozostaje otwarta, jeśli zakres, budżet i czas (tzw. triada projektowa) się zmieniają.

Zobacz też

  • RFC 2119 (Requirement Levels) Dokument RFC definiuje poziomy wymagań używane w formalnej dokumentacji. Jest często wykorzystywany w kontraktach i innych dokumentach prawnych. Należy zwrócić uwagę na to, że użyte w tym dokumencie słownictwo jest podobne, ale niekoniecznie musi posiadać to samo znaczenie.

Przypisy

  1. ↑ A Guide to the Business Analysis Body of Knowledge, International Institute of Business Analysis, 2009, ISBN 978-0-9811292-1-1.

Linki zewnętrzne