User Story ou Use Case ?

Entre User Story et Use Case, la différence ou la séparation est parfois confuse, et il me paraît intéressant de bien situer les deux en terme de similitudes, de spécificités et de complémentarité. Pour rappel, voici quelques définitions utiles se rapportant au sujet des user stories et des use cases, avant de les comparer.

Définition d'une Feature :

Une feature est un service fourni par le système, observable de l'extérieur, qui répond à un besoin, et dont la description se situe à un niveau tel que toutes les parties prenantes comprennent facilement ce dont il s'agit.

On emploie également dans le domaine de l'ingénierie des exigences les termes suivants : theme, epic, minimal marketable feature (MMF).

Exemples d'atelier pour identifier les features :

• Product Box / Boîte du Produit
• Remember the Future / Souvenir du Futur

Définition d'une User Story (ou histoire utilisateur) :

Une user story est une fonctionnalité élémentaire décrite du point de vue de l'utilisateur. Elle apporte de la valeur à l'utilisateur et peut être réalisée en moins d'une itération de deux semaines, c'est-à-dire quelques jours tout au plus. Les US sont obtenues par la décomposition des features. L'écriture d'une US s'appuie sur la formalisation suivante :

En tant que <rôle>, je peux <action>, afin de <justification>.

User Story : matrice Rôle - Fonctionnalité - Bénéfice

Avec 3 attributs récurrents :

• un rôle,
• une action : le but fonctionnel,
• une justification (parfois facultative, car elle peut être évidente),
• la plus-value métier, représentant le bénéfice que va tirer l'utilisateur de la user story,
• le coût en story points, c'est-à-dire l'estimation de l'effort nécessaire à la réalisation de la user story.

Et éventuellement des attributs complémentaires :

• une priorité déduite de la plus-value métier et du coût,
• La fréquence d'utilisation de la US par le rôle : plus grande est la fréquence d'utilisation, plus important sera le soin apporté aux tests (tests unitaires, d'intégration, de charge, etc).
• Des informations complémentaires : texte, schéma, diagramme.

Et toujours les tests d'acceptation (story tests) associés à la US : en fin d'itération, la US est considérée finie seulement si tous les tests d'acceptation sont validés. Les tests d'acceptation, ou conditions de satisfaction, ont eux-mêmes leur formalisme :

Étant donné... <pré-condition : état du système>
Quand... <événement : acteur + action>
Alors... <résultat observable de l'extérieur>
[Et... <autre résultat observable>]

Définition d'un Use Case (ou cas d'utilisation) :

Un use case est une description des interactions qui vont permettre à l'acteur d'atteindre son objectif en utilisant le système. Les interactions sont regroupées en scénarii. Un acteur est une entité décrite par son rôle, ses besoins et ses capacités.

Rédaction d'un cas d'utilisation :

• Fiche récapitulative :
• Titre,
• Identifiant,
• Acteurs,
• Description.
• Préconditions
• Post-conditions
• Scénario principal : séquence d'étapes ordonnées dans le temps (3 à 9 étapes).
• Scénarii alternatifs éventuels : variations / exceptions, cas d'erreur et leur gestion.

Un cas d'utilisation ne doit pas se réduire à l'IHM, ce qui masquerait les interactions du système avec d'autres acteurs que l'utilisateur final.

Le diagramme des cas d'utilisation comprend :

• un ou des acteurs, représentés par des pictogrammes humanoïdes,
• des cas d'utilisation, représentés par des ellipses,
• des relations, représentées par des traits :
• relations simples (trait continu), 
• inclusions (traits pointillés terminés par une flèche et stéréotype "includes"),
• extensions (traits pointillés terminés par une flèche et stéréotype "extends"),
• généralisations (ou spécialisations, ou héritages) (trait continu terminé par une flèche triangulaire).

Qu'il s'agisse de User Story ou de Use Case, les deux techniques servent à appréhender les besoins des utilisateurs en terme d'interaction avec un système, mais leurs manières de le faire divergent en de nombreuses occasions.

	User Story	Use Case
Finalité	En association avec les tests d'acceptation, rédiger les exigences fonctionnelles du point de vue de l'utilisateur. Faciliter l'estimation et la planification : les US décomposées peuvent être planifiées dans des itérations différentes. Comme éléments du backlog de produit, les US sont orientées vers la gestion et le suivi des projets.	Seulement recueillir l'expression des besoins et rédiger les spécifications détaillées des exigences fonctionnelles sous forme de processus métier.
Traçabilité	US conservée dans le Backlog de produit.	UC conservé dans le document des spécifications fonctionnelles.
Granularité	Fine : une fonctionnalité élémentaire. Une US peut être une partie d'un UC : tout ou partie d'un scénario, ou éclatée dans plusieurs scénarii. Implémentée et testée en moins d'une itération.	Grande : une macro-fonctionnalité qui en réunit de plus petites. Implémenté et testé en une ou plusieurs itérations.
Formalisme	Phrase composée de 3 attributs : rôle ("qui ?"), action ("quoi ?"), justification ("pourquoi ?"), et complétée par des tests d'acceptation.	Le formalisme est défini par UML. Scénarii constitués d'une séquence d'actions ou d'événements. Répondent à "qui ?" et "quoi ?". Les UC sont regroupés dans un diagramme des cas d'utilisation.
Expression	Description brève, facile à comprendre, dans le langage de tous les jours ou du métier (mais sans jargon technique).	Quantité importante d'informations, dans le langage spécifique de l'utilisateur final ou de l'expert du domaine métier. (Une demi-page pour un UC court, jusqu'à 2 pages pour un long)
Effort	Émergence rapide des exigences. Facile à écrire avec ou par des utilisateurs ou des clients.	Les UC nécessitent un long travail d'analyse et de formalisation, afin de décrire un système entier et pensé dans son intégralité.
Complétude	Les tests d'acceptation fournissent les conditions de satisfaction sous forme de scénarii courts pour valider une US.	Le scénario principal décrit le comportement nominal. Pour le reste, les scénarii alternatifs et d'erreur viennent combler les manques.
Maintenabilité	Facile à maintenir, car le format est synthétique.	Difficile à maintenir, car le format implique un contenu très conséquent. De plus, les UC mélangent les interactions et les règles métier, ce qui pose problème quand les besoins évoluent.
Focus	Valeur métier pour l'utilisateur final.	Interactions entre l'utilisateur final et le système.
Visibilité du contexte global	Difficile de lier les US les unes aux autres. Une partie du contexte est fournie par les features et la vision du produit.	Les scénarii montrent l'enchaînement temporel des actions.
Culture de travail	Adaptée au travail collaboratif et à des échanges de proximité. Favorable à l'émergence de débats et à la négociation.	Adapté à des échanges distants et contractuels.
Tests	Les US contiennent déjà les tests d'acceptation à réaliser pendant les développements, puis lors de la démonstration pour la validation avec le Product Owner. Cf. ATDD.	Les UC permettent de préparer les tests de recette, car les scénarii donnent les parcours à réaliser au cours des tests fonctionnels. Mais ils n'indiquent pas les critères d'acceptation pour statuer.
Relation avec d'autres méthodes	Technique issue de l'eXtreme Programming et associée aux méthodes agiles.	Technique associée au Processus Unifié.
Auteur de référence	Mike Cohn	Alistair Cockburn

Ainsi, on constate déjà un certain nombre d'impacts selon le choix qui sera fait entre User Story et Use Case :

• Impact sur la vision du produit :
• Les US expliquent ce que doit faire un système, mais aussi pourquoi. Les US sont regroupées au travers des features dont elles sont issues.
• Les UC expliquent bien ce que doit faire un système, mais pas pourquoi il le fait. Les UC sont liés entre eux par le diagramme des cas d'utilisation, et leurs scénarii relient les fonctionnalités entre elles.
• Impact sur les cycles des livraisons :
• Cycle court avec les US et livraison au plus tôt de leur plus-value métier pour un retour sur investissement plus tôt et plus rapide ;
• Livraisons plus espacées avec les UC.
• Impact sur le processus de développement :
• Longue phase de spécification avec les UC suivie de phases distinctes définies par le processus (RUP, cycle en V ou cascade) ;
• Réalisation par petits périmètres fonctionnels, qui autorise un transfert continu et opportuniste de la connaissance métier vers l'équipe de développement, une collaboration entre toutes les parties prenantes à chaque itération, ainsi qu'un retour rapide du ressenti utilisateur permettant d'éventuels changements au plus tôt (et donc à moindre coût).
• Impact sur la validation ou recette :
• Les critères sont connus avant les développements avec les US, ce qui permet de limiter les interprétations ;
• Les critères sont exprimés après les développements avec les UC seuls comme exigences, ce qui nécessite une deuxième interprétation des exigences à la rédaction du cahier de recette, potentiellement différente, et donc une maintenance corrective accrue.

En revanche, il existe une complémentarité entre user story et use case, entre la vision du produit et la visibilité du contexte global. Dans la mesure où il serait possible de construire le scénario principal d'un cas d'utilisation sur une seule histoire utilisateur, on pourrait tirer parti d'un diagramme des cas d'utilisation reprenant différents items du backlog de produit.

Liens :

• Innovation Games
• Wikipédia : User Story, Cas d'utilisation, UML, Diagramme des cas d'utilisation
• Scrum, le guide pratique de la méthode agile la plus populaire, Claude Aubry
• UML 2 par la pratique, Pascal Roques
• Blog de Claude Aubry : Use-case et user story, User stories et use-cases
• Blog de Laurent Carbonnaux : User Story vs Use Case
• Matrice Rôle - Fonctionnalité - Bénéfice, Institut Agile