Tâche: Détailler un cas d'utilisation
Cette tâche concerne la localisation des détails qui sont ajoutés à un cas d'utilisation spécifique.
Disciplines: Exigences
Objet

L'objet de cette tâche est de :

  • Décrire un ou plusieurs des flux d'événements du cas d'utilisation de manière suffisamment détaillée pour permettre au développement d'application de démarrer dessus.
  • Détailler le cas d'utilisation pour la compréhension et la satisfaction de l'acteur ou du client.
Relations
Etapes
Revue et amélioration des scénarios

Commencez par revoir et affiner les scénarios que vous utiliserez au cours du cycle de développement. Il est possible que des scénarios aient déjà été identifiés dans la Tâche : Identifier les acteurs et les cas d'utilisation. Dans ce cas, utilisez les scénarios mentionnés comme point de départ pour déterminer les éléments nécessaires à la description des flux.

Détail du flux d'événements

Lors de la Tâche : Identifier les acteurs et les cas d'utilisation, il se peut que vous ayez  déjà identifié le flux d'événements du cas d'utilisation. Utilisez cette description comme point de départ, et détaillez-la progressivement.

Les storyboards vous aideront à comprendre et à détailler les flux des cas d'utilisation. Un autre élément à prendre en compte est le prototype d'interface utilisateur, s'il en existe déjà un.

Décrivez les cas d'utilisation en fonction des standards définis pour le projet Pour des raisons de cohérence, déterminez les points suivants avant de commencer à décrire les cas d'utilisation :

  • Comment le cas d'utilisation commence-t-il ? Le début d'un cas d'utilisation doit décrire clairement le signal qui active ce cas. Vous pouvez écrire par exemple : "Le cas d'utilisation commence quand ... se produit".
  • Comment le cas d'utilisation se termine-t-il ? Vous devez indiquer clairement l'événement qui signale la fin du cas d'utilisation. Vous pouvez écrire par exemple : "Lorsque ... se produit, le cas d'utilisation se termine."
  • Comment le cas d'utilisation interagit-il avec les acteurs ? Pour réduire les risques de malentendu, indiquez précisément ce qui appartient au système et ce qui ne lui appartient pas. Structurez la description sous la forme d'une série de paragraphes, chacun décrivant une action de la manière suivante : "Lorsque l'acteur effectue ..., le système effectue..." Vous pouvez aussi souligner les interactions en décrivant les signaux échangés entre le cas d'utilisation et les acteurs, par exemple : Le cas d'utilisation commence lorsqu'il reçoit le signal "démarrer" de la part de l'opérateur.
  • Comment le cas d'utilisation échange-t-il des informations avec un acteur ? Si vous le souhaitez, vous pouvez faire référence aux arguments des signaux, mais il est peut-être préférable d'écrire, par exemple, "Le cas d'utilisation commence lorsque l'utilisateur se connecte au système en donnant son nom et son mot de passe".
  • Par quels mécanismes le cas d'utilisation répète-t-il certains comportements ? Dans la mesure du possible, exprimez cela en langage courant. Néanmoins, dans certains cas exceptionnels, il peut être utile d'utiliser des constructions de type code comme WHILE-END WHILE, IF-THEN-ELSE ou LOOP-END LOOP, si l'expression en langage courant s'avère difficile. Malgré tout, il est préférable d'éviter ce genre de construction dans les descriptions de cas d'utilisation, car elles sont difficiles à lire et à gérer.
  • Le flux d'événements du cas d'utilisation comporte-t-il des situations pour lesquelles différentes options sont possibles ? Parfois, l'acteur est confronté à un choix. Toutes ces situations doivent être présentées de manière identique. Par exemple :

    "L'acteur choisit l'une des options suivantes, une ou plusieurs fois :

    a) . . .

    b) . . .

    c) . . ." etc.

  • Comment le cas d'utilisation doit-il être décrit afin qu'il soit compréhensible pour le client et les utilisateurs ? L'utilisation d'une terminologie spécifique à une méthodologie donnée (par exemple, cas d'utilisation, acteur, signal, etc.) peut rendre le texte difficile à comprendre. Pour faciliter la compréhension, vous pouvez énumérer les actions ou opter pour une autre approche de ce type. Quelle que soit l'approche retenue, vous devez la définir dans les instructions relatives à la modélisation des cas d'utilisation, afin que vous l'ayez toujours à l'esprit tout au long du processus de description des cas d'utilisation.

Contentez-vous de décrire les opérations réalisées dans le cadre du cas d'utilisation, ne vous arrêtez pas sur la manière de résoudre les problèmes internes spécifiques au système. Ces détails seront abordés plus tard dans le cycle de vie, ne fournissez donc pas une description trop exhaustive à ce stade. Décrivez uniquement les éléments qui vous paraissent stables sur le long terme.

Si le flux d'événements d'un cas d'utilisation s'avère trop détaillé ou complexe, ou s'il vous semble présenter différentes parties indépendantes les unes des autres, scindez-le en plusieurs cas d'utilisation.

Pour la rédaction du texte de description, voir Produit : Glossaire. Au fur et à mesure de l'apparition de nouveaux concepts, intégrez dans le glossaire les nouveaux termes qui s'y rapportent. Ne changez jamais la définition d'un terme sans en informer au préalable les membres de l'équipe concernés.  Pour plus d'informations, voir  Tâche : Définir un vocabulaire commun.

Contenu de la description d'un flux d'événements

La description d'un flux d'événements doit répondre aux questions suivantes :

  • Comment et quand le cas d'utilisation commence-t-il ?
Exemple :

"Le cas d'utilisation peut commencer lorsque la fonction 'Administer Order' (Passer une commande) est activée par un utilisateur."

  • Quand le cas d'utilisation interagit-il avec les acteurs et quelles sont les données échangées ?
Exemple :

Pour créer une nouvelle commande, l'utilisateur active la fonction 'New' (Nouveau) puis spécifie les données obligatoires suivantes concernant la commande : nom, éléments réseau (au moins un) et type de fonction de mesure. Il est également possible de spécifier des données optionnelles concernant la commande : un commentaire (brève description textuelle). Ensuite, l'utilisateur active la fonction 'OK' et la nouvelle commande est créée dans le système.

Remarque : Vous devez être explicite concernant les données échangées entre les acteurs et le cas d'utilisation. Sinon, le client et les utilisateurs ne comprendront pas la description du cas d'utilisation.

  • Comment et quand le cas d'utilisation utilise-t-il les données stockées dans le système, ou stocke-t-il des données dans le système ?
Exemple :

L'utilisateur active la fonction 'Modify' (Modifier) pour modifier une commande existante et spécifie un numéro de commande (petit nombre entier). Ensuite, le système initialise un formulaire de commande avec le nom de la commande, ses éléments réseau et son type de fonction de mesure. Ces données sont extraites d'un périphérique de stockage secondaire.

  • Comment et quand le cas d'utilisation se termine-t-il ?
Exemple :

"Le cas d'utilisation se termine lorsque la fonction 'Exit' (Quitter) est activée par le demandeur".

Vous devez également décrire les flux d'événements spéciaux ou exceptionnels. Un flux exceptionnel est un sous-flot du cas d'utilisation qui ne correspond pas au comportement normal ou de base du cas d'utilisation. Toutefois, ce flux est nécessaire pour une description complète du comportement du cas d'utilisation. Un exemple de flux exceptionnel est donné dans le premier exemple. Si le cas d'utilisation reçoit des données inattendues (par exemple, si l'acteur n'est pas celui qui est prévu dans ce contexte particulier), il s'arrête automatiquement. Ces événements (acteur inattendu et fin prématurée) n'appartiennent pas au flux d'événements normal.

Les autres choses "à faire" ou "ne pas faire" dans le cadre de la description d'un cas d'utilisation sont les suivantes :

  • Décrivez le flux d'événements, et pas uniquement le fonctionnement et l'objet du cas d'utilisation.
  • Décrivez uniquement les flux qui appartiennent au cas d'utilisation concerné, et pas la structure des autres cas d'utilisation qui fonctionnent en parallèle.
  • Ne mentionnez pas les acteurs qui ne communiquent pas avec le cas d'utilisation en question.
  • Ne décrivez pas de manière trop détaillée les interactions du cas d'utilisation avec les acteurs.
  • Si l'ordre des sous-flux décrits pour le cas d'utilisation est sans importance, ne les présentez pas comme si leur ordre était important.
  • Utilisez les termes définis dans le glossaire commun et tenez compte des règles suivantes pour la rédaction :
  • Utilisez un vocabulaire simple. N'utilisez pas un terme complexe si un équivalent plus simple existe.
  • Ecrivez des phrases courtes et concises.
  • Evitez les adverbes (très, plus, assez, etc.).
  • Surveillez votre ponctuation.
  • Evitez les phrases complexes.

Pour plus d'informations, voir Instructions : Cas d'utilisation ainsi que les considérations sur  le contenu et   le style du flux d'événements.

Etablissement de la structure du flux d'événements

Le flux d'événements d'un cas d'utilisation peut être décomposé en plusieurs sous-flux. Lorsque le cas d'utilisation est activé, les sous-flux peuvent se combiner de différentes manières si les conditions suivantes sont réunies :

  • Le cas d'utilisation peut suivre différents chemins en fonction des informations saisies par un acteur donné ou des valeurs de certains attributs ou objets. Par exemple, un acteur peut choisir l'étape suivante parmi plusieurs options, ou le flux d'événements peut être différent selon qu'une valeur est supérieure ou inférieure à un chiffre donné.
Exemple :

Une partie de la description du cas d'utilisation Retrait d'argent pour un distributeur automatique peut être la suivante : "La somme d'argent que le client souhaite retirer est comparée au solde du compte concerné". Si cette somme excède le solde du compte, le client en est informé et le cas d'utilisation se termine. Sinon, la somme demandée est retirée du compte.

  • Le cas d'utilisation peut exécuter certains sous-flux dans un ordre différent.
  • Le cas d'utilisation peut exécuter plusieurs sous-flux en même temps.

Vous devez décrire tous ces flux optionnels et alternatifs. Il est recommandé de décrire chaque sous-flot dans un supplément distinct ajouté à la section flux d'événements ; cette approche est obligatoire dans les cas suivants :

  • Sous-flux qui constituent une part importante d'un flux d'événements.
  • Flux d'événements exceptionnels. Cela permet de mieux mettre en lumière le flux d'événements normal.
  • Sous-flux exécutés à intervalles réguliers dans le cadre d'un même flux d'événements.

En revanche, si un sous-flot constitue une infime partie d'un flux d'événements, il est préférable de le décrire dans le corps du texte.

Exemple :

"Ce cas d'utilisation est activé lorsque la fonction 'administer order' est appelée par l'un des acteurs Demandeur ou Administrateur de la gestion des performances. Si le signal ne provient pas de l'un de ces acteurs, le cas d'utilisation annule l'opération et affiche un message approprié à l'utilisateur. En revanche, si l'acteur est reconnu, le cas d'utilisation poursuit en..."

Vous pouvez illustrer la structure du flux d'événements par un diagramme d'activité : voir Instructions : Diagramme d'activité dans le modèle du cas d'utilisation.  

Pour plus d'informations, voir la section sur la structure dans Instructions : Cas d'utilisation.

Illustration des relations avec les acteurs et les autres cas d'utilisation

Créez des diagrammes illustrant le cas d'utilisation et ses relations avec les acteurs et les autres cas d'utilisation. Un diagramme de ce type est considéré comme un diagramme appartenant au cas d'utilisation, et doit donc lui être associé. Notez que ce type de diagramme spécifique à un cas d'utilisation n'est généralement pas d'une grande utilité, sauf si certaines relations du cas d'utilisation avec d'autres éléments méritent d'être explicitées, ou encore en cas de complexité inhabituelle concernant le rôle des différents acteurs.

Pour plus d'informations, voir Instructions : Diagramme de cas d'utilisation.

Description des exigences particulières

Toute exigence liée au cas d'utilisation mais qui n'est pas mentionnée dans le flux d'événements du cas d'utilisation, doit être décrite dans les exigences spécifiques du cas d'utilisation. Généralement, ces exigences ne sont pas fonctionnelles.

Pour plus d'informations, voir la section sur les exigences particulières dans Instructions : Cas d'utilisation.

Définition de protocole(s) de communication

Définissez le protocole de communication pour chaque acteur lorsqu'il s'agit d'un autre système ou d'un matériel extérieur. S'il s'agit d'un protocole existant (par exemple un protocole reconnu ou standard), la description du cas d'utilisation peut se contenter de nommer ce protocole. S'il s'agit d'un nouveau protocole, vous devez indiquer où se trouve la description de ce protocole, car elle sera nécessaire lors du développement du modèle d'objet.

Description des conditions préalables

Les conditions préalables décrivent l'état dans lequel le système doit se trouver pour que le cas d'utilisation puisse commencer.

Exemple :

Pour qu'un distributeur automatique puisse délivrer de l'argent, les conditions préalables suivantes doivent être remplies :

  • Le réseau doit être accessible.
  • Le distributeur doit être prêt à traiter des transactions.
  • Le distributeur doit disposer de suffisamment d'argent pour répondre aux demandes.
  • Le distributeur doit disposer de suffisamment de papier pour imprimer un reçu pour au moins une transaction.

Ces conditions préalables peuvent s'appliquer par exemple au cas d'utilisation Retrait d'argent.

N'oubliez pas de décrire l'état du système. Evitez de décrire en détail d'autres tâches accessoires qui ont eu lieu avant le cas d'utilisation.

Les conditions préalables n'ont pas pour objet de créer une séquence de cas d'utilisation. Vous ne rencontrerez jamais de cas nécessitant l'exécution d'un premier cas, puis d'un deuxième, afin d'obtenir un flux d'événements significatif. Si vous avez l'impression d'être arrivé à ce type de situation, cela signifie probablement que vous avez trop décomposé le modèle de cas d'utilisation. Corrigez ce problème en combinant les cas d'utilisation interdépendants pour constituer un seul cas d'utilisation. Si cela rend le   cas d'utilisation trop complexe, vous pouvez utiliser des techniques permettant de structurer les cas d'utilisation, comme celles présentées au paragraphe  Etablissement de la structure du flux d'événements du cas d'utilisation ou dans la Tâche : Structurer le modèle de cas d'utilisation.

Pour plus d'informations, voir la section sur les conditions préalables dans Instructions : Cas d'utilisation.

Description des post-conditions

Les post-conditions indiquent les différents états dans lesquels le système peut se trouver à l'issue du cas d'utilisation. Le système doit impérativement se trouver dans l'un des états mentionnés une fois l'exécution du cas d'utilisation terminée. Cette section décrit également les actions effectuées par le système à l'issue du cas d'utilisation, quel que soit le déroulement du cas d'utilisation.

Exemple :

Si le distributeur automatique affiche systématiquement le message 'Bienvenue' à l'issue de chaque cas d'utilisation, cela peut être indiqué dans les post-conditions.

De la même manière, si le distributeur automatique ferme toujours la transaction client à l'issue d'un cas d'utilisation de type Retrait d'argent, et ce quels que soient les événements qui se sont produits, cela doit être mentionné dans les post-conditions.

Les post-conditions permettent de réduire la complexité et d'améliorer la lisibilité du flux d'événements d'un cas d'utilisation.

Les post-conditions n'ont pas pour objet de créer une séquence de cas d'utilisation. Vous ne rencontrerez jamais de cas nécessitant l'exécution d'un premier cas, puis d'un deuxième, afin d'obtenir un flux d'événements significatif. Si vous avez l'impression d'être arrivé à ce type de situation, vous devez combiner les cas d'utilisation interdépendants pour constituer un seul cas d'utilisation. Si cela rend le cas d'utilisation trop complexe, vous pouvez utiliser des techniques permettant de structurer les cas d'utilisation, comme celles présentées au paragraphe Etablissement de la structure du flux d'événements du cas d'utilisation ci-dessus, ou dans la Tâche : Structurer le modèle de cas d'utilisation.

Pour plus d'informations, voir la section sur les post-conditions dans Instructions : Cas d'utilisation.

Description des points d'extension

Si le cas d'utilisation doit être complété par un autre cas d'utilisation (voir Instructions : Relations d'extension), vous devez décrire les points d'extension (voir la section sur les points d'extension dans Instructions : Cas d'utilisation).

Evaluation de vos résultats

Revoyez le cas d'utilisation avec les parties prenantes, afin qu'elles en aient une vision claire et qu'elles soient d'accord sur sa description.

Une description de cas d'utilisation n'est complète que si elle décrit toutes les actions que le cas d'utilisation exécute, implémente ou permet, depuis le début jusqu'à la fin. Avant de terminer, assurez-vous que la description affiche toutes les caractéristiques d'un "bon" cas d'utilisation. Pour plus d'informations, voir Liste de contrôle : Cas d'utilisation.

Considérations clés
Lorsque vous détaillez un cas d'utilisation, en particulier pour prendre en charge sa revue, vous pouvez, si vous le souhaitez, générer une spécification de cas d'utilisation. Pour plus d'informations, voir les rapports, les canevas, les exemples et les guides d'utilisation de l'outil pour construire des rapports, qui sont associés au produit : cas d'utilisation.
Plus d'informations