Artefact :
|
![]() | Un cas d'utilisation définit un jeu d'instances de cas d'utilisation où chaque instance constitue une séquence d'actions effectuée par le système, débouchant sur un résultat dont la valeur est observable par un acteur spécifique. |
---|---|
Autres relations : |
Partie de Modèle de cas d'utilisation
Etend : Exigence logicielle |
Rôle : | Spécificateur d'exigences |
Caractère facultatif/Occurrence: | Requis lorsque des techniques de cas d'utilisation sont à utiliser. |
Modèles et rapports : |
|
Exemples : |
|
Représentation UML : | Cas d'utilisation (première classe d'élément UML) |
Informations supplémentaires : |
L'objet principal du cas d'utilisation est de recenser, depuis la perspective de l'utilisateur final, le comportement requis du système afin d'atteindre un ou plusieurs objectifs souhaités.
Les cas d'utilisation constituent un artefact central dans RUP, et en tant que tels sont utilisés dans de nombreux rôles et cadres, notamment :
Le modèle de spécification de cas d'utilisation fourni contient les propriétés texte du cas d'utilisation. Ce document est utilisé avec un outil de gestion des exigences, comme Rational RequisitePro, afin de spécifier et de marquer les exigences dans les propriétés du cas d'utilisation.
Un cas d'utilisation consiste essentiellement d'une spécification textuelle (dénommée Spécification de cas d'utilisation) contenant un énoncé du flux d'événements et décrivant l'interaction entre les acteurs et le système. Cette spécification contient aussi généralement d'autres informations, telles que préconditions, postconditions, exigences spéciales et scénarios clés. Le cas d'utilisation peut aussi être représenté dans UML sous une forme visuelle présentant les relations avec d'autres cas d'utilisation et acteurs.
Nom de la propriété | Brève description | Représentation UML |
---|---|---|
Nom | Nom du cas d'utilisation. | Attribut "Nom" pour l'élément de modélisation. |
Brève description | Brève description du rôle et de l'objet du cas d'utilisation. | Valeur marquée, de type "texte court". |
Flux d'événements | Description textuelle de ce que réalise le système dans le cadre du cas d'utilisation (et non pas de la manière dont des problèmes spécifiques sont résolus par le système). Cette description doit être intelligible pour le client. | Valeur marquée, de type "texte mis en forme". |
Exigences spéciales | Description textuelle qui rassemble toutes les exigences, par exemple non fonctionnelles, qui ne sont pas couvertes par le cas d'utilisation mais qui doivent être prises en compte lors de la conception ou de l'implémentation. | Valeur marquée, de type "texte court". |
Préconditions | Description textuelle définissant une contrainte sur le système quant aux conditions dans lesquelles le cas d'utilisation peut démarrer. | Valeur marquée, de type "texte court". |
Postconditions | Description textuelle définissant une contrainte sur le système quant aux conditions dans lesquelles le cas d'utilisation doit se terminer. | Valeur marquée, de type "texte court". |
Points d'extension | Liste d'emplacements dans le flux d'événements du cas d'utilisation où un comportement additionnel peut être inséré à l'aide d'une relation d'extension. | Valeur marquée, de type "texte court". |
Relations | Relations telles que communication d'associations, inclusion, généralisation et extension, auxquelles participe le cas d'utilisation. | Appartenance à un package englobant, via l'agrégation "propriétaire de". |
Diagrammes d'activité | Ces diagrammes illustrent la structure du flux d'événements. | Les participants ont un propriétaire via l'agrégation "types" et des "relations" sur une collaboration reliée au cas d'utilisation. |
Diagrammes de cas d'utilisation | Ces diagrammes illustrent les relations impliquant le cas d'utilisation. | Les participants ont un propriétaire via l'agrégation "types" et des "relations" sur une collaboration reliée au cas d'utilisation. |
Autres diagrammes | Autres illustrations graphiques du cas d'utilisation. | Valeur marquée, de type non interprété. |
Les cas d'utilisation sont identifiés, et peuvent être brièvement décrits, vers le début de la phase de création afin de faciliter la définition de la portée du système. Les cas d'utilisation ayant une incidence sur l'analyse ou la conception de l'architecture du système sont ensuite décrits en détails au cours de la phase d'élaboration. Les autres le sont lors de la phase de construction.
Un Spécificateur d'exigences est responsable de l'intégrité du cas d'utilisation, garantissant que :
Il est recommandé que le spécificateur des exigences responsable d'un cas d'utilisation soit aussi chargé du package où il est intégré. Pour plus d'informations, voir Principes et conseils : Package de cas d'utilisation.
Déterminez le niveau d'élaboration requis pour le cas d'utilisation :
Certains projets emploient les cas d'utilisation de manière informelle afin de détecter les exigences mais documentent et assurent la maintenance de ces exigences sous une autre forme. La personnalisation adoptée pour vos cas d'utilisation peut dépendre de l'envergure du projet, de l'expérience acquise, de votre jeu d'outils, des relations avec le client, etc. Voir Principes et conseils : Cas d'utilisation pour plus d'indications sur la personnalisation des cas d'utilisation.
RUP (Rational Unified Process)
|