Recueillir efficacement les besoins
CHAPITRE 3
97
L’exemple pris par Mike Cohn 1 nous démontre que cette description statique présente
quelques inconvénients. Imaginons la description suivante :
• Le produit devra fonctionner avec un moteur à essence.
• Le produit devra être équipé de quatre roues.
• Le produit devra être équipé de pneus gomme sur chaque roue.
• Le produit devra disposer d’un volant.
• Le produit devra avoir une structure en acier.
Tout laisse supposer que le produit décrit est une voiture. Encore que des exigences
complémentaires soient nécessaires pour préciser la forme, la couleur, le modèle, la
puissance… de cette voiture.
Imaginons, à présent, que l’approche adoptée soit davantage orientée vers les buts et
besoins de l’utilisateur :
• En tant qu’utilisateur, je veux tondre ma pelouse plus rapidement et plus facilement.
• En tant qu’utilisateur, je veux pouvoir être confortablement assis lorsque je tonds ma
pelouse.
• En tant qu’utilisateur, je veux pouvoir parcourir le terrain et manœuvrer.
En analysant ces exigences orientées vers l’usage de l’utilisateur, on comprend rapidement qu’il s’agit d’une tondeuse autoportée que souhaite le client et non une voiture !
Documenter toutes les exigences d’un système en appliquant la norme IEEE présente un
double inconvénient : d’une part, cela peut être fastidieux car consommateur de temps, et
d’autre part on se focalise davantage sur la description du produit ou du système plutôt que
sur les buts des utilisateurs. On imagine, en outre, la difficulté pour prioriser ces exigences et
estimer le coût de chacune d’entre elles, compte tenu de leur degré de finesse.
Deux solutions fondées sur le fonctionnement du système ou du produit nous sont proposées ; il s’agit de techniques de formalisation plus dynamiques, l’une plus « classique »,
avec les cas d’utilisation (use cases), la seconde plus « légère », les user stories.
Les cas d’utilisation d’UML
Le cas d’utilisation ou use cases est une technique de formalisation ou de modélisation
UML, recommandée, entre autres, dans la méthode du Processus unifié (use-case driven
development).
Un cas d’utilisation (UC) décrit, d’un point de vue strictement fonctionnel, les échanges
entre le système à développer et les acteurs externes (utilisateurs ou autre système), dans
un contexte particulier. Il décompose l’usage qui est fait du produit ou du système à développer dans un but précis. La séquence d’étapes pour atteindre ce but est décrite dans un
scénario nominal ; mais l’on doit envisager différentes séquences, selon les conditions
qui peuvent varier, pour atteindre le même but ou échouer ; ce sont les scénarios d’exception ou d’échec.
1. http://.mountaingoatsoftware.com
GestProjInform Livre Page 97 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 3
97
L’exemple pris par Mike Cohn 1 nous démontre que cette description statique présente
quelques inconvénients. Imaginons la description suivante :
• Le produit devra fonctionner avec un moteur à essence.
• Le produit devra être équipé de quatre roues.
• Le produit devra être équipé de pneus gomme sur chaque roue.
• Le produit devra disposer d’un volant.
• Le produit devra avoir une structure en acier.
Tout laisse supposer que le produit décrit est une voiture. Encore que des exigences
complémentaires soient nécessaires pour préciser la forme, la couleur, le modèle, la
puissance… de cette voiture.
Imaginons, à présent, que l’approche adoptée soit davantage orientée vers les buts et
besoins de l’utilisateur :
• En tant qu’utilisateur, je veux tondre ma pelouse plus rapidement et plus facilement.
• En tant qu’utilisateur, je veux pouvoir être confortablement assis lorsque je tonds ma
pelouse.
• En tant qu’utilisateur, je veux pouvoir parcourir le terrain et manœuvrer.
En analysant ces exigences orientées vers l’usage de l’utilisateur, on comprend rapidement qu’il s’agit d’une tondeuse autoportée que souhaite le client et non une voiture !
Documenter toutes les exigences d’un système en appliquant la norme IEEE présente un
double inconvénient : d’une part, cela peut être fastidieux car consommateur de temps, et
d’autre part on se focalise davantage sur la description du produit ou du système plutôt que
sur les buts des utilisateurs. On imagine, en outre, la difficulté pour prioriser ces exigences et
estimer le coût de chacune d’entre elles, compte tenu de leur degré de finesse.
Deux solutions fondées sur le fonctionnement du système ou du produit nous sont proposées ; il s’agit de techniques de formalisation plus dynamiques, l’une plus « classique »,
avec les cas d’utilisation (use cases), la seconde plus « légère », les user stories.
Les cas d’utilisation d’UML
Le cas d’utilisation ou use cases est une technique de formalisation ou de modélisation
UML, recommandée, entre autres, dans la méthode du Processus unifié (use-case driven
development).
Un cas d’utilisation (UC) décrit, d’un point de vue strictement fonctionnel, les échanges
entre le système à développer et les acteurs externes (utilisateurs ou autre système), dans
un contexte particulier. Il décompose l’usage qui est fait du produit ou du système à développer dans un but précis. La séquence d’étapes pour atteindre ce but est décrite dans un
scénario nominal ; mais l’on doit envisager différentes séquences, selon les conditions
qui peuvent varier, pour atteindre le même but ou échouer ; ce sont les scénarios d’exception ou d’échec.
1. http://.mountaingoatsoftware.com
GestProjInform Livre Page 97 Vendredi, 3. avril 2009 12:07 12