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

Modèle Hypothèses et Contraintes

Lorsqu'un analyste travaille sur les informations acquises à partir du processus d'élicitation, il rencontre généralement des déclarations ou des conditions qui sont mieux décrites comme des hypothèses qui ont été faites ou des contraintes qui restreindront la solution d'une manière ou d'une autre. Il ne s'agit pas d' Exigences , mais elles jouent un rôle important dans le processus de développement des exigences car elles ont la capacité d'affecter la solution et doivent être comprises.

Contraintes Métier

Une Contrainte Métier est une restriction ou une limitation commerciale imposée sur les choix qui peuvent être faits pour la conception, la mise en œuvre ou le déploiement de la solution. Il s'agit généralement de restrictions de budget, de temps et de ressources, mais il peut s'agir de tout type de limitation, comme le contexte du déploiement de l'entreprise où la solution ne doit pas modifier la façon dont le personnel de la succursale travaille actuellement. Une contrainte Métier peut également limiter l'accès ou la présentation d'informations telles que "Seuls les quatre derniers chiffres d'un numéro de carte de crédit peuvent être affichés dans les rapports". Il y a un certain chevauchement avec les règles métier et l'analyste doit veiller à séparer les deux notions. Les contraintes Métier peuvent être modélisées dans Enterprise Architect à l'aide d'un élément Constraint disponible à partir de la page de la boîte à outils commune ou d'un élément Exigences stéréotypé. Ils peuvent être liés à un ou plusieurs éléments de modèle à l'aide d'une relation de dépendance. Les contraintes peuvent également être créées en tant que propriété d'un élément à l'aide de la fenêtre Propriétés .

Example Feature with Constraint element modeled in Sparx Systems Enterprise Architect

Hypothèses

Une hypothèse est une affirmation que l'on croit vraie mais qui n'a pas encore été vérifiée. Il est impératif que les hypothèses soient modélisées et que des tentatives soient faites pour les vérifier car elles ont le potentiel, si elles s'avèrent fausses, de modifier considérablement la définition du problème et donc la solution. Il peut s'agir de déclarations faites sur la façon dont les choses sont faites actuellement ou elles pourraient concerner un processus ou une solution future. Les hypothèses sont similaires aux Risques , et les bonnes pratiques prescriraient qu'elles soient gérées de la même manière que les Risques . Des tentatives doivent être faites pour les vérifier le plus tôt possible dans la phase de développement des exigences. Un exemple d'hypothèse est : « L'utilisateur connaîtra la signification des icônes de la boîte à outils telles qu'elles sont utilisées dans d'autres applications Windows ». Sur la base de cette hypothèse, le concepteur de la solution peut prévoir de ne pas implémenter d'info-bulles pour les icônes. Les hypothèses peuvent être modélisées dans Enterprise Architect à l'aide d'un élément Constraint, disponible à partir de la page de la boîte à outils 'Common', ou en tant qu'élément Exigences stéréotypé. Ils peuvent être liés à un ou plusieurs éléments de modèle à l'aide d'une relation de dépendance.

Technical assumption modeled as a constraint in Sparx Systems Enterprise Architect

Contraintes techniques

Une contrainte technique est toute restriction sur les choix qui peuvent être faits pour l'architecture, la conception, la mise en œuvre ou le déploiement de la solution. Ils peuvent commencer par des principes définis dans l'architecture d'entreprise qui restreignent les types de plate-forme, le langage de programmation et la décision d'acheter ou de construire une partie de la solution. Il peut également s'agir de restrictions sur le type de protocole ou de norme que la solution doit mettre en œuvre ou respecter. Les restrictions sur les tailles et les formats de fichiers peuvent également limiter les choix de solutions. Il y a un certain chevauchement avec les exigences non fonctionnelles et l'analyste doit veiller à séparer les deux notions. Les contraintes techniques peuvent être modélisées dans Enterprise Architect à l'aide d'un élément Constraint disponible sur la page de la boîte à outils "Common" ou en tant qu'élément Exigences stéréotypé. Ils peuvent être liés à un ou plusieurs éléments de modèle à l'aide d'une relation de dépendance. Les contraintes peuvent également être créées en tant que propriété d'un élément à l'aide de la fenêtre Propriétés .