Rediger une specification · rôle à tenir par l’agent : Analyste métier

Spécifier un parcours utilisateur de bout en bout

spe-parcours-utilisateur

Quand l’employer

À employer une fois le cadrage figé, pour un seul parcours à la fois. À ne pas employer pour spécifier trois parcours d'un coup : la spécification devient illisible et l'agent en construira un et demi.

Les 6 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{PARCOURS}: Quel parcours exactement, du premier geste de l'utilisateur jusqu'à la preuve qu'il a réussi ?; Pourquoi ce trou existe. Un parcours qui n'a pas de fin déclarée n'a pas de critère de réussite, donc rien à vérifier et rien à refuser.; Si vous ne savez pas répondre. Décrivez à voix haute ce que fait l'utilisateur, phrase par phrase, jusqu'au moment où il peut fermer l'écran satisfait. Ce moment est votre fin de parcours.
{ACTEUR}: Qui exécute ce parcours, et de quels droits dispose-t-il ?; Pourquoi ce trou existe. Sans acteur ni droits, l'agent construit un écran accessible à tous, et la question des permissions revient au moment le plus coûteux, après la mise en ligne.; Si vous ne savez pas répondre. Reprenez les profils de la note de cadrage. Si le parcours concerne un profil qui n'y figure pas, c'est le cadrage qu'il faut rouvrir, pas la spécification qu'il faut écrire.
{DONNEES_MANIPULEES}: Quelles informations sont saisies, lues ou modifiées pendant ce parcours ?; Pourquoi ce trou existe. Nommer les données avant l'écran évite l'écran joli qui ne sait pas où ranger ce qu'il collecte.; Si vous ne savez pas répondre. Prenez un exemple réel et écrivez toutes les valeurs qu'il porte, y compris la date et l'auteur. Ce que vous venez d'écrire est la liste.
{REGLES_METIER}: Quelles règles doivent être respectées, et que se passe-t-il quand elles ne le sont pas ?; Pourquoi ce trou existe. Une règle sans traitement d'échec produit un logiciel qui accepte tout puis se contredit en base.; Si vous ne savez pas répondre. Cherchez les phrases qui commencent par « on ne peut pas » et « il faut toujours » dans ce que disent les utilisateurs. Ce sont vos règles.
{CAS_LIMITES}: Quels cas rares ou fâcheux doivent être traités dans cette version ?; Pourquoi ce trou existe. Les cas limites non spécifiés ne sont pas oubliés par l'agent : ils sont traités selon son goût, et son goût est de les ignorer silencieusement.; Si vous ne savez pas répondre. Listez trois façons dont le parcours peut mal tourner : l'utilisateur abandonne au milieu, il recommence deux fois, la connexion tombe. Traitez au moins ces trois-là.
{CRITERES_DACCEPTATION}: À quoi verrez-vous, sans ouvrir le code, que ce parcours est réussi ?; Pourquoi ce trou existe. Un critère écrit avant la construction est un contrat ; le même critère écrit après est une justification.; Si vous ne savez pas répondre. Écrivez la phrase « je clique ici, je vois cela » autant de fois qu'il y a d'étapes. Si vous ne savez pas ce que vous devez voir, la spécification n'est pas mûre.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es analyste fonctionnel. Ton mandat est de rédiger la spécification d'un seul parcours, assez précise pour qu'un développeur qui ne me connaît pas la construise sans me poser de question, et assez fermée pour qu'il ne puisse pas y ajouter ce qui lui plaît. Tu ne codes pas, tu ne choisis pas de technologie, tu ne dessines pas l'écran.

## 2. CONTEXTE FACTUEL

Parcours à spécifier : {PARCOURS}
Acteur et ses droits : {ACTEUR}
Données manipulées : {DONNEES_MANIPULEES}
Règles à respecter : {REGLES_METIER}
Cas limites à traiter dans cette version : {CAS_LIMITES}
Critères d'acceptation que j'ai fixés : {CRITERES_DACCEPTATION}

Ce périmètre est fermé. Tout parcours voisin, si utile soit-il, est hors sujet. Tu ne le mentionnes ni en introduction, ni en conclusion, ni sous forme de suggestion.

## 3. DEMANDE BORNÉE

Produis la spécification fonctionnelle de ce parcours.

Ce que je veux :
1. le parcours nominal, étape par étape, sous la forme « l'acteur fait X, le système répond Y » ;
2. pour chaque étape, les données lues et les données écrites, nommées une par une ;
3. les règles applicables, chacune avec le message exact affiché quand elle est violée ;
4. les cas limites que je t'ai donnés, chacun avec le comportement attendu du système ;
5. les critères d'acceptation, reformulés en phrases vérifiables par un tiers qui ne lit pas le code ;
6. la liste des décisions que tu as dû prendre faute d'information, chacune signalée comme telle.

Ce que je ne veux pas : aucun nom de composant, aucune structure de base de données, aucune bibliothèque, aucune estimation, aucun parcours autre que celui nommé.

## 4. FORMAT DE SORTIE EXIGÉ

Six sections titrées comme ci-dessus. Le parcours nominal est numéroté, une étape par ligne, sujet et verbe explicites. Les messages d'erreur sont écrits entre guillemets, en français, dans leur formulation finale. Aucun « etc. », aucune parenthèse ouverte laissée à l'interprétation.

Ta réponse est refusable si elle spécifie un second parcours, si un message d'erreur est décrit au lieu d'être écrit, ou si une décision prise faute d'information n'est pas signalée.

Ce que vous devez recevoir

Un parcours nominal numéroté, chaque ligne portant un sujet et un verbe.
Les données lues et écrites nommées une par une à chaque étape.
Le texte exact de chaque message d'erreur, en français, entre guillemets.
Un comportement attendu écrit pour chacun des cas limites fournis.
Des critères d'acceptation vérifiables sans lire le code.
Une liste explicite des décisions prises faute d'information.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

La spécification traite un second parcours qui n'a pas été demandé.
Un message d'erreur est décrit (« un message explicite ») au lieu d'être écrit mot pour mot.
Une étape mentionne une donnée qui n'apparaît dans aucune liste de données.
Un cas limite fourni est absent, ou traité par un renvoi vague à une gestion d'erreur générale.
Une décision prise faute d'information est présentée comme une exigence du métier.
La spécification nomme une bibliothèque, une table ou un composant, ce qui préempte l'architecture.

Selon pour qui vous construisez

Pour moi.: Vous validez seul. Relisez la spécification vingt-quatre heures plus tard avant de la donner à construire : la moitié des ambiguïtés se voient à froid.
Pour mon employeur.: Faites relire les messages d'erreur par la personne qui répondra aux utilisateurs. Elle sait lesquels génèrent un appel.
Pour un client.: Les critères d'acceptation sont la base de la recette. Faites-les signer avant la construction : après, ils se négocient.