Les cas d’utilisation sont des documents textuels décrivant l’interaction entre un système (un logiciel à développer) et un ou plusieurs acteurs (les utilisateurs ou systèmes externes). Le cas d’utilisation décrit plusieurs scénarios, mais, en général, il y a un scénario principal « Happy Path » représentant ce qui se passe lorsqu’il n’y a pas d’anomalie.
Les cas d’utilisation sont une manière de documenter les fonctionnalités (les exigences fonctionnelles).
D’autres méthodologies de développement peuvent déterminer les besoins avec les récits utilisateur (user stories), qui sont généralement plus courts et moins prescriptifs que des cas d’utilisation. Par exemple, dans un récit utilisateur, on ne spécifie pas un ordre d’interactions entre l’acteur et le système. Une raison pour ne pas spécifier autant de détails est que ça peut changer beaucoup (surtout au début du projet). Voir cette discussion sur stackexchange.com pour en savoir plus sur les différences.
La théorie sur comment écrire les cas d’utilisation ne fait pas partie de ce manuel (voir Larman, 2005, Chapitre 6).
La notation UML inclut les diagrammes de cas d’utilisation, qui sont comme une table des matières pour les fonctionnalités d’un système.
3.1 Exemple : Le jeu Risk
Nous décrivons un cas d’utilisation à l’aide d’un exemple concernant le jeu Risk.
Selon « Risk ». 2019. Wikipédia. (accédé le 9 décembre 2019) :
Alors, nous proposons les étapes (les interactions entre les acteurs et le système) pour ce scénario :
3.1.1 Scénario : Attaquer un pays
- Le Joueur attaquant choisit d’attaquer un pays voisin du Joueur défenseur.
- Le Joueur attaquant annonce combien de régiments il va utiliser pour son attaque.
- Le Joueur défenseur annonce combien de régiments il va utiliser pour sa défense.
- Les deux Joueurs jettent le nombre de dés selon leur stratégie, choisie aux étapes précédentes.
- Le Système compare les dés, élimine les régiments de l’attaquant ou du défenseur selon les règles et affiche le résultat.
Les Joueurs répètent les étapes 2 à 5 jusqu’à ce que l’attaquant ne puisse plus attaquer ou ne veuille plus attaquer.
3.1.2 Diagramme de cas d’utilisation
La figure 3.1 est un exemple de diagramme de cas d’utilisation.
Un diagramme de cas d’utilisation n’étant q’une sorte de table des matières des fonctionnalités, il ne montre qu’une faible partie des détails trouvés dans le texte de chaque cas d’utilisation. Le diagramme ne peut donc remplacer la documentation textuelle.
Dans la figure 3.1, le cas d’utilisation « … » signifie qu’il y a d’autres cas d’utilisation à spécifier concrètement, c’est-à-dire tous les autres cas d’utilisation du jeu, par exemple pour distribuer les régiments à chaque tour, etc.
Le cas d’utilisation Démarrer n’est pas normalement indiqué dans un diagramme. C’est une astuce pédagogique proposée par Larman Larman (2005), car il faudra concevoir et coder ce scénario, bien qu’il ne soit pas une fonctionnalité connue par l’utilisateur.