 **MoSCoW** est une technique permettant de prioriser les besoins ou les exigences d'un projet. Cette technique est utilisée dans l'analyse business et le développement de logiciels afin de parvenir à une compréhension commune sur l'importance qu'ils accordent à la livraison de chaque exigence. Ceci ce fait avec toutes les parties prenantes du projet. Les lettres majuscules de l'acronyme **MoSCoW** signifient : **M**ust, **S**hould, **C**ould, **W**on't. Les _**o**_ ont été ajoutés afin que ce soit prononçable. Pour certains, la classification avec des numéros semble plus logique, plus naturel. Cependant, une fois le développement commencé, toutes les fonctionnalités prennent souvent pour priorité '1' ce qui créé de fortes confusions et ne permet donc pas de livrer le projet dans de bonnes conditions. ## M comme Must **MUST**, ce qui **DOIT** être fait. Cela décrit une exigence qui doit être satisfaite dans la solution finale afin que le produit soit un succès. Ces exigences sont non-négociables, sans elles, le projet est un échec. Elles doivent être finalisées en tenant compte de : - l'accord de tous les intervenants, - l'examination de la porté du projet ainsi que son but, - la correspondance entre l'objectif du projet et les exigences listées. ##S comme Should **SHOULD**, ce qui **DEVRAIT** être fait dans la mesure du possible. Cela décrit une exigence qui doit être incluse dans la solution finale si tout se passe bien. Ces exigences sont importantes mais moins critiques pour le succès du projet. En effet, ces exigences sont tout aussi importantes que les _**MUST**_ mais peuvent être faites plus tard dans le cycle de développement du projet. Lors des prochaines itérations par exemple. ##C comme Could **COULD**, ce qui **POURRAIT** être fait dans la mesure où cela n'a pas d'impact sur les autres tâches. Ce sont des exigences non-critiques. Elles sont souvent décrites comme des fonctionnalités qui seraient bien d'avoir : "Ca serait top d'avoir ça !". Ce n'est donc pas indispensable pour le succès du projet. Cependant elles ne sont pas à oublier, inclure ces exigences peut permettre d'augmenter le confort ainsi que la satisfaction du client pour un coup de développement souvent faible. ##W comme Won't **WON'T**, ce qui **NE SERA PAS** fait mais prévu pour plus tard. Ce sont des exigences qui n'affectent pas le succès du projet. Elles ne sont généralement pas prévues dans le planning mais peuvent être traitées dans une version ultérieure du projet. Certains, utilise le **W** pour "_Would like_", ce qui permet d'être moin définitif et laisse donc la possibilité d'ajouter ces exigences si le scope, le budget ou les délais changent.
Afin de fournir un projet réussi, il est essentiel que l'ensemble des exigences soient clairement priorisées avec le client. Ceci n'est bien sûr qu'un élément pour la réussite, il ne faut pas oublier de bien définir l'objectif globale, la qualité, les délais ainsi que le budget. - Avez-vous déjà utilisé cette méthode ? - Vous utilisez une autre méthode de prioritisation ? Quels sont ses avantages ?
