Cas d'utilisation et scénarios

Objectif

Un cas d'utilisation répond à une question: pour un objectif donné qu'un acteur poursuit à travers la solution, quelles sont toutes les manières dont la tentative peut se dérouler? Il rassemble en un seul artefact le chemin nominal, les variantes qui atteignent quand même le but et les échecs, et il attache à chacun ce qui doit rester vrai à la fin. La décision qu'il soutient est une décision de périmètre fonctionnel: ce que la solution doit permettre de faire, exprimé en termes d'objectifs d'acteurs plutôt qu'en fonctions techniques. La valeur métier de chaque cas est portée par l'objectif nommé, ce qui empêche d'écrire une capacité que personne n'a de raison d'exercer.

Le livrable a deux faces. La face textuelle est le cas lui-même: un nom à l'impératif, un objectif, les acteurs, le déclencheur, les préconditions, le scénario principal numéroté, ses alternatives, ses exceptions et les garanties de sortie. La face graphique est le diagramme de cas d'utilisation, qui pose la frontière du système et montre d'un coup d'œil quels acteurs participent à quels cas et quels cas en réutilisent d'autres. Le texte porte le comportement, le diagramme porte le périmètre. Un projet a besoin des deux.

La technique est née chez Ivar Jacobson, qui a présenté le cas d'utilisation à la conférence OOPSLA en 1987 et l'a développé dans sa méthode Objectory, puis dans son ouvrage de 1992. Jacobson a ensuite été l'un des trois auteurs d'UML, ce qui explique que la notation du diagramme soit aujourd'hui normalisée par l'Object Management Group. La manière d'écrire les scénarios, elle, doit l'essentiel à Alistair Cockburn, dont l'ouvrage de 2001 fixe les niveaux d'objectif et la structure en scénario principal plus extensions que les analystes emploient au quotidien.

Usage

Quand l'utiliser

• Cadrer le périmètre fonctionnel d'une solution: le diagramme montre les objectifs des acteurs et où passe la frontière du système.
• Interaction riche entre un acteur et un système: plusieurs chemins, des conditions, des issues d'échec à spécifier ensemble.
• Besoin d'un langage lisible par les parties prenantes: le flux narratif se comprend sans formation, contrairement à une spécification formelle.
• Objectifs d'acteurs déjà identifiés: la liste des acteurs et de leurs buts, issue de l'analyse des parties prenantes, alimente directement les cas.
• Base pour les tests et la conception: chaque scénario est un cas de test candidat, chaque garantie une assertion à vérifier.
• Comportement à figer avant le développement: le cas articule ce que le système doit faire, indépendamment de la façon dont il sera construit.

Quand ne pas l'utiliser

• Besoin encore flou, à explorer par la conversation: prendre les user stories, négociables et dimensionnées pour un sprint.
• Objet de l'étude: les règles et les décisions: prendre l'analyse des règles métier, qui les gère à part.
• Objet de l'étude: l'apparence et l'agencement des écrans: prendre le prototypage, où vit le détail de l'interface.

Description

Le cas, le scénario, le diagramme

Trois objets se recouvrent et se confondent. Le cas d'utilisation est l'unité orientée objectif: l'ensemble des façons dont une tentative d'atteindre un but peut se dérouler. Un scénario est un chemin concret à travers ce cas, une seule suite d'étapes. Le scénario principal, celui où tout se passe bien, est le chemin le plus court et le plus simple vers l'objectif. Les scénarios alternatifs atteignent le but par un autre chemin, les scénarios d'exception se terminent sans l'atteindre. Le diagramme de cas d'utilisation ne raconte aucun scénario: il montre, au-dessus de tout cela, quels acteurs participent à quels cas et comment les cas se relient. La formulation de Cockburn est la plus compacte: un cas d'utilisation est un scénario principal plus un jeu d'extensions, chaque extension étant une condition et les étapes qu'elle déclenche.

Les éléments d'un cas d'utilisation

Le nom est un verbe suivi d'un complément qui nomme l'action de l'acteur et sa cible: « Renouveler un abonnement », jamais un intitulé statique comme « Gestion des abonnements ». L'objectif décrit en une phrase l'issue réussie du point de vue de l'acteur principal, et il sert de résumé au cas. Les acteurs sont les personnes ou les systèmes extérieurs à la solution qui interagissent avec elle, désignés par le rôle qu'ils jouent. L'acteur principal a l'objectif et déclenche le plus souvent le cas; les acteurs secondaires, comme un système de paiement, rendent un service que la solution appelle pour aboutir. Certaines écoles déconseillent de traiter un système ou un événement en acteur; l'usage reste minoritaire.

La précondition énonce ce qui doit être vrai avant que le cas puisse commencer. Le cas la suppose vraie à son départ et la laisse hors de son déroulement: écrire « le titulaire est authentifié » en précondition dispense d'ajouter une étape d'authentification au scénario. Le déclencheur est l'événement qui lance le flux, le plus souvent une action de l'acteur principal, parfois un événement temporel comme une routine de fin de journée ou un rapprochement de fin de mois. Les garanties, ou postconditions, énoncent ce qui doit être vrai quand le cas se termine, et elles se dédoublent: la garantie de succès vaut sur le chemin réussi, la garantie minimale vaut même en cas d'échec et protège la sécurité et l'intégrité des données. Une garantie doit tenir pour tous les scénarios, principal comme alternatifs, sans quoi elle n'est qu'un vœu attaché au seul scénario principal.

Choisir le niveau d'objectif

Un cas d'utilisation s'écrit à un niveau, et le choix du niveau est celui qu'on rate le plus souvent. Cockburn en propose une échelle, celle du niveau de la mer. Le niveau objectif utilisateur, la surface de l'eau, est celui où un seul acteur atteint un seul objectif en une seule séance de travail: c'est là qu'un analyste écrit. Au-dessus, le niveau résumé couvre un processus qui enjambe plusieurs objectifs utilisateur (« Gérer son compte »): trop large pour être écrit d'une pièce, il se décompose. En dessous, le niveau sous-fonction décrit une étape réutilisée par plusieurs cas (« S'authentifier », « Effectuer le paiement »): candidat à la factorisation en cas inclus. Le test tient en une question: un acteur peut-il l'accomplir en une fois et repartir en ayant obtenu quelque chose de valeur?

Deux dérives suivent d'un mauvais niveau. La première est le cas écrit trop haut, qui devient un fourre-tout où l'objectif se dilue. La seconde, plus insidieuse, est le modèle CRUD: transformer Créer, Lire, Modifier, Supprimer en quatre cas d'utilisation par entité. Ce sont des sous-fonctions; elles gonflent le modèle et n'apprennent rien sur l'intention de l'acteur. Personne ne se connecte pour « mettre à jour une ligne d'abonnement », on se connecte pour renouveler son abonnement. Le niveau objectif utilisateur est le garde-fou contre les deux dérives.

Écrire le scénario principal en boîte noire

Le scénario principal s'écrit en étapes numérotées, alternant l'acteur et la solution, du point de vue de l'acteur et surtout en boîte noire: chaque étape dit ce que le système fait, vu de l'extérieur. Trois à neuf étapes suffisent à un cas sain. Ce principe de boîte noire est la ligne directrice la plus facile à trahir, de deux façons.

La première est la fuite de l'interface dans le flux: « le titulaire clique sur le bouton bleu », « choisit dans la liste déroulante », « la fenêtre modale apparaît ». Le flux dit ce que le système accomplit. Le détail de l'interface appartient au prototypage, où il se conçoit et se teste sans figer prématurément le comportement. La seconde est l'enfouissement des règles métier dans les étapes: coder en dur un barème, une table de taux, une logique d'éligibilité au fil du scénario. Ces règles se gèrent séparément, par l'analyse des règles métier, et l'étape s'y réfère. Un cas qui enferme une règle devient faux le jour où la règle change, et la règle reste enfouie dans un document que personne ne relit.

Dériver les alternatives et les exceptions

Le scénario principal une fois posé, on parcourt chaque étape et l'on demande: quoi d'autre pourrait se produire ici? Chaque branche se repère par le numéro de l'étape qu'elle quitte, une lettre distinguant les branches d'une même étape: 5a, 6a. Une alternative atteint quand même l'objectif par un autre chemin et rejoint le flux principal. Une exception se termine sans l'objectif, et l'on énonce alors la sortie: ce que le système fait et quelle garantie tient malgré l'échec. C'est ici que la garantie minimale prend son sens, en nommant ce qui reste vrai quand le but n'est pas atteint. L'exhaustivité est un piège: le format souple invite à capturer chaque micro-variante, et un cas noyé sous quarante branches n'est plus lu. On garde les chemins réels, on écarte les hypothèses de laboratoire.

Lire le diagramme de cas d'utilisation

Le diagramme pose la frontière du système et distribue les objectifs des acteurs autour d'elle. La notation, normalisée par UML, se réduit à quelques signes pour qui veut le lire. Un acteur est un personnage filiforme, placé à l'extérieur de la frontière: c'est un rôle. Un cas d'utilisation est une ellipse, placée à l'intérieur, portant le nom en verbe plus complément. La frontière du système est un rectangle qui enclôt les ellipses; on l'étiquette du nom du système. Une association est un trait plein reliant un acteur à un cas: elle marque que l'acteur participe au cas et accède à la fonctionnalité décrite.

Deux relations relient les cas entre eux, et les lecteurs manquent cette distinction plus que toute autre. L'«include» est une flèche pointillée à tête ouverte, marquée du mot-clé, qui va du cas de base vers le cas inclus: le cas de base exécute toujours le comportement inclus. On l'emploie pour factoriser un comportement partagé par plusieurs cas, « Effectuer le paiement » réutilisé par « Renouveler un abonnement » et par « Acheter un billet ». L'«extend» est aussi une flèche pointillée à tête ouverte, mais elle pointe du cas qui étend vers le cas de base, ce qui surprend la plupart des lecteurs: la flèche vise le cas de base. L'extension ajoute un comportement conditionnel, à un point d'extension défini, et le cas de base reste complet et fonctionnel sans elle. La règle tient en une ligne: «include» veut dire «toujours et réutilisé», «extend» veut dire «parfois et optionnel». Employer l'un pour l'autre ou dessiner la flèche d'«extend» vers le cas qui étend est l'erreur UML la plus répandue. Une généralisation existe aussi, un trait plein terminé par un triangle creux, pour un acteur ou un cas qui est une variété spécialisée d'un autre; c'est la relation la moins employée.

La notation s'arrête là pour le business analyste: ces quelques signes suffisent à lire un diagramme de cas d'utilisation et à en discuter avec les parties prenantes. La sémantique fine d'UML, ses autres diagrammes et l'usage avancé d'«include» et d'«extend» relèvent d'une formation dédiée à la modélisation. Sur-décomposer un modèle en inclusions imbriquées est de la décomposition fonctionnelle déguisée, qui perd l'objectif que le cas devait porter.

Conduire l'exercice

1. Identifier les acteurs et leurs objectifs
   À partir de la liste des parties prenantes, nommer chaque rôle extérieur qui interagit avec la solution et le but qu'il poursuit.
2. Nommer chaque cas par son objectif
   Un verbe, un complément, au niveau objectif utilisateur.
3. Écrire le scénario principal
   Des étapes numérotées, en boîte noire, du point de vue de l'acteur. Aucune mécanique d'écran, aucune règle métier codée en dur.
4. Dériver les alternatives et les exceptions
   Parcourir chaque étape, étiqueter les branches contre l'étape qu'elles quittent, énoncer une sortie pour chaque exception.
5. Définir précondition, déclencheur et garanties
   Ce qui doit déjà être vrai, ce qui lance le cas, ce qui tient à la fin sur le succès et même sur l'échec.
6. Dessiner le diagramme
   Acteurs hors de la frontière, cas en ellipses à l'intérieur, associations en traits pleins, comportement partagé en «include», comportement optionnel en «extend». Garder les règles et les décisions hors des étapes et y renvoyer.

Cas d'utilisation ou user story

La confusion avec la user story mérite d'être levée, car les deux couvrent le même terrain. Une user story est un court substitut négociable à une conversation, « en tant que voyageur, je veux renouveler mon abonnement afin de continuer à circuler », dimensionné pour tenir dans un sprint. Un cas d'utilisation est une spécification comportementale plus complète d'un objectif, avec tous ses flux et ses garanties. Les deux sont complémentaires: une story dont l'interaction se révèle complexe s'élabore en cas d'utilisation quand vient le moment de fixer les chemins et les issues. On choisit selon le risque et la maturité du besoin, l'une pour ouvrir la discussion, l'autre pour arrêter le comportement.

Considérations IA

Le premier usage rentable est l'ébauche. À partir d'une transcription d'entretien, d'une description de processus ou d'un jeu de user stories, un modèle de langage propose un premier scénario principal numéroté et une liste d'alternatives et d'exceptions candidates. Il est rapide sur cette partie mécanique, et il laisse à l'analyste le travail de tri plutôt que celui de la page blanche. Le deuxième usage est celui où la machine excelle: énumérer ce qui peut mal tourner à l'étape N. Paiement refusé, session expirée, article devenu indisponible, modification concurrente: un modèle déroule ces exceptions comme une liste de contrôle, et le business analyste ne garde que celles qui peuvent survenir.

Le troisième usage est la vérification structurelle. On demande au modèle si chaque étape a une issue définie, si les garanties tiennent sur tous les flux, si une précondition est supposée sans être écrite, si deux cas se recouvrent. Il repère les oublis de structure; leur gravité reste à juger. Le quatrième usage est le nommage et le niveau: signaler qu'un « cas » est en réalité une sous-fonction CRUD ou un résumé et proposer des noms en verbe plus complément. Le cinquième est la conversion de format, passer d'un cas complet à un paragraphe informel ou l'inverse et préparer les versions multilingues.

Ce que l'IA ne peut pas porter tient à la nature de la technique. L'identification des acteurs et des objectifs est un acte d'élicitation et un arbitrage politique: qui sont les vraies parties prenantes, quels objectifs comptent, où passe la frontière du système. Le modèle inventera des acteurs plausibles et faux. Le comportement réel du système ne se devine pas: seules les parties prenantes et les contraintes de la solution définissent ce que le système fait, et un flux produit par un modèle est une hypothèse à valider. La validité des cas limites mêle risques réels et fiction dans la même phrase: un humain décide lesquels sont dans le périmètre, lesquels sont traités ailleurs, lesquels ne peuvent pas survenir. Enfin le modèle ne doit pas enfouir dans les étapes des règles d'éligibilité, des taux ou des traitements de données personnelles qu'il aurait devinés. L'IA ébauche et éprouve les flux, le business analyste détient les acteurs, le périmètre et ce qui est vrai.

Exemples

Un portail libre-service où un client gère ses abonnements de transport en ligne. Le cas « Renouveler un abonnement » exerce les deux relations du diagramme: « Effectuer le paiement » est partagé avec l'achat d'un billet, donc inclus, et un bon de réduction est optionnel, donc en extension.

On lit d'abord le périmètre. Le diagramme place le titulaire et le système de paiement de part et d'autre de la frontière, répartit les objectifs du titulaire en cas distincts et montre ce que ces cas se partagent. L'association relie l'acteur au cas auquel il participe. La flèche d'«include» tire « Effectuer le paiement » hors des deux cas qui le réutilisent, ce qui rend visible le comportement partagé sans le recopier. La flèche d'«extend» accroche « Appliquer un bon de réduction » au renouvellement en pointant vers le cas de base, qui reste complet et fonctionnel sans elle.

L'artefact écrit reprend la même histoire de plus près: identité et garanties d'abord, puis les scénarios réunis en un seul tableau où chaque ligne porte son type de chemin.

Un scénario est un chemin dans ce cas: le principal enchaîne 1 à 8, l'alternative 5a substitue une étape et rejoint le flux, l'exception 6a le termine sans objectif et la garantie minimale tient alors puisque rien n'est débité ni enregistré. Ce que le diagramme ajoute au texte est la portée: « Effectuer le paiement » est inclus par « Renouveler un abonnement » comme par « Acheter un billet », et ce partage justifie de le sortir en cas inclus plutôt que de le recopier dans chaque scénario.

Visualisations

Deux figures portent l'exemple. Le diagramme de cas d'utilisation montre le périmètre: le titulaire et le système de paiement de part et d'autre d'une frontière rectangulaire, les cas en ellipses à l'intérieur, l'association en trait plein, l'«include» et l'«extend» en flèches pointillées, la flèche d'«extend» pointant vers le cas de base pour rendre visible le sens que l'intuition inverse. Le tableau des scénarios montre le comportement: le même cas parcouru comme plusieurs chemins étiquetés. Le premier répond à « qui touche quoi et qu'est-ce qui est partagé », le second à « comment la tentative se déroule ».

Coût

Outils

Un traitement de texte suffit à écrire un cas, et un gabarit, celui de Cockburn par exemple, garantit qu'aucun champ n'est oublié: périmètre, niveau, acteur principal, parties prenantes, préconditions, garanties, déclencheur, scénario principal, extensions. Un tableur porte bien le tableau des scénarios numérotés, et un tableau blanc suffit à esquisser une première frontière et deux ou trois ellipses. Ces outils génériques conviennent tant que les cas restent peu nombreux et peu liés entre eux.

Pour le diagramme, les outils de dessin généralistes, diagrams.net, Lucidchart ou Visio, portent des gabarits de cas d'utilisation corrects; leur apport s'arrête au dessin. Les ateliers de modélisation UML, Enterprise Architect, Visual Paradigm ou Modelio, tiennent le cas et son diagramme comme des objets d'un même modèle, les tracent vers les diagrammes qui les réalisent et signalent une flèche d'«extend» mal orientée ou un cas sans acteur. Quand les cas se comptent par dizaines et servent de base aux tests, les outils de gestion des exigences et d'ALM, Jama, Polarion, Azure DevOps ou DOORS, les rattachent aux exigences, aux cas de test et aux versions et rendent visible la couverture d'un scénario par ses tests.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.47 Use Cases and Scenarios: la définition, la liste des éléments (acteurs, préconditions, déclencheur, flux principal, alternatifs et exceptions, garanties), le diagramme de cas d'utilisation et le renvoi à UML pour sa notation.
• Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992: l'ouvrage fondateur du cas d'utilisation, issu de la méthode Objectory et présenté dès OOPSLA 1987.
• Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2001: les niveaux d'objectif (l'échelle du niveau de la mer), la structure en scénario principal plus extensions, le vocabulaire d'acteurs et les formats complet et informel.
• Object Management Group, Unified Modeling Language (UML), version 2.5.1 (formal/17-12-05, 2017): la notation normalisée du diagramme de cas d'utilisation, acteur, cas, frontière, association, «include», «extend» et généralisation.