Activité :
|
Objet
|
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 : |
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 :
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.
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.
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 :
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.
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.
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.
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.
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).
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.
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:
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.
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 :
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.
Incluez les éléments suivants dans votre description générale du modèle de cas d'utilisation :
Vois aussi la section Description générale dans Principes et conseils : Modèle de cas d'utilisation.
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 :
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)
|