Gains :
- Capacité à distinguer les exigences fonctionnelles et non fonctionnelles et à rédiger des expressions d'exigences claires et mesurables avec le soutien de l'intelligence artificielle
- Capacité à utiliser l'intelligence artificielle avec des invites structurées pour extraire l'histoire de l'utilisateur, les critères d'acceptation et la limite de portée des notes d'entretien.
- Prendre l'habitude de vérifier les exigences générées par l'IA pour détecter toute ambiguïté, contradiction et règle manquante et de les confirmer auprès des parties prenantes.
L'analyse des besoins consiste à définir de manière complète, claire et vérifiable ce qu'un système doit faire. C’est l’une des étapes où le spécialiste MIS produit le plus de valeur ; car une erreur ici augmente de façon exponentielle à la fin du projet. Il existe deux types fondamentaux d’analyse des besoins. L'exigence fonctionnelle décrit le travail que le système doit effectuer : « Le système doit envoyer un e-mail au client lorsqu'il confirme la commande. » L'exigence non fonctionnelle décrit ce que devrait être le système : des qualités telles que les performances, la sécurité, la convivialité et l'accessibilité. "L'écran de rapport doit s'ouvrir en moins de 2 secondes à charge moyenne" est une exigence non fonctionnelle.
Une bonne exigence a trois caractéristiques : elle est claire (elle a une interprétation unique), elle est mesurable (elle a un seuil testable) et elle est traçable (il est clair de quel besoin métier elle provient). « Le système doit être rapide » ne répond à aucun de ces critères ; « rapide » est subjectif, ne peut être mesuré, ne peut être testé. À ce stade, l’IA constitue une aide puissante pour rédiger les exigences et détecter les formulations ambiguës ; mais seule la partie prenante décide quelle règle métier est réelle.
Histoire d'utilisateur et critères d'acceptation
Un format courant dans la rédaction des exigences modernes est la user story : « En tant que [rôle], pour [objectif], je veux [fonctionnalité] ». Exemple : "En tant que commercial, je souhaite calculer la remise depuis l'écran du mobile afin de pouvoir établir des devis rapides sur le terrain." L'histoire est courte et axée sur les affaires ; Il n'impose pas de solution technique.
Chaque histoire doit avoir des critères d'acceptation : des conditions testables qui doivent être remplies pour que l'histoire soit considérée comme « correcte ». Un modèle fréquemment utilisé est le modèle « Donné/Quand/Puis » : « Étant donné : le client est dans le segment VIP. Quand : commande supérieure à 10 000 TL. Ensuite : le système applique une remise de 5 %. » Ce modèle élimine toute ambiguïté car il relie clairement la condition et le résultat attendu.
Astuce : lorsque vous écrivez une user story pour l'intelligence artificielle, assurez-vous de dire "générer au moins 2 critères d'acceptation au format Donné/Quand/Alors pour chaque story". Lorsque le modèle est obligé de produire des références, des lacunes cachées dans les exigences deviennent visibles.
Étape par étape : Extraction des exigences assistée par l'IA
Étape 1 — Collectez les entrées brutes. Journaux d'appels, e-mails, captures d'écran existantes, listes de plaintes. Plus l’apport est réel, moins il y a de fabrication.
Étape 2 — Extrayez la première série d'histoires. Donnez une contribution brute à l’intelligence artificielle et demandez-lui de produire des brouillons de user story. Cette étape n’est pas une liste complète, mais une première étape.
Étape 3 — Ajoutez des critères d'acceptation. Générez des critères Donné/Quand/Alors pour chaque histoire. Une histoire pour laquelle des critères ne peuvent être produits signifie en réalité qu’elle n’est pas suffisamment définie.
Étape 4 — Rechercher les contradictions et les lacunes. Demandez à l'IA « y a-t-il des contradictions, des duplications ou des situations indéfinies entre ces exigences ? » Demandez et faites vérifier. Filtrez le résultat en tant qu'humain.
Étape 5 — Priorisez et confirmez. Priorisez les histoires avec les parties prenantes en fonction de la valeur commerciale et de l’urgence. La décision prioritaire appartient à l’unité commerciale et non à l’IA.
N'oubliez pas les exigences non fonctionnelles
La plupart des projets ont des difficultés sur le terrain car ils oublient les non-fonctionnels lors de la rédaction des exigences fonctionnelles. Un rapport peut fonctionner « correctement », mais s’il met 45 secondes à s’ouvrir, personne ne l’utilisera. Le tableau suivant présente les types d'exigences non fonctionnelles couramment négligés et des exemples d'écriture mesurables.
Genre
mauvaise expression
expression mesurable
Performances
"Il faut être rapide"
"Réponse à la requête < 2 secondes à charge moyenne"
accessibilité
"Tout le monde devrait pouvoir l'utiliser"
"Conforme WCAG 2.1 AA ; navigation complète au clavier"
Sécurité
"Ça devrait être sûr"
"Les données personnelles sont cryptées au repos ; l'accès est basé sur les rôles"
disponibilité
"Ça devrait être facile"
"Le nouvel utilisateur finalise la commande en 3 étapes sans formation"
Disponibilité/continuité
"Je ne devrais pas planter"
"Disponibilité mensuelle ≥ 99,5 %"
Trois mini-cases : en chiffres
Cas 1 — Le prix d'un besoin non mesurable. L'écran, qui a été développé dans une banque avec l'exigence que "l'écran de rapport s'ouvre rapidement", s'est ouvert en 22 secondes sous charge de terrain. Le développeur pensait fournir le mot « rapide » dans son environnement (2 secondes). Si l'exigence avait été écrite comme suit : « < 3 secondes aux heures de pointe, débit réel », le problème aurait été détecté lors des tests. Le réaménagement a coûté 3 semaines et un coût supplémentaire mesurable.
Cas 2 — Écart capturé par les critères d'acceptation. Lors de la rédaction des critères d'acceptation pour l'histoire « Le système applique la remise » dans un projet de commerce électronique, la partie prenante a remarqué que ce qui se passerait si la remise était en conflit avec le coupon et la remise VIP n'était pas du tout discuté. Une seule question Donné/Quand/Alors a évité l’erreur de double remise avant la mise en ligne ; Cette erreur a entraîné de graves pertes de revenus dans des projets similaires.
Cas 3 — Règle créée par l'IA. Dans un projet RH, AI a ajouté la phrase « la demande de congé est automatiquement approuvée dans les 24 heures » au projet d'exigences. Aucune approbation automatique de ce type n’a été discutée lors de la réunion ; Le modèle avait élaboré une règle qui semblait « raisonnable ». À côté de chaque exigence, l’expert écrit « source : quel entretien/document ? En ajoutant la colonne, il a supprimé 4 phrases non sourcées.
Invite faible/Invite forte
Invite faible :
Écrivez des user stories pour ce projet.
Invite puissante :
Votre rôle : Vous êtes un analyste commercial MIS. Extrayez les témoignages d'utilisateurs de la note d'entretien ci-dessous. Règles : - Format : "En tant que [rôle], pour [objectif], je veux [fonctionnalité]. " - Écrivez AU MOINS 2 critères d'acceptation pour chaque récit au format Donné/Quand/Alors. raccord.- Rédiger les exigences non fonctionnelles mesurables (performance, sécurité, accessibilité) dans une section séparée. Note d'entretien :[texte]
Une invite puissante applique simultanément le format de l'histoire, les critères d'acceptation, la traçabilité des sources et les exigences non fonctionnelles ; Cela facilite le contrôle de la sortie.
Quatre modèles copiables
1) Clarification des exigences :
Passez en revue l’exigence ci-dessous. Marquez chaque affirmation qui est vague, incommensurable ou ouverte à plus d’une interprétation et rédigez une question de clarification pour chacune. N'inventez pas la réponse. Exigence : [texte]
2) Analyse des contradictions :
Dans la liste des exigences ci-dessous, recherchez les éléments qui se contredisent, sont répétitifs ou laissent des lacunes logiques. Rapportez chaque constatation avec les numéros d’éléments et une justification en une phrase. Liste : [texte]
3) Générer des critères d'acceptation :
Écrivez au moins 4 critères d'acceptation pour la user story suivante au format Given/When/Then, y compris les cas limites et d'exception. Énumérez également tous les points qui restent flous. Histoire : [texte]
4) Aperçu de la portée :
Rédigez les éléments « Dans le champ d'application » et « Hors du champ d'application » sous forme de tableau à deux colonnes conformément aux exigences suivantes. Étiquetez [CONFIRMATION REQUISE] pour tout article dont vous n'êtes pas sûr. Exigences : [texte]
Erreurs courantes
- Penser que la solution est un besoin. "Ajouter un menu déroulant" est une solution et non une exigence. L'exigence indique que « l'utilisateur doit pouvoir sélectionner le pays dans la liste définie » ; L'équipe informatique conçoit la solution.
- Sauter ceux qui ne sont pas fonctionnels. Le simple fait d’écrire « quoi faire » et d’oublier « comment être » (vitesse, sécurité, accessibilité) est la faille la plus courante et la plus coûteuse.
- Utiliser des adjectifs incommensurables. Des mots comme « rapide, facile, sûr, convivial » ne sont pas valides sans seuil.
- Ne pas remarquer la règle que l'IA a inventée. Le modèle peut ajouter des règles « raisonnables » mais non réellement énoncées ; Demandez des ressources pour chaque besoin.
- Laisser la priorité à l’IA. Ce qu'il faut faire en premier est une décision de valeur commerciale ; L'unité commerciale le donne.
Attention : La phrase la plus dangereuse dans l'analyse des besoins est « tout le monde le sait déjà ». Les hypothèses tacites ne figurent pas dans la documentation, ne figurent jamais dans le code et émergent sur le terrain. Demandez à l'IA : « qu'est-ce qui est supposé mais n'est pas écrit dans cette exigence ? » rend visibles ces hypothèses cachées.
En résumé
L'analyse des besoins définit ce que le système doit faire de manière claire, mesurable et traçable. Les exigences fonctionnelles décrivent le poste, les exigences non fonctionnelles décrivent les qualités, et ces dernières sont souvent oubliées. La user story et les critères d’acceptation Given/When/Then sont des outils puissants qui éliminent l’incertitude. L'intelligence artificielle accélère considérablement la production de storyboards, de critères d'acceptation, de détection de conflits et de clarification des questions ; Cependant, l'exactitude de la règle métier, la portée et la décision de priorité, ainsi que la source de chaque phrase relèvent de la responsabilité de l'humain. Ne finalisez aucune exigence sans source et incommensurable.
Tâche de candidature
Rédigez une demande commerciale en un paragraphe pour un « système de rendez-vous en ligne » imaginaire (par exemple, « Les clients devraient pouvoir prendre des rendez-vous en ligne, le personnel devrait pouvoir voir les calendriers »). (1) Créez au moins 5 user stories et 2 critères d'acceptation pour chacune avec une invite forte à partir de cette demande. (2) Trouver au moins 2 lacunes cachées dans les critères produits par le modèle (par exemple double rendez-vous en même temps, règle d'annulation). (3) Inclure au moins 3 exigences non fonctionnelles sous une forme mesurable. (4) Identifiez au moins 3 éléments comme étant « hors de portée ». (5) Marquez une règle que le modèle aurait pu inventer et écrivez comment vous la confirmeriez.
liste de contrôle
- [ ] J'ai écrit séparément les exigences fonctionnelles et non fonctionnelles.
- [ ] Chaque exigence est claire, mesurable et testable.
- [ ] Chaque histoire a des critères d'acceptation Donné/Quand/Alors.
- [ ] Je peux retracer la source (conversation/document) de chaque exigence.
- [ ] J'ai marqué les règles possibles que l'IA avait inventées et je les ai laissées pour confirmation.
- [ ] J'ai fait la priorisation en collaboration avec la business unit.