Les exigences perdent leur raison d’être en cours de projet. C’est là le vrai problème.
Elles naissent en atelier, atterrissent dans une liste, migrent vers l’outil de tickets – et un jour plus personne ne sait quel besoin métier se trouvait derrière. TAOM conserve le lien avec l’étape, le rôle et le système dont l’exigence est issue.
Affinement
Une exigence ne s’écrit pas, elle s’affine
Entre « il nous faut un contrôle » et un champ construit, il y a huit étapes. Le désaccord en projet vient rarement du contenu, mais de l’incertitude sur qui porte l’étape suivante.

L’intérêt
La question qui arrive deux ans plus tard
Un jour, quelqu’un demande pourquoi tel champ existe, si un contrôle est encore nécessaire, ou ce qui se passe si l’on retire une extension.

À quoi tient une exigence
Six liens qui subsistent
Processus
Dans quel déroulement elle est nécessaire.
Activité
À quelle étape précise elle est apparue.
Rôle
Qui en a besoin et qui en répond.
Système
Quelle application doit la satisfaire.
Objectif métier
À quoi elle contribue.
Contexte de développement
Ce qui en est construit – jusqu’à la catégorie WRICEF.
D’où elles viennent
La plupart des exigences sont des constats issus de la découverte
Ce qui ressort en atelier
- 01Fonctions système manquantesCe que le système ne sait pas faire et que l’on contourne.
- 02Solutions de contournementLe tableur à côté du système, sans lequel rien ne tourne.
- 03Lacunes d’interfaceDes données transférées à la main.
- 04Obligations et preuvesCe que quelqu’un satisfait au passage, sans que ce soit documenté.
- 05Problèmes de donnéesDes champs auxquels personne ne se fie.
Aucune rupture entre les deux
Ces constats naissent lors de la découverte de processus – et restent attachés à l’étape où ils sont apparus.
Découverte → constat → exigence → réalisation forme ainsi un seul acte, et non un passage de relais entre deux outils.
Ce qui en résulte
Mené jusqu’à la recette
- 01Exigences métierCe dont le métier a besoin, dans la langue du métier.
- 02Exigences fonctionnellesCe que le système doit fournir pour cela.
- 03Objets WRICEFWorkflow, Report, Interface, Conversion, Enhancement, Form.
- 04Spécifications fonctionnelles et techniquesComportement et réalisation, tous deux sur le même lien.
- 05User storiesPour les équipes qui travaillent ainsi – avec la même origine.
- 06Critères de recetteCe à quoi l’on mesure que c’est satisfait.
Occasions typiques
Où cela s’emploie
- 01Projets de transformationQuand beaucoup d’exigences naissent en même temps et perdent vite leur lien.
- 02Suites du fit-to-standardChaque écart devient une exigence motivée.
- 03Remplacement de systèmes anciensDistinguer les particularités nécessaires au métier de celles qui sont seulement historiques.
- 04Préparation d’auditProuver pourquoi un contrôle existe et où il agit.
- 05Passage à la réalisationDes spécifications qui livrent aussi la raison métier.
- 06Test et recetteOn teste contre le besoin, pas seulement contre le document.
Commencer
Avec une exigence actuellement contestée
Prenez-en une dont plus personne ne sait dire pourquoi elle est formulée ainsi. Rattachez-la à l’étape dont elle est issue – et voyez combien la discussion devient plus claire.