Métier du métier pour les Exigences

Exigences n'apparaissent pas isolément 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éfinie dans un ou plusieurs documents commerciaux. Ces documents et les informations qu'ils contiennent peuvent être inclus dans les modèles et fournir un point d'ancrage important pour les Exigences .

Affaire Métier

Le Métier Case est un document ou un argumentaire de haut niveau qui tente d'articuler les raisons d'initier un projet. Il s'agit d'un artefact important pour l'analyste des exigences, car il contiendra généralement des informations décrivant la valeur commerciale, les moteurs 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 incluse en tant qu'artefact dans le modèle.

Moteurs et objectifs

Métier moteurs et les objectifs du métier sont souvent documentés par des penseurs stratégiques de haut niveau, tels que des architectes d'entreprise ou 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. Ce sont généralement des préoccupations au niveau de l'entreprise et doivent donc être modélisées 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 Vision, et les modéliser dans un Paquetage d'entreprise au-dessus des Paquetages de projet dans le dépôt.

Vision et concept de fonctionnement

Alors que le Métier Case décrit la raison commerciale du lancement du projet, la Vision élabore généralement l'opportunité ou le problème plus en détail, 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 de 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 les Exigences architecturalement significatifs, les contraintes et les environnements de déploiement.

Politiques et Règles Métier

Une politique est un principe ou une déclaration d'intention de haut niveau généralement défini et géré par un organe de gouvernance ; une règle de 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 les 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 de Métier . Enterprise Architect prend en supporte la modélisation des politiques et des Règles Métier à l'aide d'exigences Exigences , mais possède également une capacité de 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 le même ensemble de 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 sensibles de l'organisation, 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. Ils 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.