• 20 heures
  • Facile

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

Ce cours est diplômant et vous permet d'obtenir des crédits universitaires européens (ECTS).

J'ai tout compris !

Mis à jour le 22/02/2019

La description textuelle d’un cas d’utilisation

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Dans ce chapitre, nous allons découvrir l’utilité de décrire les scénarios des cas d’utilisation, ainsi que les éléments nécessaires à la description du déroulement des d’actions.

Définition

Les diagrammes réalisés jusqu’à maintenant (diagramme de contexte, diagramme de packages, diagramme de cas d’utilisation) nous ont permis de découvrir petit à petit les fonctionnalités (appelées aussi des cas d’utilisation) que l’on devrait avoir dans le futur logiciel.

Nous allons désormais parler de l’interaction entre les acteurs et le système : il s’agit de décrire la chronologie des actions qui devront être réalisées par les acteurs et par le système lui-même. On parle d’ailleurs de scénarios.

La description d’un cas d’utilisation permet de :

  • clarifier le déroulement de la fonctionnalité ;

  • décrire la chronologie des actions qui devront être réalisées ;

  • d’identifier les parties redondantes pour en déduire des cas d’utilisation plus précises qui seront utilisées par inclusion, extension ou généralisation/spécialisation. Et oui, dans ce cas nous réaliserons des itérations sur les diagrammes de cas d’utilisation ;

  • d’indiquer d’éventuelles contraintes déjà connues et dont les développeurs vont devoir tenir compte lors de la réalisation du logiciel. Ces contraintes peuvent être de nature diverse.

Décrire le déroulement des actions pour un cas d’utilisation peut vous paraître simple, mais c’est un travail qui demande beaucoup de réflexion et de questionnement. On commence souvent par une première description, basée sur les informations que l’on a obtenu auprès du client et/ou des futurs utilisateurs. Lors de la réalisation de cette première description, on découvre souvent des questions auxquels nous n’avons pas de réponse.

Par exemple :
Si une personne n’est pas encore « cliente » sur la boutique en ligne et qu’elle souhaite réaliser un achat :

  • Doit elle s’incrire avant de commencer la procédure d’achat ?

  • Peut-elle s’inscrire pendant la procédure d’achat, par exemple juste avant de régler ?

Nous pouvons, bien sûr, avoir une idée sur la question. On se base d’ailleurs souvent sur des situations déjà vues ou vécues pour faire des propositions au client et aux utilisateurs.

Oui, j’ai bien dit : faire des propositions. Il ne s’agit pas de décrire ce que nous pensons être mieux, mais plutôt ce que le client et les utilisateurs souhaitent. Nos idées ne sont donc que des possibilités qu’il faut soumettre aux personnes concernées afin d’engager une communication, dans le but de découvrir les réels besoins.

On réalise alors une fiche descriptive pour chaque cas d’utilisation, de façon à raconter l’histoire du déroulement des différentes actions.

Cette fiche descriptive doit comporter 4 volets :

  1. L’identification

  2. La description des scénarios

  3. La fin et les post-conditions

  4. Les compléments

Le schéma suivant illustre la relation entre le diagramme des cas d’utilisation et la description textuelle d’un cas d’utilisation.

Diagramme des cas d’utilisation + Description textuelle

Description textuelle d’un cas d’utilisation simple

Nous allons d’abord nous intéresser à un cas d’utilisation simple (sans relation avec d’autres cas d’utilisation), par exemple : « Consulter catalogue produits ». À partir de la dernière version du diagramme de cas d’utilisation du package « Gestion des achats », nous verrons comment cela devrait se faire en pratique.

Prêt ? Allons-y, réalisons ensemble la fiche descriptive du cas d’utilisation « Consulter catalogue produits » visible ci-dessous.

 

Le diagramme de cas d’utilisation du packages « Gestion des achats »

Volet 1 : L’identification

Dans le volet identification, on indique :

  • Le numéro du cas d’utilisation, de façon aléatoire. Cela permet ensuite de les classer plus facilement ;

  • le nom du cas d’utilisation (avec indication du package) ;

  • l’acteur (ou les acteurs) s’il s’agit d’un cas d’utilisation principal ou le nom du cas d’utilisation principal lorsqu’il s’agit d’un cas d’utilisation interne ;

  • une description succincte du cas d’utilisation ;

  • la date de rédaction de la fiche et l’auteur, voire éventuellement les dates de mise à jour et les auteurs successifs ;

  • les pré-conditions : il s’agit des conditions obligatoires au bon déroulement du cas d’utilisation. Par exemple, nous avons vu dans le chapitre précédent qu’il fallait obligatoirement s’authentifier avant même de pouvoir « Consulter le catalogue produit ». Dans le cas, le package « Authentification » est une pré-condition ;

  • les événements à l’origine du démarrage du cas d’utilisation ;

Voici donc comment la fiche descriptive débuterait pour notre cas d’utilisation « Consulter catalogue produit » :

Cas n° 1

Nom : Consulter catalogue produit (package « Gestion des achats »)
Acteur(s) : Acheteur (client ou commercial)
Description : La consultation du catalogue doit être possible pour un client ainsi que pour les commerciaux de l’entreprise.
Auteur : Carina Roels
Date(s) : 10/11/2013 (première rédaction)

Pré-conditions : L’utilisateur doit être authentifié en tant que client ou commercial (Cas d’utilisation « S’authentifier » – package « Authentification »)
Démarrage : L’utilisateur a demandé la page « Consultation catalogue »

 

Volet 2 : La description des scénarios (ou dialogue)

Nous allons maintenant décrire les scénarios qui explicitent la chronologie des actions qui seront réalisées par l’utilisateur et le système. Il existe 3 parties :

  • Le scénario nominal 
    Il s’agit ici de décrire le déroulement idéal des actions, où tout va pour le mieux.

  • Les scénarios alternatifs 
    Ici, il s’agit de décrire les éventuelles étapes différentes liées aux choix de l’utilisateur, par exemple. C’est le cas des étapes liées à des conditions.

  • Les scénarios d’exception
    On parlera de scénario d’exception lorsque une étape du déroulement pourrait être perturbée à cause d’un événement anormal. Par exemple, lorsqu’une recherche de client ne trouve aucun client correspondant aux critères fournis.

Les scénarios mettent en évidence les interactions entre les actions de l’utilisateur et le système (le logiciel). Cela peut se faire par une liste numérotée d’actions ou sous forme de tableau qui démontre clairement ce qui est réalisé par l’utilisateur et ce qui est du ressort du système.

La représentation de ces scénarios vous est personnelle. Ici, nous avons choisi de vous proposer une description textuelle, en listant le déroulement du scénario nominal par des chiffres (1, 2, 3…) et les scénarios alternatif et d’exception par des lettres rattachées aux numéros de l’action principale (1a, 1b, 2a, 2b…).

Exemple : Description détaillée du cas d’utilisation « Consulter catalogue produits » (Package « Gestion des achats »).

Pour rappel, la description initiale du projet indiquait qu’un acheteur doit avoir la possibilité de consulter le catalogue des produits. Aucune information supplémentaire n’avait été fournie quant à cette consultation. Il nous appartient donc de poser les bonnes questions au client et aux éventuels futurs utilisateurs pour décrire le scénario nominal. Nous pouvons supposer que notre site de vente en ligne doive permettre une consultation du catalogue de produits, par catégorie.

Le scénario nominal 

1. Le système affiche une page contenant la liste les catégories de produits.
2. L’utilisateur sélectionne une des catégories.
3. Le système recherche les produits qui appartiennent à cette catégorie.
4. Le système affiche une description et une photo pour chaque produit trouvé.                                           
5. L’utilisateur peut sélectionner un produit parmi ceux affichés.
6. Le système affiche les informations détaillées du produit choisi.
7. L’utilisateur peut ensuite quitter cette description détaillée.
8. Le système retourne à l’affichage des produits de la catégorie (retour à l’étape 4)

Les scénarios alternatifs

2.a L’utilisateur décide de quitter la consultation de la catégorie de produits choisie.
2.b L’utilisateur décide de quitter la consultation du catalogue.
5.a L’utilisateur décider de quitter la consultation de la catégorie de produits choisie.                                  
5.b L’utilisateur décide de quitter la consultation du catalogue.
7.a L’utilisateur décide de quitter la consultation de la catégorie de produits choisie.
7.b L’utilisateur décide de quitter la consultation du catalogue.

 

Volet 3 : La fin et les post-conditions

Le 3e volet d’une description détaillée d’un cas d’utilisation concerne :

  • la fin du cas d’utilisation ;

  • les post-conditions.

La fin permet de récapituler toutes les situations d’arrêt du cas d’utilisation. Cela permet parfois de s’apercevoir que l’on n’a pas vu tous les cas de figure qui peuvent se présenter.

Par exemple, notre cas d’utilisation peut s’arrêter aux étapes 2, 5 et 7 car l’utilisateur peut décider de quitter la consultation du catalogue pour revenir à l’accueil par exemple.

Les post-conditions nous indiquent un résultat tangible qui est vérifiable après l’arrêt du cas d’utilisation et qui pourra témoigner du bon fonctionnement. Cela pourrait être une information qui a été enregistrée dans une base de données ou dans un fichier, ou encore un message envoyé par mail, etc.

Par exemple, ici il n’y en a pas car la consultation du catalogue ne donne pas lieu à l’enregistrement d’informations dans un fichier ou une base de données.

Voici le volet 3 de notre cas d’utilisation « Consulter catalogue produits ».

Fin : Scénario nominal : aux étapes 2, 5 ou 7, sur décision de l’utilisateur                                                            

Post-conditions : Aucun

Oui, il est vrai que ce cas d’utilisation est tellement simple que nous n’ayons pas grand-chose à indiquer. Il n’y a pas de post-conditions, puisqu’il ne restera pas de preuve tangible du bon fonctionnement du cas d’utilisation. Mais ne vous inquiétez pas, nous verrons un exemple un peu plus fourni dans pas longtemps.

Volet 4 : Les compléments

Les compléments peuvent porter sur des sujets variés :

  • l’ergonomie ;

  • la performance attendue ;

  • des contraintes (techniques ou non) à respecter ;

  • des problèmes non résolus (ou questions à poser au client et aux futurs utilisateurs).

Vous avez une petite idée des compléments qu’on pourrait indiquer pour le cas d’utilisation « Consulter catalogue produits » ? Voyons si nous avons eue la même idée.

Ergonomie 

L’affichage des produits d’une catégorie devra se faire par groupe de 15 produits. Toutefois, afin d’éviter à l’utilisateur d’avoir à demander trop de pages, il devra être possible de choisir des pages avec 30, 45 ou 60 produits.

Performance attendue 

La recherche des produits, après sélection de la catégorie, doit se faire de façon à afficher la page des produits en moins de 10 secondes.

Problèmes non résolus 

Nous avons fait la description basée sur l’information que les produits appartiennent à une catégorie. Est-ce qu’il existe des sous-catégories ?
Si tel est le cas, la description devra être revue.

Est-ce que la consultation du catalogue doit être possible uniquement par catégorie ou est-ce qu’on doit prévoir d’autres critères de recherche de produits ?

Doit-on prévoir un affichage trié sur des critères choisis par l’utilisateur (par exemple : par tranche de prix, par disponibilité, etc) ?

Bon, nous avons vu les 4 volets d’une fiche descriptive d’un cas d’utilisation. Voici la synthèse de notre première fiche.

Cas n°1

Nom : Consulter catalogue produit (package « Gestion des achats »)
Acteur(s) : Acheteur (client ou commercial)
Description : La consultation du catalogue doit être possible pour un client ainsi que pour les commerciaux de l’entreprise.
Auteur : Carina Roels
Date(s) : 10/11/2013 (première rédaction)

Pré-conditions : L’utilisateur doit être authentifié en tant que client ou commercial (Cas d’utilisation « S’authentifier » – package « Authentification »)
Démarrage : L’utilisateur a demandé la page « Consultation catalogue »

DESCRIPTION

Le scénario nominal :

1. Le système affiche une page contenant la liste les catégories de produits. 
2. L’utilisateur sélectionne une des catégories.
3. Le système recherche les produits qui appartiennent à cette catégorie.
4. Le système affiche une description et une photo pour chaque produit trouvé.
5. L’utilisateur peut sélectionner un produit parmi ceux affichés.
6. Le système affiche les informations détaillées du produit choisi. 
7. L’utilisateur peut ensuite quitter cette description détaillée.
8. Le système retourne à l’affichage des produits de la catégorie (retour à l’étape 4)

Les scénarios alternatifs

2.a L’utilisateur décide de quitter la consultation de la catégorie de produits choisie. 
2.b L’utilisateur décide de quitter la consultation du catalogue. 
5.a L’utilisateur décider de quitter la consultation de la catégorie de produits choisie.
5.b L’utilisateur décide de quitter la consultation du catalogue.
7.a L’utilisateur décide de quitter la consultation de la catégorie de produits choisie.
7.b L’utilisateur décide de quitter la consultation du catalogue.

Fin : Scénario nominal : aux étapes 2, 5 ou 7, sur décision de l’utilisateur

Post-conditions : Aucun

COMPLEMENTS

Ergonomie 

L’affichage des produits d’une catégorie devra se faire par groupe de 15 produits. Toutefois, afin d’éviter à l’utilisateur d’avoir à demander trop de pages, il devra être possible de choisir des pages avec 30, 45 ou 60 produits.

Performance attendue 

La recherche des produits, après sélection de la catégorie, doit se faire de façon à afficher la page des produits en moins de 10 secondes.

Problèmes non résolus 

Nous avons fait la description basée sur l’information que les produits appartiennent à une catégorie. Est-ce qu’il existe des sous-catégories ?

Si tel est le cas, la description devra être revue.

Est-ce que la consultation du catalogue doit être possible uniquement par catégorie ou est-ce qu’on doit prévoir d’autres critères de recherche de produits ?

Doit-on prévoir un affichage trié sur des critères choisis par l’utilisateur (par exemple : par tranche de prix, par disponibilité, etc) ?

Je pense que nous sommes prêts à découvrir comment on décrit un cas d’utilisation qui a de nombreuses relations avec d’autres cas d’utilisation. C’est ce que nous allons faire dans la prochaine section.

Les cas d’utilisation complexes

Lors de la description textuelle de cas d’utilisation, vous aurez parfois des cas plus complexes que ce que nous venons de voir. Il s’agit dans ce cas souvent de cas d’utilisation dont le scénario renvoie vers d’autre cas d’utilisation. Les fameux cas d’utilisation internes !

Je vous propose d’illustrer ce point par le cas suivant : « enregistrer un achat ». La particularité de ce cas d’utilisation est qu’il soit lié à plusieurs autres cas d’utilisation avec des relations « include » et « extend ».

L’identification

Cas n° 2

Nom : Enregistrer un achat (package « Gestion des achats »)
Acteur(s) : Acheteur (client ou commercial)
Description : L’enregistrement d’un achat doit pouvoir être utilisé en ligne, par un client ainsi que par les commerciaux de l’entreprise. L’enregistrement comprend les produits demandés et le règlement de l’achat.
Auteur : Carina Roels
Date(s) : 10/11/2013 (première rédaction)

Pré-conditions : L’utilisateur doit être authentifié en tant que client ou commercial (Cas d’utilisation « S’authentifier » – package « Authentification »)
Démarrage : L’utilisateur a demandé la page « Enregistrer des achats »

Description des scénarios

Description détaillé de « Enregistrer un achat » du package « Gestion des achats ».

Le scénario nominal

1. Le système vérifie le type d’utilisateur connecté (si commercial ou client)
2. Si l’utilisateur est le commercial, le système fait appel au cas d’utilisation interne « sélectionner un client »
3. Le système affiche des informations concernant le client
4. Le système fait appel au cas d’utilisation interne « Constituer panier »
5. Le système fait appel au cas d’utilisation interne « Saisir information pour livraison»
6 Le système fait appel au cas d’utilisation interne « Enregistrer le règlement»
7. Le système enregistre définitivement l’achat
8. Le système affiche le récapitulatif de l’achat.

Les scénarios d’exception

2.a Le système n’affiche aucun utilisateur sélectionné.
Il affiche « Veuillez sélectionner le client concerné par l’achat » (retour à l’étape 2)
6.a L’enregistrement du règlement n’a pas réussi.
Le système récapitule les informations dans un message qui est envoyé au département commercial. (Arrêt du cas d’utilisation)
7.a L’enregistrement définitif de l’achat n’a pas réussi.
Le système récapitule les informations dans un message qui est envoyé au département commercial. (Arrêt du cas d’utilisation)

Nous pensions que ce cas d’utilisation était complexe, à cause des différentes relations avec les autres cas d’utilisation. En réalité, la description est assez simple. Il a suffi d’indiquer l’ordre dans lequel les autres cas d’utilisation seront utilisés.

Nous pouvons constater que l’utilisateur n’intervient pas du tout dans le cas d’utilisation principal. Les interactions entre l’utilisateur et le système seront précisées dans les descriptions des cas d’utilisation internes.

On a beaucoup parlé des relations de type « include » et une relation de type « extend », mais je ne les vois pas clairement dans la description. Comment on les distingue ?

Rappelez-vous qu’une relation de type « extend » est soumise à une condition. Nous l’avions d’ailleurs indiqué dans le diagramme de cas d’utilisation : le point d’extension.

Dans la fiche descriptive, cela se traduit par une indication de la condition et du cas d’utilisation lié : Si l’utilisateur est commercial, le système fait appel au cas d’utilisation « Sélectionner client ». Cela signifie que les actions du cas d’utilisation « Sélectionner un client » seront déroulées avant de poursuivre avec les autres étapes, uniquement si l’utilisateur connecté est commercial.

Une relation de type « include » est indiquée par une simple indication du cas d’utilisation lié. Par exemple : Le système fait appel au cas d’utilisation « Constituer panier.
Les actions du cas d’utilisation « Constituer panier » seront donc toujours déroulées à cet endroit, avant de poursuivre avec les autres étapes.

Fin et post-conditions

Fin 

  • Scénario nominal : sur décision de l’utilisateur, après le point 8 (affichage du récapitulatif de l’achat)

  • Scénario d’exception : après le point 6 ou 7, si l’enregistrement du règlement ou de l’achat définitif ne réussit pas.

Post-conditions 

  • Scénario nominal : l’achat et son règlement ont été enregistrés en base de données.

  • Scénario d’exception : l’achat a été récapitulé dans un message et a été envoyé au service commercial de l’entreprise.

La fin et les post-conditions sont ici différentes dans le scénario nominal et dans les scénarios d’exception.

On constate que dans le scénario nominal, le cas d’utilisation aura produit un résultat tangible : l’achat et le règlement auront été enregistrés en base de données.
Pour les scénarios d’exception, le résultat serait un envoi de message au service commercial avec un récapitulatif de l’achat qui n’a pas abouti.

Les compléments

Ergonomie 

L’enregistrement d’un achat doit pouvoir se faire avec un maximum de 3 pages. Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtres pop-up.

Problèmes résolus 

Nous avons décrit le cas où un utilisateur est soit un commercial, soit un client connu (indiqué par la pré-condition). Est-ce bien ainsi que cela devra fonctionner ? Serait-il envisageable de dérouler l’ensemble des actions lié à la constitution du panier avant de s’enregistrer comme client ?

Voici la synthèse de notre deuxième fiche.

Cas n° 2

Nom : Enregistrer un achat (package « Gestion des achats »)

Acteur(s) : Acheteur (client ou commercial)
Description : L’enregistrement d’un achat doit pouvoir être utilisé en ligne, par un client ainsi que par les commerciaux de l’entreprise. L’enregistrement comprend les produits demandés et le règlement de l’achat.
Auteur : Carina Roels
Date(s) : 10/11/2013 (première rédaction)

Pré-conditions : L’utilisateur doit être authentifié en tant que client ou commercial (Cas d’utilisation « S’authentifier » – package « Authentification »)
Démarrage : L’utilisateur a demandé la page « Enregistrer des achats »

DESCRIPTION

Le scénario nominal

1. Le système vérifie le type d’utilisateur connecté (si commercial ou client)
2. Si l’utilisateur est le commercial, le système fait appel au cas d’utilisation interne « sélectionner un client »
3. Le système affiche des informations concernant le client
4. Le système fait appel au cas d’utilisation interne « Constituer panier »
5. Le système fait appel au cas d’utilisation interne « Saisir information pour livraison»
6. Le système fait appel au cas d’utilisation interne « Enregistrer le règlement»
7. Le système enregistre définitivement l’achat
8. Le système affiche le récapitulatif de l’achat.

Les scénarios d’exception

2.a Le système n’affiche aucun utilisateur sélectionné. 
Il affiche « Veuillez sélectionner le client concerné par l’achat » (retour à l’étape 2)
6.a L’enregistrement du règlement n’a pas réussi. 
Le système récapitule les informations dans un message qui est envoyé au département commercial. (Arrêt du cas d’utilisation)
7.a L’enregistrement définitif de l’achat n’a pas réussi. 
Le système récapitule les informations dans un message qui est envoyé au département commercial. (Arrêt du cas d’utilisation)

Fin :

  • Scénario nominal : sur décision de l’utilisateur, après le point 8 (affichage du récapitulatif de l’achat)

  • Scénario d’exception : après le point 6 ou 7, si l’enregistrement du règlement ou de l’achat définitif ne réussit pas.

Post-conditions :

  • Scénario nominal : l’achat et son règlement ont été enregistrés en base de données.

  • Scénario d’exception : l’achat a été récapitulé dans un message et a été envoyé au service commercial de l’entreprise.

COMPLEMENTS

Ergonomie 

L’enregistrement d’un achat doit pouvoir se faire avec un maximum de 3 pages. Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtres pop-up.

Problèmes résolus 

Nous avons décrit le cas où un utilisateur est soit un commercial, soit un client connu (indiqué par la pré-condition). Est-ce bien ainsi que cela devra fonctionner ? Serait-il envisageable de dérouler l’ensemble des actions lié à la constitution du panier avant de s’enregistrer comme client ?

Voilà, nous avons constitué les fiches descriptives de deux cas d’utilisation pas à pas. Vous pouvez consulter les fiches complètes en annexe 1.

Je vous entends penser « Mais, il faut faire cela pour tous les cas d’utilisation ? C’est énormément de travail ! ».

Laissez-moi de nouveau vous répondre par analogie. Si l’architecte en charge de votre projet de construction d’une maison se contentait de faire seulement une partie des plans avant de lancer les travaux, seriez-vous satisfait ?

Je parie que non !

 

Exemple de certificat de réussite
Exemple de certificat de réussite