Séminaires des parties prenantes

L'analyste des exigences ou l'analyste d'affaires est chargé de la tâche difficile de recueillir 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 la collecte des besoins des parties prenantes est d' 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 fasse preuve d'une compréhension ou d'une volonté d'apprendre les éléments qui composent le domaine.

On pense parfois à tort que l'on va articuler un ensemble d'exigences clairement définies qui peuvent être saisies dans l'outil en tant Exigences des parties prenantes ; c'est loin d'être le cas. Les parties prenantes articulent généralement un large éventail d'idées, notamment des politiques, Règles Métier , des définitions de données, des contraintes Gestion de Projet , Exigences fonctionnelles, des Exigences Métier , des problèmes de système existants et même des 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 lors des réunions. Il faut donc trouver un moyen pour le scribe chargé de documenter les déclarations de les intégrer dans l'outil sans se soucier du type d'informations enregistrées. Les enregistrer dans l'outil plutôt que de les griffonner dans le carnet de l'analyste est une bonne pratique, car cela permet de les afficher pendant la réunion et aux parties prenantes de voir les commentaires des autres.

Enterprise Architect dispose de plusieurs facilités qui peuvent vous aider à organiser 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 inhérentes aux langages modélisation tels que UML .

Au fur et à mesure que des termes importants sont découverts, ils peuvent être intégrés au Glossaire du Projet et, même s'il n'y a pas assez de temps pour discuter et débattre de la signification convenue, les mots serviront de liste initiale d'entités importantes dans le domaine. Alternativement, les termes peuvent être créés dans un Modèle de Domaine et reliés les uns aux autres par des connecteurs qui décrivent les relations importantes entre les termes.

Les parties prenantes peuvent également être modélisées et leurs relations organisationnelles entre elles 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 une adhésion.

Diagramme de cartographie mentale

Un diagramme de cartographie mentale 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 des exigences, 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 efficace de la manière 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 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 déclarations. Cette étape est généralement réalisée dans la phase d'analyse du processus de développement des exigences.

Glossaire

Avant un atelier, un analyste peut remplir le Glossaire du Projet avec les termes existants et leurs significations glanés à partir de la lecture de la documentation du projet, comme un Métier Case 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 de référence pour les discussions avec de nombreuses parties prenantes et, idéalement, un modèle squelette devrait être créé avant le début de tout atelier. Le Modèle de domaine doit être simple et les éléments du domaine doivent être dotés d'un nom et d'une description ou d'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 préoccupations sont pris en compte et gérés correctement. Enterprise Architect permet de créer des modèles de domaine à l'aide du diagramme de classes UML .

Discussions

La fenêtre Discuss & Révision est une facilité pratique qui permet de commenter les éléments sans contaminer les notes avec des discussions qui ne contribuent pas à l'intégrité du modèle. Les modélisateurs placent souvent notes sur diagrammes ou écrivent des questions dans les champs Notes des éléments, et celles-ci sont gênantes et doivent être supprimées lors de la génération de la documentation formelle à partir du modèle. La fenêtre Discuss & Révision permet à un modélisateur d'initier une discussion et aux autres d'y répondre. C'est un moyen idéal de discuter des exigences.

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