Points de contrôle : Cas d'utilisation
- Chaque cas d'utilisation concret est-il en interaction avec au moins un acteur ?
Sinon, quelque chose est incorrect; un cas d'utilisation qui n'interagit pas avec un acteur est superflu et vous devez le supprimer. Pour plus d'informations, voir Principes et conseils : Cas d'utilisation .
- Chaque cas d'utilisation est-il indépendant des autres ? Si deux cas d'utilisation sont toujours activés dans la même séquence, vous devrez probablement les fusionner dans un seul cas d'utilisation.
- Pour un cas d'utilisation inclus : pose-t-il des postulats sur les cas d'utilisation qui l'incluent? De tels postulats doivent être évités, de manière à ce que le cas d'utilisation inclus ne soit pas affecté par les changements des cas d'utilisation auxquels il appartient.
- Y a-t-il des cas d'utilisation ayant des comportements ou des flux d'événements similaires ? Si c'est le cas, et si vous voulez que leur comportement soit similaire, vous devez les fusionner dans un cas d'utilisation unique. Ceci facilite l'introduction de tous changements ultérieurs. Remarque :vous devez impliquer les utilisateurs si vous décidez de fusionner des cas d'utilisation, car les utilisateurs qui interagissent avec le nouveau cas d'utilisation fusionné seront probablement concernés.
- Une partie du flux des événements a-t-elle été déjà modélisée dans un autre cas d'utilisation ? Si c'est le cas, vous pouvez faire en sorte que le nouveau cas d'utilisation utilise l'ancien.
- Une partie du flux des événements fait-elle déjà partie d'un autre cas d'utilisation ? Si c'est le cas, vous pouvez extraire cette partie du flux et la faire utiliser par les cas d'utilisation concernés. Remarque :vous devez impliquer les utilisateurs si vous décidez de "réutiliser" la partie du flux, car les utilisateurs des cas d'utilisation existants seront probablement touchés.
- Le flux d'événements d'un cas d'utilisation devrait-il être inséré dans le flux d'événements d'un autre ? Si c'est le cas, vous le modéliserez avec une relation d'extension à un autre cas d'utilisation.
- Les cas d'utilisation ont-ils des noms uniques, intuitifs et significatifs de manière à ce qu'ils ne soient pas mélangés dans une étape ultérieure ? Si ce n'est pas le cas, vous devez changer leurs noms.
- Les clients et autres utilisateurs comprennent-ils les noms descriptifs des cas d'utilisation ? Chaque nom de cas d'utilisation doit décrire le comportement du cas d'utilisation.
- Les cas d'utilisation satisfont-ils à toutes les exigences qui régissent leurs performances ? Vous devez inclure toutes exigences (non fonctionnelles) devant être traitées dans les modèles d'objets des exigences spéciales du cas d'utilisation.
- La séquence de communication entre l'acteur et le cas d'utilisation est-elle conforme aux attentes de l'utilisateur ?
- Le moment et la manière dont le flux des événements démarre et s'arrête sont-ils clairs ?
- Un comportement qui n'est activé que lorsqu'une condition n'est satisfaite peut exister. Y a-t-il une description de ce qui se produit lorsqu'une condition donnée n'est pas satisfaite ?
- Certains cas d'utilisation sont-ils trop complexes ? Si vous voulez que votre modèle de cas d'utilisation soit facile à comprendre, vous aurez peut être à scinder les cas d'utilisation complexes.
- Y a-t-il un cas d'utilisation qui contient des flux d'événements disparates ? Si c'est le cas, il serait préférable de le diviser en deux ou plusieurs cas d'utilisation distincts. Un cas d'utilisation qui contient des flux d'événements disparates sera très difficile à comprendre et à maintenir.
- Le sous-flux d'un cas d'utilisation est-il modélisé d'une manière précise ?
- Est-il clair pour celui qui souhaite exécuter un cas d'utilisation ? L'objet du cas d'utilisation est-il également clair ?
- Les interactions avec les acteurs et les informations échangées sont-elles claires ?
- La description brève donne-t-elle une image réelle du cas d'utilisation ?
| |
|