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 :
- Le client introduit sa carte dans le guichet automatique
- Le distributeur vérifie que la carte est une carte bancaire valide
- Le guichet automatique demande un code PIN
- Le client saisit son code PIN
- Le GAB valide la carte bancaire par rapport au code PIN
- Le guichet automatique présente des options de service, notamment « Retirer »
- Le client choisit « Retirer »
- Le guichet automatique présente des options pour les montants
- Le client sélectionne un montant ou saisit un montant
- Le guichet automatique vérifie qu’il a suffisamment d’argent liquide dans sa trémie
- Le guichet automatique vérifie que le client est en dessous des limites de retrait
- Le guichet automatique vérifie les fonds suffisants sur le compte bancaire du client
- Le guichet automatique débite le compte bancaire du client
- Le GAB restitue la carte bancaire du client
- Le client prend sa carte bancaire
- Le guichet automatique émet l’argent du client
- 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
Explorer plus d’exemples de diagrammes de cas d’utilisation
Vous pouvez les modifier instantanément avec Visual Paradigm Free Tool en cliquant sur les exemples de liens ci-dessous :
Liens connexes