Toutes les exigences sont importantes, mais elles sont classées par ordre de priorité afin de fournir rapidement les avantages commerciaux les plus importants et les plus immédiats. Les développeurs essaieront initialement de livrer toutes les exigences Must have, Should have et Could have, mais les exigences Should et Could seront les premières à être supprimées si le délai de livraison semble menacé.
La signification en anglais simple des catégories de priorisation a de la valeur pour amener les clients à mieux comprendre l’impact de la définition d’une priorité, par rapport à des alternatives comme High, Medium et Low.
Les catégories sont généralement comprises comme :
Must have Les exigences étiquetées Must have sont critiques pour le calendrier de livraison actuel afin qu’il soit un succès. Si une seule exigence Must have n’est pas incluse, la livraison du projet doit être considérée comme un échec (note : les exigences peuvent être déclassées de Must have, par accord avec toutes les parties prenantes concernées ; par exemple, lorsque de nouvelles exigences sont jugées plus importantes). MUST peut également être considéré comme l’acronyme de Minimum Usable Subset. Should have Les exigences étiquetées comme Should have sont importantes mais pas nécessaires à la livraison dans le délai actuel de livraison. Bien que les exigences « Should have » puissent être aussi importantes que les exigences « Must have », elles ne sont souvent pas aussi critiques en termes de temps ou il peut y avoir une autre façon de satisfaire l’exigence afin qu’elle puisse être reportée à une livraison ultérieure. Pourrait avoir Les exigences étiquetées comme Pourrait avoir sont souhaitables mais pas nécessaires et pourraient améliorer l’expérience de l’utilisateur ou la satisfaction du client pour un faible coût de développement. Elles seront généralement incluses si le temps et les ressources le permettent. N’auront pas (cette fois) Les exigences étiquetées comme N’auront pas, ont été convenues par les parties prenantes comme étant les éléments les moins critiques, les moins rentables, ou non appropriés à ce moment-là. Par conséquent, les exigences « Won’t have » ne sont pas planifiées dans le calendrier de la prochaine période de livraison. Les exigences Won’t have sont soit abandonnées, soit reconsidérées pour être incluses dans une boîte à calendrier ultérieure. (Remarque : on utilise parfois le terme Would like to have ; toutefois, cet usage est incorrect, car cette dernière priorité indique clairement que quelque chose est en dehors du champ de la livraison). (Le BCS dans l’édition 3 & 4 du Business Analysis Book décrit ‘W’ comme ‘Want to have but not this time around’)
VariantesEdit
Parfois W est utilisé pour signifier Wish (ou Would), c’est-à-dire encore possible mais peu probable d’être inclus (et moins probable que Could). On le distingue alors de X pour Exclu pour les éléments qui sont explicitement exclus.
.