Instructions: Atelier de cas d'utilisation
Ces instructions indiquent comment se préparer et animer un atelier de cas d'utilisation.
Relations
Description principale

Organisation de l'atelier

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.

Outils

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.

Définition des acteurs

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.

Un système administratif

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 ?

Diagramme décrit dans le texte d'accompagnement.

Instance ou classe ?

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.

Astuces

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

Diagramme décrit dans le texte d'accompagnement.

Définition des 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é.

Rédigez une brève description pour chaque cas d'utilisation

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.

Diagramme décrit dans le texte d'accompagnement.

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.

Description étape par étape du flux d'événements pour chaque 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,

Diagramme décrit dans le texte d'accompagnement.

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.

Capture de spécifications supplémentaires

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.

Rattacher des exigences à des cas d'utilisation

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.

Diagramme décrit dans le texte d'accompagnement.

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 ?