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

Séminaires des parties prenantes

L' Exigences des exigences 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 Exigences de l'ingénieur des 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 affiche également une compréhension ou une volonté d'apprendre sur les éléments qui composent le domaine de l'ingénierie.

Il y a parfois une idée fausse selon laquelle ce qui sera articulé au cours de ces ateliers 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'ingénieur n'aura pas le temps de catégoriser toutes ces déclarations à l'intérieur des 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ées dans l'outil plutôt que griffonnées dans le cahier de l'ingénieur 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 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 qui accompagnent les langages de modélisation tels que SysML. Ce diagramme montre une carte mentale de départ créée à partir d'un modèle qui peut être modifié pour répondre 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 utilisée couramment, 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 de la 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 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 en tant que blocs dans un diagramme de définition de Bloc 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 s'identifier 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.