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 :   
Entrée d'activités :    Sortie d'activités :   

Objet Haut de la page

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 :

  • Par les clients, pour décrire ou tout au moins approuver la description du comportement du système.
  • Par les utilisateurs potentiels, pour déchiffrer le comportement du système.
  • Par les architectes logiciels, pour identifier les fonctionnalités importantes du point de vue de l'architecture.
  • Par les personnes chargées d'analyser, de concevoir et d'implémenter le système, pour saisir le comportement requis du système et perfectionner sa définition.
  • Par les concepteurs, afin d'identifier des classes à partir du flux d'événements des cas d'utilisation.
  • Par les testeurs, en tant que base à partir de laquelle ils peuvent identifier un sous-ensemble de scénarios de test requis.
  • Par les responsables, afin de planifier et d'évaluer la charge de travail de chaque itération.
  • Par les rédacteurs de la documentation, pour comprendre le comportement du système depuis la perspective de la séquence d'utilisation à décrire dans la documentation (comme le guide de l'utilisateur du système).

Bref aperçu Haut de la page

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. 

Propriétés Haut de la page

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é. 

Calendrier Haut de la page

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.

Responsabilité Haut de la page

Un Spécificateur d'exigences est responsable de l'intégrité du cas d'utilisation, garantissant que :

  • le cas d'utilisation se conforme à ses exigences (c'est-à-dire décrit la fonctionnalité pertinente au cas d'utilisation, et seulement celle-ci)
  • le flux d'événements est lisible et est adapté à son objectif
  • les relations de cas d'utilisation provenant de ce cas d'utilisation sont justifiées et maintenues cohérentes
  • le rôle du cas d'utilisation en cas de communication d'associations est clair et intuitif
  • les diagrammes décrivant le cas d'utilisation et ses relations sont intelligibles et adaptés à leur objectif
  • les exigences spéciales sont intelligibles et adaptées à leur objectif
  • les préconditions sont intelligibles et adaptées à leur objectif
  • les postconditions sont intelligibles et adaptées à leur objectif

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.

Personnalisation Haut de la page

Déterminez le niveau d'élaboration requis pour le cas d'utilisation :

  • Description des flux principaux seulement ?
  • Description des cas d'utilisation les plus importants seulement ?
  • Description complète des préconditions et des postconditions ?

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)   2003.06.15