Réserver une Démo
Pré. Proc.

Séminaires des parties prenantes

L'ingénieur Exigences 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'ingénieur Exigences 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'ingénieur utilise une terminologie que les parties prenantes comprennent et qu'il fasse également preuve d'une compréhension ou d'une volonté d'apprendre les éléments qui composent le domaine de l'ingénierie.

On pense parfois à tort que ces ateliers sont l'occasion de formuler un ensemble d'exigences clairement définies pouvant être saisies dans l'outil sous forme Exigences des parties prenantes. Or, c'est loin d'être le cas. Les parties prenantes formulent 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, 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'ingénieur n'aura pas le temps de classer toutes ces déclarations au cours des réunions. Il faut donc trouver un moyen pour le rédacteur 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'ingénieur 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 pratique consiste à utiliser le diagramme Mind Mapping 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 SysML. Ce diagramme montre une carte mentale de départ créée à partir d'un motif qui peut être modifié pour s'adapter aux besoins de l'atelier.

An example of a mind map created in Sparx Systems Enterprise Architect.

La facilité Mind Mapping est disponible en passant à cette perspective ou, si elle est couramment utilisée, elle peut être ajoutée à un ensemble de perspectives défini par l'utilisateur à l'aide de la facilité Mes Perspectives .

Cette perspective, comme d’autres, nécessite l’activation d’une technologie appropriée, qui dans ce cas est le Mind Mapping.

MindMapping MDG Technology in Sparx Systems Enterprise Architect.

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 sous forme de blocs dans un diagramme de définition Bloc 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 s'identifier dans les modèles, ce qui crée une 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.