Recueil des besoins : user stories et priorisation MoSCoW

Informatique de gestion · Bachelor 1

Techniques de recueil, exigences fonctionnelles et non fonctionnelles, user stories, MoSCoW.

Introduction

La majorité des échecs de projets informatiques proviennent d'exigences mal comprises plutôt que d'erreurs techniques. Le recueil des besoins vise à établir, avec les parties prenantes, ce que le système doit faire et dans quelles conditions de qualité.

Les techniques courantes sont l'interview, l'atelier, l'observation du travail réel, l'analyse de documents et le prototypage. On distingue les exigences fonctionnelles (ce que fait le système) des exigences non fonctionnelles (performance, sécurité, disponibilité, ergonomie, conformité).

En méthode agile, une exigence se formule souvent en user story: En tant que [rôle], je veux [action] afin de [bénéfice], accompagnée de critères d'acceptation vérifiables. Les ressources étant limitées, la méthode MoSCoW aide à arbitrer: Must, Should, Could, Won't.

Objectifs d'apprentissage

Choisir une technique de recueil adaptée au contexte
Distinguer exigences fonctionnelles et non fonctionnelles
Rédiger une user story avec critères d'acceptation
Appliquer la priorisation MoSCoW
Repérer une exigence ambiguë ou non testable

Concepts clés

Techniques de recueil: Interview, atelier, observation, questionnaire, analyse documentaire, prototype: à combiner pour croiser les points de vue.
Exigence non fonctionnelle: Contrainte de qualité: temps de réponse, disponibilité, sécurité, protection des données, ergonomie.
User story: Formulation courte centrée sur la valeur pour l'utilisateur, complétée de critères d'acceptation (Given/When/Then possible).
MoSCoW: Must have, Should have, Could have, Won't have (this time): classement par priorité pour un périmètre donné.

Conclusion

Un bon recueil des besoins combine écoute, observation et formalisation testable. User stories et MoSCoW offrent un cadre simple pour arbitrer.

La qualité des exigences se mesure à leur vérifiabilité: ce qui ne peut pas être testé ne peut pas être validé.

Cartes

Pourquoi observer le travail réel en plus des interviews ?: Parce que les personnes décrivent souvent le processus officiel, pas leurs pratiques réelles.
Qu'est-ce qu'une partie prenante ?: Toute personne ou groupe affecté par le système ou influençant le projet: utilisateurs, direction, informatique, clients.
Exemple d'exigence fonctionnelle ?: Le système permet de générer une facture au format PDF à partir d'une commande.
Exemple d'exigence non fonctionnelle ?: La page de recherche s'affiche en moins de deux secondes pour 200 utilisateurs simultanés.
Qu'est-ce qu'une exigence testable ?: Une exigence formulée avec un critère mesurable permettant de vérifier qu'elle est satisfaite.
Format d'une user story ?: En tant que [rôle], je veux [action] afin de [bénéfice].
À quoi servent les critères d'acceptation ?: À définir de façon vérifiable quand la story est considérée comme terminée.
Que signifie le W de MoSCoW ?: Won't have this time: ce qui est explicitement exclu du périmètre actuel, pas forcément abandonné.
Comment reconnaître une exigence ambiguë ?: Elle emploie des termes vagues (rapide, convivial, flexible) sans critère mesurable.
Risque du dérapage de périmètre (scope creep) ?: Des ajouts non maîtrisés augmentent coûts et délais; un backlog priorisé et une gestion des changements le limitent.

Glossaire

Partie prenante: Personne ou groupe concerné par le système ou le projet.
Exigence: Capacité ou qualité que le système doit offrir.
User story: Description brève d'un besoin du point de vue d'un utilisateur.
Critère d'acceptation: Condition vérifiable de validation d'une exigence ou story.
MoSCoW: Technique de priorisation en quatre catégories.
Backlog: Liste ordonnée des exigences ou stories à réaliser.