Rédiger des récits utilisateurs et des critères de réception vérifiables
Auteur: AILesson9 min de préparationTesté avec:ChatGPTRévisé: 2026-08-28
Réponse rapide
Transformer des besoins utilisateurs et commerciaux confirmés en récits délimités et en comportements observables sans inventer de décisions produit. Fournir: Besoin et preuves, Décisions produit approuvées, Livraison et validation. Résultat attendu: Un ensemble de récits comprenant les preuves, les limites, les scénarios, les critères de réception, les besoins non fonctionnels, les dépendances et les décisions en suspens.
1
Ajouter votre contexte
Votre texte reste dans ce navigateur. AILesson Prompts ne l’envoie ni à un modèle ni à un serveur.
2
Votre prompt
Les champs non remplis restent visibles sous forme d’espaces réservés, afin que vous puissiez quand même copier et modifier le prompt.
Rédigez des récits utilisateurs et des critères de réception vérifiables à partir de besoins confirmés et de décisions produit approuvées.
Situations, rôles, objectifs et comportements des utilisateurs, preuves, justification commerciale, limites de la recherche et contre-exemples :
[evidence]
Périmètre retenu, flux de travail, états, règles, autorisations, données, intégrations, plateformes, besoins non fonctionnels et exclusions :
[product]
Version, équipes, dépendances, analyse, accessibilité, confidentialité, sécurité, environnements, achèvement et décisions en suspens :
[delivery]
Distinguez le besoin étayé par des preuves, l’hypothèse produit, la décision approuvée, l’hypothèse de mise en œuvre et le choix non résolu. Séparez les récits par acteur et par résultat indépendant, et non par couche technique ou en une épopée surdimensionnée. N’utilisez la phrase du récit utilisateur que comme résumé ; ajoutez le contexte, l’emplacement de la preuve, les éléments inclus et exclus du périmètre, les préconditions, le déclencheur, le parcours principal, les parcours alternatifs et d’erreur, les autorisations, le traitement des données, les règles métier et les dépendances. Rédigez les critères de réception sous forme de scénarios observables Étant donné/Quand/Alors ou équivalents, couvrant le parcours nominal, les limites, les données manquantes ou non valides, les refus d’autorisation, les actions simultanées ou répétées, la récupération, l’accessibilité, la confidentialité et la sécurité, l’analyse et la compatibilité, uniquement lorsque ces éléments sont approuvés. N’inventez ni texte d’interface, ni état, ni seuil, ni intégration, ni rôle, ni conservation des données, ni objectif de performance, ni notification, ni comportement en cas d’erreur, ni indicateur. Présentez les décisions non résolues comme des questions bloquant les critères concernés. N’ajoutez aucune idée de solution lorsqu’aucune solution n’a été approuvée. Terminez par la traçabilité des preuves aux récits puis aux critères, ainsi que par un audit de la testabilité, du périmètre, des conflits et de l’état de préparation.
Privé par défautL’assemblage du prompt se fait localement dans votre navigateur. Évitez de placer des informations confidentielles dans un service d’IA, sauf si votre organisation l’autorise.
De l'entrée au résultat
Un exemple détaillé
Voyez comment un contexte concret transforme cette recette en résultat utilisable.
Entrée réelle
Besoin et preuves
Éléments de recherche, sessions UX P01/P03 : lorsqu’une passation Ready n’affiche pas la responsabilité de l’acceptation, les responsables cherchent parmi plusieurs personnes ou manquent une mention attendue. Les cas négatifs P02/P04 montrent que certaines attentes sont intentionnelles ou concernent une approbation connue. Motif métier approuvé : réduire l’incertitude évitable sans alourdir les notifications. Les éléments n’établissent ni la prévalence ni une demande d’e-mail.
Décisions produit approuvées
Solution de phase de découverte approuvée pour le prototype : afficher un champ accepter facultatif sur une passation ; seuls le requester ou le workspace coordinator peuvent le définir/modifier ; owner et accepter peuvent le voir. Les états Draft, Active, Ready, Accepted restent. Si aucun accepter n’est défini, afficher l’état comme unassigned avec le jeton de conception approuvé, texte exact de l’interface en attente. Aucun e-mail ni notification push. Accepter doit être un membre actif de l’espace. Le journal d’audit consigne l’acteur, l’ancien/nouvel accepter et l’heure. Application web uniquement. Aucun changement de conservation approuvé.
Livraison et validation
Version prototype pour test d’utilisabilité, pas pour la production. Design est responsable du texte ; Engineering valide l’appartenance et l’événement d’audit ; Accessibility exige utilisation au clavier, libellé programmatique et statut non indiqué uniquement par la couleur. Examen de confidentialité terminé pour l’utilisation des identifiants membres existants. Noms d’événements analytiques et seuil de performance non résolus. Définition de terminé : conception révisée, prototype fonctionnel, tests unitaires, contrôle d’accessibilité, script de recherche. Ne pas écrire de SLA de production.
Exemple de sortie
Récit 1 — attribuer la responsabilité de la réception
En tant que requester ou workspace coordinator, je dois pouvoir désigner un active workspace member comme accepter d’un transfert afin que les personnes concernées puissent voir qui est habilité à l’accepter. Preuves : P01/P03 ; le périmètre correspond à une hypothèse de prototype, et non à une demande validée.
Critères de réception
• Étant donné un transfert web et un requester/coordinator admissible, quand cette personne choisit un active workspace member et confirme, alors ce membre est enregistré comme accepter et devient visible pour le requester, l’owner et l’accepter. L’interface exacte de confirmation n’est pas résolue et doit provenir de la conception approuvée.
• Étant donné une personne qui n’est ni requester ni coordinator, quand elle consulte le transfert, alors elle peut voir l’accepter, mais pas le modifier. Le comportement approuvé en cas de refus de l’action manque et bloque la formulation du critère exact.
• Étant donné un compte inactif ou n’appartenant pas à l’espace de travail, quand il est fourni comme accepter, alors le système ne l’enregistre pas. Le texte exact de l’erreur est en attente de Design ; ne l’inventez pas.
• Étant donné un accepter existant, quand un acteur autorisé le modifie ou le supprime, alors les données d’audit consignent l’acteur, l’ancienne valeur, la nouvelle valeur et l’heure. La conservation suit la politique existante ; aucune nouvelle durée n’est précisée.
Récit 2 — comprendre qu’un transfert n’est pas attribué
En tant qu’owner ou requester, je dois pouvoir percevoir qu’aucun accepter n’est attribué afin de décider s’il faut en désigner un ou poursuivre intentionnellement sans en avoir. Cette formulation préserve les contre-exemples P02/P04 et ne laisse pas entendre que toute attente constitue une erreur.
Critères : en l’absence d’accepter, le jeton visuel approuvé signalant l’absence d’attribution apparaît ; l’état reste Ready au lieu de créer un nouvel état. L’indicateur comporte un libellé programmatique et ne se distingue pas uniquement par la couleur. Les utilisateurs du clavier peuvent atteindre le champ et effectuer toutes les actions autorisées dans un ordre logique. Les textes exacts, visible et accessible, sont en attente de Design et bloquent toute affirmation définitive à leur sujet.
Hors périmètre : e-mail et notification push, déploiement en production, nouvelle durée de conservation, affirmation de prévalence ou de résultat, attribution automatique et SLA de production. Le critère d’analyse reste bloqué jusqu’à l’approbation des noms et de l’objectif des événements. La traçabilité relie P01/P03 aux récits de visibilité, tandis que P02/P04 imposent une attribution facultative sans alerte automatique.
Pourquoi cela fonctionne
1
La traçabilité empêche qu’une phrase concise de récit ne masque un comportement produit non étayé.
2
Les scénarios limites et d’échec rendent les critères de réception utiles au-delà du seul parcours nominal d’une démonstration.
Vérifier le résultat
Chaque récit est-il relié à une preuve confirmée du besoin et à une décision produit approuvée ?
Les critères sont-ils observables, sans ambiguïté et exempts d’éléments d’interface ou de seuils inventés ?
Les limites, les autorisations, les erreurs, la récupération, l’accessibilité, la confidentialité et les décisions en suspens sont-elles couvertes lorsqu’elles sont pertinentes ?
Utilisez-la en toute confiance
Questions fréquentes
Des réponses pratiques sur le bon moment pour utiliser cette recette, ce qu’il faut fournir et les cas où une vérification humaine reste nécessaire.
Que dois-je préparer avant d’utiliser « Rédiger des récits utilisateurs et des critères de réception vérifiables » ?
Pour utiliser « Rédiger des récits utilisateurs et des critères de réception vérifiables », préparez le besoin et les preuves, les décisions produit approuvées, ainsi que la livraison et la validation. Ne remplacez les espaces réservés que par des informations vérifiables. Si un détail est inconnu, signalez explicitement cette incertitude au lieu de demander au modèle de le déduire.
Dans quels cas le résultat de « Rédiger des récits utilisateurs et des critères de réception vérifiables » n’est-il pas prêt à être utilisé ?
Le résultat n’est pas prêt s’il ne produit pas encore, à partir des preuves fournies, le livrable annoncé — un ensemble de récits comprenant les preuves, les limites, les scénarios, les critères de réception, les besoins non fonctionnels, les dépendances et les décisions en suspens — ou s’il repose sur des hypothèses non résolues, des validations manquantes ou des détails inventés. Utilisez les vérifications comme critères d’autorisation : révisez les données sources ou désignez nommément une personne habilitée à effectuer la relecture au lieu de peaufiner un résultat non étayé.
Quels outils d’IA disposent de tests consignés pour « Rédiger des récits utilisateurs et des critères de réception vérifiables » ?
Le registre de tests publié pour « Rédiger des récits utilisateurs et des critères de réception vérifiables » mentionne ChatGPT à la date du 2026-08-28. Il confirme l’existence d’exécutions consignées, mais ne garantit ni la compatibilité ni des résultats identiques dans les versions ultérieures du produit. Avec un autre outil ou une autre version, conservez toutes les contraintes visibles et répétez les vérifications du résultat avant toute utilisation.
Transformer les questions de recherche en tâches réalistes et non directives, avec des preuves de réussite, des observations, des relances et les limites du prototype
Votre prochaine étape : mettez l’IA à contribution
Passez de la compréhension de l'IA à l'action. Entraînez-vous à formuler des requêtes, à évaluer et à améliorer les résultats grâce à des leçons interactives pour le travail et la vie quotidienne.
ChatGPT
