Caractéristiques des bonnes Exigences

Le plus souvent, les erreurs et les lacunes 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. Des exigences bien articulées, gérées et Exigences sont donc impératives pour tout processus de développement de système. Enterprise Architect dispose d'un élément de liste de contrôle des Exigences pratique disponible à partir de la page "Extended Exigences " 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 du bien 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 également
Atomique	Une exigence doit articuler un seul besoin de 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 en permettant aux modélisateurs 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 commerciale requise par les parties prenantes. Enterprise Architect peut aider en permettant à chaque exigence d'être tracée à un élément de mise en œuvre 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érentes et exprimer le comportement du système ; tout écart doit être déterminé et le chevauchement entre les exigences doit être résolu. Suivre un processus d'exigences aidera grandement, et Enterprise Architect a 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 des Matrice où, par exemple, une matrice des parties prenantes et de leurs exigences identifierait rapidement les parties prenantes qui n'avaient pas d'exigences.	Matrice des relations
Complet	Chaque exigence doit décrire en détail la fonctionnalité ou le comportement nécessaire qui permettra de 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 Discuter & Révision . Certains analystes préfèrent marquer les exigences comme devant être remplies, en ajoutant à l'élément Requirement une balise telle que « TBC ». Enterprise Architect peut aider en permettant à l'analyste de rechercher dans les Paquetages d'exigences pour cette balise 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 Discussion et 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 Exigences des exigences.
Courant	Une exigence doit être à jour et refléter les connaissances actuelles et l'état du projet. Enterprise Architect peut aider l'analyste en permettant aux sources des exigences d'être modélisées et les exigences elles-mêmes peuvent être retracées jusqu'à ces artefacts, de sorte que lorsque la source est modifiée, tous les éléments affectés peuvent être localisés.
Indépendant	Les exigences doivent être indépendantes les unes des autres et ne pas avoir d'énoncés qui se chevauchent qui entrent en conflit les uns avec les autres ou réaffirment le même besoin. Un degré d'analyse sera nécessaire car il y aura inévitablement un certain chevauchement, mais cela peut être réduit au minimum en créant des exigences dans les hiérarchies et en travaillant systématiquement. Enterprise Architect a un certain nombre de fonctionnalités qui peuvent aider à cela, y compris la Matrice des relations, qui aidera à identifier les chevauchements. La fonction de recherche pratique et flexible pourrait également être utilisée pour identifier les déclarations qui se chevauchent ou sont contradictoires.
Modifiable	Cela signifie qu'une exigence peut être modifiée sans qu'il soit nécessaire de modifier d'autres exigences connexes. Elle s'applique également à une spécification d' Spécification de logiciel (système) et Exigences qu'elle puisse être modifiée facilement. Enterprise Architect peut aider à résoudre ces deux problèmes ; les Exigences elles-mêmes peuvent facilement être localisées grâce à la facilité de recherche , et le texte et les propriétés peuvent être modifiés facilement. La spécification des Spécification du système est Exigences générée à partir du modèle, donc en changeant 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 des parties prenantes, des moteurs et des objectifs commerciaux, et à des entités de processus en aval telles que des cas d'utilisation et des composants. Enterprise Architect permet de tracer les éléments dans n'importe quelle direction et fournit un certain nombre d'outils utiles pour visualiser les traces, y compris la Matrice des relations, la fenêtre de traçabilité et le diagramme des Exigences lui-même. La facilité Insert Related Elements permet de construire automatiquement un diagramme de traces.
Non ambigu	Une exigence ne doit pouvoir être interprétée que d'une seule façon. Des Exigences ambiguës peuvent entraîner un retard, un dépassement de budget ou une mauvaise fonctionnalité ou un mauvais comportement. Enterprise Architect peut aider à l'ambiguïté en aidant les analystes à enregistrer des commentaires sur les exigences, en utilisant la Discussion facilité .
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. La clé pour y parvenir est 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 de Test jusqu'aux exigences et de visualiser leur relation de plusieurs manières, y compris l'utilisation de la Matrice des relations. Les résultats Test peuvent également être enregistrés directement dans Enterprise Architect .
Nécessaire	Exigences doivent enregistrer une capacité ou un comportement qui est vraiment nécessaire ou qui spécifie que le système ou le produit doit se conformer à 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 des relations ; les exigences qui n'ont pas de source seront évidemment identifiées comme inutiles ou nécessitant une enquête plus approfondie.
Réalisable	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 Discuss & Révision .