Métier Contexte des Exigences

Exigences n'apparaissent pas de manière isolée mais sont généralement définies ou découvertes dans le contexte d'un problème ou d'une opportunité commerciale qui a été défini dans un ou plusieurs documents commerciaux. Ces documents et les informations qu'ils contiennent peuvent être inclus dans les modèles et fournissent un point d'ancrage important pour Exigences .

Affaire Métier

Le Métier Case est un document ou un argument de haut niveau qui tente d'articuler les raisons du lancement d'un projet. Il s'agit d'un artefact important pour l'analyste des exigences, car il contient généralement des informations décrivant valeur commerciale, les facteurs déterminants et les risques commerciaux et techniques. Il place l'effort dans le contexte d'autres fonctions de l'entreprise et décrit les options de solution à un niveau élevé. Il s'agit d'une source importante d'exigences et doit être inclus en tant qu'artefact dans le modèle.

Pilotes et objectifs

Les moteurs et les objectifs Métier sont souvent documentés par des penseurs stratégiques de haut niveau, tels que des architectes d'entreprise. Les moteurs définissent les ressources, les processus ou les contraintes qui sont essentiels au fonctionnement de l'organisation, et les objectifs décrivent la position que l'organisation souhaite atteindre. Il s'agit généralement de préoccupations au niveau de l'entreprise et doivent donc être modélisés au-dessus du niveau des projets individuels. Ils existent souvent dans la documentation de haut niveau, et même lorsqu'ils ne sont pas clairement articulés au niveau de l'organisation, un analyste peut les extraire de la documentation de projet précédente, comme un document de vision, et les modéliser dans un Paquetage d'entreprise au-dessus des Paquetages de projet dans le référentiel.

Vision et concept d'opération

Alors que le cas Métier décrit la raison commerciale pour laquelle le projet a été lancé, la Vision élabore généralement l'opportunité ou le problème de manière plus détaillée, en décrivant le contexte commercial, la position sur le marché, les principales parties prenantes et les exigences, les choix de solutions et les contraintes. La Vision est le plus souvent créée avant la constitution de l'équipe et peut être une excellente source d'informations sur les exigences. La fonctionnalité système requise est souvent exprimée à l'aide Fonctionnalités .

Enterprise Architect dispose d'une large gamme d'outils et de types d'éléments qui peuvent être utilisés pour modéliser le contenu du document Vision, y compris les utilisateurs, les parties prenantes, les cas d'utilisation et Exigences importants sur le plan architectural, les contraintes et les environnements de déploiement.

Politiques et Règles Métier

Une politique est un principe de haut niveau ou une déclaration d'intention généralement définie et gérée par un organe de gouvernance ; une règle Métier est une mise en œuvre de la politique. Il ne s'agit pas strictement d'exigences et elles sont souvent définies au niveau de l'entreprise plutôt qu'au niveau du projet, ce qui facilite leur réutilisation dans plusieurs projets. Les politiques et Règles Métier peuvent être modélisées à l'aide d'éléments d'exigence stéréotypés, et les exigences métier et système peuvent leur être attribuées à partir de projets individuels. Il existe un certain chevauchement avec les exigences réglementaires et de sécurité, que certaines méthodes considèrent comme des types de règles Métier . Enterprise Architect supporte la modélisation des politiques et Règles Métier à l'aide Exigences stéréotypées, mais dispose également d'une capacité Modélisation des règles Métier qui peut créer du code exécutable pour une variété de langages.

• Métier Rule Modélisation est disponible dans les éditions Unified et Ultimate d' Enterprise Architect

Les parties prenantes et leurs préoccupations

Les parties prenantes ont généralement les mêmes préoccupations, que les projets soient en cours ou non. Un responsable de la sécurité sera par exemple préoccupé par la vulnérabilité des données organisationnelles sensibles, un responsable de l'expérience client sera préoccupé par la rapidité d'accès et un directeur financier sera intéressé par le retour sur investissement. Ces préoccupations peuvent être modélisées au niveau de l'entreprise car elles sont génériques et indépendantes des projets individuels. Elles fourniront une source de compréhension des exigences au niveau du projet et aideront à identifier les lacunes dans le paysage des exigences. Enterprise Architect peut être utilisé pour modéliser les parties prenantes à l'aide d'une classe UML stéréotypée et ces préoccupations de haut niveau peuvent être modélisées à l'aide d'une exigence stéréotypée en tant que préoccupation des parties prenantes.