Écrire une conception que toute l’équipe lit
Acteurs, fonctionnalités, objets, règles : décrire un produit par besoins reliés plutôt que par pages.
Le document de spécification a mauvaise réputation : long, figé, lu une fois puis oublié. Pourtant, une équipe a besoin d’une description partagée de ce qu’elle construit.
Pourquoi les documents linéaires décrochent
Un document texte raconte le produit dans un ordre. Mais un produit n’a pas d’ordre : un acteur utilise plusieurs fonctionnalités, un objet est manipulé à plusieurs endroits, une règle s’applique partout. Dès qu’un élément change, il faut le retrouver partout où il est cité.
Quatre catalogues
Une alternative consiste à écrire chaque élément une seule fois, dans un catalogue. Quatre suffisent généralement :
- Les acteurs : qui utilise le produit (client, administrateur, coach…).
- Les fonctionnalités : ce qu’ils peuvent faire.
- Les objets : ce que le produit manipule, avec leurs champs.
- Les règles : ce qui doit toujours être vrai.
Des besoins pour les relier
Les catalogues ne disent pas encore qui fait quoi. C’est le rôle du besoin, une phrase que tout le monde sait lire : « En tant que Client, je veux passer commande, pour recevoir mes articles. » Le besoin nomme ses acteurs, sa fonctionnalité, les objets concernés et les règles à respecter — par exemple l’objet Commande, dont le champ paiement porte la règle 3-D Secure.
L’héritage, sans le jargon
Quand plusieurs acteurs partagent des caractéristiques, l’héritage évite les répétitions : un Coach et un Client héritent tous deux d’Utilisateur, et ses besoins sont aussi les leurs. Il en va de même pour les objets : un objet qui hérite d’un autre récupère ses champs, et peut en surcharger certains.
Un diagramme sans le dessiner
Chaque besoin a son diagramme, généré à partir de ce qu’il relie : les acteurs, la fonctionnalité, les objets avec leurs champs, les règles. Personne ne le dessine, donc personne n’oublie de le mettre à jour.
Exporter pour les humains et les machines
Chaque besoin s’exporte en Markdown avec tout son contexte. Le format se lit aussi bien par un développeur qui découvre le projet que par un assistant IA qui doit en comprendre le contexte.