Recueillir efficacement les besoins
CHAPITRE 3
93
Formaliser les besoins
Pourquoi formaliser les besoins ?
Traditionnellement, les besoins exprimés par les utilisateurs ou leur représentant sont
formalisés dans un support documentaire linéaire, qu’il s’agisse d’un volumineux cahier
des charges ou d’un mail de quelques lignes. En tout état de cause, ils sont exprimés dans
un langage métier, celui des utilisateurs, en termes d’usage ou de services attendus.
Ces besoins sont ensuite pris en charge par l’équipe de réalisation puis introduits dans un
cycle de fabrication ; ce cycle de fabrication comporte une succession d’étapes au cours
desquelles le besoin subit plusieurs transformations et revêt la forme d’un modèle, d’une
classe, de lignes de code, d’un composant technique, d’un document ou d’un scénario de
test, pour devenir une fonctionnalité opérationnelle.
Comment établir un rapprochement entre des besoins initiaux et les états intermédiaires que connaissent ces besoins ? Comment introduire une communication entre
des utilisateurs qui expriment ces besoins et des techniciens qui « manipulent » des
concepts techniques, sachant qu’ils utilisent des supports et des outils différents ?
Comment limiter les ruptures dans la chaîne de fabrication ?
L’enjeu de la formalisation des besoins est double :
1. Aucune déperdition d’information n’est acceptable aux franchissements d’étapes de
la chaîne de fabrication.
En effet, comme dans le jeu du téléphone arabe (ce jeu qui consiste à se transmettre
rapidement une phrase de bouche à oreille entre les joueurs un par un, le premier
inventant la phrase, et le dernier récitant à voix haute la phrase qu’il a entendue et
On obtient ainsi un tableau de rapprochement entre les besoins et les différents acteurs
(tableau 3-2).
Dans notre exemple, le besoin 1 sera détaillé par Mme X et Mlle A qui pourra avoir une contribution ; il sera validé par M. Y ; M. Z, quant à lui, sera informé du résultat. Le besoin 2 sera
traité par M. Y, qui est probablement un directeur, puisqu’il valide son propre travail.
NB : Une personne peut détenir à la fois le rôle de responsable et d’approbateur.
Ainsi, chaque besoin a un référent, source d’information et centre de décision.
Tableau 3-2 Exemple matrice RACI
Mme X
M. Y
M. Z
Mlle A
Besoin 1
R
A
I
C
Besoin 2
R/A
I
Besoin 3
A
R
I
C
GestProjInform Livre Page 93 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 3
93
Formaliser les besoins
Pourquoi formaliser les besoins ?
Traditionnellement, les besoins exprimés par les utilisateurs ou leur représentant sont
formalisés dans un support documentaire linéaire, qu’il s’agisse d’un volumineux cahier
des charges ou d’un mail de quelques lignes. En tout état de cause, ils sont exprimés dans
un langage métier, celui des utilisateurs, en termes d’usage ou de services attendus.
Ces besoins sont ensuite pris en charge par l’équipe de réalisation puis introduits dans un
cycle de fabrication ; ce cycle de fabrication comporte une succession d’étapes au cours
desquelles le besoin subit plusieurs transformations et revêt la forme d’un modèle, d’une
classe, de lignes de code, d’un composant technique, d’un document ou d’un scénario de
test, pour devenir une fonctionnalité opérationnelle.
Comment établir un rapprochement entre des besoins initiaux et les états intermédiaires que connaissent ces besoins ? Comment introduire une communication entre
des utilisateurs qui expriment ces besoins et des techniciens qui « manipulent » des
concepts techniques, sachant qu’ils utilisent des supports et des outils différents ?
Comment limiter les ruptures dans la chaîne de fabrication ?
L’enjeu de la formalisation des besoins est double :
1. Aucune déperdition d’information n’est acceptable aux franchissements d’étapes de
la chaîne de fabrication.
En effet, comme dans le jeu du téléphone arabe (ce jeu qui consiste à se transmettre
rapidement une phrase de bouche à oreille entre les joueurs un par un, le premier
inventant la phrase, et le dernier récitant à voix haute la phrase qu’il a entendue et
On obtient ainsi un tableau de rapprochement entre les besoins et les différents acteurs
(tableau 3-2).
Dans notre exemple, le besoin 1 sera détaillé par Mme X et Mlle A qui pourra avoir une contribution ; il sera validé par M. Y ; M. Z, quant à lui, sera informé du résultat. Le besoin 2 sera
traité par M. Y, qui est probablement un directeur, puisqu’il valide son propre travail.
NB : Une personne peut détenir à la fois le rôle de responsable et d’approbateur.
Ainsi, chaque besoin a un référent, source d’information et centre de décision.
Tableau 3-2 Exemple matrice RACI
Mme X
M. Y
M. Z
Mlle A
Besoin 1
R
A
I
C
Besoin 2
R/A
I
Besoin 3
A
R
I
C
GestProjInform Livre Page 93 Vendredi, 3. avril 2009 12:07 12