User Stories et Use Cases sont deux outils permettant de déterminer les besoins utilisateurs, dans le cadre par exemple d’un projet de développement.
Aujourd’hui, ils sembleraient que ces deux concepts soient en concurrence, chacun proposant des aspects d’analyse spécifiques.

 

Use Cases: UML et relation fonctionnelle

Un Use Case (ou cas d’utilisation) correspond à une liste d’étapes, définissant les interactions entre un rôle et un système, c’est-à-dire toutes les fonctionnalités que doit fournir le système.
Il peut être représenté sous 2 formes: la description textuelle et le diagramme.

Le template textuel n’est pas universel et dépend du style du concepteur, mais en règle général, il se compose des éléments suivants: le nom, l’objectif, l’acteur principal, les acteurs secondaires,les pré-conditions nécessaires au déclenchement de l’action, la description de la séquence nominale, de la séquence alternatives, des séquences d’exceptions et des post-conditions.

En UML, il se symbolise par un diagramme de la forme suivante:

L’acteur symbolise un élément externe interagissant avec un système. Ce n’est pas forcément un « humain », il peut aussi représenter un autre système. Il est représenté sous forme de « stickman ».
Le cas d’utilisation, en forme de bulle, correspond à un aspect fonctionnel du système. Comme dans cet exemple, le cas d’utilisation se compose d’un verbe à l’infinitif et décrit une action.

Pour d’avantages d’informations sur le diagramme Use Cas, voir la source: uml-sysml.org.

Agile, les besoins utilisateurs

La méthode Agile est une méthode de gestion de projets Web introduite “officiellement” en 2001 avec la parution du “Manifesto for Agile Software Development” co-écrit par 17 grands acteurs du domaine de l’informatique et du développement de logiciel. Leurs volontés étaient de proposer un nouveau mode de conception des programmes informatiques.

Cette méthode fonctionne sur la base de l’itératif et de l’incrémental, les tâches vont s’effectuer petit à petit, par ordre de priorité, avec des  phases de contrôle et d’échange avec le client.

Incrémental:
Dans le développement incrémental, le projet est divisé en parties dans lequel nous avons décidé d’effectuer telles ou telles tâches: chaque partie se complète.

Itératif:
Ici le projet est traité dans sa globalité mais à chaque cycle des améliorations sont effectuées.

Il s’agit d’une méthode très souple qui va permettre de mettre en évidence rapidement les erreurs grâce à un feed-back régulier avec le client et de s’adapter aux évolutions des ses besoins, donc à tous changements éventuels.

L’objectif étant de satisfaire au mieux à toutes les demandes du client tout en facilitant le travail de développement: ici les relations avec le client reposeront sur une collaboration et non sur un engagement contractuel.

Le lien suivant informe sur les spécificités de la méthode Agile: http://www.agiliste.fr/fiches/les-specifications-agiles/

« Les enjeux sont clairs: réaliser des spécifications compréhensibles à la fois par un utilisateur et par un développeur … ».

Dans cet article rédigé par Florent Lothon, coach et formateur Agile, l’auteur insiste sur un problème récurrent auquel sont confrontés les équipes de développeurs: Comment définir le besoin utilisateur dans un langage compréhensible pour l’utilisateur et le développeur.

Florent Lothon évoque les différents constats comme les besoins changeant durant le processus de développement logiciel ou encore le fait que les utilisateurs ne savent ce qu’ils veulent qu’après avoir testé la première version du logiciel.

 

User Stories:

Concept

Les User Stories, littéralement récits utilisateur en français, consistent en quelques lignes de texte décrivant une fonctionnalité qu’un système doit offrir pour permettre à un utilisateur donné de réaliser un objectif.

Les User Stories sont rédigées dans le langage commun et ne comportent par conséquent pas de terminologies techniques.

L’intérêt majeur de cette approche est qu’elle est centrée sur l’utilisateur du système: c’est le besoin utilisateur qui est le point de départ de la fonctionnalité et pas l’inverse.

Format

Leur format respecte le schéma suivant :

En tant que <rôle> je veux <quoi> afin de <pourquoi>.

Exemple :

Le « rôle » correspond au rôle de l’utilisateur du système.  Si on développe l’exemple précédent, dans un système classique de gestion de dossiers scolaires, différents rôles peuvent être : « utilisateur » et « administrateur ». « Utilisateur » représente l’utilisateur « normal », c’est à dire l’étudiant qui vient consulter ses notes. « Administrateur » représente un professeur ou un membre de l’administration qui rentre les notes des élèves dans le système.

Le « quoi » décrit l’action qui doit être rendue possible par le système et permettre à l’utilisateur de réaliser l’objectif mentionné dans le « pourquoi ». Concrètement, il s’agit de la fonctionnalité à développer dans le système.

Parfois la partie « pourquoi » n’est pas mentionnée soit parce que le cas n’est pas adapté, soit tout simplement parce que l’auteur du récit utilisateur ne la juge pas utile. Il est à noter tout de même que, dans la mesure ou le cas est adapté, cette partie présente l’intérêt de s’assurer que la fonctionnalité décrite répond bien à un besoin concret.

 

L’utilisation des récits utilisateur dans Agile

Les récits utilisateur sont fréquemment utilisés dans les environnements Agile car ils sont adaptés à ses principes et aux valeurs véhiculées par les méthodes associées (Extreme Programming, Scrum, etc.). Par conséquent, ils suivent certaines règles : notamment, ils doivent décrire des fonctionnalités qui peuvent être développées rapidement (de l’ordre de quelques jours) pour s’adapter aux cycles de développement courts et récursifs des méthodes Agile.

Lorsqu’un récit utilisateur a une taille trop importante, on le découpe en récits plus détaillés. Certains sont appelés des épiques (epic en anglais) et englobent des récits utilisateur qui partagent un même thème.

Cette hiérarchie permet de présenter  les récits utilisateurs de la manière suivante et d’avoir ainsi une représentation visuelle et claire d’un système et des fonctionnalités attendues :

 Il n´y a pas de règle qui spécifie que les récits utilisateurs doivent être rédigés par un acteur particulier. En effet, leur but est principalement d’engager une discussion entre les principaux acteurs du projet. Ceci étant dit, il est d’avantage important que les acteurs adéquats soient présents lors de cette discussion, c’est à dire notamment les personnes les plus à même de comprendre les besoins du client du projet et de formuler des solutions adaptées.

Mis en œuvre dans le cadre des méthodes Agile, les récits utilisateurs, rédigés en début de projet, sont susceptibles d’être modifiés au cours du développement de celui-ci pour correspondre au mieux aux besoins du client qui peuvent évoluer dans le temps. Le chef de produit (du projet) a la responsabilité de s’assurer que ceux-ci couvrent correctement les besoins tout au long du projet.

 

En bref: les règles d’un bon récit utilisateur

Comme indiqué sur le ticket « un récit utilisateur » du site « We do product management » (source : http://www.wdpm.org/definitions/recit-utilisateur/), un récit utilisateur doit être caractérisé par les attributs suivants pour être efficace:

• Indépendant : la livraison de la fonctionnalité décrite ne doit pas dépendre de la livraison d’une autre fonctionnalité en cours de développement
• Négociable : le périmètre ou le niveau de complexité de la fonctionnalité peut être discuté avec l’équipe de développement
• Valorisable : la fonctionnalité doit créer de la valeur métier
• Estimable : le coût de développement doit pouvoir être estimé en fonction des éléments à disposition
• Suffisamment petit : le récit utilisateur doit être contenu dans une itération, au côté d’autres récits utilisateurs
• Testable : il doit être possible de tester la fonctionnalité pour définir si elle peut être livrée aux utilisateurs

 

User Story VS Use Case

Pour comparer les deux approches, attachons nous aux caractéristiques suivantes.

Niveau de complexité (compréhension par le lecteur)

 

Les User Stories, peu importe le nombre, restent indépedantes les unes des autres. Pour un lecteur sans connaissance technique, il est beaucoup plus simple de lire et surtout de comprendre une phrase courte, sans relation avec les autres User Stories.

Le Use Case fonctionne à travers des scénarios, divisés en plusieurs actions simples. Comme pour les User Stories, le langage est simple à comprendre. Cependant, il s’agit d’un ensemble d’actions et le principe de système et de rôle représentent déjà des connaissances techniques.

Les Users stories sont plus simples à comprendre que les Use Cases.

On retrouve d’ailleurs dans les User Stories les valeurs véhiculées par Agile, à savoir une minimisation de la documentation et la promotion des échanges entre l’équipe de développement  et le client. En effet, l’un des objectifs des User Stories est d’engager une discussion entre ces différents acteurs.

 

 

Poids du format et maintenabilité

 

Au niveau du poids du format, là encore les User Stories se révèlent plus efficaces de par la méthode de rédaction. Même si le niveau de détail est différent, évaluer un besoin par des User Stories se révèlent plus court à réaliser qu’avec des Use Cases.
Un changement dans un des Use Cases entraîne des modifications dans le système, au niveau des scénarios de séquence et dans le diagramme, ce qui n’est pas pas le cas avec les User Stories qui peuvent être modifiées à souhait.

 

 

Niveau de détails et précision de la documentation

 

Sur ce point, les Use Cases l’emportent. La rédaction lourde et la présence d’aspects plus techniques permettent un niveau de détails importants. L’idée est de ne rien laisser au hasard et de bien analyser tous les déroulements possibles d’une action (scénario nominal, alternatif et exception). Les User Stories, de par leur format beaucoup plus léger, ne permettent pas un niveau de complexité équivalent.

 

 

Estimation du temps de conception

 

Les Use Cases sont généralement plus adaptés que les User Stories pour estimer le temps de conception d’un projet. En effet, ils intègrent toutes les exigences nécessaires pour valider une fonctionnalité (scénarios nominal, alternatif, exception) tandis que les User Stories ne décrivent pas directement une fonctionnalité en elle meme mais plutot l’objectif et les tests d’acceptance qui lui sont liés.

 

 

Synthèse

Pour conclure, les Use Cases et les User Stories répondent à des besoins differents.

La méthode des Use Cases, plus “lourde”, fournit un niveau de détail suffisamment élevé pour ne pas laisser de place à l’interprétation. Au contraire, celle des User Stories, beaucoup plus “légère” et rapide à mettre en oeuvre, du fait du peu de détails qu’elle comporte laisse de la place à l’interpretation.

Par conséquent, on utilisera l’une ou l’autre de ces deux méthodes en fonction du contexte. Si le système à développer est complexe par exemple, il sera nécessaire de le documenter de facon détaillée dans des Use Cases afin de le rendre compréhensible par tous. Au contraire, si le systeme est suffisamment simple, il n’est peut etre pas nécessaire de passer autant de temps sur la documentation, et la méthode des User Stories suffit alors à couvrir les besoins de conception.

L’expérience et le niveau de compétence de l’équipe de développement de meme que le degré de confiance qu’un chef de produit place dans celle-ci jouent aussi un role important dans la décision. En effet, si le chef de produit estime que son équipe de développement a l’expérience et les compétences nécessaires pour interpréter correctement, c’est à dire dans le sens du client, les exigences du projet alors il préfèrera certainement une documentation sous la forme User Stories, quitte à rediscuter par la suite certains choix de developpement et à effectuer quelques modifications.

 

Bibliographie

• Transparents du cours CASI

• uml-sysml.org, « Use Cases »
• http://www.agiliste.fr , « Méthode Agile »

• http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/ , “User Stories and Use Cases”,  Scott Sehlhorst, 02/02/2009

• http://www.qualitystreet.fr/2009/02/16/user-story-vs-use-case-soyez-agile/, « User Stories VS Use Cases »

• http://www.agilemodeling.com/artifacts/userStory.htm , “Introduction to User Stories”

• http://en.wikipedia.org/wiki/User_story , “User Story”

• http://www.mountaingoatsoftware.com/topics/user-stories , “User Stories”

• http://www.extremeprogramming.org/rules/userstories.html , “User Stories”

• http://www.wdpm.org/definitions/recit-utilisateur/ , “Un récit utilisateur (user story)”

• http://fr.wikipedia.org/wiki/Méthode_agile , “Méthode Agile”