Tutti i requisiti sono importanti, ma sono prioritari per fornire presto i maggiori e più immediati benefici di business. Gli sviluppatori inizialmente cercheranno di consegnare tutti i requisiti “Must have”, “Should have” e “Could have”, ma i requisiti “Should” e “Could” saranno i primi ad essere rimossi se i tempi di consegna sembrano minacciati.
Il significato in parole povere delle categorie di priorità ha valore nel far capire meglio ai clienti l’impatto dell’impostazione di una priorità, rispetto ad alternative come Alta, Media e Bassa.
Le categorie sono tipicamente intese come:
Deve avere I requisiti etichettati come Deve avere sono critici per l’attuale timebox di consegna affinché sia un successo. Se anche un solo requisito Must have non è incluso, la consegna del progetto dovrebbe essere considerata un fallimento (nota: i requisiti possono essere declassati da Must have, in accordo con tutti gli stakeholder interessati; per esempio, quando nuovi requisiti sono considerati più importanti). MUST può anche essere considerato un acronimo per il Minimum Usable Subset. Dovrebbe avere I requisiti etichettati come Dovrebbe avere sono importanti ma non necessari per la consegna nell’attuale timebox di consegna. Mentre i requisiti Should have possono essere importanti quanto i Must have, spesso non sono così critici dal punto di vista temporale o ci può essere un altro modo per soddisfare il requisito in modo che possa essere trattenuto fino ad un futuro timebox di consegna. Could have I requisiti etichettati come Could have sono desiderabili ma non necessari e potrebbero migliorare l’esperienza dell’utente o la soddisfazione del cliente per un piccolo costo di sviluppo. Questi saranno tipicamente inclusi se il tempo e le risorse lo permettono. Won’t have (this time) I requisiti etichettati come Won’t have, sono stati concordati dagli stakeholder come gli elementi meno critici, con il minor ritorno economico, o non appropriati in quel momento. Di conseguenza, i requisiti Won’t have non sono pianificati nella pianificazione per il prossimo timebox di consegna. I requisiti Won’t have sono abbandonati o riconsiderati per l’inclusione in un timebox successivo. (Nota: occasionalmente viene usato il termine Would like to have; tuttavia, quell’uso non è corretto, poiché quest’ultima priorità sta chiaramente affermando che qualcosa è al di fuori della portata della consegna). (Il BCS nell’edizione 3 & 4 del Business Analysis Book descrive ‘W’ come ‘Want to have but not this time around’)
VariantiModifica
A volte W è usato per significare Wish (o Would), cioè ancora possibile ma improbabile da includere (e meno probabile di Could). Questo è poi distinto da X per Excluded per gli elementi che sono esplicitamente non inclusi.