147 lines
6.4 KiB
Plaintext
147 lines
6.4 KiB
Plaintext
(Prompt et reéponses fait sur Chat GPT - modele 5.1)
|
||
|
||
|
||
|
||
Q1 Frontière EF/ENF dépendante du contexte
|
||
|
||
Je voulais que Chat GPT m'aide a comprendre avec des exemple de contexte car j'en avais pas vraiment, j'ai donc poser la question au chat l'aide du prompt : "Peux-tu me donner un exemple pour la question 1 en utilisant une fonctionnalité différente de celle déjà utilisée ? J’aimerais voir un autre exemple afin de comprendre comment réaliser l’exercice étape par étape. (Ne réalise pas toutes les questions)"
|
||
|
||
Il m'a tout d'abord généré sa reponse :
|
||
"Nouvelle fonctionnalité choisie (INVENTÉE) :
|
||
« Le système envoie un email quand un utilisateur modifie son adresse. »
|
||
Maintenant je te montre comment répondre à Q1-a, Q1-b et Q1-c avec CETTE fonctionnalité de manière partielle, pour que tu comprennes comment faire pour n’importe quel cas.
|
||
|
||
Q1-a – ANALYSE DU CONTEXTE (exemple inventé)
|
||
|
||
Contexte 1 : Application de livraison (ex : Uber Eats)
|
||
|
||
Dans ce type d’application, l’adresse du client est critique pour réussir une livraison.
|
||
Si l’utilisateur change son adresse, prévenir immédiatement est une action essentielle pour éviter des erreurs logistiques.
|
||
Donc dans ce contexte, envoyer un email = EF (fonction métier).
|
||
|
||
Pourquoi ?
|
||
|
||
Parce que si l’adresse change et que personne n’est informé, la livraison peut échouer.
|
||
|
||
Contexte 2 : Réseau social (ex : Instagram)
|
||
|
||
Dans un réseau social, changer son adresse n’a aucun impact métier important.
|
||
L’envoi d’un email sert juste à améliorer la sécurité du compte.
|
||
Donc ici, c’est une ENF (sécurité).
|
||
|
||
Pourquoi ?
|
||
|
||
Parce que ce n’est pas une vraie fonctionnalité métier.
|
||
L’utilisateur est venu pour socialiser, pas pour gérer son adresse.
|
||
|
||
Q1-b – Rédaction DES EXIGENCES pour chaque contexte
|
||
Tu dois réécrire une exigence adaptée au contexte.
|
||
Une pour le contexte 1, une pour le contexte 2.
|
||
|
||
Exigence pour le contexte 1 (livraison → EF)
|
||
« Lorsqu’un utilisateur modifie son adresse principale, le système doit immédiatement envoyer un email au client et au livreur associé contenant la nouvelle adresse, l’ancienne adresse et la date de modification. »
|
||
Ça décrit bien une action métier → EF.
|
||
|
||
Q1-c – Impact sur le BACKLOG selon EF ou ENF
|
||
Tu expliques comment EF/ENF affecte l’organisation du travail.
|
||
|
||
Si EF → devient une User Story prioritaire
|
||
Dans le contexte de livraison :
|
||
L’envoi de mail devient une vraie User Story :
|
||
|
||
“En tant que livreur, je veux être informé quand l’utilisateur change d’adresse pour éviter une erreur de livraison.”
|
||
|
||
|
||
Elle sera priorisée car elle empêche les erreurs du métier.
|
||
Elle peut être découpée en sous-stories : format du mail, contenu, timing…
|
||
|
||
Plus de stories → backlog plus granularisé.
|
||
Si ENF → devient un critère d’acceptation
|
||
Dans le contexte du réseau social :
|
||
Pas une User Story.
|
||
|
||
|
||
C’est un critère d’acceptation de la story : “Gérer son compte”.
|
||
C’est moins prioritaire.
|
||
|
||
|
||
On peut le mettre dans un sprint plus tard.
|
||
Moins de stories → backlog plus simple.
|
||
|
||
"
|
||
|
||
-------
|
||
|
||
Q2 – Refonte d’un backlog non INVEST
|
||
|
||
PARTIE 1 – Prompt que j’ai utilisé
|
||
« Peux-tu me donner un exemple de la manière de refaire un backlog non conforme à INVEST ? J’aimerais voir comment identifier les problèmes d’une User Story, puis comment construire un nouveau backlog conforme à INVEST. Ne fais pas l’exercice complet, juste un exemple pour m’aider à comprendre. »
|
||
|
||
PARTIE 2 – Réponse donnée par ChatGPT
|
||
|
||
Exemple :
|
||
Ancienne User Story : « En tant qu’utilisateur, je veux une interface moderne pour que ce soit joli. »
|
||
|
||
Problèmes INVEST :
|
||
|
||
– I : dépend d’autres stories (refonte complète)
|
||
– N : contenu flou, non négociable
|
||
– V : valeur métier faible
|
||
– E : impossible à estimer (« moderne » est subjectif)
|
||
– S : trop grande
|
||
– T : non testable
|
||
|
||
Backlog corrigé :
|
||
|
||
US1 : En tant qu’utilisateur, je veux activer le mode sombre afin d’améliorer le confort visuel.
|
||
US2 : En tant qu’utilisateur, je veux modifier la taille du texte afin d’adapter l’affichage à mes besoins.
|
||
US3 : En tant qu’utilisateur, je veux changer la langue de l’interface afin de personnaliser mon expérience.
|
||
|
||
-------
|
||
|
||
Q3 – Gestion des ruptures de stock dans une boutique en ligne
|
||
|
||
PARTIE 1 – Prompt que j'ai utilisé
|
||
« Peux-tu m’expliquer comment rédiger un processus métier clair en plusieurs étapes, comment compléter un diagramme de classes du domaine avec de nouvelles classes et attributs, et comment écrire un scénario Given/When/Then pour tester une exigence ? Donne-moi juste un exemple pour comprendre la méthode. »
|
||
|
||
PARTIE 2 – Exemple de réponse donnée par ChatGPT
|
||
|
||
Exemple de processus métier :
|
||
|
||
L’utilisateur consulte la fiche d’un produit.
|
||
Le système affiche le stock disponible.
|
||
Si le produit est en rupture, le système bloque l’ajout au panier.
|
||
Le système propose une alerte de remise en stock.
|
||
Si l’utilisateur accepte, il est inscrit sur la liste d’attente.
|
||
Lors du réapprovisionnement, le système notifie les utilisateurs inscrits.
|
||
|
||
|
||
Exemple de compléments au DCD :
|
||
– Classe : AlerteStock, attributs : dateInscription, canalNotification.
|
||
– Classe : CommandeFournisseur, attributs : dateCommande, quantite, statut.
|
||
Exemple Given/When/Then :
|
||
Given un produit en rupture,
|
||
When l’utilisateur active l’alerte,
|
||
Then il reçoit une notification lorsque le produit revient en stock.
|
||
|
||
-------
|
||
|
||
Q4 – Complémentarité entre User Stories et Cas d’utilisation
|
||
|
||
PARTIE 1 – Exemple de prompt que j’aurais pu utiliser
|
||
|
||
« Peux-tu m’expliquer comment une User Story peut être déclinée en plusieurs cas d’utilisation, et comment expliquer les risques d’un projet qui n’utilise que des User Stories ou seulement des Cas d’utilisation ? Donne-moi juste un exemple pour comprendre la logique générale, sans faire l’exercice complet. »
|
||
|
||
PARTIE 2 – Exemple de réponse donnée par ChatGPT
|
||
|
||
Exemple :
|
||
|
||
User Story : « En tant que client, je veux payer ma commande en ligne afin de la finaliser. »
|
||
Cas d’utilisation possibles :
|
||
– Saisir ses informations de paiement
|
||
– Confirmer le paiement
|
||
– Obtenir une confirmation de commande
|
||
Risques si on utilise seulement des User Stories : manque de précision sur les enchaînements et les erreurs.
|
||
Risques si on utilise seulement des Cas d’utilisation : perte de la notion de valeur métier, backlog impossible à prioriser.
|
||
|