Wszystkie wymagania są ważne, ale są uszeregowane według priorytetów, aby wcześnie dostarczyć największe i najbardziej natychmiastowe korzyści biznesowe. Deweloperzy będą początkowo próbowali dostarczyć wszystkie wymagania Must have, Should have i Could have, ale wymagania Should i Could będą pierwszymi, które zostaną usunięte, jeśli czas dostarczenia będzie wyglądał na zagrożony.
Zwykłe angielskie znaczenie kategorii priorytetyzacji ma wartość w uzyskiwaniu klientów, którzy lepiej rozumieją wpływ ustalenia priorytetu, w porównaniu do alternatyw takich jak Wysoki, Średni i Niski.
Kategorie są zazwyczaj rozumiane jako:
Muszą mieć Wymagania oznaczone jako Muszą mieć są krytyczne dla bieżącego przedziału czasowego dostarczenia, aby było ono sukcesem. Jeżeli choćby jedno wymaganie Must have nie jest uwzględnione, realizacja projektu powinna być uznana za porażkę (uwaga: wymagania mogą zostać zdegradowane z kategorii Must have, poprzez porozumienie ze wszystkimi odpowiednimi interesariuszami; na przykład, gdy nowe wymagania zostaną uznane za ważniejsze). MUST może być również akronimem dla Minimalnego Użytecznego Podzbioru (Minimum Usable Subset). Powinny mieć Wymagania oznaczone jako Powinny mieć są ważne, ale nie są konieczne do dostarczenia w bieżącym oknie czasowym dostawy. Podczas gdy wymagania Powinny być tak samo ważne jak Muszą być, często nie są one tak krytyczne czasowo lub może istnieć inny sposób na spełnienie wymagania tak, że może ono być odłożone do przyszłego przedziału czasowego dostawy. Mogłyby mieć Wymagania oznaczone jako Mogłyby mieć są pożądane, ale nie konieczne i mogą poprawić doświadczenie użytkownika lub zadowolenie klienta za niewielki koszt rozwoju. Zazwyczaj będą one włączone, jeśli czas i zasoby na to pozwolą. Wymagania oznaczone jako Nie będą miały (tym razem) Wymagania oznaczone jako Nie będą miały, zostały uzgodnione przez interesariuszy jako najmniej krytyczne, o najniższym zwrocie lub nieodpowiednie w tym czasie. W rezultacie, wymagania typu „nie będę miał” nie są planowane w harmonogramie na następny przedział czasowy dostawy. Wymagania typu „nie będę miał” są albo porzucane, albo ponownie rozważane do włączenia w późniejszym przedziale czasowym. (Uwaga: czasami używane jest określenie Would like to have; jednakże, takie użycie jest niepoprawne, ponieważ ten ostatni priorytet wyraźnie stwierdza, że coś jest poza zakresem dostawy). (BCS w wydaniu 3 & 4 Business Analysis Book opisuje 'W' jako 'Want to have but not this time around')
WariantyEdit
Czasami W jest używane w znaczeniu Wish (lub Would), tzn. wciąż możliwe, ale mało prawdopodobne do uwzględnienia (i mniej prawdopodobne niż Could). To jest wtedy odróżnione od X dla Excluded dla pozycji, które są wyraźnie nie zawarte.