Un schéma plutôt qu’un beau discours
Après avoir défini le périmètre du projet et ses objectifs généraux (vente en ligne de photos imprimées à la demande), ayant établi une liste des fonctionnalités principales, il faut maintenant étudier, plus en détails, comment les intervenants vont interagir en termes de processus. C’est ce qu’on appelle les cas d’utilisation ou « Use Cases ».
S’il est tentant, à ce stade, de décrire en long et en large les différents flux et actions, il peut s’avérer préférable de réaliser un schéma, moins verbeux. Si on y trouve très peu de texte (seuls quelques petites remarques ou commentaires, aidant à la compréhension immédiate), n’oublions pas que chaque fonctionnalité sera décrite ultérieurement dans des « User Stories ».
But use cases : Décrire en détail comment un utilisateur (acteur) interagit avec un système pour atteindre un objectif.
But user stories: Décrire pourquoi et pour qui une fonctionnalité est nécessaire, sans détailler le “comment”.
Pragmatisme agile
Dans un contexte d’agilité pure, on commencerait probablement par rédiger les User Stories avant de schématiser les Use Cases. Je trouve qu’il est plus judicieux de commencer par le schéma, afin d’avoir une vue globale des flux et processus, plutôt que de commencer avec un focus spécifique sur un objectif précis. Certaines personnes préfèrent la représentation schématique, alors que d’autres sont plus réceptives au formalisme des User Stories. Les deux approches sont complémentaires, nécessaires et suffisantes dans la plupart des cas.
Rappelons qu’il s’agit surtout de moyens d’analyser, de réfléchir à un projet, en mode évolutif « Work In Progress ». Il arrive que des nouveaux besoins soient découverts en cours d’analyse, alors que d’autres fonctionnalités sont abandonnées. C’est par exemple le cas de la recherche par mots-clés prévue au départ, mais qui s’avère finalement peu adaptée au type de site internet considéré ici. En revanche, certains besoins ont été précisés, les voici.
- Pouvoir passer commande en tant qu’invité, sans devoir obligatoirement créer un compte.
- Proposer au téléchargement gratuit un fond d’écran pour mobile (1290 × 2796) représentant la photo.
- Proposer des réductions sous deux formes : pour tous, avec un code promo.
- Ajouter au panier d’achats ou commander directement une photo (si possible).
Une petite dose d’UML
Le but du schéma Use Cases est d’illustrer les actions possibles d’un utilisateur (visiteur du site) et les parcours qu’il doit emprunter pour atteindre ses objectifs (naviguer dans le catalogue des photos, zoomer sur un visuel, obtenir des informations comme le prix, passer commande, etc.).
Sont également schématisées les (ré)actions du site internet (blocs verts), qui sont volontairement simplifiées (pas de différenciation back et front end, pas de représentation de la base de données ou des API).
Les notations UML suivantes sont utilisées : <<include>> (inclusion obligatoire, déclenchement automatique de l’action liée) et <<extend>> (extension optionnelle, déclenchée suite à une action d’un persona).
Certaines fonctionnalités non essentielles « nice to have » sont représentées en orange, alors que d’autres sont abandonnées en cours de réflexion et sont marquées en rouge.
Les interactions avec des systèmes externes sont indiquées en noir, « hors scope ».
Parfois, plusieurs orientations sont possibles dans le workflow, sur base d’une réponse à une question. La représentation est un losange turquoise.
La Figure 1 illustre la légende du schéma.
Analyses complémentaires et granularité
Certaines actions demandent une analyse plus profonde (ex. : paniers d’achats session et enregistré), pour voir ce qu’il est possible de faire, sur base du module WordPress/WooCommerce choisi, sans avoir recours à du code custom (sur mesure). En fonction du besoin, une analyse technique formelle peut être réalisée.
Le niveau de détail fixé n’est pas très fin. Par exemple, le processus de rappel du mot de passe (cf. Figure 2) en cas d’oubli ne prend pas en compte la mention d’une adresse e-mail non existante en référentiel ou le fait que l’utilisateur doive cliquer sur un lien dans l’e-mail automatiquement envoyé pour réinitialiser son mot de passe.
Et après ?
Dans un article prochain, nous verrons comment les User Stories, avec leur structure « En tant que… Je souhaite… Afin de… » permettent de traduire les actions du schéma en fonctionnalités décrites du point de vue de l’utilisateur, en favorisant la plus-value apportée pour atteindre un objectif précis.