L'analyse des exigences
- Code
- PRO 1.04
- Public
- Rayon disciplinaire, tous publics
- Cours
- 10 pages, PDF
- Diaporama
- 25 diapositives, thèmes sombre et clair, PowerPoint modifiable et PDF
- Synthèse
- 2 pages, PDF
- Podcast
- Fichier audio
- Vidéo
- Fichier vidéo MP4
- Infographie
- L'essentiel de la fiche sur une image
- Avec l'achat
- Téléchargement dans votre espace client
« Il faut que ça marche mieux. » Comment transformer ce besoin vague, partiel et contradictoire en quelque chose de précis, mesurable et testable ? C'est tout le travail de l'analyse des exigences — le pont entre le cadrage et la réalisation.
Voir ce que traite le coursCours
10 pages rédigées, en PDF.
Diaporama
25 diapositives en PowerPoint modifiable, thème sombre pour projeter et thème clair pour imprimer.
Synthèse
2 pages pour réviser l'essentiel.
Podcast
La notion expliquée à l'oral, à écouter hors de l'écran.
Vidéo
Une présentation animée de la notion, en MP4.
Infographie
L'essentiel de la fiche sur une image.
Ce que traite le cours
11 parties, 10 pages
IPourquoi l'analyse des exigences : le pont entre besoin et solution
- Du besoin à l'exigence : une transformation rigoureuse
- Le coût caché des défauts d'exigences
IILes quatre niveaux d'exigences : du métier au système
IIIExigences fonctionnelles vs non fonctionnelles : la distinction clé
- Le modèle FURPS+
- Le piège classique : tout fonctionnel, rien de non fonctionnel
IVLes techniques de recueil (élicitation des exigences)
- Combiner les techniques selon le contexte
VPrioriser avec MoSCoW : quatre catégories qui forcent les arbitrages
- Le principe d'arbitrage : pas plus de 60 % en MUST
- Le « W » : la valeur de dire « pas cette fois »
VILe format user story : exprimer le besoin de l'utilisateur
- La force du format : 3 questions, 1 phrase
- Les critères d'acceptation : la condition de Done
VIILe modèle de Kano : qualifier les attentes utilisateur
- La hiérarchie de priorisation Kano
- La dynamique temporelle des attentes
VIIILa matrice de traçabilité : relier exigences, livrables et tests
- Les 7 colonnes obligatoires
- La traçabilité bi-directionnelle
IXVérification et validation : Boehm et la double V
XPièges classiques et facteurs clés de succès
- Les pièges classiques
- Les facteurs clés de succès
XIArticulation inter-fiches et synthèse
- Positionnement dans le référentiel
Notions, outils et auteurs
Chaque repère mène aux autres fiches qui le traitent.
Notions
Modèles et outils
Présentation de la notion
Du besoin flou à l'exigence testable
Une exigence est, selon l'IEEE 830, « une condition ou une capacité qui doit être satisfaite ou possédée par un système ». Le besoin est vague, partiel, contextuel ; l'exigence est précise, complète, formelle, traçable. L'analyse effectue ce passage sans trahir le besoin initial.
La suite de cet article se lit librement sur le Mag : lire le guide complet de la notion.
Objectifs de la fiche
- Transformer un besoin flou en exigence précise, complète, formelle et testable
- Distinguer les quatre niveaux d'exigences : métier, parties prenantes, fonctionnelles, non fonctionnelles
- Appliquer la règle d'or : une exigence doit toujours remonter à un objectif métier
- Prioriser des exigences avec la méthode MoSCoW et les classer avec le modèle de Kano
- Rédiger des exigences en format user story centré utilisateur
- Justifier l'investissement en analyse par la règle des coûts 1-10-100 de Boehm
Questions fréquentes
Qu'est-ce que l'analyse des exigences en gestion de projet ?
C'est le pont entre le cadrage et la réalisation. Elle transforme le besoin exprimé — souvent flou, partiel, contradictoire — en exigences structurées, hiérarchisées et testables, sans trahir le besoin initial.
Quels sont les quatre niveaux d'exigences ?
Selon le BABOK Guide (IIBA) : les exigences métier (ce que veut l'organisation), les exigences parties prenantes (ce dont chaque acteur a besoin), les exigences fonctionnelles (ce que le système fait) et les exigences non fonctionnelles (comment il le fait : qualité, performance, sécurité).
Qu'est-ce que la méthode MoSCoW ?
C'est une méthode de priorisation des exigences en quatre catégories : Must (indispensable), Should (souhaitable), Could (optionnel) et Won't (exclu). Elle se combine souvent avec le format user story et le modèle de Kano.
Pourquoi investir dans l'analyse des exigences ?
Parce que les défauts d'exigences sont à l'origine de 40 à 60 % des échecs de projets selon le Standish Group. La règle des coûts 1-10-100 de Boehm montre qu'un défaut coûte 1 à corriger en phase d'exigences contre 100 à 1 000 après mise en production.