Diagramme de cas d’utilisation vs spécification de cas d’utilisation

Il ne suffit pas de montrer le diagramme de cas d’utilisation en   notation UML . Chaque cas d’utilisation est accompagné d’un texte expliquant le but du cas d’utilisation ainsi que la fonctionnalité accomplie lorsqu’un cas d’utilisation est exécuté.

La spécification de cas d’utilisation est généralement créée lors de la phase d’analyse et de conception de manière itérative.

  • Dans un premier temps, seule une brève description des étapes nécessaires pour exécuter le flux normal du cas d’utilisation (c’est-à-dire, quelle fonctionnalité est fournie par le cas d’utilisation) est écrite.
  • Au fur et à mesure que l’analyse progresse, les étapes sont étoffées pour ajouter plus de détails.
  • Enfin, les flux exceptionnels sont ajoutés au cas d’utilisation
  • Chaque projet peut adopter un modèle de cas d’utilisation standard pour la création de la spécification de cas d’utilisation.

Cas d’utilisation vs spécification de cas d’utilisation

Un cas d’utilisation décrit une tâche effectuée par un acteur produisant un résultat de valeur commerciale pour une entreprise. Un cas d’utilisation peut être visualisé sous la forme d’un diagramme de cas d’utilisation ou/et dans un format de spécification textuelle structurée :

Le cas d’utilisation (tâche — qu’un client souhaite exécuter) peut être :

  • Interactif  - Un cas d’utilisation du système décrit l’interaction d’un acteur avec un système dans la poursuite de l’objectif commercial défini
  • Manuel  — Une séquence d’actions exécutées par un acteur
  • Automatisé  — Une séquence d’étapes exécutées par un programme ou un script

Caractéristiques des cas d’utilisation

Un cas d’utilisation a :

  • Un seul but
  • Un point de départ unique
  • Un point final unique
  • Plusieurs chemins pour aller du début à la fin
  • c’est-à-dire spécifier le comportement pour une variété de conditions possibles
  • Chaque condition peut nécessiter une ou des actions spécifiques

Par exemple — Le client paie la facture :

Il existe plusieurs chemins pour  atteindre l’objectif :

  • Paiement par téléphone
  • Par mail
  • En personne
  • par chèque
  • en liquide, etc…

Un chemin qui  ne mène pas au but :

  • La carte de crédit est refusée

Approche de cas d’utilisation agile

Le modèle de cas d’utilisation et ses cas d’utilisation individuels évoluent niveau par niveau au fil du temps. Tous les cas d’utilisation d’un modèle n’auront pas nécessairement besoin d’être spécifiés au même niveau de détail.

Juste à temps et juste assez

Les cas d’utilisation peuvent être écrits à différents niveaux de données et de portée, chacun ayant un objectif :

  • Résumé : descriptions générales et aperçus généraux des fonctionnalités du système ou des processus métier.
  • Niveau utilisateur  : descriptions des utilisateurs liées aux tâches et comment ils interagissent avec le système ; descriptions d’un processus métier spécifique. Les cas d’utilisation au niveau de l’utilisateur sont généralement considérés comme se situant au niveau de la tâche qui constitue le travail principal de l’utilisateur.
  • Sous-fonction : descriptions des activités de niveau inférieur utilisées pour compléter les sous-parties d’un cas d’utilisation principal.

Remarque : Certains cas d’utilisation peuvent être suffisamment spécifiés jusqu’au niveau II. Vous vous arrêtez lorsque suffisamment de détails sont obtenus en utilisant juste à temps et juste assez.


Une spécification détaillée des cas d’utilisation

Le cas d’utilisation détaillé est une représentation textuelle illustrant une séquence d’événements ainsi que d’autres informations de cas d’utilisation connexes dans un certain format. Les gens adoptent généralement un modèle de cas d’utilisation standard pour enregistrer les informations détaillées des cas d’utilisation


Modèle de cas d’utilisation — Exemple de cas de retrait au guichet automatique

Comme mentionné précédemment, il existe plusieurs styles de notation pour les cas d’utilisation (par exemple, style de diagramme, langage de modélisation unifié, format textuel). Quelle que soit la notation utilisée, elle doit être facile à comprendre. Vous pouvez utiliser des modèles, comme ceux d’  Alistair Cockburn , mais c’est aussi une option pour utiliser ce qui convient le mieux à votre équipe.

Spécification de cas d’utilisation

Nom du cas d’utilisation :  retirer de l’argent

Acteur(s) : Client (primaire), Système bancaire (secondaire)

Description sommaire :  permet à tout client d’une banque de retirer de l’argent de son compte bancaire.

Priorité :  doit avoir

Statut :  Moyen Niveau de détails

Condition préalable :  Le client de la banque a une carte à insérer dans le GAB
Le GAB est correctement en ligne

Condition(s) postérieure(s) :

  • Le client de la banque a reçu son argent (et éventuellement un reçu)
  • La banque a débité le compte bancaire du client et enregistré les détails de la transaction

Chemin de base :

  1. Le client introduit sa carte dans le guichet automatique
  2. Le distributeur vérifie que la carte est une carte bancaire valide
  3. Le guichet automatique demande un code PIN
  4. Le client saisit son code PIN
  5. Le GAB valide la carte bancaire par rapport au code PIN
  6. Le guichet automatique présente des options de service, notamment « Retirer »
  7. Le client choisit « Retirer »
  8. Le guichet automatique présente des options pour les montants
  9. Le client sélectionne un montant ou saisit un montant
  10. Le guichet automatique vérifie qu’il a suffisamment d’argent liquide dans sa trémie
  11. Le guichet automatique vérifie que le client est en dessous des limites de retrait
  12. Le guichet automatique vérifie les fonds suffisants sur le compte bancaire du client
  13. Le guichet automatique débite le compte bancaire du client
  14. Le GAB restitue la carte bancaire du client
  15. Le client prend sa carte bancaire
  16. Le guichet automatique émet l’argent du client
  17. Le client prend son argent

Chemins alternatifs :

2a. Carte invalide

2b. Carte à l’envers

5a. Carte volée

5b. NIP invalide

10a. Insuffisance d’espèces dans la trémie

10b. Mauvaise dénomination de l’argent dans la trémie

11a. Retrait au-dessus des limites de retrait

12a. Fonds insuffisants sur le compte bancaire du client

14a. Carte bancaire coincée dans la machine

15a. Le client ne prend pas sa carte bancaire

16a. Argent bloqué dans la machine

17a. Le client ne prend pas son argent

  • un guichet automatique ne peut pas communiquer avec le système bancaire
  • b Le client ne répond pas à l’invite du guichet automatique

Règles commerciales :

B1 : Format du NIP

B2 : Nombre de tentatives de code PIN

B3 : Possibilités d’entretien

B4 : Options de montant

B5 : Limite de retrait

B6 : la carte doit être retirée avant la distribution d’espèces

Prérogatives non fonctionnelles:

NF1 : Délai de transaction complète

NF2 : Sécurité pour la saisie du code PIN

NF3 : Délai pour autoriser le retrait de la carte et de l’argent liquide

NF4 : Prise en charge de la langue

NF5 : Support aveugle et partiellement aveugle


Leave a Reply

Votre adresse e-mail ne sera pas publiée.