Les cas d’utilisation

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 :

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.

diagramme use case

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.

Écrire un cas d’utilisation en 12 étapes

  1. Délimitez les frontières du système
  2. Listez les acteurs principaux
  3. Listez les objectifs de chaque acteur principal
  4. A l’aide de ces éléments, écrivez les cas d’utilisation de niveau stratégique
  5. Relisez-vous : corrigez, adaptez, fusionnez, retirez des objectifs stratégiques
  6. Prenez un de ces cas d’utilisation simplifiés, et réfléchissez à son fonctionnement du point de vue utilisateur.
  7. Ajoutez-y les intérêts, préconditions et garanties.
  8. Afin de décrire l’objectif des sous-fonctions, commencez par rédiger le scénario nominal (quand tout va bien)
  9. Réfléchissez ensuite aux conditions d’échec et aux conditions alternatives de succès
  10. Indiquez de quelle façon doivent se comporter les acteurs et le système dans chacun de ces scénarios (alternatif et d’échec)
  11. Pour une meilleure lisibilité, isolez les « gros » cas d’utilisation ayant besoin d’espace
  12. Relisez l’ensemble en partant du haut (objectifs stratégiques) vers le bas (objectifs utilisateur puis sous-fonction). Corrigez, adaptez, fusionnez, retirez des objectifs si nécessaire.

Poster un Commentaire

avatar
  S’abonner  
Notifier de