"Les cas d'utilisation, c'est bien, mais leur description détaillée est
un peu lourde. Finalement, nous ce qui nous intéresse c'est la
spécification des écrans.", voilà ce qu'un développeur m'a récemment dit concernant des spécifications fonctionnelles
que j'avais rédigées. L'approche par cas d'utilisations (use case) pour expliciter les exigences fonctionnelles d'un système est un grand classique de la MOA. Mais alors si les développeurs les jugent indigestes, à qui et à quoi servent-ils ? C'est en lisant ce billet Use
cases: a personal history (and a bit of a love affair) de Laura Brandenburg,
que je me suis rendu compte que je n'étais pas le seul à me poser ces
questions.
Rappels sur les cas d'utilisation
Un diagramme de cas d'utilisation en UML permet de figurer le comportement d'un système face aux stimulations d'acteurs externes, le tout avec un formalisme extrêmement simple.Voilà un exemple décrivant le fonctionnement d'un restaurant :
Un cas d'utilisation est représenté par une "patate". Chaque cas d'utilisation peut ensuite être décrit de manière détaillée avec par exemple le formalisme suivant :
Les cas d'utilisation pour discuter avec le métier
L'avantage d'un diagramme de cas d'utilisation est qu'il est très simple à comprendre. Hormis les associations de type "extends" ou "includes", le formalisme se comprend de lui même. Donc pour appréhender un système existant ou pour expliciter le périmètre d'un projet, ce genre de diagramme me parait indispensable. Et même si on travaille avec des "user stories" dans le cadre d'une méthode agile, réaliser un diagramme de cas d'utilisation permet d'avoir une vision d'ensemble, nécessaire pour les discussions au niveau d'un processus.
Les cas d'utilisation comme outil d'analyse
A moins d'être sur une évolution très simple ou d'être un expert du sujet, il me parait impossible de passer directement du besoin exprimé par l'utilisateur à une maquette détaillée de l'interface prête à être réalisée par l'équipe de développement. Alors comment mener l'analyse qui permettra de rédiger une spécification fonctionnelle détaillée ? Et bien par exemple en utilisant le modèle présenté précédemment pour expliciter les cas d'utilisations car il permet de :
- Formaliser l'exécution normale du cas d'utilisation ;
- Découvrir les cas alternatifs, qui sont souvent oubliés par les différentes parties-prenantes ;
- Découvrir les règles métiers, même celles qui ne se traduiront pas par une règle dans l'interface graphique.
Même si finalement les développeurs auront tendance à se focaliser sur la description des IHM, les cas d'utilisation facilitent la conception de ces IHM et permettent d'avoir rapidement une vision globale du système ou processus étudié. Alors oui, ils peuvent paraitre trop simplistes sous forme de diagramme et trop complexes lorsqu'ils sont explicités de manière détaillée, mais il me semble que c'est un outil indispensable à toute analyse fine du métier.
!