Diagramme de cas d’utilisation vs 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