Construire des critères de priorisation pour les exigences fonctionnelles

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

Réponse rapide

Définir des critères fonctionnels fondés sur des preuves, des conditions impératives, des échelles, les incertitudes, les dépendances et les règles de décision avant de noter les options. Fournir: Contexte de la décision, Fonctionnalités candidates et preuves, Contraintes de notation et de gouvernance. Résultat attendu: Une grille de priorisation étalonnée, un contrat de preuve, un tableau de notation, une analyse de sensibilité et un modèle de journal de décision.

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.

Construisez un cadre défendable de priorisation des fonctionnalités pour la décision et les options fournies.

Contexte de la décision :
[decision]

Options et preuves :
[candidates]

Règles de notation et de gouvernance :
[rules]

Distinguez les conditions impératives des critères comparatifs. Pour chaque critère, définissez la question de décision, l’échelle assortie de repères comportementaux, les preuves autorisées, l’indicateur indirect interdit, le sens, la pondération uniquement si elle est approuvée, le traitement des données manquantes, le degré de confiance et le risque de double comptage. Lorsqu’ils sont pertinents, distinguez la portée auprès des utilisateurs, la gravité, l’adéquation stratégique, la confiance dans les preuves, l’effort, la charge opérationnelle, le risque technique, l’accessibilité, la confidentialité, la sûreté et les dépendances. N’inventez ni impact, ni estimation, ni utilisateurs, ni revenus, ni obligations, ni pondérations, ni précision. Une note pondérée facilite la discussion ; elle ne prime pas sur les conditions impératives, les dépendances, l’incertitude ou l’autorité de décision. Étalonnez le cadre avec au moins deux des options fournies, ne présentez une vue brute et une vue ajustée selon la confiance que si cette règle est explicite, testez la sensibilité à des variations plausibles des pondérations ou des estimations, repérez les options dominées et incomparables, puis produisez une feuille de notation, les lacunes de preuve, les choix de séquencement, un journal de décision et un déclencheur de révision.
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

Contexte de la décision
Choisir au plus un projet de découverte et de livraison de six semaines pour un petit produit de facturation au quatrième trimestre. Objectif : réduire les échecs de recouvrement des factures des travailleurs indépendants. Capacité : quatre semaines-ingénieur, une semaine-designer et aucun poste supplémentaire à l’assistance. Un examen de sécurité est obligatoire pour toute modification des données de paiement. Le responsable produit formule la recommandation ; le GM décide. Le niveau d’accessibilité WCAG 2.2 AA constitue une condition de publication. Les travaux réglementaires obligatoires sont traités séparément et ne doivent pas entrer dans ce classement.
Fonctionnalités candidates et preuves
F1, planification des rappels de paiement : 18 des 24 travailleurs indépendants interrogés déclarent envoyer les rappels manuellement ; les données d’événements montrent que 31 % des factures en retard font l’objet d’un rappel manuel. Réussite de la tâche sur prototype : 7/8. Estimation : 3 à 5 semaines-ingénieur et une semaine-designer ; dépend du service de notifications ; l’assistance prévoit des questions sur la configuration des fuseaux horaires. F2, ton des rappels rédigés par l’IA : 9/24 demandent de l’aide pour la formulation ; aucune preuve comportementale d’usage ; compréhension du prototype : 5/8 ; estimation de 2 à 4 semaines-ingénieur, plus un coût récurrent du modèle et une vérification du contenu ; les évaluations relatives à la confidentialité et aux hallucinations n’ont pas été effectuées. F3, webhook de statut de paiement : demandé par 4 partenaires comptables représentant 620 comptes liés ; les journaux des partenaires indiquent 14 000 interrogations du statut par mois. Estimation de 5 à 8 semaines-ingénieur ; nécessite un examen de sécurité et le versionnage de l’API ; effet sur le recouvrement des utilisateurs non mesuré. F4, thèmes de couleur des factures : 6/24 mentionnent l’image de marque ; données analytiques indisponibles ; estimation de 1 à 2 semaines-ingénieur ; aucune dépendance. Les estimations sont des fourchettes, pas des engagements.
Contraintes de notation et de gouvernance
Utiliser des échelles de 1 à 4 assorties de repères. Critères comparatifs et pondérations approuvés : preuves du problème utilisateur 30 %, contribution attendue au recouvrement 25 %, adéquation stratégique 15 %, faisabilité de la livraison 20 %, viabilité opérationnelle 10 %. La confiance dans les preuves est présentée séparément et n’est pas multipliée par la note. Conditions impératives : accessibilité pour toutes les fonctionnalités ; sécurité pour les données de paiement. Ne pas utiliser l’ancienneté du demandeur ni le nombre brut de comptes des partenaires comme substitut au bénéfice pour l’utilisateur final. Un impact inconnu reçoit la note 1, et non 0. Toute fourchette d’effort qui dépasse la capacité doit être signalée. Un écart inférieur ou égal à 0,2 reste indécis ; utiliser la valeur de la collecte de preuves comme critère de départage, et non des décimales arbitraires.

Exemple de sortie

Cadre de priorisation

Les repères utilisent une échelle de 1 à 4. Preuves du problème : simple anecdote ; éléments qualitatifs répétés ; éléments qualitatifs et comportementaux ; preuves fortes reproduites. Contribution au recouvrement : inconnue ; indirecte mais plausible ; indicateur avancé mesuré ; résultat de recouvrement mesuré. Adéquation stratégique : de périphérique à directe. Faisabilité : dépasse clairement la capacité ; fourchette dépassant la capacité ou dépendance majeure non résolue ; tient dans la capacité avec une dépendance maîtrisable ; tient largement dans la capacité. Viabilité : risque récurrent non résolu ; charge élevée ; charge maîtrisable ; faible charge. Chaque note cite ses preuves ; le degré de confiance, faible, moyen ou élevé, reste séparé.

FonctionnalitéPreuvesRecouvrementAdéquationFaisabilitéViabilitéPondéréeConfiance/conditions
F1424222.9moyenne à élevée ; accessibilité non vérifiée
F2213211.8faible ; risques de confidentialité et de contenu non résolus
F3312121.9moyenne pour la difficulté d’intégration, faible pour le recouvrement ; condition de sécurité non vérifiée
F4211442.2faible à moyenne ; accessibilité non vérifiée

Recommandation : F1 est le projet de découverte et de livraison le mieux placé, mais ne doit pas être approuvé automatiquement. Sa fourchette de 3 à 5 semaines dépasse la capacité de quatre semaines et les questions opérationnelles liées aux fuseaux horaires ne sont pas résolues. Avant de s’engager, réduire la fourchette d’estimation, tester la dépendance au service de notifications, définir les valeurs par défaut des fuseaux horaires et vérifier la conformité WCAG AA. F3 ne tient pas dans la capacité annoncée et ne dispose d’aucune preuve de son effet sur le recouvrement ; envisager une phase de découverte distincte. Au vu des preuves actuelles, F2 est dominée par F1 et ajoute des contrôles récurrents non résolus. F4 est réalisable, mais faiblement liée à l’objectif.

Sensibilité : porter la pondération de la faisabilité de 20 % à 35 % pourrait rapprocher F4 de F1 ; abaisser de 4 à 3 la note de F1 pour les preuves du problème réduirait son avance. La décision est donc sensible au degré de confiance dans la capacité, mais pas au point de rendre F2 préférable. Consignez la décision du GM, les preuves retenues, les exceptions, le responsable et le déclencheur de révision. Rouvrez le classement si l’estimation de F1 dépasse cinq semaines, si la condition d’accessibilité échoue, si la dépendance aux notifications bloque le projet ou si de nouvelles preuves de résultat de recouvrement apparaissent.

Pourquoi cela fonctionne

  1. 1

    Les repères comportementaux et les contrats de preuve permettent de comparer les notes entre évaluateurs

  2. 2

    Les conditions impératives et les analyses de sensibilité révèlent quand un classement net est instable ou invalide

Vérifier le résultat

  • Chaque critère mesure-t-il une seule dimension pertinente pour la décision à l’aide de repères observables ?

  • Les preuves manquantes, le degré de confiance, les conditions impératives, les dépendances et le double comptage sont-ils visibles indépendamment de la note totale ?

  • Des variations plausibles des pondérations ou des estimations modifieraient-elles la recommandation et déclencheraient-elles une révision ?

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 « Construire des critères de priorisation pour les exigences fonctionnelles » ?

Pour utiliser « Construire des critères de priorisation pour les exigences fonctionnelles », préparez le contexte de la décision, les fonctionnalités candidates et leurs preuves, ainsi que les contraintes de notation et de gouvernance. Ne remplacez les champs réservés que par des informations vérifiables. Si un élément est inconnu, indiquez-le explicitement au lieu de demander au modèle de le déduire.

Dans quels cas le résultat de « Construire des critères de priorisation pour les exigences fonctionnelles » 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 résultat annoncé — une grille de priorisation étalonnée, un contrat de preuve, un tableau de notation, une analyse de sensibilité et un modèle de journal de décision — ou s’il repose sur des hypothèses non résolues, des approbations manquantes ou des éléments inventés. Utilisez les contrôles comme conditions de publication : révisez les données sources ou désignez un responsable autorisé pour l’examen, plutôt que de peaufiner un résultat sans fondement.

Quels outils d’IA disposent de tests consignés pour « Construire des critères de priorisation pour les exigences fonctionnelles » ?

Le registre de tests publié pour « Construire des critères de priorisation pour les exigences fonctionnelles » mentionne ChatGPT au 2026-08-28. Cela confirme l’existence d’essais 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, conservez toutes les contraintes visibles et répétez les contrôles du résultat avant utilisation.

Faites avancer votre travail