À propos de ce cours
Cette leçon explique comment définir les fonctionnalités d'une application à partir des besoins observés. Elle présente la traçabilité besoin, user story, fonctionnalité, écran et test, la rédaction de user stories (« En tant que… je veux… afin de… »), la distinction entre exigences fonctionnelles et non fonctionnelles mesurables, les critères d'acceptation au format « Étant donné / Quand / Alors », la priorisation MoSCoW et la story map qui définit un MVP traversant tout le parcours. Trois activités portent sur CantineCampus.
| Durée | Niveau | Prérequis | À la fin de la leçon |
|---|---|---|---|
| 1 heure 15 (cours et 3 activités) | Débutant, chapitre « Architecture de l'information et parcours utilisateur » | Optimiser la navigation et le parcours utilisateur | Vous savez passer des besoins aux fonctionnalités, les écrire en user stories testables et les prioriser |
-
Objectifs
- Relier chaque fonctionnalité à un besoin observé.
- Rédiger des user stories.
- Distinguer les exigences fonctionnelles et non fonctionnelles.
- Écrire des critères d'acceptation testables.
- Prioriser les fonctionnalités et définir un MVP avec une story map.
-
Du besoin à la fonctionnalité
- Une fonctionnalité est une capacité de l'application qui permet à l'usager d'accomplir quelque chose : commander, recharger, filtrer les plats végétariens.
- Elle ne naît pas d'une idée de l'équipe, mais d'un besoin observé (entretiens, tests, données) : « Je ne veux pas attendre à midi » conduit à « commander à l'avance avec une heure de retrait ».
- La traçabilité relie chaque fonctionnalité à son besoin, à son écran et à son test : on peut répondre à « pourquoi cette fonction existe-t-elle ? » et à « comment sait-on qu'elle marche ? ».
- Une demande n'est pas un besoin : « ajoutez un chat » est une solution ; le besoin derrière est peut-être « poser une question sur un allergène ».
-
Écrire des user stories
- Une user story décrit une fonctionnalité du point de vue de l'usager, en une phrase : « En tant que [usager], je veux [action], afin de [bénéfice]. »
- Exemple : « En tant qu'étudiant pressé, je veux commander mon repas à l'avance, afin de ne pas faire la queue. »
- Le « afin de » est essentiel : il garde le besoin visible et permet de trouver d'autres solutions.
- Une bonne user story est indépendante, négociable, utile à l'usager, estimable, petite et testable (critères INVEST).
- Une story trop grande (« gérer mon compte ») se découpe en plusieurs (« consulter mon solde », « recharger », « voir mon historique »).
-
Exigences fonctionnelles et non fonctionnelles
- Les exigences fonctionnelles disent ce que l'application fait: consulter le menu, commander, annuler avant 11 h.
- Les exigences non fonctionnelles disent comment elle doit le faire : rapidité, accessibilité, sécurité, compatibilité, fonctionnement avec un réseau lent.
- Une exigence non fonctionnelle doit être mesurable: « l'application doit être rapide » ne se vérifie pas ; « une commande se passe en moins de 60 secondes par 4 usagers sur 5 » se vérifie.
- Les exigences d'accessibilité (WCAG niveau AA) et de protection des données (RGPD) sont des exigences non fonctionnelles à écrire dès le départ.
-
Les critères d'acceptation
- Les critères d'acceptation disent quand une user story est terminée. Ils servent au développeur, au testeur et au designer.
- Le format « Étant donné / Quand / Alors » (Given / When / Then) décrit un scénario : la situation de départ, l'action, le résultat attendu.
- Écrivez un scénario pour le chemin heureux et un pour chaque cas limite: heure dépassée, solde insuffisant, commande déjà préparée.
- Un critère d'acceptation décrit un résultat observable (« un message confirme l'annulation »), pas une solution technique.
-
Prioriser et définir le MVP
- On ne développe pas tout en même temps. La méthode MoSCoW classe chaque fonctionnalité : Must (indispensable), Should (importante), Could (souhaitable), Won't (pas cette fois).
- Le MVP (produit minimum viable) est la plus petite version qui permet à l'usager d'accomplir son objectif de bout en bout.
- La story map (Jeff Patton) aligne les grandes étapes du parcours de gauche à droite (découvrir, choisir, commander, payer, récupérer) et empile les stories par version de haut en bas.
- Le MVP est une tranche horizontale qui traverse tout le parcours : un menu, un panier et un paiement simples valent mieux qu'un menu parfait sans paiement.
- Le classement croise la valeur pour l'usager et l'effort de réalisation (matrice valeur × effort).
🍽 Exemple : CantineCampus
- Le directeur demandait des avis sur les plats. Aucun entretien n'en a montré le besoin : la fonction est classée Could, « plus tard ».
- Les allergènes ne sont demandés que par quelques usagers, mais leur absence peut mettre leur santé en danger : Must, dès le MVP.
⚠ Piège : une liste de 40 fonctionnalités toutes classées « Must » n'est pas une priorisation. Visez au plus 60 % de « Must » dans une version.
-
Aide-mémoire
-
Activités
Activité 1Besoin ou solution ? · ⏱ 10 min
- Classez ces demandes en « besoin » ou « solution » : « un chat avec la cuisine », « savoir si un plat contient des arachides », « une carte des restaurants », « ne pas perdre de temps à midi », « un mode sombre ».
- Pour chaque solution, retrouvez le besoin probable et proposez une autre solution.
📁 Résultat attendu : le classement et les besoins reformulés.
Activité 2User stories et critères · ⏱ 25 min
- Rédigez cinq user stories pour CantineCampus : commander, recharger, consulter les allergènes, annuler, voir l'historique.
- Pour deux d'entre elles, écrivez les critères d'acceptation au format « Étant donné / Quand / Alors », cas limites compris.
- Ajoutez deux exigences non fonctionnelles mesurables.
📁 Résultat attendu : les cinq stories, les scénarios et les deux exigences.
Activité 3La story map · ⏱ 20 min
- Sur une grande feuille ou dans FigJam, écrivez les étapes du parcours (découvrir, choisir, commander, payer, récupérer).
- Placez vos stories sous chaque étape, puis tracez la ligne du MVP.
- Classez chaque story en MoSCoW et vérifiez que le MVP traverse tout le parcours.
📁 Résultat attendu : la story map avec la ligne du MVP.
-
Erreurs fréquentes
| Symptôme | Cause | Solution |
|---|---|---|
| Fonction sans usager | Idée de l'équipe, pas un besoin | Remonter au besoin ; sinon, la retirer |
| « En tant qu'utilisateur, je veux un bouton » | Story qui décrit une solution | Décrire l'objectif et le bénéfice |
| « L'application doit être rapide » | Exigence non mesurable | Un chiffre et une condition de test |
| Story sans critères d'acceptation | On ne sait pas quand c'est fini | Étant donné / Quand / Alors, cas limites compris |
| Tout est « Must » | Pas de vraie priorisation | MoSCoW, valeur × effort, MVP traversant |
-
Bilan
- Chaque fonctionnalité remonte à un besoin et descend jusqu'à un test.
- La user story décrit qui, quoi et pourquoi.
- Les exigences sont fonctionnelles (quoi) ou non fonctionnelles (comment, mesurable).
- Les critères d'acceptation rendent la story testable.
- MoSCoW et la story map définissent un MVP qui traverse tout le parcours.
Une fonctionnalité qui ne répond à aucun besoin n'est pas un plus : c'est un écran de plus à comprendre.