« 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.
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.
Le coût caché des défauts d'exigences
Les études de Barry Boehm établissent la règle des 1-10-100 : un défaut détecté en phase d'exigences coûte 1 à corriger ; en conception, 5 ; en développement, 10 ; en test, 50 ; après mise en production, 100 à 1 000. Le CHAOS Report du Standish Group identifie d'ailleurs les défauts d'exigences comme cause principale d'échec dans 40 à 60 % des projets en difficulté — devant les défauts techniques ou de planification.
Les quatre niveaux d'exigences
Le BABOK Guide (IIBA) distingue quatre niveaux à ne jamais confondre, dans une pyramide cumulative :
- Exigences métier — ce que veut l'organisation.
- Exigences parties prenantes — ce dont chaque acteur a besoin.
- Exigences fonctionnelles — ce que le système fait.
- Exigences non fonctionnelles — comment il le fait (qualité, performance, sécurité).
La règle d'or : une exigence doit toujours pouvoir remonter à un objectif métier.
Prioriser, exprimer, tracer
- MoSCoW (Must / Should / Could / Won't) priorise les exigences.
- User story (« En tant que… je veux… afin de… ») les exprime de manière centrée utilisateur.
- Modèle de Kano — les classe selon leur impact sur la satisfaction.
- Matrice de traçabilité — les relie aux livrables et aux tests.