Modélisation des récits utilisateur

Votre équipe peut créer des modèles pour l'aider à comprendre les récits utilisateur à estimer ou à développer. Votre équipe peut également utiliser des modèles dans les discussions en cours avec le responsable du produit pendant le développement, si les questions sont autrement complexes.

Par exemple, votre projet peut impliquer un ensemble de concepts nouveaux dans votre équipe. En travaillant avec le responsable du produit, votre équipe peut développer un diagramme de classes de domaine pour capturer ces concepts et leurs relations. Si votre équipe doit comprendre les principales séquences dans une activité d'utilisateur, elle peut créer un diagramme d'activités.

Pour plus d'informations, consultez Modélisation des besoins des utilisateurs.

Modèle des domaines : langage des utilisateurs

Diagrammes de classes de domaine

Un diagramme de classes de domaine présente les concepts et les relations associés à l'application. Toute personne associé à l'application peut ensuite utiliser ces concepts pour bénéficier d'une connaissance plus cohérente.

L'exemple de l'illustration précédente n'est pas directement un diagramme de classes de la solution logicielle, qui peut représenter ces relations de différentes façons. En fait, il présente un vocabulaire avec lequel vous pouvez écrire des récits utilisateur :

Le client sélectionne un Menu à partir duquel il établit une Commande, puis le client crée des Éléments commandés dans la Commande en sélectionnant des Éléments de menu dans le Menu.

Comme il s'agit d'un modèle de concepts et non d'objets dans un programme, normalement vous n'assignez pas d'opérations aux classes lorsque le diagramme est utilisé à cette fin. Vous pouvez plutôt utiliser des diagrammes d'activités pour décrire les actions que les utilisateurs exécutent.

Pour plus d'informations, consultez Diagrammes de classes UML : indications.

Diagrammes d'activités

Votre équipe peut expliquer le flux d'activités qu'un utilisateur peut exécuter et présenter les autres actions possibles à chaque point à l'aide de diagrammes d'activités.

Lorsque votre équipe crée des tests, elle peut faire référence à des diagrammes d'activités et créer un test pour chaque tracé du diagramme d'activités.

Un récit utilisateur peut introduire un tracé dans un diagramme d'activités existant. Par exemple, un récit utilisateur peut être « En tant que client, je peux choisir d'enregistrer une commande pour plus tard au lieu de la régler maintenant ». Lorsque le récit est effectuée dans un sprint à développer, le diagramme d'activités peut être mis à jour pour exprimer la nouvelle fonction.

Le diagramme d'activités peut décrire un ensemble complet de chemins que l'utilisateur peut suivre à l'aide d'une version particulière de votre application, si vous mettez à jour le diagramme pour refléter tous les récits utilisateur que l'équipe a implémentés.

Pour plus d'informations, consultez Diagrammes d'activités UML : instructions.

Utilisation du modèle pour identifier les lacunes

Votre équipe peut mieux comprendre les spécifications de vos utilisateurs en évitant les malentendus qui se produisent au cours des conversations qui ne sont pas décrites dans un diagramme. Par exemple, un diagramme fait clairement la distinction entre un élément de commande et un élément de menu.

La création du modèle permet à votre équipe de poser des questions qu'elle ne poserait pas nécessairement à ce stade de développement. Parmi ces techniques, citons :

• Poser des questions sur les cardinalités dans un diagramme de classes (par exemple, « Un élément de menu peut-il apparaître dans plusieurs menus ? »).

• Poser des questions sur des boucles dans le diagramme de classes (par exemple, «Quel que soit l'ordre, tous les éléments appartiennent-ils au même menu ? »).

Les réponses à ces questions peuvent être ajoutées sous la forme de commentaires dans le diagramme.

Cohérence du modèle

Votre équipe peut résoudre les ambiguïtés en s'assurant que le modèle et les récits utilisateur sont cohérents :

• Les récits utilisateur utilisent les termes qui sont définis dans le modèle et sont cohérentes avec les relations qu'il définit. Si le modèle définit des éléments de menu, les récits ne doivent pas utiliser le terme « produits » pour désigner la même réalité. Si le diagramme de classes indique qu'un élément de menu appartient à un seul menu, les récits ne doivent pas faire référence au partage de cet élément entre des menus.

• Chaque récit utilisateur décrit une série d'étapes autorisées par les diagrammes d'activités.

• Les récits utilisateur ou les activités décrivent le mode de création et de suppression de chaque classe et relation du diagramme de classes. Par exemple, quel récit utilisateur crée un élément de menu ? Quand est-ce qu'une commande est détruite ?

Modèles et journal des travaux en souffrance du produit

Votre équipe peut marquer des modèles et des tables de montage séquentiel pour indiquer les parties à modifier par chaque récit utilisateur et peut utiliser des couleurs ou des commentaires sur un modèle pour vous aider à planifier le développement. Par exemple, votre équipe peut appliquer des couleurs aux actions dans un diagramme d'activités pour indiquer celles qui ont déjà été effectuées et celles qui le seront dans le sprint suivant.

Pour plus d'informations, consultez Modélisation des besoins des utilisateurs.

Modèles et tests

Votre équipe peut utiliser un modèle de domaine comme base pour les tests système, ce qui simplifie les relations entre les tests et les spécifications des utilisateurs. Ces relations permettent à votre équipe de mettre à jour les tests rapidement et correctement et de s'assurer que le produit répond aux nouvelles spécifications.

Votre équipe peut lier un quelconque élément dans un modèle UML (Unified Modeling Language) à un élément de travail, par exemple un test. Lorsqu'une partie du modèle change, le modèle permet à votre équipe d'identifier les tests auxquels il est lié.

Utilisez le modèle de domaine pour vous aider à créer des tests :

• Créez au moins un test qui inclut la construction de chaque type ou association, par exemple un élément de menu ou de commande, et au moins un test qui inclut sa suppression.

• Assurez-vous que tous les chemins décrits par les diagrammes d'activités sont testés.

  Notes

  Les tests doivent également traiter les chemins exceptionnels que vous n'illustreriez pas nécessairement en temps normal dans les diagrammes d'activités.

• Utilisez le vocabulaire du modèle de domaine pour définir les tests. Par exemple, vos tests peuvent inclure un test de l'action Choisir un élément de menu, qui vérifierait que l'action s'exécute dans l'ordre de plan contenant un nouvel élément d'ordre de plan. Pour écrire des tests automatisés, vous pouvez utiliser des classes et des relations basés directement sur le diagramme.

Pour plus d'informations, consultez Mise au point de tests à partir d'un modèle.