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 :
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
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.
|
|