Séminaires des parties prenantes

L'analyste des exigences ou l'analyse métier est chargé de la tâche difficile d'éliciter les exigences, ce qui nécessite une excellente communication avec les parties prenantes, y compris le client et l'équipe d'analyse. Une façon très efficace de faciliter l'élicitation des besoins des parties prenantes consiste à exécuter un atelier avec toutes les parties prenantes clés présentes. Les compétences de l'analyste en tant que communicateur, diplomate et médiateur sont importantes pour créer un environnement collaboratif et respectueux propice à l'exploration des besoins et des préoccupations des parties prenantes. Il est impératif que l'analyste utilise une terminologie que les parties prenantes comprennent et affiche une compréhension ou une volonté d'apprendre les éléments qui composent le domaine.

Il y a parfois une idée fausse selon laquelle ce qui sera articulé est un ensemble d'exigences clairement définies qui peuvent être saisies dans l'outil en tant Exigences des parties prenantes ; c'est loin de la réalité de ce qui se passe. Les parties prenantes articuleront généralement un large éventail d'idées, y compris les politiques, les Règles Métier , les définitions de données, la Gestion de Projet , les Exigences fonctionnelles, les Métier de Exigences , les problèmes de système existants et même les solutions suggérées. Même lorsqu'un consultant externe est utilisé pour exécuter ces réunions, l'analyste n'aura pas le temps de classer toutes ces déclarations dans les réunions. Ce qu'il faut, c'est un moyen pour le scribe chargé de documenter les déclarations de les intégrer à l'outil sans se soucier du type d'informations enregistrées. Les avoir enregistrés dans l'outil plutôt que griffonnés dans le cahier de l'analyste est la meilleure pratique car cela permet de les afficher pendant la réunion et aux parties prenantes de voir les commentaires des autres.

Enterprise Architect a un certain nombre de facilités qui peuvent aider avec ces ateliers. Une méthode très efficace consiste à utiliser le diagramme MindMapping pour enregistrer les déclarations des parties prenantes, ce qui est très efficace car c'est une méthode bien connue et qui n'introduit aucune des formalités qui accompagnent les langages de modélisation tels que UML .

Au fur et à mesure que des termes importants sont découverts, ils pourraient être entrés dans le Glossaire du Projet , et même s'il n'y a pas le temps de discuter et de débattre du sens convenu, les mots agiront comme une liste initiale d'entités importantes dans le domaine. Alternativement, les termes peuvent être créés dans un Modèle de domaine et liés les uns aux autres avec des connecteurs qui décrivent les relations importantes entre les termes.

Les parties prenantes peuvent également être modélisées et leurs relations organisationnelles les unes avec les autres peuvent être décrites dans un diagramme . Il s'agit d'une technique utile qui permet aux principales parties prenantes de se situer dans les modèles, ce qui crée l'adhésion.

Diagramme de Mind Mapping

Un diagramme de Mind Mapping peut être utilisé pour enregistrer les déclarations des parties prenantes lors d'un atelier d'élicitation. Les déclarations ne sont pas catégorisées mais simplement enregistrées et plus tard au cours de la phase d'analyse du développement de l'exigence, elles peuvent être converties en éléments appropriés ou conservées et les Exigences peuvent être retracées jusqu'aux sujets, créant ainsi un enregistrement de la façon dont l'exigence a été dérivée. Il s'agit d'une technique utile qui évite aux parties prenantes d'avoir à connaître les langages de modélisation et leur permet de se concentrer sur l'articulation de leurs besoins. Elle libère également l'analyste des préoccupations concernant l'élément à utiliser pour modéliser les énoncés. Cette étape est généralement effectuée dans la phase d'analyse du processus de développement de l'exigence.

Glossaire

Avant un atelier, un analyste peut remplir le Glossaire du Projet avec les termes existants et leurs significations qui ont été glanées à partir de la lecture de la documentation du projet, comme un cas de Métier ou un document de vision. Au cours des ateliers, à mesure que de nouveaux termes sont découverts, ils peuvent être ajoutés au glossaire et leurs définitions peuvent être discutées et saisies ou reportées à plus tard dans la phase d'analyse.

Modèle de domaine

Un modèle de domaine servira de modèle directeur pour les discussions avec de nombreux intervenants et, idéalement, un modèle squelette devrait être créé avant le début de tout atelier. Le Modèle de domaine doit rester simple et les éléments de domaine doivent recevoir un nom et une description ou une responsabilité et, au départ, seules les connexions importantes doivent être établies entre les éléments. Au fur et à mesure que l'atelier progresse, de nouveaux éléments seront découverts et pourront être ajoutés directement au modèle, donnant aux parties prenantes l'assurance que leurs besoins et leurs préoccupations sont bien pris en compte et bien gérés. Enterprise Architect permet de créer des modèles de domaine à l'aide du diagramme de classe UML .

Discussions

La fenêtre Discuter & Révision est une facilité facilité qui permet de commenter des éléments sans contaminer les notes avec des discussions qui finalement ne contribuent pas à l'intégrité du modèle. Les modélisateurs placent souvent des notes sur les diagrammes ou écrivent des questions dans les champs Notes de l'élément, et ceux-ci sont gênants et doivent être supprimés lorsque la documentation formelle est générée à partir du modèle. La fenêtre Discuter & Révision permet à un modélisateur d'initier une discussion et à d'autres de répondre. C'est un moyen idéal pour discuter des besoins.

La fenêtre Discuter et Révision affiche de manière pratique les Discussions pour tous les éléments du référentiel.