Objet
  • Définir la portée du système, en d'autres termes, ce qui sera géré par le système et ce qui sera géré en dehors du système.
  • Définir les personnes et les éléments qui interagiront avec le système.
  • Décrire le fonctionnement du système.
Rôle :  Analyste système 
Fréquence : Selon les besoins. Généralement, plusieurs fois pour chaque itération, notamment pendant les phases de création et d'élaboration.
Etapes
Artefacts d'entrée :    Artefacts de sortie :   
Plus d'informations :   
Guides d'utilisation de l'outil :   

Détails sur l'enchaînement des activités :   

Identifier les acteurs Haut de la page

L'identification des acteurs est l'une des premières étapes à effectuer pour définir l'utilisation d'un système. Chaque type de phénomène extérieur avec lequel le système doit interagir est représenté par un acteur. Pour identifier les acteurs, posez-vous les questions suivantes :

  • Quels groupes d'utilisateurs ont besoin du système pour effectuer leur travail ?
  • Quels groupes d'utilisateurs sont indispensables à l'exécution des principales fonctions du système ?
  • Quels groupes d'utilisateurs sont nécessaires à l'exécution de fonctions secondaires, comme la maintenance et l'administration du système ?
  • Le système va-t-il interagir avec des systèmes matériels ou logiciels extérieurs ?

Chaque personne, groupe ou phénomène qui entre dans une ou plusieurs de ces catégories est susceptible d'être ajouté à la liste des acteurs.

Pour savoir si vous avez choisi les bons acteurs (humains), vous pouvez désigner deux ou trois personnes qui joueront le rôle d'acteur, ce qui vous permettra de voir si les acteurs que vous avez définis suffisent à répondre à leurs besoins. Pour plus d'informations sur les caractéristiques d'un acteur, voir Principes et conseils : Acteur.

Dans un premier temps, il peut être difficile d'identifier les acteurs appropriés. D'ailleurs, vous ne pourrez pas les identifier tous tant que vous n'aurez pas votre liste complète de cas d'utilisation. En effet, seule l'analyse des cas d'utilisation peut vous donner une compréhension suffisante de l'environnement du système et des différentes interactions avec le système. Une fois cette analyse effectuée, vous pourrez revoir votre modèle d'origine, car il est fréquent de choisir trop d'acteurs dans un premier temps. Toutefois, soyez vigilent si vous changez les acteurs : cela peut affecter les cas d'utilisation. Toute modification des acteurs constitue un changement majeur au niveau des interfaces et du comportement du système.

Nommez et décrivez brièvement les acteurs identifiés

Le nom de l'acteur doit renseigner sur son rôle. Vous devez également vous assurer que le nom de votre acteur ne risque pas d'être confondu avec un autre nom d'acteur.

Rédigez une brève description indiquant les responsabilités de l'acteur et les raisons pour lesquelles il a besoin du système. Etant donné que les acteurs sont des éléments extérieurs au système, il est inutile de les décrire en détail. Voir aussi la section Brève description dans Principes et conseils : Acteur.

Identifier les cas d'utilisation Haut de la page

Après avoir effectué une première ébauche de la liste des acteurs, l'étape suivante consiste à identifier les cas d'utilisation applicables au système. Les premiers cas d'utilisation ne sont pas définitifs, vous serez certainement amené à les modifier plusieurs fois avant qu'ils ne deviennent stables. Si la vision ou les exigences du système sont incomplètes, ou si l'analyse du système est vague, le fonctionnement du système ne sera pas clair. Par conséquent, vous devez toujours vous demander si vous avez identifié les cas d'utilisation appropriés. En outre, vous n'obtiendrez une version finale qu'après avoir maintes fois ajouté, supprimé, combiné et scindé des cas d'utilisation. Vous aurez une meilleure compréhension des cas d'utilisation une fois que vous les aurez décrits en détail.

Pour identifier les cas d'utilisation appropriés, commencez par réfléchir à ce que chaque acteur attend du système. Il ne faut jamais oublier qu'un système n'existe qu'à travers ses utilisateurs, et doit donc être basé sur leurs besoins. L'étude des exigences fonctionnelles définies pour le système vous permettra de mettre en lumière la plupart des besoins des acteurs. Pour chaque acteur, humain ou non, posez-vous les questions suivantes :

  • Du point de vue de l'acteur, quelles sont les principales tâches que le système doit exécuter ?
  • L'acteur va-t-il créer, stocker, modifier, supprimer ou lire des données dans le système ?
  • L'acteur sera-t-il amené à informer le système de changements extérieurs soudains ?
  • L'acteur doit-il être informé de certains événements qui se produisent dans le système ?
  • L'acteur sera-t-il amené à démarrer ou à arrêter le système ?

Les réponses à ces questions représentent les flux d'événements qui identifient les cas d'utilisation susceptibles d'être retenus. Tous les cas d'utilisation potentiels ne constituent pas forcément des cas distincts : certains peuvent être des variantes d'un même cas. Il n'est pas toujours aisé de déterminer s'il s'agit d'une variante ou d'un cas d'utilisation distinct. Toutefois, les choses se clarifieront lorsque vous décrirez les flux d'événements de manière détaillée.

Outre les exigences, un modèle d'entreprise de votre organisation (également appelé modèle métier) peut constituer une source d'informations précieuse lors de l'identification des cas d'utilisation. Un modèle d'entreprise explique comment le système d'information peut être incorporé aux opérations existantes, vous donnant ainsi une bonne représentation de l'environnement du système. Vous trouverez également des concepts à définir dans le modèle d'entreprise, car il contient les "objets métier" de l'entreprise.

Plusieurs modèles de cas d'utilisation peuvent être définis pour un système. Pour identifier le modèle "optimal", créez deux ou trois modèles, choisissez celui que vous préférez et développez-le plus en détail. Le développement de plusieurs modèles possibles vous aide également à mieux comprendre le système.

Une fois que vous avez défini votre premier modèle de cas d'utilisation, vérifiez qu'il répond bien à toutes les exigences fonctionnelles. Relisez attentivement la liste d'exigences pour vous assurer que tous vos cas d'utilisation répondent bien à toutes les exigences.

Pour plus d'informations sur les caractéristiques des cas d'utilisation et la marche à suivre pour les identifier, voir Principes et conseils : Modèle de cas d'utilisation et Principes et conseils : Cas d'utilisation.

Nommez et décrivez brièvement les cas d'utilisation identifiés

Le nom d'un cas d'utilisation doit refléter le résultat obtenu suite à ses interactions avec les acteurs concernés. Si cela s'avère nécessaire à la compréhension de la fonction du cas d'utilisation, n'hésitez pas à choisir un nom comportant plusieurs mots. Chaque cas d'utilisation doit porter un nom unique. Voir aussi la section Nom dans Principes et conseils : Cas d'utilisation.

Définissez chaque cas d'utilisation en rédigeant une brève description. Pour écrire cette description, référez-vous au glossaire et, si nécessaire, définissez de nouveaux concepts. Voir aussi la section Brève description dans Principes et conseils : Cas d'utilisation.

Définissez le flux d'événements

A ce stade, vous devez également développer une première ébauche du flux d'événements du cas d'utilisation. Décrivez chaque flux comme une brève étape de performance, sans entrer dans les détails. La personne qui sera chargée de spécifier le cas d'utilisation (même si c'est vous) aura besoin de cette description étape par étape. Commencez par décrire le flux d'événements principal et ajoutez ensuite les flux supplémentaires.

Exemple :

La première description étape par étape du flux d'événements du cas d'utilisation Recyclage d'articles pour un système de recyclage pourrait être la suivante :

  • Le client appuie sur le bouton "Démarrer".
  • Le client introduit les articles à recycler.
  • Le système détermine les types d'articles.
  • Le système incrémente le total quotidien pour chaque type d'article reçu.
  • Le client appuie sur le bouton "Reçu".
  • Le système imprime le reçu.
Répertorier les exigences supplémentaires

Certaines exigences liées au système ne peuvent pas être associées à un cas d'utilisation particulier : énumérez-les dans les Spécifications supplémentaires (voir Artefact : Spécifications supplémentaires).

Décrire les interactions des acteurs et des cas d'utilisation Haut de la page

Etant donné qu'il est important de voir comment les acteurs sont liés aux cas d'utilisation, il convient de dresser la liste de tous les acteurs susceptibles d'interagir avec chaque cas d'utilisation identifié. Pour cela, vous devez définir une association de communication navigable dans le même sens que la transmission de signal entre l'acteur et le cas d'utilisation.

En général, les transmissions de signal sont bidirectionnelles. Dans ce cas, les associations de communication doivent être navigables dans les deux sens. Vous devez définir au maximum une association de communication par paire acteur-cas d'utilisation.

En outre, vous devez décrire brièvement chaque association de communication définie.

Pour plus d'informations, voir Principes et conseils : association des communications.

Regrouper les cas d'utilisation et les acteurs Haut de la page

Si vous avez trop d'acteurs et de cas d'utilisation, regroupez-les en packages afin de simplifier la maintenance du modèle de cas d'utilisation. Cela facilite également la compréhension du modèle de cas d'utilisation et simplifie l'affectation des responsabilités au sein du modèle en permettant aux développeurs d'être chargés de groupes de cas d'utilisation ou d'acteurs.

Par exemple, des cas d'utilisation peuvent être regroupés si:

  • Ils interagissent avec le même acteur.
  • Ils ont des relations d'inclusion ou d'exclusion entre eux.
  • Ils sont tous optionnels et sont disponibles soit tous ensemble, soit pas du tout.

Il existe également d'autres motifs de regroupement. Toutefois, pour préserver la simplicité du modèle, il est important d'adopter une stratégie claire lorsque vous procédez à des regroupements.

Pour plus d'informations, voir Principes et conseils : Regroupement de cas d'utilisation.

Présenter le modèle de cas d'utilisation dans des diagrammes Haut de la page

Vous pouvez illustrer les relations entre les cas d'utilisation et les acteurs, mais aussi avec les cas d'utilisation associés, à l'aide de diagrammes. Ces diagrammes peuvent contenir les éléments suivants :

  • Les acteurs appartenant au même groupe de cas d'utilisation.
  • Un acteur et tous les cas d'utilisation avec lesquels il interagit.
  • Les cas d'utilisation qui traitent les mêmes informations.
  • Les cas d'utilisation utilisés par le même groupe d'acteurs.
  • Les cas d'utilisation qui sont souvent utilisés en une séquence.
  • Les cas d'utilisation qui appartiennent au même groupe de cas d'utilisation.
  • Les cas d'utilisation les plus importants. Un diagramme de ce type peut faire office de synthèse du modèle et peut être inclus dans la vue de cas d'utilisation.
  • Les cas d'utilisation développés ensemble (dans le même incrément).

Chaque diagramme doit appartenir au groupe correspondant dans le modèle de cas d'utilisation.

Pour plus d'informations, voir Principes et conseils : Diagramme de cas d'utilisation.

Développer une description générale du modèle de cas d'utilisation Haut de la page

Incluez les éléments suivants dans votre description générale du modèle de cas d'utilisation :

  • Séquences au cours desquelles les cas d'utilisation sont généralement exécutés par les utilisateurs.
  • Fonctions non assurées par le modèle de cas d'utilisation.

Vois aussi la section Description générale dans Principes et conseils : Modèle de cas d'utilisation.

Evaluer vos résultats Haut de la page

Vous devez évaluer votre modèle de cas d'utilisation à ce stade afin de vous assurer que votre travail semble correct, mais il est inutile de faire un contrôle détaillé. Vérifiez également les points de contrôle applicables aux modèles de cas d'utilisation. Concentrez-vous spécialement sur les points de contrôle relatifs aux acteurs, aux cas d'utilisation et aux modèles de cas d'utilisation, disponibles dans Activité : Revoir les exigences.

Il est important que des personnes extérieures à l'équipe de développement (par exemple, des utilisateurs ou des clients) approuvent le modèle de cas d'utilisation à ce stade. Par conséquent, vous devez impliquer les utilisateurs et le client dans le processus de conception du modèle de cas d'utilisation avant de terminer cette activité. Vous pouvez utiliser le rapport Etude sur le modèle de cas d'utilisation et ses diagrammes pour orienter les discussions.

Les parties concernées devront déterminer si :

  • Tous les cas d'utilisation nécessaires ont été identifiés.
  • Des cas d'utilisation inutiles ont été identifiés.
  • Le comportement de chaque cas d'utilisation est décrit dans le bon ordre.
  • Le flux d'événements de chaque cas d'utilisation est aussi complet qu'il peut l'être à ce stade.
  • La description générale permet de bien comprendre le modèle de cas d'utilisation.

Pour connaître les autres points à évoquer, voir les points de contrôle applicables aux acteurs, aux cas d'utilisation et aux modèles de cas d'utilisation, disponibles dans Activité : Revoir les exigences.



RUP (Rational Unified Process)   2003.06.15