La décision
Décrivez le comportement observable avant la technologie : personne, situation initiale, action et résultat vérifiable. Ajoutez les droits et exceptions qui modifient ce résultat.
Un cas concret
Dans un outil fictif de frais, une personne soumet un reçu, son responsable accepte ou renvoie avec motif, puis la comptabilité exporte les validations. Précisez reçu illisible, responsable absent et modification ultérieure du montant.
Écrire un exemple que l’on peut jouer
Utilisez des valeurs fictives : reçu de déplacement, projet, envoi. Le responsable ne voit que les dossiers autorisés. Le retour exige un motif et rend éditable ; l’approbation fixe une version. Précisez si la correction ultérieure crée une nouvelle version, demande une nouvelle validation ou est refusée. Le scénario doit être jouable avec des cartes avant de parler technique.
Séparer règles, préférences et hypothèses
« Seule la finance exporte les validations » est un droit ; « bouton en haut à droite », une suggestion ; « tableur nécessaire », une hypothèse à vérifier. Le design peut ainsi évoluer sans changer la promesse. Notez source et personne compétente. Pour une obligation, obtenez formulation autorisée ou interprétation qualifiée, pas une supposition technique.
Relire avec chaque rôle
Demandeur, responsable et finance suivent le même cas : téléversement interrompu, absence, export répété, reçu corrigé. Ajoutez les décisions nécessaires et gardez les préférences ouvertes. Décrivez démonstration et données sûres. Versionnez les exigences approuvées. La clarté permet de construire et évaluer sans inventer les décisions de l’entreprise.
Les options à comparer
Un récit donne le contexte, un croquis l’interaction, les exemples d’acceptation les limites. Combinez-les utilement ; un document immense ne remplace pas des décisions actuelles.
Les points de rupture
N’exprimez pas les règles métier en tables de base de données. « Rapide » et « simple » exigent tâche et critère. Séparez comportement demandé et suggestions visuelles, avec un décideur pour les contradictions.
Avant de lancer le projet
Une autre personne peut-elle démontrer réussite et échec ? Les rôles sont-ils clairs ? Les exemples sont-ils partageables ? Apportez exigences et incertitudes au cadrage du MVP.