Caractéristiques des bonnes Exigences

Le plus souvent, les erreurs et les déficiences des systèmes peuvent être attribuées à l'ingénierie des exigences, et la littérature mentionne fréquemment le faible coût de la correction d'une exigence par rapport au coût élevé de la correction du système une fois qu'il est construit. Exigences bien articulées, gérées et testées sont donc impératives pour tout processus de développement de système. Enterprise Architect dispose d'un élément pratique de liste de contrôle Exigences disponible sur la page « Exigences étendues » de la boîte à outils Exigences .

Example Requirements Checklist element created in Sparx Systems Enterprise Architect.

La liste de contrôle peut être utilisée pour indiquer si une exigence est prête à être mise en œuvre.

Qualités des bonnes Exigences

Pour être efficace, un ensemble d' Exigences doit être complet et enregistrer pleinement les besoins des parties prenantes de manière cohérente, cohérente et sans ambiguïté. Enterprise Architect fournit un ensemble complet de fonctionnalités et d'outils pour aider l'analyste à produire des ensembles d' Exigences de haute qualité.

Qualité	Description	Voir aussi
Atomique	Une exigence doit articuler un besoin unique d'une partie prenante ou un attribut de qualité. Lorsqu'une exigence contient plusieurs besoins, il n'est pas possible d'analyser les besoins indépendamment. Enterprise Architect peut aider les modélisateurs en permettant de créer des hiérarchies d'exigences dans la fenêtre Navigateur , qui peuvent être décomposées en une exigence atomique.
Réalisable	Le besoin spécifié dans l'exigence doit être réalisable. Si une exigence n'est pas réalisable, le système ne sera pas en mesure de fournir la valeur métier requise par les parties prenantes. Enterprise Architect peut vous aider en permettant de relier chaque exigence à un élément d'implémentation tel qu'un cas d'utilisation ou un composant. La Matrice de relations peut être utilisée pour identifier rapidement les exigences qui ne sont pas rattachées à un élément de niveau inférieur.
Cohésif	Les exigences en tant qu'ensemble doivent être cohérentes et cohésives et exprimer le comportement du système ; les éventuels écarts doivent être déterminés et les chevauchements entre les exigences doivent être résolus. Suivre un processus d'exigences sera d'une grande aide, et Enterprise Architect dispose d'un certain nombre de facilités qui faciliteront le maintien de la cohésion des exigences. Les exigences manquantes peuvent être identifiées à l'aide de la Matrice de relations où, par exemple, une matrice des parties prenantes et de leurs exigences permettrait d'identifier rapidement les parties prenantes qui n'avaient pas d'exigences.	Matrice de relations
Complet	Chaque exigence doit décrire en détail la fonctionnalité ou le comportement nécessaire pour répondre au besoin de la partie prenante. Enterprise Architect peut aider les membres de l'équipe en utilisant la Bibliothèque d'Équipe facilité ou la fenêtre Discuss & Révision . Certains analystes préfèrent marquer les exigences comme devant être complétées, en ajoutant à l'élément Exigence une étiquette telle que « TBC ». Enterprise Architect peut aider en permettant à l'analyste de rechercher dans les Paquetages d'exigences cette étiquette et de renvoyer une liste d'éléments qui nécessitent un travail supplémentaire. Un Modèle Vue peut également être configuré à l'aide de cette recherche pour remplir la vue. La fenêtre Discuss & Révision est également utile car les informations ajoutées ne font pas partie de l'Exigence elle-même et ne contaminent pas les notes de l'Exigence avec du texte qui ne fait pas partie de la définition Exigences .
Actuel	Une exigence doit être à jour et refléter les connaissances actuelles et l'état du projet. Enterprise Architect peut aider l'analyste en permettant de modéliser les sources des exigences et de remonter aux exigences elles-mêmes jusqu'à ces artefacts, de sorte que lorsque la source est modifiée, tous les éléments affectés puissent être localisés.
Indépendant	Les exigences doivent être indépendantes les unes des autres et ne pas comporter de déclarations qui se chevauchent, qui sont en conflit les unes avec les autres ou qui réitèrent le même besoin. Un certain degré d'analyse sera nécessaire car il y aura inévitablement des chevauchements, mais ceux-ci peuvent être réduits au minimum en créant des exigences dans des hiérarchies et en travaillant de manière systématique. Enterprise Architect dispose d'un certain nombre de fonctionnalités qui peuvent vous aider à cet égard, notamment la Matrice de relations, qui permet d'identifier les chevauchements. La fonction de recherche pratique et flexible peut également être utilisée pour identifier les déclarations qui se chevauchent ou qui sont en conflit.
Modifiable	Cela signifie qu'une exigence peut être modifiée sans qu'il soit nécessaire de modifier d'autres exigences associées. Cela s'applique également à une Spécification Exigences logicielles (système) et nécessite qu'elle puisse être modifiée facilement. Enterprise Architect peut vous aider à résoudre ces deux problèmes : les Exigences elles-mêmes peuvent être facilement localisées grâce à la facilité de recherche, et le texte et les propriétés peuvent être modifiés facilement. La Spécification Exigences système est générée automatiquement à partir du modèle, donc en modifiant simplement une ou plusieurs exigences et en régénérant le document, elle sera mise à jour.
Traçable	Une exigence est une spécification d'une caractéristique ou d'un comportement, et n'existe pas de manière isolée mais est généralement liée à des entités de processus en amont telles que les parties prenantes, les moteurs et les objectifs commerciaux, et à des entités de processus en aval telles que les cas d'utilisation et les composants. Enterprise Architect permet de tracer des éléments dans n'importe quelle direction et fournit un certain nombre d'outils utiles pour visualiser les traces, notamment la Matrice de relations, la fenêtre de traçabilité et le diagramme Exigences lui-même. La facilité Insérer des éléments associés peut être utilisée pour construire automatiquement un diagramme de traces.
Non ambigu	Une exigence ne doit pouvoir être interprétée que d'une seule manière. Exigences ambiguës peuvent entraîner un retard dans le projet, un dépassement du budget ou une fonctionnalité ou un comportement incorrect. Enterprise Architect peut aider à résoudre l'ambiguïté en aidant les analystes à enregistrer des commentaires sur les exigences, à l'aide de la facilité Discussion.
Vérifiable	Une exigence est vérifiable si le système ou le produit mis en œuvre peut être testé pour s'assurer que l'exigence a été satisfaite. Pour y parvenir, il est essentiel de savoir quel test doit être exécuter pour vérifier une exigence particulière. Enterprise Architect peut aider en permettant au modélisateur de retracer les cas Test jusqu'aux exigences et de visualiser leur relation de plusieurs manières, notamment en utilisant la Matrice de relations. Les résultats Test peuvent également être enregistrés directement dans Enterprise Architect .
Nécessaire	Exigences doivent enregistrer une capacité ou un comportement réellement nécessaire ou qui spécifie que le système ou le produit doit être conforme à des contraintes telles que des normes. Enterprise Architect peut aider en permettant au modélisateur de relier chaque exigence à sa source et en utilisant la Matrice de relations ; les exigences qui n'ont pas de source seront évidemment identifiées comme inutiles ou nécessitant une enquête plus approfondie.
Possible	Une exigence qui ne peut pas être mise en œuvre signifie que le besoin de la partie prenante ne sera pas satisfait. Il est préférable d'identifier ces exigences le plus rapidement possible afin de ne pas décevoir le propriétaire de l'exigence. Enterprise Architect peut aider en permettant aux analystes, architectes, concepteurs et développeurs de discuter de l'exigence et de déterminer sa faisabilité à l'aide de la fenêtre Discuter et Révision .