Les cas d’utilisation

(temps de lecture moyen: 2 m 45 s)

• Qu’est-ce-qu’un cas d’utilisation ?
• Rédiger un cas d’utilisation
• Quels sont les formats de cas d’utilisation ?
• Exigences et cas d’utilisation
• Écrire un cas d’utilisation en 12 étapes

Qu’est-ce-qu’un cas d’utilisation ?

Un cas d’utilisation définit le comportement d’un système sous diverses conditions, en réponse à la requête d’un utilisateur souhaitant atteindre un objectif donné. Il regroupe un ensemble de scénarios d’utilisation, du point de vue des différents acteurs qui interagissent avec le système.

Le système à l’étude (SAE) dépend de l’analyse à réaliser. Si celle-ci porte sur les processus métier, il s’agira de l’organisation / de l’entreprise elle-même. Les acteurs concernés pourront être les fournisseurs, les clients, les services internes, etc.

Si l’analyse porte sur le comportement de tout ou partie d’un logiciel, le SAE désignera ce dernier. Les acteurs des cas d’utilisation seront les utilisateurs interagissant avec le programme informatique, ainsi que les programmes externes.

Un cas d’utilisation doit être clair, non ambigu, facile et rapide à lire. Il décrit une action simple dans laquelle un acteur obtient un résultat ou transmet une information à un autre acteur.

Rédiger un cas d’utilisation

Cependant, écrire un cas d’utilisation efficace n’est pas si simple… En effet, le rédacteur doit apprendre à manipuler 3 concepts fondamentaux :

• La portée: quel est le véritable système à l’étude ?
• L’acteur principal: qui est le détenteur de l’objectif décrit?
• Le niveau: à quel niveau (granularité de détails) se situe l’objectif ?

La description dépend in fine du niveau attendu pour les besoins de l’activité ou du livrable du Business Analyst.

En d’autres termes :

• un document de cadrage décrit généralement les cas d’utilisation au niveau des objectifs stratégiques.
• Les spécifications fonctionnelles générales pourront détailler les scenarios jusqu’au niveau des objectifs utilisateur.
• Enfin, lors de la rédaction des spécifications fonctionnelles détaillées, le Business Analyst rédigera des cas d’utilisations pour le niveau des sous-fonctions du système.

Quels sont les différents formats de cas d’utilisation ?

Les normes d’écriture sont variées, allant de la forme descriptive textuelle à la représentation conceptuelle sous forme de diagrammes.

La forme descriptive peut utiliser des tableaux à une ou deux colonnes, le style RUP (Rational Unified Process), ou encore le style à énoncés algorithmiques (« Si … alors… sinon », « cas 1, …n », « tant que….alors »…).

Les cas d’utilisation à base de diagrammes sont essentiellement basés sur la méthodologie UML, avec les acteurs dessinés en « bonhommes allumettes », le système analysé délimité par un rectangle, et les objectifs écrits dans des formes elliptiques. Les Acteurs et les objectifs sont reliés par des segments indiquant les interdépendances.

Le choix de l’un ou l’autre de ces formats est guidé par la lisibilité et le niveau de détail attendus.

Exigences et cas d’utilisation

Si vous utilisez des cas d’utilisation pour décrire des exigences, retenez que :

• Ceux-ci doivent détailler précisément ce que doit faire le système.
• Ils ne sont pas dédiés à la description des règles métier, des formats de données etc. Ces exigences sont décrites séparément.
• Ne rentrez pas dans les détails dès le début de votre analyse. Apprenez à fonctionner selon la méthode « entonnoir » : partez du général pour descendre progressivement vers des niveaux inférieurs.
• Ne confondez pas description des fonctions d’un système avec cas d’utilisation.
• Ne perdez pas de vue que dans la plupart des cas, l’usage des outils informatique est et doit rester un support, une plus-value pour mieux exercer son métier, et non pas une contrainte ! Pour garder cet objectifs en tête, rien de tel qu’un cas d’utilisation bien ficelé pour comprendre rapidement ce que l’utilisateur attend du système de son point de vue métier.