Une présentation d’exigences produit n’est pas un PRD copié-collé. Elle met en avant ce dont la revue a besoin : problème, périmètre, non-objectifs, critères d’acceptation et décisions en suspens. Avec texte vers présentation, vous pouvez créer un premier brouillon éditable à partir d’un plan vérifié ; les exigences et leurs limites doivent toujours venir de votre PRD.
Clarifier le problème et l’objectif
Commencez par le problème utilisateur et la décision attendue pendant la revue. Citez les éléments utiles, comme des observations d’usage ou des motifs de support, sans donner aux données une portée qu’elles n’ont pas. Un objectif décrit le changement recherché, pas encore la solution technique.
Séparer périmètre et non-objectifs
Listez séparément les cas inclus et ceux qui sont volontairement exclus. Les non-objectifs évitent une extension silencieuse du projet. Marquez les hypothèses et questions ouvertes au lieu de les présenter comme des exigences établies.
Rédiger des critères vérifiables
Décrivez un résultat observable : qui fait quoi, dans quelle condition et comment le vérifier ? Évitez « simple » ou « rapide » sans mesure. Reliez chaque critère à une priorité et à une dépendance connue.
Rendre visibles dépendances et risques
Montrez les interfaces, sources de données, contrôles juridiques et décisions d’autres équipes. Une dépendance n’est pas forcément un blocage : indiquez son statut, son responsable et la prochaine action. Ne transformez pas une estimation non validée en engagement de date.
Ajouter un journal des décisions
Terminez par un tableau court : décision, options, recommandation, justification, responsable et échéance. Séparez ce qui est décidé, proposé et à clarifier. Après la réunion, chacun voit ce qui a réellement été convenu.
Structure de revue recommandée
- Problème, objectif et question de revue
- Public cible et contexte étayé
- Périmètre et non-objectifs
- Exigences et critères d’acceptation
- Dépendances, risques et hypothèses
- Décisions ouvertes et prochaines étapes
Gardez une décision ou une preuve au centre de chaque diapositive. Le support accélère la revue ; il ne remplace pas le PRD complet.
Les limites du format
La présentation sert d’interface de décision. Elle ne remplace ni la spécification complète ni l’implémentation. Conservez le lien vers le PRD, identifiez les changements et ne présentez comme confirmé que ce qui a été validé en revue.
Nommer la question de revue
Ouvrez par une phrase comme « valider le périmètre de la première version de la boîte partagée ». Ajoutez le décideur, la date visée et le problème utilisateur ou métier. Un nom de projet ne permet pas de savoir si le support répond à la bonne question.
Décrivez le problème avec une observation et une limite. Séparez besoin et solution : « les agents perdent le contexte quand une conversation change de file » est un problème ; « construire un service de routage » est une hypothèse. La première diapositive doit rester utile à une personne arrivée en retard : décision, recommandation, périmètre et risque ouvert.
Rendre le périmètre explicite
Présentez trois niveaux : inclus, exclu et reporté. Les éléments inclus décrivent un comportement ou un résultat observable. Pour une boîte partagée, il peut s’agir d’affecter une conversation à une file, d’afficher son responsable et de tracer un transfert ; le routage automatique par sentiment ou une application mobile peuvent être exclus. Ce sont des exemples, pas des fonctionnalités promises.
Quand deux exigences se contredisent, montrez l’arbitrage. Une première version plus rapide peut ne prendre en charge qu’un fournisseur d’identité, tandis qu’une phase ultérieure en ajoute d’autres. Nommez la conséquence et la personne qui accepte le compromis.
Expliquer le plus petit flux utile
Choisissez un flux principal : déclencheur, choix importants et résultat attendu. Gardez les cas limites à part jusqu’à ce que le chemin principal soit compris. Pour chaque étape, montrez l’information nécessaire, l’action et le retour reçu. Signalez les politiques et services externes ; n’inventez pas des contrôles pour remplir un écran.
Signalez accessibilité et erreurs lorsqu’elles changent l’exigence : que se passe-t-il en cas de refus, de connexion indisponible ou de permission absente ? Un flux qui ne fonctionne que dans le cas idéal n’est pas une exigence complète.
Rendre l’acceptation vérifiable
Utilisez une forme observable : étant donné une condition, lorsqu’une action survient, alors un résultat est visible. Regroupez critères fonctionnels, qualité et préparation opérationnelle. Associez les critères à risque à une méthode de vérification : test automatisé, session d’utilisabilité, contrôle de sécurité, test de charge ou inspection manuelle. Cette méthode est le contrôle convenu, pas une preuve de succès futur.
Montrer dépendances et choix
Listez fournisseur d’identité, migration, contrôle juridique, composant du design system ou API d’une autre équipe avec responsable et état. Le calendrier ne doit montrer que les points d’intégration, de test et de décision utiles à la revue ; une estimation incertaine n’est pas un engagement. Pour les options, comparez temps d’apprentissage, réversibilité, risque utilisateur et maintenance, puis dites pourquoi une option est préférable.
Terminer par une approbation enregistrable
Demandez une validation du périmètre, une validation sous conditions ou un retour pour une modification précise. Ajoutez un journal : approuvé, exclu, responsable et prochaine échéance. Si les preuves sont faibles, proposez une tâche de découverte ou un prototype avec un objectif d’apprentissage. Envoyez le support avec le PRD et une date de version afin de conserver ce qui était connu, choisi et non résolu.
