Qu’est-ce qu’un cas d’utilisation ? avec des exemples et un outil gratuit

Un cas d’utilisation est un outil permettant d’identifier les objectifs commerciaux d’un système. L’identification des cas d’utilisation aide à définir la portée du système, en s’assurant que toutes les exigences à trouver seront alignées sur les valeurs, les besoins et la stratégie commerciale.

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

Un cas d’utilisation représente un objectif commercial de haut niveau à atteindre par une personne, certaines parties ou certains sous-systèmes en interagissant avec un système, qui peut être le système en cours de développement ou le système à maintenir, selon la nature de votre projet logiciel.

Use case

Les cas d’utilisation ne sont ni des exigences système ni des fonctions à implémenter. En fait, il est important de garder les cas d’utilisation éloignés des exigences, car vous avez besoin d’un ensemble clair de cas d’utilisation qui vous aide à définir les objectifs commerciaux et la portée du système. En effet, la capture des exigences s’effectue après l’identification des cas d’utilisation (épisodes) puis leur découpage en un ensemble d’histoires utilisateur correspondantes (objectifs commerciaux).

Forme graphique du cas d’utilisation

Les cas d’utilisation peuvent être visualisés dans un diagramme de cas d’utilisation UML. Un cas d’utilisation est représenté par une ellipse dans le diagramme, avec son nom apparaissant au centre de la forme. En plus du cas d’utilisation, un diagramme de cas d’utilisation typique contient deux autres éléments : l’acteur et le lien.

Use case diagram

Un acteur est un rôle qui interagit avec le système pour atteindre un ou plusieurs objectifs commerciaux représentés par les cas d’utilisation. L’interaction entre un acteur et un cas d’utilisation est représentée par une association (lien). Notez qu’un acteur ne représente pas nécessairement une entité physique spécifique (par exemple John), mais simplement un rôle (par exemple Client). En réalité, un rôle peut être joué par différentes personnes, et inversement, une personne peut jouer plusieurs rôles.

Comment identifier un cas d’utilisation ?

Les cas d’utilisation sont identifiés en communiquant avec les propriétaires commerciaux ou les cadres supérieurs de l’entreprise. Nous les appelons souvent les parties prenantes commerciales. Il est important d’identifier les cas d’utilisation avec les parties prenantes commerciales et non avec d’autres personnes, car elles ont une vision claire des orientations et des opérations réelles de l’entreprise. Elles disposent également de l’autorité et des informations nécessaires pour prendre des décisions commerciales. Ainsi, les cas d’utilisation identifiés sont tous alignés sur les valeurs, les besoins et la stratégie commerciale de l’entreprise.

Pourquoi utiliser les cas d’utilisation ?

Beaucoup de personnes considèrent l’identification des cas d’utilisation comme une étape redondante. Elles préfèrent passer directement à l’identification des exigences du système. Alors, l’approche des cas d’utilisation est-elle inutile ?

Lorsque vous allez développer un système à grande échelle, qui implique généralement de nombreux parties prenantes ayant des attentes différentes sur le système final, aboutissant à une grande quantité d’exigences de manière difficile à gérer. Un cas d’utilisation peut servir de placeholder pour accueillir un groupe d’histoires utilisateur liées, qui partagent un objectif commercial plus large et une portée commune.

Gardez à l’esprit que les cas d’utilisation sont identifiés en communiquant avec les propriétaires commerciaux et les cadres supérieurs qui supervisent la croissance de leurs entreprises et ont la capacité de prendre des décisions stratégiques. En raison de cela, les cas d’utilisation reflètent directement les objectifs commerciaux que le système cible doit atteindre. En identifiant les exigences à partir des cas d’utilisation, les exigences sont très probablement dans la portée du système, permettant ainsi d’atteindre les valeurs commerciales attendues par les propriétaires. En outre, les cas d’utilisation facilitent également une catégorisation significative des exigences. Les fonctionnalités logicielles proposées peuvent être planifiées en fonction de l’importance des cas d’utilisation, plutôt que de se baser uniquement sur les opinions des parties prenantes de première ligne, qui peuvent ne pas être entièrement alignées sur les attentes des propriétaires commerciaux.

Exemples de cas d’utilisation

Voici quelques exemples pour illustrer l’utilisation des cas d’utilisation. L’exemple donné ici sert uniquement à illustrer, il n’existe pas de méthode définitive pour déterminer quels cas d’utilisation doivent être identifiés pour un système cible particulier. La règle d’or pour le processus d’identification des cas d’utilisation est toujours d’être le résultat d’une participation active et d’implication avec les parties prenantes commerciales.

Système

Cas d’utilisation

  • Distributeur automatique de billets
    • Retirer de l’argent, transférer de l’argent, faire un don, régler des factures, changer le code PIN
  • Album photo en ligne
    • Télécharger une photo, partager une photo, supprimer une photo
  • Application de suivi de santé
    • Enregistrer une séance d’entraînement, produire des statistiques d’entraînement, relever un défi

Sur la base des exemples ci-dessus, nous pourrions alors avoir les discussions suivantes :

Le cas d’utilisation produit un objectif observable

Exemple de cas d’utilisation – Distributeur automatique de billets

Le distributeur automatique de billets est un exemple classique lorsqu’on explique le concept de cas d’utilisation ou d’analyse de cas d’utilisation. Vous vous demandez peut-être pourquoi il n’existe pas de cas d’utilisation pour « Connexion », qui est une étape inévitable de toutes les opérations du distributeur. Comme dit, les cas d’utilisation sont des objectifs commerciaux à atteindre. Ils produisent un résultat observable pour l’acteur qui interagit avec le système pour atteindre le cas d’utilisation. Ici, « connexion » n’est qu’une partie des autres opérations. La « connexion » elle-même ne produit aucun résultat observable – personne ne se connecte à un distributeur et s’en va, n’est-ce pas ? Ainsi, nous ne considérons pas la « connexion » comme un cas d’utilisation.

N’est-ce pas que « changer le code PIN » est trop petit pour être un cas d’utilisation ? La réponse est : l’identification des cas d’utilisation ne repose ni sur la quantité de travail que l’utilisateur doit accomplir, ni sur le nombre de fonctions système à développer. Tant qu’il s’agit d’un objectif commercial que le partie prenante commerciale souhaite que le système cible atteigne, c’est un cas d’utilisation. Dans ce cas, nous considérons que les clients qui changent leur code PIN via le distributeur automatique constituent un cas d’utilisation.

Exemple de cas d’utilisation – Album photo en ligne

Un album photo en ligne typique permet aux utilisateurs de marquer leurs photos téléchargées. Le fait de « marquer une photo » est-il alors un cas d’utilisation ? La réponse est : cela dépend. Si les parties prenantes commerciales souhaitent permettre aux utilisateurs d’accéder au système pour marquer leurs photos, même sans effectuer d’autres actions pendant la session, alors « marquer une photo » devrait être un cas d’utilisation. Toutefois, si elles considèrent que marquer une photo n’est qu’une étape du processus de téléchargement des photos, et qu’il n’existe aucun autre moyen de marquer une photo par la suite, alors « marquer une photo » ne serait pas un cas d’utilisation. Un autre cas serait que les parties prenantes souhaitent simplement permettre aux utilisateurs de modifier les photos qu’ils ont téléchargées, par exemple pour modifier le titre, la description, les balises, etc. Dans ce cas, il est probable qu’un cas d’utilisation « modifier une photo » soit créé. On voit donc que l’identification d’un cas d’utilisation n’est pas une étape anodine. On peut imaginer que la fonctionnalité de marquer des photos sera prise en charge de manière très différente selon les cas d’utilisation « marquer une photo » et « modifier une photo ».

Exemple de cas d’utilisation – application de suivi de santé

Bien que les cas d’utilisation ne soient pas des exigences, cela ne signifie pas qu’ils sont abstraits ou dépourvus de focus. Prenons l’exemple de l’application de suivi de santé. Enregistrer un entraînement, produire des statistiques d’entraînement et fixer des objectifs sont tous suffisamment clairs pour définir la portée des fonctionnalités. Le fait de maintenir une bonne santé peut-il être un cas d’utilisation ? Eh bien, ce serait un mauvais choix car sa portée est trop large. Toute application de suivi de santé cherche à aider l’utilisateur à atteindre cet objectif, mais avec cet objectif si vaste, nous ne sommes pas certains de ce que les applications pourraient réellement mettre en œuvre comme fonctionnalités !

Comment rédiger un cas d’utilisation ?

La forme la plus simple d’un cas d’utilisation consiste en un + ou qui décrit un objectif métier. Voici quelques exemples :

  1. S’inscrire
  2. Passer une commande
  3. Retirer de l’argent
  4. Publier une offre d’emploi
  5. Investiguer les défaillances des cas

Comme dit précédemment, les cas d’utilisation sont conçus pour identifier les objectifs métiers. N’utilisez pas cela pour rédiger des exigences, ni pour décrire les interactions entre l’utilisateur et le système. Toutes ces étapes seront détaillées dans les activités de développement ultérieures, mais pas maintenant.

Utilisation du cas d’utilisation avec l’histoire utilisateur

Les histoires utilisateur sont également un outil important dans le développement agile. Chaque histoire utilisateur se compose d’une brève description rédigée du point de vue de l’utilisateur. Voici quelques exemples d’histoire utilisateur :

  1. L’utilisateur souhaite régler un paiement par carte de crédit.
  2. L’utilisateur souhaite régler un paiement par PayPal.
  3. L’utilisateur souhaite éventuellement inclure une assurance livraison lors du paiement.
  4. L’utilisateur souhaite choisir une adresse de livraison différente lors du paiement.
  5. L’utilisateur souhaite recevoir un SMS lors de la création réussie de la commande.

Un cas d’utilisation est un outil pour définir la portée d’une fonctionnalité, tandis qu’une histoire utilisateur capture ce que l’utilisateur fait ou doit faire dans le cadre de son travail, menant finalement à la création de certaines exigences. Nous pouvons utiliser ces deux méthodes de capture d’exigences pour identifier les bonnes exigences. Voici les étapes à suivre : tout d’abord, communiquez avec les parties prenantes commerciales pour identifier les objectifs métiers comme cas d’utilisation. Ensuite, concentrez-vous sur un cas d’utilisation particulier, communiquez avec les utilisateurs de terrain pour identifier les histoires utilisateur associées à ce cas d’utilisation. Étant donné que l’identification des histoires utilisateur est guidée par un cas d’utilisation, les exigences identifiées à la fin seront alignées sur les objectifs métiers.

Use case and user stories

Visual Paradigm fournit tous les outils dont vous avez besoin dansdéveloppement logiciel agile, qui inclutoutil de diagramme de cas d’utilisation UML, (histoire utilisateur) agile, sprint, storyboardetmaquettes pour la conception UX, outil de gestion des tâches, etc.

Références

  1. Diagramme de cas d’utilisation – Langage de modélisation unifié (UML)
  2. Qu’est-ce qu’un diagramme de cas d’utilisation ?
  3. Créer un diagramme de cas d’utilisation UML
  4. Meilleures pratiques et exemples de diagrammes de cas d’utilisation
  5. Modèles de diagrammes de cas d’utilisation
  6. Description du cas d’utilisation dans Visual Paradigm pour UML
  7. Diagramme de cas d’utilisation
  8. Comment dessiner un diagramme de cas d’utilisation ?

Leave a Reply