Réserver une Démo

SVP notez : Cette page d’aide n’est pas pour la dernière version d’Enterprise Architect. La dernière aide peut être trouvée ici.

Pré. Proc.

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 .

MindMapping MDG Technology in Sparx Systems Enterprise Architect.

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.

There are a number of situations where it is useful to define requirements inside an element. Requirements are typically created as elements in the Specification Manager, or as part of a Requirements diagrams or directly in the Project Browser. Enterprise Architect allows you to move (copy) an External Requirement into an element creating an Internal Requirement. This is quite commonly done so down-process workers like developers can see the Functional and Non Functional Requirements when working with a Use Case or Component. It can also be used as a device to list a series of applicable requirements under an element in a report. For example high level Business Requirements could be moved internal to a Business Process and if a report were generated the Business Requirements would be listed directly under the Business Process.

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.

Mind Mapping diagram modeling Business Stakeholder Collaboration in Sparx Systems Enterprise Architect

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.

Entering a glossary item in the Glossary Item Details dialog.

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 .

Business Modeling, Domain models in Sparx Systems Enterprise Architect

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.

The Element Discussion facility can be used to discuss requirements, in Sparx Systems Enterprise Architect.

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