Les user stories, use cases, job stories et déclarations de besoins sont quatre façons de noter ce que le logiciel doit faire. Ils sont souvent présentés comme des rivaux, mais ils répondent à des questions différentes à différents niveaux de détail. Une user story demande qui veut quoi et pourquoi. Un use case parcourt une interaction étape par étape, y compris ce qui peut mal se passer. Une job story part de la situation dans laquelle se trouve l'utilisateur. Une déclaration de besoin énonce une règle que le système doit respecter.
Ce guide compare les quatre, montre la même fonctionnalité écrite de chaque manière, et explique laquelle utiliser quand. Pour les bases de l'écriture de stories, consultez notre guide central sur comment rédiger des user stories.
Comparaison rapide
| User story | Use case | Job story | Déclaration de besoin | |
|---|---|---|---|---|
| Format | En tant que [utilisateur], je veux [action], afin de [bénéfice] | Acteur, objectif, préconditions, scénario de succès principal, extensions, postconditions | Quand [situation], je veux [motivation], afin de [résultat attendu] | Le système doit [comportement ou contrainte] |
| Centré sur | Un type d'utilisateur et son objectif | L'interaction entre un acteur et le système | La situation et la motivation, pas la persona | Le comportement ou la qualité du système |
| Longueur | Une phrase plus des critères d'acceptation | Demi-page à plusieurs pages | Une phrase | Une phrase par besoin, plusieurs par document |
| Origine | Extreme Programming ; format de Connextra (2001) | Ivar Jacobson (fin des années 1980) ; style basé sur les objectifs d'Alistair Cockburn (2000) | Paul Adams chez Intercom ; développé par Alan Klement (2013) | Génie logiciel traditionnel (aujourd'hui ISO/IEC/IEEE 29148) |
| Idéal pour | Backlogs agiles et planification des sprints | Flux complexes, intégrations, travaux réglementés ou contractuels | Découverte et conception, en particulier pour des utilisateurs variés dans la même situation | Besoins non fonctionnels, conformité, contrats à périmètre fixe |
| Faible en | Présenter l'ensemble du flux et les cas limites | Vitesse ; difficile de rester à jour lors d'itérations rapides | Planifier et estimer de manière autonome | Expliquer le pourquoi ; facile de rédiger des listes non testables |
User stories
Une user story est une brève description d'une fonctionnalité, racontée du point de vue de la personne qui la souhaite. Le format habituel, « En tant que [type d'utilisateur], je veux [action], afin de [bénéfice] », est né de l'équipe Connextra en 2001 et s'est diffusé grâce au livre de Mike Cohn, User Stories Applied. Les user stories ont grandi avec l'Extreme Programming, où elles étaient délibérément brèves : Ron Jeffries décrivait chaque story comme une carte, une conversation et une confirmation (les 3 Cs). La carte n'est pas la spécification ; c'est lors de la conversation que les détails sont convenus, et les critères d'acceptation les confirment.
Points forts : les user stories sont assez petites pour être estimées et terminées dans un sprint, faciles à lire pour les parties prenantes non techniques, et elles maintiennent la valeur (« afin de ») en vue. Mike Cohn expose le cas en leur faveur dans Avantages des user stories pour les exigences.
Limites : un backlog de user stories individuelles ne montre pas comment elles s'assemblent en un flux, et le format facilite l'omission des cas d'erreur. Les équipes corrigent le premier problème avec une carte de user stories et le second avec des critères d'acceptation bien rédigés (voir nos modèle d'histoire utilisateur).
Cas d'utilisation
Un cas d'utilisation décrit comment un acteur (une personne ou un autre système) utilise le système pour atteindre un objectif, sous forme d'une séquence d'étapes, ainsi que les façons dont cette séquence peut se ramifier ou échouer. Ivar Jacobson a introduit les cas d'utilisation à la fin des années 1980, et le livre de Alistair Cockburn, Writing Effective Use Cases (2000), a établi le style centré sur l'objectif et en texte brut que la plupart des équipes utilisent aujourd'hui (Le site de Cockburn).
Un cas d'utilisation complet comprend généralement :
- Acteur principal : qui initie l'interaction.
- Objectif et périmètre : ce que l'acteur souhaite et quel système est décrit.
- Préconditions : ce qui doit déjà être vrai.
- Déclencheur : ce qui démarre le cas d'utilisation.
- Scénario de succès principal : les étapes numérotées lorsque tout se passe bien.
- Extensions : chemins alternatifs et d'échec, chacun lié à l'étape où ils se ramifient.
- Postconditions ou garanties : ce qui est vrai à la fin, en cas de succès et en cas d'échec.
Points forts : la section des extensions oblige à réfléchir à ce qui peut mal se passer, et le flux complet est visible en un seul endroit, ce qui est précieux pour les intégrations, les paiements et tout ce qui est audité. Limites : les cas d'utilisation prennent plus de temps à rédiger et à mettre à jour, et un cas d'utilisation est généralement trop volumineux pour être construit en un seul sprint.
Les cas d'utilisation se sont adaptés au travail agile. Dans Use-Case 2.0, Jacobson et ses collègues ont divisé chaque cas d'utilisation en « tranches », chacune assez petite pour être planifiée et testée, jouant un rôle très similaire à celui des user stories.
Job stories (jobs to be done)
Une job story remplace la persona par la situation : « Quand [situation], je veux [motivation], afin de [résultat attendu]. » L'idée a été mentionnée pour la première fois par Paul Adams sur le blog Intercom et développée par Alan Klement, qui l'a expliquée dans un article invité sur Intercom en 2013, Utiliser les job stories pour concevoir des fonctionnalités. Elle applique la pensée jobs-to-be-done, associée à Clayton Christensen, à la conception de fonctionnalités.
L'argument en faveur des job stories est que « En tant que parent occupé » porte des hypothèses que l'équipe ne peut pas tester, tandis que la situation (« Quand je suis sur le point de quitter la maison et que je réalise que j'ai oublié de commander des courses ») explique l'urgence, les contraintes et ce que « terminé » signifie pour l'utilisateur. Deux personas très différents dans la même situation ont souvent besoin de la même chose.
Points forts : les job stories sont efficaces en phase de découverte et de conception, elles gardent l'équipe concentrée sur le contexte et produisent de meilleures questions pour les entretiens clients. Limites : elles disent peu sur qui est autorisé à faire quoi, ce qui est important pour les permissions et les rôles, et la plupart des équipes les transforment encore en user stories ou en tâches pour la planification.
Déclarations d'exigences
Le format traditionnel est une déclaration numérotée : « Le système doit verrouiller un compte après cinq tentatives de connexion échouées. » Les spécifications d'exigences restent la norme dans les industries réglementées, les appels d'offres publics et les contrats à prix fixe, et la norme internationale actuelle pour les rédiger est l'ISO/IEC/IEEE 29148.
Les équipes agiles utilisent également des énoncés de besoins, principalement pour les besoins non fonctionnels (performance, sécurité, disponibilité, accessibilité) qui s'appliquent à de nombreuses histoires. Ceux-ci sont souvent enregistrés une seule fois, dans la définition de la fin ou dans une courte page sur les attributs de qualité, plutôt que d'être répétés sur chaque histoire.
La même fonctionnalité rédigée de trois manières
Fonctionnalité : dans une application de dépenses partagées pour colocataires, une personne paie quelque chose et partage le coût avec les autres.
En tant qu'histoire utilisateur
En tant que colocataire qui a payé pour un achat partagé, je veux partager le coût avec les personnes concernées, afin que le solde de chacun montre ce qu'il me doit.
- Je peux choisir quels membres du groupe partagent le coût ; je suis inclus par défaut.
- Le partage par défaut est égal ; je peux passer à des montants exacts ou des pourcentages.
- L'application ne sauvegardera pas un partage dont les parties ne correspondent pas au total, et indiquera l'écart.
- Le solde de chaque personne se met à jour dès que la dépense est enregistrée, et ils reçoivent une notification.
En tant que cas d'utilisation
Cas d'utilisation : Partager une dépense. Acteur principal : Payeur. Précondition : le payeur est connecté et appartient à un groupe avec au moins un autre membre. Déclencheur : le payeur choisit « Ajouter une dépense ».
- Le payeur saisit le montant, une description et la date.
- Le système affiche les membres du groupe, avec le payeur sélectionné.
- Le payeur sélectionne les membres qui partagent le coût.
- Le système propose un partage égal et affiche chaque part.
- Le payeur confirme.
- Le système enregistre la dépense, met à jour chaque solde et notifie les membres sélectionnés.
- 4a. Le payeur passe à des montants exacts ou des pourcentages : le système recalcule à mesure que chaque valeur est saisie.
- 5a. Les parts ne correspondent pas au total : le système bloque l'enregistrement et affiche la différence.
- 6a. L'appareil est hors ligne : le système enregistre la dépense localement, la marque comme en attente et la synchronise une fois en ligne.
- Postcondition en cas de succès : la dépense est enregistrée une seule fois, et chaque solde en tient compte. En cas d'échec : aucun changement de solde.
En tant qu'histoire de tâche
Lorsque je viens de payer quelque chose à la caisse qui est en partie pour mes colocataires, je veux l'enregistrer avant d'oublier le montant, afin de pouvoir être remboursé sans avoir à harceler personne.
En tant qu'énoncés de besoins
- REQ-1 : Le système doit permettre à un membre du groupe d'enregistrer une dépense avec le montant, la description, la date et le payeur.
- REQ-2 : Le système doit permettre au payeur de diviser une dépense également, par montants exacts ou par pourcentage.
- REQ-3 : Le système doit rejeter une division dont les parties ne sont pas égales au total.
- REQ-4 : Le système doit mettre à jour tous les soldes affectés dans les deux secondes suivant l'enregistrement.
Observez ce que chaque version a mis en lumière. L'histoire utilisateur est la plus facile à estimer et à planifier. Le cas d'utilisation est le seul à avoir soulevé le cas hors ligne et à avoir précisé ce qui doit être vrai si l'enregistrement échoue. L'histoire de tâche a révélé la contrainte réelle, qui est la rapidité à la caisse ; elle suggère que l'écran initial devrait demander le montant et rien d'autre, ce qu'aucune des autres versions n'aurait suggéré. Les besoins ont ajouté un objectif de performance mesurable que l'histoire laissait implicite.
Laquelle devriez-vous utiliser ?
| Situation | Commencez par | Pourquoi |
|---|---|---|
| Découverte précoce, entretiens, décision de ce qu'il faut construire | Histoires de tâche | Elles gardent l'équipe centrée sur le contexte de l'utilisateur et permettent de poser de meilleures questions lors des entretiens |
| File d'attente de produit agile, planification de sprint | Histoires utilisateur avec critères d'acceptation | Petites, estimables et lisibles par tous |
| Un flux complexe, une intégration, un mouvement d'argent | Un cas d'utilisation, puis le découper en histoires | Les extensions exposent les chemins d'échec avant qu'ils ne deviennent des bugs |
| Produit réglementé, appel d'offres public, contrat à prix fixe | Énoncés de exigences, souvent tracés jusqu'aux cas d'utilisation | Les auditeurs et les contrats nécessitent des énoncés numérotés et vérifiables |
| Objectifs de performance, de sécurité et d'accessibilité | Énoncés de exigences ou définition de la fin (definition of done) | Ils s'appliquent à de nombreuses histoires, pas à une seule |
| Un MVP avec une petite équipe | Une carte d'histoires utilisateur, avec un cas d'utilisation pour le flux le plus risqué | Assez de structure pour définir le périmètre et construire rapidement |
Peut-on les combiner ?
Oui, et la plupart des équipes matures le font. Une séquence viable ressemble à ceci :
- Utilisez des job stories pendant la phase de recherche pour capturer les situations et les motivations des utilisateurs réels.
- Disposez les capacités résultantes sur une carte d'histoires sous forme d'histoires utilisateur, et choisissez la première tranche de livraison.
- Pour les un ou deux flux où l'échec est coûteux (paiements, inscription, synchronisation des données), rédigez un cas d'utilisation léger pour identifier les extensions, puis transformez chaque extension en son propre histoire ou critère d'acceptation.
- Enregistrez les exigences transversales (performance, sécurité, accessibilité, conformité) une seule fois, sous forme d'énoncés numérotés ou dans la définition de la fin.
La règle générale : n'écrivez que ce dont l'équipe a besoin pour construire la bonne chose en toute sécurité. Une équipe MVP de trois personnes n'a pas besoin d'un document de spécifications, et une intégration bancaire ne devrait pas reposer sur une seule phrase.
Erreurs courantes
- Rédiger des cas d'utilisation comme des scripts d'interface utilisateur (« l'utilisateur clique sur le bouton bleu »), ce qui lie l'exigence à une conception qui va changer.
- Rédiger des histoires utilisateur sans le « afin que » (so that), ce qui empêche l'équipe de proposer une solution plus simple.
- Traiter une job story comme une persona déguisée (« Quand je suis une maman occupée... ») ; la situation doit être un moment, pas une identité.
- Copier une longue liste de exigences dans un backlog en une histoire par ligne, ce qui produit des histoires sans utilisateur ni valeur.
- Utiliser différents formats dans le même backlog sans accord sur lequel est la source de vérité.
Questions fréquemment posées
Quelle est la différence principale entre une histoire utilisateur et un cas d'utilisation ?
Une histoire utilisateur est une description en une phrase de qui veut une capacité et pourquoi, utilisée pour planifier et prioriser le travail. Un cas d'utilisation est une description étape par étape d'une interaction entre un acteur et le système, incluant les chemins alternatifs et d'échec. Les histoires sont plus petites et moins détaillées ; les cas d'utilisation montrent le flux complet.
Une histoire utilisateur est-elle une exigence ?
C'est une manière légère de capturer une exigence, mais pas une spécification complète. Les détails résident dans la conversation et les critères d'acceptation. Les exigences non fonctionnelles telles que la performance et la sécurité sont souvent enregistrées séparément.
Les cas d'utilisation sont-ils encore utilisés dans les équipes agiles ?
Oui, surtout pour les flux complexes ou à haut risque. Use-Case 2.0, par Ivar Jacobson et ses collègues, divise les cas d'utilisation en tranches qui peuvent être planifiées comme des histoires utilisateur, de sorte que les deux puissent coexister dans le même backlog.
Quelle est la différence entre une job story et une histoire utilisateur ?
Une histoire utilisateur part d'un type d'utilisateur (« En tant que... »). Une job story part d'une situation (« Quand... »), et se concentre sur la motivation et le résultat attendu. Les job stories proviennent de la pensée jobs-to-be-done et sont les plus utiles dans la découverte et la conception.
Un cas d'utilisation peut-il devenir plusieurs histoires utilisateur ?
Oui. Le scénario de succès principal devient souvent une ou deux histoires, et chaque extension importante devient son propre histoire ou critère d'acceptation. C'est une façon fiable de diviser une grande fonctionnalité sans perdre les cas limites.
Quelle est la différence entre un cas d'utilisation et un cas de test ?
Un cas d'utilisation décrit comment le système doit se comporter pour atteindre l'objectif d'un acteur. Un cas de test vérifie un chemin spécifique à travers ce comportement avec des entrées et des résultats attendus spécifiques. Un cas d'utilisation produit généralement plusieurs cas de test.
Pas sûr de la quantité de spécification dont votre produit a besoin ? Nous aidons les fondateurs à transformer leurs idées en un backlog défini, puis à le construire en sprints courts. Voir nos plans de développement mensuels.