Rédiger des critères d’acceptation vérifiables

Auteur: AILesson6 min de préparationTesté avec:ChatGPTRévisé: 2026-08-28

Réponse rapide

Transformer les exigences en conditions de réussite observables, cas limites, exclusions et preuves. Fournir: Exigence et résultat pour l’utilisateur, Règles métier et de qualité, Périmètre et inconnues. Résultat attendu: Un ensemble de critères d’acceptation testables avec traçabilité, exemples et décisions non résolues.

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 critères d’acceptation vérifiables pour l’exigence.

Exigence approuvée, utilisateur, objectif et source :
[requirement]

Règles métier, données, autorisations, états, seuils, accessibilité, performance et erreurs :
[rules]

Périmètre, exclusions, plateformes, dépendances, termes non résolus et personne chargée de l’approbation :
[boundaries]

Utilisez uniquement les règles fournies. Décomposez tout comportement composé en critères atomiques. Pour chaque critère, indiquez l’identifiant, l’exigence source, la condition préalable, l’action ou l’événement, le résultat attendu observable, les données de test ou un exemple de limite, la preuve et la priorité. Couvrez le parcours nominal, les entrées vides, non valides ou dupliquées, les limites d’autorisation, l’interruption ou l’achèvement partiel, le comportement relatif au temps et aux paramètres régionaux, la récupération, l’accessibilité et les seuils non fonctionnels, uniquement lorsqu’ils sont pertinents et précisés. Signalez les exigences ambiguës par « Décision nécessaire » ; n’inventez ni seuil ni mise en œuvre. Repérez les contradictions et les termes invérifiables tels que rapide, intuitif, approprié ou en temps réel. Terminez par les vérifications hors périmètre et une matrice de traçabilité.
Essayer dans le Playground
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

Exigence et résultat pour l’utilisateur
REQ-12 : une personne salariée authentifiée peut enregistrer une demande de remboursement de frais comme brouillon et y revenir ultérieurement sans la soumettre, afin de ne pas perdre un travail inachevé.
Règles métier et de qualité
Une demande comporte un ClaimID, l’identifiant de la personne salariée, la devise, les lignes de frais, les justificatifs joints, le statut et les horodatages de création et de mise à jour. Un brouillon peut ne pas contenir de justificatifs ni de centre de coûts. Seule la personne salariée qui l’a créé peut le consulter ou le modifier. La soumission valide les champs obligatoires et ne relève pas de cette user story. L’enregistrement automatique est demandé « rapidement », mais aucun intervalle n’est approuvé. Les paramètres régionaux web pris en charge sont en-GB et zh-CN. Les pièces jointes doivent respecter les règles de téléversement existantes.
Périmètre et inconnues
Web uniquement. La modification hors ligne et l’accès par les responsables sont hors périmètre. Les services d’identité et de téléversement sont des dépendances. La personne responsable du produit approuve les critères. Le comportement à l’expiration de la session et la durée de conservation des brouillons ne sont pas résolus.

Exemple de sortie

AC-01 | REQ-12 | une personne salariée authentifiée commence une demande | sélectionne « Enregistrer le brouillon » | un ClaimID unique est conservé avec la personne créatrice, le statut Draft, la devise, les lignes existantes et l’horodatage de mise à jour ; aucune soumission n’a lieu | preuve : enregistrement persistant et confirmation dans l’interface | Indispensable. AC-02 | REQ-12 | le brouillon ne comporte ni justificatif ni centre de coûts | Enregistrer le brouillon | l’enregistrement réussit, car ces champs sont facultatifs avec le statut Draft | exemple limite : une ligne de frais, sans pièce jointe ni centre de coûts | Indispensable. AC-03 | règle de propriété | la personne salariée B demande le brouillon de la personne salariée A depuis l’interface ou par une URL directe | l’accès est refusé et aucun détail de la demande n’est exposé | preuve : test ou journal d’autorisation | Indispensable. AC-04 | retour ultérieur | la personne créatrice se reconnecte plus tard avec les paramètres en-GB ou zh-CN | le brouillon apparaît avec les valeurs enregistrées et une présentation adaptée aux paramètres régionaux ; les montants et horodatages sous-jacents restent inchangés | Indispensable. AC-05 | dépendance au téléversement | l’enregistrement d’une pièce jointe échoue selon les règles de téléversement existantes | le comportement du brouillon et le message permettant la récupération doivent être confirmés ; ne pas affirmer que la pièce jointe a été conservée | Décision nécessaire.

Décisions nécessaires : intervalle d’enregistrement automatique remplaçant « rapidement » ; comportement des modifications non enregistrées à l’expiration de la session ; durée de conservation et avis de suppression. Hors périmètre : validation lors de la soumission, accès des responsables, modification hors ligne. Traçabilité : REQ-12→AC-01/02/04 ; propriété→AC-03 ; dépendance au téléversement→AC-05.

Pourquoi cela fonctionne

  1. 1

    Les résultats observables et les exemples de limites rendent l’accord testable avant le début de la mise en œuvre.

  2. 2

    La mention « Décision nécessaire » empêche qu’une ambiguïté du produit ne soit dissimulée dans un cas de test.

Vérifier le résultat

  • Chaque critère est-il atomique, observable et rattachable à une exigence fournie ?

  • Les conditions limites sont-elles pertinentes plutôt que génériques ?

  • Les seuils manquants et les termes non définis ont-ils été laissés comme décisions à prendre ?

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 critères d’acceptation vérifiables » ?

Pour « Rédiger des critères d’acceptation vérifiables », préparez l’exigence et le résultat pour l’utilisateur, les règles métier et de qualité, ainsi que le périmètre et les inconnues. Remplacez les espaces réservés uniquement par des informations que vous pouvez vérifier. Si un détail est inconnu, indiquez-le explicitement au lieu de demander au modèle de le déduire.

Dans quels cas le résultat de « Rédiger des critères d’acceptation 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 éléments fournis, le résultat annoncé — un ensemble de critères d’acceptation testables avec traçabilité, exemples et décisions non résolues — 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 de validation : révisez les informations de départ ou désignez une personne autorisée chargée de la relecture, au lieu de peaufiner un résultat sans fondement.

Quels outils d’IA disposent de tests consignés pour « Rédiger des critères d’acceptation vérifiables » ?

Le relevé de tests publié pour « Rédiger des critères d’acceptation vérifiables » mentionne ChatGPT au 2026-08-28. Cela confirme que des essais ont été consignés, 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, laissez toutes les contraintes visibles et recommencez les vérifications du résultat avant utilisation.

Plus de façons d'explorer

Où se situe cette recette

Faites avancer votre travail