🛠️ Cas d’utilisation

Survol et attentes

Définitions

Cas d’usage : Un cas d’usage est un document qui analyse comment un produit ou un service sera utilisé. Ce type de document doit être compréhensible par toutes les parties prenantes. Il sert alors de point de connexion entre les différentes parties prenantes et guide le développement technique du produit ou service.

Partie prenante / Acteur : Une personne qui est affectée par le développement du produit ou service. Les parties prenantes peuvent être des utilisateurs, des gérants, des développeurs, des investisseurs, etc.

Public cible : Les personnes qui utiliseront le produit ou service. Le public cible est souvent divisé en plusieurs groupes, chacun ayant des besoins spécifiques.

Flux : séquence d’événements

Objectifs d’apprentissage

À la fin de cette leçon vous devrez être en mesure de :

énumerer les éléments d’un cas d’usage, notamment le public cible, les acteurs, les objectifs, les conditions préalables, les flux et les conditions de sortie;
distinguer les flux de base, alternatifs et exceptionnels d’un cas d’usage

Critères de succès

Je peux rédiger un cas d’usage pour une technologie ou un processus que je développe.
Je peux adapter les flux aux besoins des acteurs.

But des cas d’usage

Les cas d’usage se concentrent sur les utilisateurs du système plutôt que sur le système lui-même. Un cas d’usage doit être compréhensible par toutes les parties prenantes, pas seulement les développeurs et les testeurs. Cela inclut les clients, les utilisateurs et les dirigeants. Ainsi le texte d’un cas d’usage est plutôt narratif que technique.

Une des meilleures justifications pour la création de cas d’utilisation est qu’ils servent de véritables points de connexion. Si bien rédigés, ils peuvent être compris par toutes les parties prenantes qui peuvent alors ajouter leurs commentaires et suggestions avant que le développement ne commence. Cela permet de s’assurer que le produit ou service répondra aux besoins de tous les utilisateurs.

Comment rédiger un cas d’usage

Pour rédiger un cas d’usage, procédez comme suit :

Déterminer le public cible du produit et le décrire en détail
Nommer toutes les parties prenantes et sélectionnez un membre de cette liste comme acteur principal. Pour des projets d’informatique du point de vue des développeurs, l’acteur principal est souvent un utilisateur du système.
Déterminez exactement ce que l’utilisateur souhaite faire avec le produit (son objectif). On devrait créer un cas d’usage pour chaque objectif.
Décrivez les conditions préalables à l’utilisation du produit ou du service. Par exemple, est-ce qu’un équipement spécial est nécessaire? Est-ce que l’utilisateur doit être connecté à Internet?
Déterminer le flux typique d’événements pour une session ou l’acteur principal atteint son objectif. Cela ressemble généralement, pour les produits informatiques, à plusieurs cycles d’une action de l’utilisateur suivie par une réponse du système.
Envisager d’autres usages normaux possibles et les décrire comme flux alternatifs.
Envisager également des situations anormales (p. ex.: des bris ou des erreurs) et les décrire comme flux exceptionnels.
Finalement, décrivez les conditions de sortie qui suivent l’usage normal par l’utilisateur, p. ex.: l’enregistrement des données.

Idéalement, après la rédaction d’un cas d’usage, on aurait une discussion avec les parties prenantes pour obtenir des commentaires et des suggestions pour ajuster d’avantage les flux et les conditions afin de mieux répondre aux besoins de chacun.

Exemples

Exemple d'un cas d'usage non informatique

Le but de ce cas d’usage est de vérifier si un service de buanderie externe a la capacité requise pour nettoyer et remplacer, au besoin, le linge d’un restaurant une fois par semaine.

Public cible

Employés et clients d’un restaurant (qui utilisent le linge propre)

Acteurs

Employés de cuisine, serveurs, gérants, clients, service de buanderie

Acteur principal — service de buanderie

Objectif

Nettoyer les uniformes et le linge divers du restaurant chaque semaine

Conditions préalables

C’est un vendredi et il y a du linge sale dans le bac de la buanderie

Flux

Le flux de base pour cet exemple de cas d’usage est le suivant :

Le service de buanderie vient au restaurant le vendredi et collecte le linge sale.
De retour à la buanderie, le service trie le linge disponible.
Le service nettoie et sèche chaque charge.
Le service repasse les uniformes, les nappes et les serviettes de table.
Le service plie les articles qui doivent être pliés et accroche les autres sur des cintres.
Le service retourne le linge propre au restaurant le vendredi pour le service du soir.

Flux alternatifs :

Basse inventaire : Si un gérant signale une basse inventaire d’un item spécifique lors de la collecte, le service de buanderie ajoute la quantité d’items manquante aux items propres avant de retourner le linge au restaurant.
Vêtements encore sales : Le service de buanderie relave tout ce qu’elle trouve encore sale.

Flux exceptionnels :

Voici quelques exemples de flux exceptionnels :

Vêtement abîmé : Le service de buanderie trouve un item déchiré. Il le signale à un gérant qui décide de le réparer ou de le remplacer.
Machine en panne : La machine à laver est en panne. Le service de buanderie signale le bris (et le retard du service) au gérant du restaurant et initie la procédure de réparation.
Manque de linge propre avant le vendredi : Le gérant tente d’organiser un service additionnel pour le linge sale un autre jour de la semaine.

Conditions de sortie :

Le nombre d’items propres plus les nouveaux items est enregistré dans un registre avant que le linge quitte la buanderie.
Le gérant du restaurant signe le registre pour confirmer la réception du linge propre.

Exemple d'un projet informatique (un jeu d'aventure textuel)

Le programme est un jeu d’aventure textuel dans lequel vous vous promenez à la découverte d’objets. Les descriptions de chaque zone du jeu sont légèrement humoristiques, tout comme celles des objets que vous ramassez. Vous pouvez sauvegarder votre progression afin de ne pas avoir à collecter tous les objets depuis le début à chaque fois que vous jouez.

Public cible

Ce jeu pourrait intéresser les personnes qui n’aiment pas les jeux violents ou qui sont anxieuses car il n’y a pas de conflit dans le jeu, juste de la découverte.

La tranche d’âge est probablement celle des préadolescents et plus car l’interface textuelle nécessite beaucoup de lecture.

L’intégration de texte en couleur pourrait contribuer à rendre le programme plus lisible.

La version initiale est conçue uniquement en français, mais des versions futures pourraient être développées dans d’autres langues, comme l’anglais, car la plupart des informations textuelles sont stockées dans des fichiers extérieurs à la logique qui seraient faciles à traduire.

L’humour est une chose très personnelle et est lié à nos références culturelles, il peut donc ne pas être aussi efficace avec tout le monde. Encore une fois, il est susceptible de fonctionner mieux avec les préadolescents et les adolescents. Il doit plaire aux utilisateurs masculins et féminins, donc ne pas avoir de styles d’humour qui ne soient offensants pour aucun sexe.

Acteurs

Ceci peut être un jeu indépendant, alors les acteurs impliqués pour le réaliser sont juste le(s) développeur(s)/entrepreneur(s) et les utilisateurs.

Notre acteur principal est un adolescent de la 10e à la 12e année qui s’intéresse aux ordinateurs.

Objectif

L’utilisateur joue à un nouveau jeu.

Conditions préalables

L’utilisateur devra avoir accès à un ordinateur et à un interpréteur Python, soit localement, soit en ligne.

Flux de base

L’utilisateur lance le jeu → Les fichiers de données du jeu sont lus dans les structures de données de la mémoire du programme → Un message de bienvenue s’affiche à l’utilisateur et lui demande de charger une partie, de démarrer une nouvelle partie ou de quitter → l’utilisateur choisit une nouvelle partie → le nom du premier emplacement, la description, la navigation et d’autres options s’affichent avec une invite de saisie → l’utilisateur tape son choix → le jeu analyse le choix pour déterminer la nature de l’option et met à jour l’état du jeu en conséquence → … cela continue jusqu’à ce que l’utilisateur atteigne la fin du jeu → un message de sortie s’affiche à l’utilisateur → le programme se termine.

Flux alternatifs : sauvegarde et sortie

Il existe un emplacement dans le jeu où l’utilisateur peut aller pour sauvegarder et quitter le jeu avant de terminer.

S’il y va et choisit cette option → le jeu enregistre son inventaire dans un fichier → il ajoute également ce fichier à une liste de parties sauvegardées dans un fichier journal.

L’utilisateur relance le jeu et choisit l’option de chargement → les fichiers de données du jeu sont lus dans les structures de données de la mémoire du programme → le fichier de données utilisateur est lu en mémoire et l’état du jeu est mis à jour en conséquence → le joueur commence plus loin dans le jeu.

Blog sur le sujet du point de vue des gestionnaires de produit
Bridging the Gap : un site qui explique les cas d’usage en détail

Il y a un projet formatif en lien avec cette leçon. Voir les instructions dans le Classroom.

Introduction au génie informatique| ICS3U | M. Crowley

🛠️ Cas d’utilisation

Survol et attentes

Objectifs d’apprentissage

Critères de succès

But des cas d’usage

Comment rédiger un cas d’usage

Exemples

Public cible

Acteurs

Objectif

Conditions préalables

Flux

Public cible

Acteurs

Objectif

Conditions préalables

Flux de base

Flux alternatifs : sauvegarde et sortie

Flux alternatifs : quitter

Flux d’exception : saisie utilisateur non valide

Flux d’exception : données de jeu non valides

Conditions de sortie

Références additionnelles

Exercices

📚 Tester la compréhension

🛠️ Pratique

Keyboard shortcuts

Introduction au génie informatique| ICS3U | M. Crowley