204 lines
13 KiB
Plaintext
204 lines
13 KiB
Plaintext
Q1 Frontière EF/ENF dépendante du contexte
|
||
|
||
Ainsi en voyant cette exemple donné par (Chat GPT - modele 5.1) j'avais un début de piste pour réaliser la question:
|
||
|
||
Q1-a :
|
||
|
||
Contexte 1 : Application éducative plateforme d’apprentissage (Duolingo) ENF
|
||
Changer son mot de passe ne fait pas partie du parcours pédagogique.
|
||
C’est une exigence de sécurité, donc ENF.
|
||
|
||
Contexte 2: Plateforme d’investissements / trading (Boursorama / Trading Republic)
|
||
Dans ce type d’application, une compromission de compte peut faire perdre de l’argent.
|
||
La notification immédiate fait partie de la protection métier du capital de l’utilisateur.
|
||
|
||
Q1-b et Q1-c
|
||
|
||
Contexte 1 : Application éducative (type Duolingo)
|
||
Classification : ENF (exigence non-fonctionnelle)
|
||
|
||
Q1-b – Exigence adaptée au contexte éducatif
|
||
« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer une notification push informative dans un délai inférieur à 10 secondes, afin de garantir un niveau de sécurité minimal pour la gestion du compte. La notification doit indiquer la date et l’heure de la modification. »
|
||
Ici, l’envoi de notification n’est pas lié au cœur du métier (apprendre une langue). C’est uniquement une règle de sécurité.
|
||
|
||
Q1-c – Impact sur le backlog (application éducative)
|
||
Étant une exigence non-fonctionnelle, cette notification n’apparaît pas comme une User Story autonome dans le backlog. Elle sera intégrée comme critère d’acceptation dans une User Story plus large de type « Gérer son compte ». Cette exigence n’a pas de valeur métier directe pour l’utilisateur, ce qui la place à une priorité moindre dans le backlog. Elle ne génère pas de sous-stories, car il s’agit d’une simple contrainte technique ou de sécurité.
|
||
|
||
Contexte 2 : Plateforme d’investissement / trading
|
||
Classification : EF (exigence fonctionnelle)
|
||
|
||
Q1-b – Exigence adaptée au contexte investissement/trading
|
||
« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer immédiatement une notification push d’alerte contenant la date, l’heure, l’adresse IP d’origine et un lien permettant de bloquer rapidement le compte en cas d’activité suspecte. Le délai d’envoi de la notification ne doit pas dépasser 5 secondes. »
|
||
Dans ce contexte, informer l’utilisateur est une fonction métier essentielle, car elle permet de protéger ses actifs.
|
||
|
||
Q1-c – Impact sur le backlog (plateforme d’investissement)
|
||
Cette exigence est une exigence fonctionnelle et devient une User Story à part entière dans le backlog, car elle contribue directement à la protection des capitaux de l’utilisateur. Elle est prioritaire et doit être développée en début de projet. De plus, elle entraîne un découpage en plusieurs User Stories ou sous-tâches (définition du contenu de l’alerte, action de blocage, gestion des logs, délai d’envoi), ce qui augmente la granularité du backlog.
|
||
|
||
--------------------------
|
||
|
||
Q2 – Refonte d’un backlog non INVEST
|
||
|
||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||
|
||
Q2-a – Début de réponse
|
||
Pour la question 2-a, j’ai commencé par relire les trois User Stories données. J’ai remarqué qu’elles sont toutes formulées de manière assez large, et on voit déjà que certaines expressions comme “tableau de bord complet” ou “interface moderne” semblent poser problème. Je pense que ces US ne respectent pas vraiment les critères INVEST, mais je dois encore préciser exactement lesquels et pourquoi.
|
||
|
||
Q2-b – Début de réponse
|
||
Pour la partie 2-b, j’ai essayé de réfléchir à plusieurs User Stories plus simples et plus précises. Mon idée est de partir des mêmes besoins mais en les divisant en fonctionnalités plus petites. J’ai déjà quelques pistes, par exemple sur l’affichage des tâches ou la gestion des comptes, mais il faut que je les reformule correctement au format US.
|
||
|
||
Q2-c – Début de réponse
|
||
Pour la partie 2-c, je commence à réfléchir aux critères d’acceptation possibles pour certaines des nouvelles User Stories. Pour l’instant, je me dis qu’il faudrait au moins deux critères clairs et testables, mais je dois choisir les US les plus adaptées avant de définir ces critères.
|
||
|
||
En utilisant ce modèle, j’ai commencé à analyser les User Stories du sujet.
|
||
|
||
Réponse finale complète de mes questions à la Q2 grâce à l'aide de l'IA (Chat GPT - modele 5.1):
|
||
|
||
Q2-a – Identification des problèmes dans les User Stories
|
||
|
||
US1 : « En tant qu’utilisateur, je veux un tableau de bord complet avec une vue globale de toutes mes activités. »
|
||
|
||
Problèmes INVEST :
|
||
|
||
– I : dépend d’autres fonctionnalités
|
||
– S : trop large (« complet », « global »)
|
||
– T : non testable sans préciser les informations attendues
|
||
– E : non estimable, périmètre flou
|
||
– V : valeur métier non explicite
|
||
|
||
US2 : « En tant qu’utilisateur, je veux une interface moderne afin d’améliorer mon expérience. »
|
||
|
||
Problèmes INVEST :
|
||
|
||
– V : valeur métier non définie
|
||
– E : non estimable (« moderne » est subjectif)
|
||
– T : non testable
|
||
– S : trop large (design, navigation, composants)
|
||
|
||
US3 : « En tant qu’administrateur, je veux gérer tout le système efficacement. »
|
||
|
||
Problèmes INVEST :
|
||
|
||
– S : trop grande (« tout le système »)
|
||
– I : dépend de multiples fonctionnalités (utilisateurs, contenus…)
|
||
– T : impossible à tester
|
||
– E : impossible à estimer, périmètre trop vaste
|
||
|
||
Q2-b – Nouveau backlog contenant au moins 6 User Stories INVEST
|
||
|
||
US-A : En tant qu’utilisateur, je veux consulter la liste de mes tâches du jour afin de commencer rapidement mon travail.
|
||
US-B : En tant qu’utilisateur, je veux filtrer mes tâches par projet afin de visualiser uniquement celles qui me concernent.
|
||
US-C : En tant qu’utilisateur, je veux afficher mes tâches en retard afin d’identifier mes priorités.
|
||
US-D : En tant qu’utilisateur, je veux activer un mode clair ou sombre afin d’ajuster le confort visuel.
|
||
US-E : En tant qu’administrateur, je veux créer un compte utilisateur afin d’ajouter un nouveau collaborateur à la plateforme.
|
||
US-F : En tant qu’administrateur, je veux désactiver un compte utilisateur afin de retirer l’accès à un collaborateur quittant l’entreprise.
|
||
|
||
Q2-c – Critères d’acceptation (pour deux User Stories du backlog corrigé)
|
||
|
||
Story X – US-A : « Consulter la liste de mes tâches du jour »
|
||
|
||
Critère 1 : La section « Aujourd’hui » affiche uniquement les tâches avec une date d’échéance correspondant à la date du jour.
|
||
Critère 2 : Si aucune tâche n’est prévue pour aujourd’hui, l’application affiche le message « Aucune tâche pour aujourd’hui ».
|
||
|
||
Story Y – US-F : « Désactiver un compte utilisateur »
|
||
|
||
Critère 1 : Lorsqu’un administrateur désactive un compte, l’utilisateur concerné ne peut plus se connecter et le message « Compte désactivé » apparaît.
|
||
Critère 2 : Les tâches précédemment assignées à cet utilisateur restent visibles dans l’historique, mais le compte apparaît comme « désactivé ».
|
||
|
||
Q3 – Gestion des ruptures de stock dans une boutique en ligne
|
||
|
||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||
|
||
Q3-a – Début de réponse
|
||
|
||
Pour le début de la question 3-a, j’ai essayé de reconstituer le processus métier lié à la rupture de stock. Je vois qu’il faut décrire les étapes dans l’ordre logique, en partant du moment où le client consulte le produit jusqu’à la remise en stock. J’ai quelques premières idées mais il faut encore organiser les étapes de façon plus précise.
|
||
|
||
Q3-b – Début de réponse
|
||
|
||
Pour la partie 3-b, j’ai regardé le diagramme du domaine fourni. Je pense qu’il manque certaines classes importantes, surtout pour gérer les alertes et les commandes fournisseurs. Je dois encore déterminer exactement quelles classes et quels attributs ajouter.
|
||
|
||
Q3-c – Début de réponse
|
||
|
||
Pour le Given/When/Then, je comprends qu’il faut prendre un scénario précis autour de la remise en stock. J’ai déjà imaginé un cas où un produit est en rupture et où un utilisateur est inscrit à l’alerte, mais je dois formaliser ça correctement dans le format attendu.
|
||
|
||
|
||
Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1):
|
||
|
||
Q3-a – Rédaction du processus métier (au moins 8 étapes)
|
||
|
||
Le client consulte la page d’un produit dans la boutique en ligne.
|
||
Le système vérifie le niveau de stock du produit.
|
||
Si le stock est positif, le système permet l’ajout normal au panier.
|
||
Si le produit est en rupture, le système empêche l’ajout au panier et affiche un message d’indisponibilité.
|
||
Le système propose alors au client de s’inscrire à une alerte de remise en stock.
|
||
Si le client accepte, le système enregistre une demande d’alerte associée au client et au produit.
|
||
En parallèle, lorsque le stock atteint le seuil de rupture, le système génère automatiquement une commande fournisseur et l’associe au service logistique pour suivi.
|
||
Lorsque l’employé logistique enregistre la réception de la commande fournisseur, le système augmente le stock du produit.
|
||
Dès que le produit redevient disponible, le système déclenche une notification (email ou push) pour tous les clients inscrits à l’alerte.
|
||
|
||
|
||
Q3-b – Modifications à apporter au Diagramme de Classes du Domaine
|
||
|
||
Nouvelles classes :
|
||
|
||
– AlerteRuptureStock
|
||
– CommandeFournisseur
|
||
|
||
Nouveaux attributs pertinents :
|
||
|
||
– Produit : stockDisponible, stockSeuilRupture, etatDisponibilite
|
||
– AlerteRuptureStock : dateInscription, canalNotification
|
||
– CommandeFournisseur : dateCommande, quantiteCommande, statutCommande
|
||
|
||
Ces ajouts permettent de représenter les processus de rupture, de réapprovisionnement et de notification.
|
||
|
||
Q3-c – Scénario de test d’acceptation (Given / When / Then)
|
||
|
||
Given un produit dont le stockDisponible est égal à 0 et un client inscrit à l’alerte de remise en stock,
|
||
When l’employé logistique enregistre la réception d’une commande fournisseur augmentant le stock du produit,
|
||
Then le système met à jour l’état du produit à “disponible” et envoie une notification au client inscrit pour l’informer de la remise en stock.
|
||
|
||
Q4 – Complémentarité entre User Stories et Cas d’utilisation
|
||
|
||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||
|
||
Q4-a – Début de réponse
|
||
|
||
Pour la question 4-a, j’ai commencé par choisir une User Story autour de la commande en ligne. Je vois comment cette US peut être déclinée en plusieurs cas d’utilisation, mais je dois encore faire la liste complète des actions qui en découlent.
|
||
|
||
Q4-b – Début de réponse
|
||
|
||
Pour la partie 4-b, j’ai essayé d’identifier les problèmes d’un projet basé uniquement sur les User Stories. Je vois déjà que cela peut créer des zones floues, mais il faut que je développe mieux ces idées.
|
||
|
||
Q4-c – Début de réponse
|
||
|
||
Pour la dernière sous-question, j’ai réfléchi aux risques inverses, c’est-à-dire un projet basé seulement sur des cas d’utilisation. Je pense que cela pose des problèmes de priorisation et de valeur métier, mais je dois encore formuler tout ça plus clairement
|
||
|
||
Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1) :
|
||
|
||
Q4-a – Exemple de User Story et cas d’utilisation dérivés
|
||
|
||
User Story choisie :
|
||
|
||
« En tant que client, je veux passer une commande en ligne afin de recevoir mes produits à domicile. »
|
||
Cas d’utilisation dérivés :
|
||
– Consulter un produit et l’ajouter au panier
|
||
– Modifier le contenu du panier
|
||
– Saisir une adresse de livraison
|
||
– Choisir un mode de livraison
|
||
– Sélectionner un moyen de paiement
|
||
– Valider la commande
|
||
– Recevoir un récapitulatif de commande
|
||
|
||
Q4-b – Risques d’un projet qui ne repose que sur des User Stories
|
||
|
||
Un projet qui se limite uniquement aux User Stories risque de ne pas décrire précisément les enchaînements d’actions et les scénarios alternatifs, ce qui peut provoquer des ambiguïtés lors du développement. Les comportements attendus en cas d’erreur ou d’exception ne sont pas explicités, ce qui entraîne des implémentations différentes selon les développeurs. L’absence de scénarios détaillés complexifie également les tests, car il devient difficile de valider le comportement complet du système.
|
||
|
||
Q4-c – Risques d’un projet qui n’utilise que des Cas d’utilisation
|
||
|
||
Se baser seulement sur des Cas d’utilisation peut conduire à ignorer la notion de valeur métier et de priorisation. Tous les cas apparaissent alors sur le même niveau d’importance, ce qui rend le backlog difficile à organiser pour un développement itératif. L’équipe risque de se concentrer sur la complétude documentaire plutôt que sur la livraison de fonctionnalités ayant un impact direct pour l’utilisateur. Cela augmente le risque de retard et d’alignement insuffisant avec les besoins réels du métier.
|
||
|
||
|
||
|
||
|
||
|