L'atelier de cas d'utilisation est une réunion de brain-storming organisée. Une large gamme de connaissances doit être représentée :
-
Exigences du client
-
Conception du système
-
Conception de l'unité
-
Rational Unified Process
-
Test
Ceci signifie que le groupe sera composé de personnes aux expériences et connaissances diverses. Essayez de faire de
petits groupes (moins de dix). La façon habituelle de procéder est de réunir la moitié du groupe à partir de l'équipe
de développement et l'autre moitié à partir de représentants des utilisateurs. Le facilitateur est au centre. Le
facilitateur doit jouer le rôle de modérateur - pour catalyser les idées et les souhaits.
Les outils nécessaires sont :
-
Deux grands tableaux blancs (un suffit mais deux c'est mieux)
-
Des chevalets
-
Ruban adhésif
-
Des post-it de deux couleurs
-
Des stylos pour tableau blanc (plusieurs couleurs)
-
Des crayons de bois
-
Des murs sur lesquels fixer du papier - de préférence dans une "salle de travail" que vous pouvez utiliser et
laisser en l'état pendant deux ou trois semaines.
Essayez d'identifier qui ou ce qui utilisera le système. Commencez d'abord par les personnes qui utiliseront réellement
le système ; la plupart se concentrent plus facilement sur le concret plutôt que sur l'abstrait. Lorsque les
utilisateurs sont identifiés, essayez d'identifier le rôle que l'utilisateur joue lors de son interaction avec le
système - ceci est en général un nom approprié pour un Acteur.
Lorsque vous avez identifié les acteurs, veillez à noter une brève description pour chaque acteur ; en général, noter
en quelques points clés le rôle de l'acteur par rapport au système et ses responsabilités aidera ensuite lorsque
viendra le moment de déterminer ce que l'acteur doit faire à partir du système.
Lorsque vous définissez les acteurs, n'oubliez pas les autres systèmes avec lesquels le système en conception agit.
L'icône d'acteur est trompeuse - elle semble impliquer une 'personne', mais le concept de l'acteur couvre également les
systèmes. Trouvez d'abord les acteurs 'humains' cependant ; la plupart des groupes travailleront mieux s'ils se
penchent d'abord sur ce qui leur est familier, puis ils aborderont les aspects plus ésotériques.
Ne vous préoccupez pas de la structure du Modèle
de cas d'utilisation, ni des relations entre les acteurs ; contentez-vous de capturer les personnes ou éléments qui
utiliseront le système. Concentrez-vous sur l'identification et préparez-vous à trouver de nombreux acteurs. Ne vous
préoccupez pas trop de filtrer la liste pour l'instant ; l'identification des cas
d'utilisation (voir ci-dessous) le fera.
Posez la question suivante : quels rôles de l'organisation utiliseront ce système ? Dessinez un bonhomme pour chaque
rôle suggéré, puis inscrivez un nom sous le bonhomme. Ensuite, dressez deux colonnes d'acteurs sur le tableau - une de
chaque côté de la bulle ou de l'icône que vous avez déjà dessinée. Il peut parfois être utile d'utiliser le mot rôle ou
utilisateur au lieu d'acteur.
Questions à poser :
-
Qui utilisera ce système ?
-
A quels autres systèmes ce système enverra-t-il des informations ?
-
De quels autres systèmes recevrons-nous des informations ?
-
Qui démarre le système ?
-
Qui conservera les informations sur l'utilisateur ?
Vous pouvez avoir des questions comme "Pourquoi Tom n'est-il pas l'acteur ? C'est toujours Tom qui fait cela". Vous
devrez alors poser plus de questions pour bien comprendre le rôle de Tom. Le nom de l'acteur doit refléter le rôle.
-
Quel est le rôle de Tom ?
-
Qui d'autre est capable d'avoir ce rôle ?
-
Pourquoi Tom a-t-il ce rôle ?
De nombreux acteurs peuvent être identifiés directement grâce à leur position normale dans l'organisation. Une position
dans l'organisation peut correspondre à plus d'un rôle dans le système. Par exemple, Tom peut travailler normalement au
dépôt et être également responsable de la réorganisation du dépôt pour créer de l'espace pour de nouveaux produits. Ces
deux responsabilités peuvent correspondre à deux acteurs différents dans le système.
Certains généraliseront à l'extrême. Il se peut qu'ils suggèrent qu'un utilisateur soit un acteur - puis qu'ils disent
qu'il s'agit du seul acteur dont nous avons besoin. Exact - mais ennuyeux, et cela n'aide pas beaucoup à la
compréhension du système. Essayez d'éviter de discuter cette suggestion si elle est faite. Notez l'acteur Utilisateur
sur le tableau, puis passez à l'acteur suivant.
-
Demandez à tous s'il manque quelque chose.
-
Faites de mauvaises suggestions. Ainsi, l'équipe peut vous corriger et expliquer les rôles exacts du système.
-
Acceptez toujours toutes les suggestions - vous pouvez toujours supprimer les doubles et les non acteurs par la
suite. Critiquer les suggestions de quelqu'un ne fera que tuer l'esprit de la réunion.
Définir les acteurs prend en général entre 1 et 4 heures. Le tableau doit désormais indiquer de nombreux acteurs, mais
veillez à ce qu'il y ait encore de l'espace pour ajouter des cas d'utilisation. Lorsque l'ensemble des acteurs semble
complet, il est temps de démarrer avec les cas d'utilisation.
Effacez la bulle ou l'icône du tableau et commencez à identifier des cas
d'utilisation. Concentrez-vous sur les cas d'utilisation concrets - éviter de parler des relations d'inclusion et d'extension. Dessinez une ellipse et inscrivez le nom de chaque suggestion. Dessinez
des flèches vers les acteurs.
Utilisez le fait que vous ne savez pas que leur application peut être un point fort. Les participants à l'atelier
doivent vous dire ce que le système est sensé faire. Vous devez poser beaucoup de questions sur le système. Lorsque les
participants vous donnent des explications, des cas d'utilisation apparaîtront.
Certains peuvent comprendre le concept des cas d'utilisation immédiatement, et d'autres ne comprendront pas. Afin de
faciliter la compréhension du concept, demandez à quelqu'un de dessiner une vue du système. Une vue du système est une
abstraction de celui-ci. Par exemple, cela peut être un serveur avec une base de données et un certain nombre de
clients, ou un certain nombre de cartes de circuit indiquant leurs activités spécifiques. Cette vue est en général
facile à illustrer : un des participants prendra généralement un stylo pour tableau blanc et expliquera le
fonctionnement du système. La vue du système aidera à prolonger les cas d'utilisation d'une limite du système à une
autre et soulignera implicitement un certain nombre d'états différents du système. Posez des questions sur ces états et
des cas d'utilisation supplémentaires apparaîtront. Vérifiez ce qui se passera lorsque différentes communications
seront coupées - ceci peut vous aider à identifier des flux alternatifs dans les cas d'utilisation.
Si vous travaillez sur un système technique, la vue du système est souvent quelque chose que tous connaissent bien et
peut être la meilleure façon de trouver des acteurs. Dans ce cas, vous pouvez les laisser dessiner la vue du système
avant de commencer à demander des acteurs.
Si vous travaillez sur un système administratif, la vue du système peut ne pas être évidente pour tous. Dans ce cas, un
graphique décrivant les opérations manuelles sera plus utile. Le graphique peut expliquer de quelle façon une entité
métier passe d'une personne à une autre et ce qu'elles sont supposées en faire. Pour visualiser le processus de
commande et de livraison, le graphique peut indiquer une vue schématique du bureau du client, de notre bureau, du
stockage et du stockage du client.
Assurez-vous que le modèle de cas d'utilisation et la vue du système/de l'entité métier sont bien visibles pour tous. A
ce moment, avoir deux tableaux peut être pratique.
Les noms des cas d'utilisation peuvent être longs. Un cas d'utilisation récemment identifié peut avoir un nom aussi
long qu'une phrase - ceci constituera un bon point de départ pour la brève description du cas d'utilisation, et le nom
sera ensuite raccourci.
Il y aura toujours un certain nombre de cas d'utilisation qui sembleront avoir des parties en commun. Assurez-vous que
tous comprennent bien que ceci est acceptable pour l'instant. Il ne sert à rien de structurer à ce stade, étant donné
que nous n'en savons pas suffisamment sur le contenu des cas d'utilisation. Vous devez attendre que le flux
d'événements se dessine avant de parler des relations des cas d'utilisation.
Une fois que le groupe se met d'accord sur le fait que les cas d'utilisation au tableau couvrent la fonctionnalité de
tout le système, prenez la pause déjeuner.
Lorsque vous revenez de la pause déjeuner, examinez les résultats de la séance du matin :
-
Examinez chaque Acteur: quelles sont ses activités dans ce système? Activité peut
être préférable au mot cas d'utilisation pour ceux qui ne connaissent pas bien la technique de modélisation des cas
d'utilisation.
-
Examinez chaque Cas d'utilisation suggéré : voyez-vous la valeur que
l'utilisateur atteindra avec le cas d'utilisation ? Si le cas d'utilisation a un résultat positif, l'utilisateur
effectuera le cas d'utilisation plus facilement.
-
Examinez chaque cas d'utilisation suggéré : est-il complet ? Ou représente-t-il uniquement une petite partie d'un
plus grand ensemble ?
Questions à poser :
-
Chaque acteur doit avoir au moins un cas d'utilisation. Dans le cas contraire, la raison peut être que l'acteur est
un double (un autre acteur joue le même rôle) ou que l'acteur n'est pas réellement un utilisateur direct du
système. Dans ces cas, si après avoir discuté des avantages de conserver un acteur, les raisons n'apparaissent pas
suffisantes, cet acteur peut être supprimé.
Travaillez sur les cas d'utilisation un à un, et créez un chevalet pour chacun. Dessinez une ellipse et notez le nom du
cas d'utilisation en haut du tableau. Prenez un crayon de bois et demandez au groupe de vous aider à rédiger une brève
description du cas d'utilisation. Une brève description doit contenir 1 à 3 phrases. Il est parfois utile de dessiner
les acteurs reliés au cas d'utilisation. Essayez de laisser la moitié de la feuille vierge pour l'étape suivante.
En faisant cela, vous découvrirez qu'il y a certaines choses que tout le monde pensait claires mais qui ne sont en fait
pas claires du tout. Consultez les exigences identifiées sous besoins des
utilisateurs et caractéristiques clés dans la Vision et
essayez de savoir s'il y a des Exigences pour ce
cas d'utilisation.
De nouveaux cas d'utilisation apparaîtront. Certains cas d'utilisation disparaîtront. Fixez les feuilles de cas
d'utilisation au mur. Essayez de les organiser avec une colonne par domaine fonctionnel. (N'utilisez pas les tableaux
pour cela - vous en aurez besoin pour la vue du système, les acteurs et les cas d'utilisation.) Si vous ne pouvez pas
répondre aux questions immédiatement, notez-les sur un post-it et mettez-les sur le cas d'utilisation approprié.
Utilisez une couleur pour les questions.
Une fois que tous les cas d'utilisation ont leur chevalet et leur brève description, il est temps de passer au mode
suivant. Il est souvent sage de prendre le temps de discuter pour savoir si tous les cas d'utilisation nécessaires sont
bien présents.
Le modèle que vous avez créé jusque là peut être documenté dans Rational
Rose ou Rational RequisitePro et généré dans un rapport d'étude des modèles
de cas d'utilisation.
Commencez par structurer le texte afin de rédiger un cas d'utilisation. Il ne sert à rien de s'isoler et d'essayer de
structurer le texte sans d'abord obtenir des informations de la part des intervenants.
Travaillez sur les cas d'utilisation un à un. Inscrivez les différentes actions dans l'ordre. N'essayez pas d'imaginer
la configuration en structures de code, en boucles, en instructions pendant, etc. - contentez-vous de travaillez sur le
flux d'événements de base et ne vous préoccupez pas des flux alternatifs. Enumérez les étapes 1, 2, 3, 4 ; pour aider
le groupe à comprendre le niveau de détail requis, vous pouvez dire que vous voulez 5 à 10 étapes dans le flux de base.
Une fois que vous vous êtes mis d'accord sur les étapes du flux d'événements de base, essayez d'identifier des étapes
alternatives. Enumérez les flux alternatifs A1, A2, A3, A4,
Lors de cette discussion, de nombreuses questions seront soulevées, la plupart ne seront pas résolues avant que vous
arriviez à Analyse & Conception. N'oubliez pas de noter toutes les
questions, ainsi que toutes les suppositions que vous devez faire en chemin. Certaines questions doivent être
rapidement résolues pour que l'Indicateur d'exigences puisse détailler le flux des événements
correctement, et certaines doivent être résolues avant de commencer Analyse & Conception.
Ce que vous avez sur chaque chevalet doit maintenant être suffisant pour que l'Indicateur d'exigences soit en mesure de
détailler le flux des événements du cas d'utilisation.
Lors de cette séance, il y aura plusieurs Exigences sur le
système que vous ne pourrez peut-être pas capturer de suite dans un cas d'utilisation. En général, ces instructions
concernent la fonctionnalité, la convivialité, la fiabilité, les performances générales et la prise en charge du
système. Réservez un chevalet pour noter ces instructions. Elles constitueront une base pour vos Spécifications supplémentaires.
Expliquez les Demandes clés des intervenants et chaque caractéristique du document Vision et vérifiez que le modèle de cas d'utilisation les
couvre de façon appropriée. Déterminez quels besoins ou exigences d'utilisateur sont rattachés à
quels cas d'utilisation.
Prenez le document Vision et lisez la première caractéristique. Notez son identité sur un (ou plus si nécessaire) post-it (utilisez
une autre couleur pour différencier plus facilement les exigences et les questions). Collez le post-it sur les cas
d'utilisation qui satisfont cette exigence. Ensuite, vous pouvez entrer ces traçabilités
dans votre référentiel RequisitePro.
Il y a toujours un certain nombre d'Exigences qui ne
peuvent être reliées à aucun cas d'utilisation :
-
Il peut s'agir d'exigences spécifiques dont la conception a été remise à plus tard - notez ces exigences sur papier
(exigences de conception).
-
Il peut s'agir d'exigences générales qui ne peuvent être reliées à aucun cas d'utilisation - notez-les dans la
liste des Spécifications supplémentaires.
-
Il peut s'agir d'exigences qui ont été oubliées et nécessitent de nouveaux cas d'utilisation ou des modifications
des cas d'utilisation existants.
Prenez quelques instants pour examiner la structure de la pièce : y a-t-il des cas d'utilisation sans exigence ?
Pourquoi ? Ce cas d'utilisation est-il obligatoire ? Ou cette fonctionnalité a-t-elle été oubliée par la personne qui a
rédigé la spécification de l'exigence ? (C'est généralement le cas.) La situation doit être résolue. Le client sait-il
qu'il a besoin de cette fonctionnalité ? Est-il prêt à payer ?
|