Objet
  • Décrire un ou plusieurs flots d'événements du cas d'utilisation de manière suffisamment détaillée pour permettre de démarrer le développement logiciel.
  • Décrire les spécifications du cas d'utilisation d'une manière qui convienne à l'acteur ou au client.
Rôle :  Spécificateur d'exigences 
Fréquence : A chaque itération, pour chaque cas d'utilisation ou flot de cas d'utilisation décrit dans l'itération 
Etapes
Plus d'informations : 
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   

Détails sur l'enchaînement des activités :   

Revoir et affiner les scénarios Haut de la page

Commencez par revoir et affiner les scénarios que vous utiliserez au cours du développement. Il est possible que des scénarios aient déjà été identifiés dans Activité : 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 flots.

Les storyboards vous aideront également à comprendre et à détailler les flots 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étailler le flot d'événements Haut de la page

Vous devez déjà disposer d'une description générale, étape par étape, du flot d'événements du cas d'utilisation. Cet élément est également créé dans Activité : Identifier les acteurs et les cas d'utilisation. Utilisez cette description générale comme point de départ, et détaillez-la progressivement.

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. Par exemple, vous pouvez écrire : "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. Par exemple, vous pouvez écrire : "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. Vous pouvez structurer cette description sous la forme d'une série de paragraphes qui décrivent une action de la manière suivante : "Lorsque l'acteur effectue ..., le système effectue ....". Vous pouvez également 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 'start' 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. Toutefois, dans certains cas exceptionnels, vous pouvez être amené à 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 flot 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 le document décrivant les principes et conseils généraux applicables à 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. Lorsque vous aborderez les modèles objet, vous serez amené à compléter cette description en indiquant le fonctionnement détaillé : abstenez-vous donc de fournir une description trop exhaustive à ce stade. Décrivez uniquement les éléments qui vous paraissent stables sur le long terme.

Si le flot 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, référez-vous au 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.

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

La description d'un flot 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 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' (Nouvelle) et spécifie les informations obligatoires suivantes : 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 flots d'événements spéciaux ou exceptionnels. Un flot 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 flot est nécessaire pour une description complète du comportement du cas d'utilisation. Un exemple de flot 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 flot 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 flot d'événements, et pas uniquement le fonctionnement et l'objet du cas d'utilisation.
  • Décrivez uniquement les flots 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-flots 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 Principes et conseils : Cas d'utilisation, ainsi que les considérations sur le contenu et le style pour les flots d'événements.

Structure du flot d'événements Haut de la page

Le flot d'événements d'un cas d'utilisation peut être décomposé en plusieurs sous-flots. Lorsque le cas d'utilisation est activé, les sous-flots 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 flot 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-flots dans un ordre différent.
  • Le cas d'utilisation peut exécuter plusieurs sous-flots en même temps.

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

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

En revanche, si un sous-flot constitue une infime partie d'un flot 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 flot d'événements par un diagramme d'activité : voir Principes et conseils : Diagramme d'activités dans le modèle de cas d'utilisation.

Pour plus d'informations, voir Principes et conseils : Cas d'utilisation, structure du flot d'événements.

Illustrer les relations avec les acteurs et les autres cas d'utilisation Haut de la page

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 Principes et conseils : Diagramme de cas d'utilisation.

Décrire les éventuelles exigences spécifiques Haut de la page

Toute exigence liée au cas d'utilisation mais qui n'est pas mentionnée dans le flot 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 Principes et conseils : Cas d'utilisation, exigences spécifiques.

Définir le(s) protocoles()s de communication Haut de la page

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.

Décrire les conditions préalables Haut de la page

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étails les activités 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 flot 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 Structurer le flot d'événements du cas d'utilisation ci-dessus, ou dans Activité : Structurer le modèle de cas d'utilisation.

Pour plus d'informations, voir Principes et conseils : Cas d'utilisation, conditions préalables et post-conditions.

Décrire les post-conditions Haut de la page

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 flot 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 flot 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 Structurer le flot d'événements du cas d'utilisation ci-dessus, ou dans Activité : Structurer le modèle de cas d'utilisation.

Pour plus d'informations, voir Principes et conseils : Cas d'utilisation, conditions préalables et post-conditions.

Décrire les points d'extension Haut de la page

Si le cas d'utilisation doit être complété par un autre cas d'utilisation (voir Principes et conseils : Relation d'extension), vous devez décrire les points d'extension (voir Principes et conseils : Cas d'utilisation, points d'extension).

Evaluer vos résultats Haut de la page

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 valider votre description, assurez-vous qu'elle affiche toutes les caractéristiques d'un "bon" cas d'utilisation. Voir les points de contrôle concernant les cas d'utilisation et les rapports de cas d'utilisation dans Activité : Revoir les exigences.



RUP (Rational Unified Process)   2003.06.15