Un cas d’utilisation, c’est quoi et qu’est-ce que ça contient ?

Un cas d’utilisation:

• Est une description écrite de la manière dont les utilisateurs effectueront des tâches sur votre site Web.
• Il décrit, du point de vue de l’utilisateur, le comportement d’un système lorsqu’il répond à une demande.
• Il est représenté comme une séquence d’étapes simples, commençant par l’objectif de l’utilisateur et se terminant lorsque cet objectif est atteint.

Pourquoi écrire un cas d'utilisation ?

En tant que chef d’entreprise, vous vous demandez peut-être comment communiquer les exigences techniques ou les exigences logicielles.

Comment puis-je communiquer avec mes développeurs pour m’assurer que le développement effectué réponds au besoin prononcé ?

C’est l’un des meilleurs outils ou l’une des meilleures raisons d’utiliser un cas d’utilisation, car il s’agit d’un point de connexion entre les utilisateurs commerciaux et techniques. Ils devraient être en mesure de les comprendre et de fournir des informations en retour.

En tant qu’analystes d’affaires, nous les utilisons comme un outil de communication pour relier les gens entre eux, en termes de technique commune, de langage commun sur ce que le logiciel fera.

Il vous aide:

• à communiquer avec les parties prenantes
• de vous débarrasser de ce langage « textuel »,
• en vous concentrant davantage sur ce que fait le système que sur la manière dont il le fait.

Cela permet d’accélérer la communication, de clarifier les choses et de s’assurer que vous construisez ce dont l’entreprise a réellement besoin et ce qu’elle veut lorsque vous vous asseyez et travaillez sur le code.

Qu'est-ce qu'un cas d'utilisation ?

Comment cela résout-il ces problèmes pour nous, analystes, techniciens, utilisateurs professionnels ?

C’est une description textuelle qui capture l’interaction utilisateur-système. C’est l’interaction entre l’utilisateur et un système logiciel.

C’est différent d’un processus d’affaire, qui pourrait capturer toutes les choses que l’utilisateur ferait pour atteindre un objectif ou un résultat plus large dans l’organisation.

Le cas d’utilisation traite un objectif plus granulaire. Ainsi, il peut s’agir de « Acheter un cours« , « Regarder une vidéo« . « S’inscrire à une formation gratuite« . Des choses comme ça. Des choses très spécifiques et concrètes qu’un utilisateur peut faire avec le système logiciel, et cela capture toutes les façons dont cet utilisateur et le système peuvent interagir.

Toutes les exceptions et variations et ce qui se passe si vous allez acheter un cours, et que votre adresse e-mail n’est pas valide ou que votre carte de crédit n’est pas valide ou quelque chose comme ça. Toutes ces variations de ce qui peut aller mal dans les chemins de variantes dans la portée du système seulement. C’est ce qui nous permet d’obtenir les exigences du logiciel.

Que contient un cas d'utilisation ?

Nous allons passer en revue les sections communes qui se trouvent dans un modèle de cas d’utilisation très traditionnel.

Il faut commencer par un nom, et comme pour un processus métier, il faut que ce nom soit un verbe et un nom. Donc, « Acheter un cours », « S’inscrire à une formation gratuite », et pas seulement « Le cas d’utilisation de la formation gratuite ». Vous voulez savoir : quelle est l’action de l’utilisateur qui va être décrite dans le cas d’utilisation ?

Ensuite, il y a une brève description, et l’une des choses que j’aime vraiment inclure dans ma brève description est une phrase qui précise vraiment la portée. « Ce cas d’utilisation commence quand… » et « Ce cas d’utilisation se termine quand… » parce que ce qui se passe quand vous commencez à écrire toutes ces étapes, c’est que vous trouvez toutes ces variations. Puis, tout d’un coup, votre cas d’utilisation est partout, et vous êtes comme, « ce n’est pas une séquence d’étapes. C’est une toile. » C’est généralement parce que vous vous égarez, ou que vous explorez les alternatives de manière trop détaillée, ou que vous ne restez tout simplement pas dans le cadre des étapes qui doivent se produire pour l’objectif spécifique de ce cas d’utilisation. « Commence quand », « Finit quand ».

L’acteur : qui sont les utilisateurs, ou les rôles, ou les types d’acteurs qui pourraient utiliser le système ? Il ne s’agit pas d’un titre de poste, mais d’un acteur. Plusieurs personnes peuvent remplir ce rôle avec le système. Il s’agit de ce que le système peut identifier à votre sujet. Êtes-vous un acheteur ? Êtes-vous un administrateur ? Êtes-vous un journaliste ? Quelque chose comme ça.

Conditions préalables : Qu’est-ce qui doit être vrai avant que le cas d’utilisation ne commence ? Là encore, il s’agit d’un niveau très système. Que doit savoir le système pour être vrai avant que le cas d’utilisation ne commence ?

Ensuite, vous entrez dans le flux de base, et j’aime penser au flux de base comme au ping-pong. L’utilisateur fait une chose, le système en fait une autre. L’utilisateur fait une chose, le système en fait une autre. « Ping pong, ping pong. »

Ce n’est pas toujours aussi clair. Parfois c’est comme, « Ping, ping, pong, pong, pong. Ping pong. » Il n’est pas nécessaire que ce soit un seul va-et-vient comme ça, mais le fait d’y penser comme à un ping-pong aide vraiment à s’assurer que vous obtenez cette interaction utilisateur-système.

Ensuite, les flux alternatifs et les flux d’exception. Ce sont les chemins de variantes. Parfois – voyons un exemple. Pour « Regarder la vidéo », vous pourriez avoir « Pause ». Vous pouvez mettre la vidéo en pause. Vous pouvez terminer la vidéo. Vous pouvez faire différentes choses. Vous pouvez « Aimer » la vidéo. Parfois, cela peut ne pas rentrer dans le cadre de ce cas d’utilisation, mais toutes les différentes choses que vous pouvez faire.

Un flux d’exception pourrait être : que se passe-t-il si votre connexion Internet se coupe et que le flux se termine ? Comment cela est-il présenté à l’utilisateur ? Les choses qui tournent mal et empêchent les gens d’atteindre l’objectif final ou la fin du cas d’utilisation.

Les post-conditions sont ce qui est vrai après la fin du cas d’utilisation. S’il y a des informations qui doivent être stockées ou des sorties qui doivent être générées, elles doivent toutes avoir des étapes dans votre cas d’utilisation, et vous pouvez les capturer en tant que post-conditions, également.

Et si je ne connais pas la technologie ?

Une chose que je veux couvrir – et j’y ai fait allusion en décrivant un cas d’utilisation, mais nous recevons toujours beaucoup de questions à ce sujet – est : ce cas d’utilisation ne nécessite-t-il pas des connaissances techniques ? » Que dois-je faire si je ne connais pas la technique ? Comment communiquer avec les développeurs, et comment faire des choses comme les exigences ? Il semble que je doive connaître toute cette technologie, et que je doive connaître l’analyse commerciale. »

En réalité, vous devez considérer le cas d’utilisation comme un outil qui vous permet de communiquer sur ce que la technologie doit faire sans savoir comment elle est construite, car vous ne faites pas tous ces « Pong, pong, pong, pong ». Vous ne voyez pas toutes les pièces de la technologie qui se passent dans les coulisses.

Vous vous dites : « En tant qu’utilisateur, quelle est ma fonctionnalité observable ? Qu’est-ce que je vois le système faire pour moi ? » Nous devrions être en mesure d’être très clair à ce sujet en tant qu’analyste d’affaires.

C’est une partie de la clarté que nous apportons à la table. C’est pour cela que les cas d’utilisation sont un si bon outil ; ils nous aident à poser des questions vraiment, vraiment intelligentes qui mettent en évidence les lacunes dans la réflexion, la compréhension et les exigences.

C’est le genre de réflexion étape par étape que vous voulez faire dans vos cas d’utilisation et que vous voulez mettre sur la table. Cela vous aide vraiment à comprendre la technologie sans avoir à la construire.

Conclusion

J’espère qu’il s’agit là à la fois d’un tutoriel sur la façon de créer un cas d’utilisation et d’une leçon sur les raisons pour lesquelles ils sont si amusants et si importants, et sur la façon dont ils constituent un outil d’analyse si puissant que vous pouvez utiliser pour clarifier les exigences entre vos parties prenantes commerciales et technologiques, pour que tout le monde soit vraiment sur la même longueur d’onde quant à ce que le logiciel doit faire en utilisant un outil de communication et un outil d’analyse qui vous aide à découvrir les lacunes et à communiquer avec des personnes qui sont à la fois techniques et non techniques.

Besoin d’une montée en compétence à ce sujet ?

Réservez votre Coaching gratuit en Cliquez Ici. ça ne vous coûte rien.

Vous êtes un centre de compétences

Contactez nous sur: contact@digiar.be / +32 497 722 741