Vous êtes sur la page 1sur 260

C

Lauteur
Consultant en systmes dinformation, Yves
Constantinidis a dirig avec succs llaboration de plusieurs cahiers des charges de porte
nationale (ministre de la Sant, ministre de
lducation nationale). Informaticien de formation, il intervient sur des missions de choix de solutions, de diagnostic du systme dinformation et
damlioration du processus de dveloppement.
Son expertise la amen publier trois ouvrages
sur lingnierie du systme dinformation et la
qualit du logiciel (ditions Herms), et intervenir comme formateur auprs dtablissements
denseignement suprieur (Epita, cole des hautes
tudes en sant publique).
Michel Volle est prsident dhonneur du Club des
Matres dOuvrage des Systmes dInformation.

omment recueillir tous les besoins des acteurs du systme dinformation, et rien que leurs besoins rels ? Comment se mettre
daccord sur la spcification des exigences ? Comment aboutir
un cahier des charges clair, complet et consensuel ? Phase cruciale
dans le choix, le dveloppement ou la mise en uvre dune solution
dentreprise, la dfinition des besoins conditionnera en effet la russite du projet, notamment son cot et sa qualit. Mais cette tape
est complexe et dlicate, en raison du nombre et de la diversit des
parties prenantes, des demandes souvent divergentes, des contraintes
varies et, last but not least, du facteur humain.
Vritable guide de terrain, nourri par la grande exprience de son auteur,
cet ouvrage prsente une dmarche et des techniques prouves pour
recueillir et formaliser les vrais besoins, afin dlaborer un cahier des
charges dune qualit irrprochable, dans des dlais raisonnables et au
moindre cot. partir dun exemple permettant de mieux saisir les
enjeux, la premire partie expose les prrequis, puis dcrit le processus
et les activits prparatoires indispensables : dfinition des objectifs et
du primtre, analyse des parties prenantes, planification de llaboration. La deuxime partie dtaille les quatre grandes tapes de cette
mthode (recueil, analyse, spcification et validation), avec la cl des
modles de documents, des grilles et des check-lists. Enfin, la troisime
partie porte sur les techniques et les outils de gestion des exigences, et
sachve par des conseils pour samliorer encore. Grce cet ouvrage
dune clart exceptionnelle, le lecteur sera ainsi prt relever les dfis
que pose toute mission de dfinition des besoins.

Aux consultants en systmes


dinformation
Aux experts techniques et mtier
Aux architectes du systme
dinformation
tous ceux qui sont impliqus dans
llaboration dun cahier des charges

9 782212 127836

Mthodologie. La mthode en action. Les enjeux dune bonne


dfinition des besoins. Comptences et savoir-faire. Exigences
et cycle de vie du logiciel. La dmarche. Dfinir le concept et
les objectifs. Planifier le projet dlaboration. Dveloppement
des exigences. Ltape de recueil. Les cas dutilisation. Ltape
danalyse. Les exigences non fonctionnelles. Exigences projet
et contraintes techniques. Ltape de spcification. Structure
du cahier des charges. Ltape de validation. Amliorer le processus. Faire vivre les exigences. La gestion des exigences. Les
outils. Au-del des exigences. Neuf conseils.

Code diteur : G12783

Au sommaire

Aux assistants la matrise


douvrage (AMOA)

ISBN : 978-2-212-12783-6

qui sadresse ce livre ?

35

pour le systme dinformation

dinformation

Expression des besoins

pour le systme

YVES
CONSTANTINIDIS

Expression des besoins

Y V E S C O N S T A N T I N I D I S
P r f a c e
d e
M i c h e l
V o l l e

Expression
des besoins

pour le systme

information

Guide dlaboration
du cahier des charges

Gratuit !

60 modles de livrables
prts lemploi
un outil de cration
de business plan

user 189 at Fri Nov 19 12:40:28 +0100 2010

Livre Constant.indb 246

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Prface
Daprs le Standish Group, les projets informatiques connaissent un taux
dchec qui ne saurait tre tolr dans aucun autre domaine de lingnierie: de ses enqutes, on peut retenir quen gros 25% des projets chouent,
50% aboutissent avec un dlai et un cot trs suprieurs la prvision,
25% seulement sont convenablement russis. En cas dchec, on entend
souvent dire cest la faute de linformatique, mais en fait, il convient
de dire que, par principe, cest toujours la faute du mtier que le produit informatique devait outiller (matrise douvrage, MOA). Certes, il arrive que le
ralisateur du produit (matrise duvre, MOE) soit dfaillant, mais alors
la MOA aurait d prendre en temps utile des mesures pour redresser la
situation. Souvent dailleurs, le seul tort de la MOE sera davoir accept
un contrat impossible, car lingnierie des besoins a t dfaillante et le
projet tait donc condamn ds le dpart: la MOA sest lance dans le
projet sans savoir ce quelle voulait faire, sans avoir exprim ses priorits
ni lev les ambiguts du vocabulaire, puis par la suite elle a t versatile,
etc. Une expression de besoin bien faite garantit le succs ou du moins
(car on ne peut jamais se prmunir contre toutes les surprises) une probabilit de succs de lordre de 90%: on mesure lenjeu si lon compare
ce taux aux donnes du Standish Group.
Jean-Pierre Meinadier est lun des matres franais les plus respects en
ingnierie des systmes industriels1. Invit participer un projet de systme dinformation (SI), il fut immdiatement congdi pour avoir pos
une question juge incongrue: qui est responsable?. Il a alors compris
que contrairement un projet dautomobile ou davion, dont les enjeux
techniques sont mesurables et froids, un SI est chaud: chaque
projet comporte implicitement de tels enjeux politiques de lgitimit,
de dcoupage des pouvoirs et de responsabilit, que lentreprise prfre
souvent laisser implicites les donnes ncessaires son succs. Cest
cette chaleur du SI qui explique le taux dchec extravagant des projets. Les acteurs ne manquent ni de bon sens ni dintelligence, mais ils les
mettent au service de priorits qui ne sont pas celles de lefficacit de la
production de lentreprise ni de la qualit de ses produits objectifs qui,
en revanche, sont prcisment ceux que sert un SI.

1. Jean-Pierre Meinadier, Ingnierie


et intgration des
systmes, Hermes,
1998.

Livre Constant.indb 5

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

Lenjeu de lingnierie des besoins nest donc pas purement technique:


il sagit de promouvoir des priorits (efficacit, qualit) qui sans doute
devraient tre celles de toute entreprise, mais qui sopposent dautres
formulations de sa mission (produire de largent ou de la valeur pour
lactionnaire) ainsi que les intrts des corporations professionnelles.
Pour pouvoir agir dans les sables mouvants de la sociologie et de lidologie, il faut des ides claires et des principes fermes: cest ce que nous
propose ici Yves Constantinidis. On peut en effet dsamorcer les piges
de la politique si lon sait sy prendre temps, dans ltape prliminaire et relativement froide de lexpression de besoins, si lon se
donne la peine dliminer les dfauts du vocabulaire et les malentendus
quils provoquent, si lon sest enquis de la pertinence des besoins et
priorits, si lon a obtenu les validations qui, tant authentiques, scellent
laccord ultrieur des dirigeants et leur soutien au projet.
Le pivot de cette affaire, cest la personne morale que Constantinidis
nomme assistance matrise douvrage et que je prfre nommer
matrise douvrage dlgue (MOAD), car elle a reu du directeur, stratge et responsable suprme de la MOA quil engage par sa signature,
dlgation du soin de lexpertise en SI. La MOAD a trois interlocuteurs:
les stratges (celui du mtier et le DG, stratge de lentreprise), les utilisateurs (qui se subdivisent en plusieurs catgories) et linformatique
(cest--dire la MOE qui peut tre, selon les cas, soit la DSI de lentreprise,
soit un fournisseur). Elle doit savoir parler les langages de ces divers
interlocuteurs et assurer entre eux la fonction dinterprte. La MOAD est
donc une vraie spcialit, et celui qui a exerc cette fonction pendant
quelques annes acquiert une connaissance approfondie de lentreprise
et du mtier pour lesquels il travaille, y compris dans leurs dimensions
politiques et symboliques quil sait grer avec souplesse et discrtion. Malheureusement, les entreprises nont pas encore toutes compris
la ncessit de cette fonction, ni peru les comptences quelle exige: sa
dnomination change dune entreprise lautre, et cela montre bien la
perplexit des DRH.
Loutil fondamental de la MOAD est un modle, une mise en forme qui
concrtise lexpression de besoin en schmatisant le mtier tel quil fonctionnera une fois outill par le SI. Tout comme une base de donnes, ce
modle est un tre que personne ne peut voir en entier, mais qui prsente
chaque catgorie dacteurs la vue qui lui convient: linformaticien, le
diagramme de classe, tape initiale de la programmation dans un langage
objets (et quelques autres diagrammes) ; au stratge, le diagramme
dactivit qui dcrit le processus. Pour les utilisateurs, la vue pourra tre
audiovisuelle : en plaant sur lintranet un dessin anim complt par
une documentation et un outil dautoformation, on aide chacun percevoir la finalit du systme et ltendue de sa responsabilit personnelle,

VI

Livre Constant.indb 6

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Prface

on lucide le processus de production dans lequel il intervient. Le cahier


des charges est, sur ce modle, la vue qui prcise et rcapitule toutes les
exigences auxquelles le produit doit satisfaire, quelles soient propres au
mtier ou la plate-forme technique de linformatique. Ce document peut
prendre une forme contractuelle, mais mieux vaut le concevoir comme
une tape ncessaire de la coopration entre la MOE et la MOAD.
Pour prendre une mtaphore dans la vie courante, supposons que vous
fassiez construire une maison. Vous avez tabli son plan avec laide dun
architecte et dites: dans cette pice, il faudra quatre prises de courant
et une applique commande par un interrupteur. Ce sont l des spcifications gnrales, produites par la MOAD avec le conseil de la MOE et valides
par le stratge. Puis la MOE demande la MOA de dire o installer les
prises, les interrupteurs et lapplique. Marquer ces emplacements sur le
plan, cest tablir les spcifications dtailles, produites par la MOE et valides par la MOAD. Enfin, la MOE fera le plan de cblage qui prcise le
parcours des goulottes et saignes: ce sont des spcifications techniques qui
nintressent pas la MOA, mais qui sont indispensables pour passer la
ralisation.
Il importe de respecter cette progression: comme le dit Donald Knuth,
loptimisation prmature est la racine de tous les maux et certains
projets senlisent parce que lon se proccupe, ds une phase initiale, de
choix techniques qui devraient intervenir plus tard. Il faut, nous lavons
dit, que les validations soient authentiques: chacun des responsables doit
pouvoir comprendre les documents quon lui soumet, et se savoir engag
par sa signature. Il ne convient pas, par exemple, de soumettre le diagramme de classe un stratge, car cette vue sur le modle nest pas
faite pour lui: comme il ne la comprendra pas, sa signature sera passive et
il nhsitera pas par la suite remettre le modle en question alors que
les travaux sont dj engags. La MOAD doit donc lui prsenter lappui
du diagramme dactivit une synthse en franais, claire et en quelques
pages, qui indique ce quil sagit de faire, comment on envisage de le faire et
pourquoi il ne convient pas de le faire autrement. Il sera galement utile de
lui prsenter le processus sous la forme dun dessin anim, mme si certains stratges prennent cela comme une atteinte leur srieux. Entre
le stratge et la MOAD, le rapport est celui qui existe entre le dcideur et
lexpert. La dcision revient au stratge qui, ayant la vue densemble, peut
tenir compte de contraintes et dopportunits que lexpert ignore; mais
le stratge doit couter lexpert qui, mieux que lui, se tient au courant de
ltat de lart des SI.
Il ne suffit pas de russir des projets: il faut encore que linformatique
soit bien utilise. La MOAD a donc avec les utilisateurs une relation
continue : elle les forme, observe leur relation avec le poste de travail,
promeut les bonnes pratiques et combat les mauvaises. Pour la MOE,

VII

Livre Constant.indb 7

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

la MOAD doit tre un client comptentqui sait ce quil veut et qui connat
assez linformatique pour en comprendre les contraintes, mais qui se
garde dimposer des choix techniques. Enfin, et mme si le cahier des
charges prcise les obligations de chacun, la relation entre la MOAD et
la MOE doit tre plus partenariale que contractuelle. Il convient quelles
travaillent en tandem ds le dbut du projet, la responsabilit du travail
passant de lune lautre selon ltape considre.
Certains SI sont tonnamment bien russis. Lorsquon interroge les utilisateurs, ils disent on sait ce quon a faire, le travail est clair,
lentreprise est bien dirige, on est bien outills, etc. Et si lon senquiert de la cause de cette russite, on reoit toujours la mme rponse:
le DG (ou le directeur) sest impliqu personnellement, il a mis le poids
de son autorit dans la balance, il a rgl les problmes politiques. Un
SI nest pas en effet seulement une affaire dinformatique : sa conception inclut la dfinition du travail humain, lorganisation du processus
de production et de son contrle. Cest pourquoi il faut considrer que
la responsabilit globale du SI appartient la MOA, personne morale, et
nommment son directeur, personne physique qui engage la MOA par
sa signature. Nos entreprises auront fait un grand pas lorsquelles sauront quun directeur ou un DG qui dit cest la faute de linformatique
rvle une incomptence
Michel Volle,
prsident dhonneur du Club des Matres dOuvrage
des Systmes dInformation

VIII

Livre Constant.indb 8

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Remerciements
Je tiens remercier les confrres qui mont apport leurs remarques
et leurs ides, en particulier Dominique Lepre, Benjamin Lemoine,
Josselin Coupard et Jean-Franois Goglin. Merci tous mes clients,
matres duvre, matres douvrage et utilisateurs qui, en se prtant
des interviews ou en participant des groupes de travail, mont permis
damliorer ma dmarche. Merci Suzanne Robertson et Karl Wiegers,
qui mont encourag lors de lcriture de cet ouvrage. Merci Michel
Volle, qui en a crit la prface. Merci Nicolas, Mlina et Karin pour leurs
ides fraches et leur soutien moral.

Livre Constant.indb 9

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 10

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Table des matires


Guide de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Quiz: tes-vous prt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Rponses au quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Partie 1 Mthodologie
Chapitre 1 La mthode en action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Un exemple imaginaire, mais concret . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Le point sur les concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapitre 2 Les enjeux dune bonne dfinition des besoins . . . . . . . . . . . . . . . . . . . .
Lutilit dun cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Un investissement trs rentable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les gains cachs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les difficults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amliorer les pratiques dlaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21
21
21
23
23
24
26

Chapitre 3 Comptences et savoir-faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27


Le savoir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Le savoir-faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Le savoir-tre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapitre 4 Exigences et cycle de vie du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Le cycle de vie du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Matres douvrage et matres duvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Btisseurs et exploitants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
La phase dexigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Les engagements rciproques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

XI

Livre Constant.indb 11

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

Chapitre 5 La dmarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Dcrire, documenter, communiquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Les diffrents niveaux dexigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Les tapes de llaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Description formelle du processus global . . . . . . . . . . . . . . . . . . . . . . . . . 44
Le processus en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Check-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapitre 6 Dfinir le concept et les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Une activit pralable indispensable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Objectifs, primtre et parties prenantes . . . . . . . . . . . . . . . . . . . . . . . . . 50
Recueillir les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Dterminer le primtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Analyser les parties prenantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Grille de questionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Tableau des parties prenantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Le document de cadrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Check-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapitre 7 Planifier le projet dlaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Le plan projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Cadrer la mthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
laborer le plan projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Check-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Partie 2 Dveloppement des exigences


Chapitre 8 Ltape de recueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Lenjeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Le processus de recueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Le plan de recueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Risques lis au recueil et attnuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Dtermination des profils utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Recherche des sources dexigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Techniques de recueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Lanalyse de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
La runion dun groupe de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

XII

Livre Constant.indb 12

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Table des matires

Linterview structure individuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76


Le brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Le diagramme des affinits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Lobservation directe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Les questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
La rutilisation dexigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Lanalyse de produits existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Rechercher linformation l o elle se trouve . . . . . . . . . . . . . . . . . . . . . . 86
Les bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Check-list de fin dtape de recueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Chapitre 9 Les cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Quest-ce quun cas dutilisation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Le contenu dun cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Avantages des cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
laboration des cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Un exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Difficults et risques des cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . 99
Les diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Chapitre 10 Ltape danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Utilit de ltape danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Le processus danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Structurer et organiser les exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
tablir un dictionnaire de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Analyser les rgles mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Dfinir les priorits dun projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Modliser sous forme graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Maquettes et prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Matrices CRUD et RACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
valuer la faisabilit et le cot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Check-list danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Chapitre 11 Les exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Les caractristiques de qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
La norme ISO/CEI25000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Zoom sur lutilisabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

XIII

Livre Constant.indb 13

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

Chapitre 12 Exigences projet et contraintes techniques . . . . . . . . . . . . . . . . . . . . . 137


Contraintes de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Contraintes denvironnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Services daccompagnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Chapitre 13 Ltape de spcification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Le processus de spcification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
La formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
La structuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Cas des exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Check-list de spcification dune exigence . . . . . . . . . . . . . . . . . . . . . . . 152
Check-list dtape de spcification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Chapitre 14 Structure du cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Le modle de cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Le modle IEEE830 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Le modle AFNORX50-151 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Le modle de Wiegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Le modle Volere (Robertson & Robertson) . . . . . . . . . . . . . . . . . . . . . 162
Construire son propre modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Check-list: cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Chapitre 15 Ltape de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Intrt de la validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Le processus de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Les techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Vrification par check-lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Relecture simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Relecture croise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Revue formelle et inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
laboration de cas de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Contrle qualit des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Impliquer les personnes concernes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Check-list: validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Chapitre 16 Un modle de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Un processus-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
tape 1: cadrer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

XIV

Livre Constant.indb 14

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Table des matires

tape 2: planifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tape 3: analyser lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tape 4: recueillir et analyser les besoins . . . . . . . . . . . . . . . . . . . . . . .
tape 5: spcifier les exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tape 6: valider les exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tape 7: capitaliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179
180
182
184
184
185

Chapitre 17 Amliorer le processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187


Pourquoi le processus peut tre amlior? . . . . . . . . . . . . . . . . . . . . . . 187
Comment le processus peut tre amlior . . . . . . . . . . . . . . . . . . . . . . 189
La mthode du document navette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Partie 3 Faire vivre les exigences


Chapitre 18 La gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
La gestion des changements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Une discipline ncessaire et rentable . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Chapitre 19 Les outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Check-list: votre projet en a-t-il besoin? . . . . . . . . . . . . . . . . . . . . . . . . 205
Les bonnes raisons dutiliser les outils . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Fonctions de base et fonctions avances . . . . . . . . . . . . . . . . . . . . . . . . 206
Attention aux mirages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Quand et comment choisir un outil? . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Chapitre 20 Au-del des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
tude de choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
tude comparative complexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
tude dopportunit complexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
tude dintgrabilit et design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Chapitre 21 Neuf conseils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
1. Ayez toujours lobjectif en tte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
2. Analysez et validez au plus tt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
3. Lancez-vous un dfi et donnez-vous les moyens de le russir . . . . . . . 222
4. Conciliez concepts et action de terrain . . . . . . . . . . . . . . . . . . . . . . . . 223
5. Concentrez-vous sur votre livrable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
6. Sachez russir presque coup sr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
7. Mettez en avant votre client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

XV

Livre Constant.indb 15

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

8. Perdez un peu de temps pour en gagner beaucoup . . . . . . . . . . . . . . 225


9. Faites de la dfinition des besoins un projet en soi . . . . . . . . . . . . . 225
Annexe Les questions large spectre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Comment utiliser ces questions? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Liste de questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Glossaire franais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Glossaire bilingue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

XVI

Livre Constant.indb 16

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Guide de lecture
Cet ouvrage prsente une dmarche structure dingnierie des exigences
pour les systmes dinformation, en suivant une logique qui va des
concepts gnraux jusquaux conseils pratiques. Il a lambition de guider
le lecteur depuis les objectifs stratgiques jusqu la validation finale du
cahier des charges, et au-del. Il gagne donc tre lu dun bout lautre,
dans lordre des chapitres.
Paralllement, cet ouvrage a pour vocation de servir de guide de terrain
que tout consultant ou analyste, quelle que soit son exprience, peut
utiliser dans sa pratique quotidienne. Il doit donc tre consultable de
manire non linaire. La carte heuristique de la figure1 page 3 tente de
concilier ces deux approches, en permettant au lecteur de naviguer plus
facilement entre les tapes et les techniques.
La premire partie de ce livre dcrit le mtier, la dmarche et les tapes
prparatoires la dfinition des besoins, ncessaires pour mener bien
une mission dlaboration dun cahier des charges.
Le premier chapitre donne un exemple concret (bien que fictif) qui permet
de mettre en situation tout lecteur, quil soit dbutant ou expriment. Il
introduit les notions de base et le vocabulaire, qui nest pas encore bien
stabilis dans notre mtier.
Le chapitre2 est le seul soccuper du pourquoi. Il prsente les enjeux,
les cots, les gains et les risques.
Le chapitre3 numre et dtaille les comptences ncessaires llaboration dun bon cahier des charges. Il faut la voir comme une check-list
qui sert samliorer, voire recruter un consultant.
Le chapitre4 situe lingnierie des exigences dans le cycle de vie du logiciel ; il permet de mieux comprendre les enjeux et met en lumire les
rapports de force entre les diffrents acteurs.
On prsente au chapitre5 la dmarche de dveloppement des exigences,
qui part de lobjectif et va jusquau cahier des charges. Cette dmarche
est gnrique: elle concerne la quasi-totalit des activits dlaboration

Livre Constant.indb 1

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

dun cahier des charges. Lenjeu est de ladapter son organisation pour
ensuite pouvoir loptimiser.
Le chapitre6 dtaille ltape pralable de dfinition des objectifs et du
concept, cruciale et souvent nglige, dont dpend grandement la russite dun projet.
Dfinir les besoins pour un logiciel est un projet part entire. Le
chapitre7 parle de gestion de projet, spcifiquement pour la phase dexigences.
La deuxime partie de cet ouvrage dcrit les quatre activits de dveloppement des exigences: recueil (chapitre8), analyse (chapitre10), spcification
(chapitre13) et validation (chapitre15). Des chapitres intermdiaires permettent de faire un zoom sur des techniques trs utiles, comme les cas
dutilisation (chapitre9). Le chapitre11 est entirement consacr aux exigences non fonctionnelles, beaucoup trop souvent ngliges.
Le chapitre14 donne la description de plusieurs modles de spcification
dexigences (cahier des charges) quune organisation pourra reprendre en
y apportant les adaptations ncessaires.
Le lecteur aura alors pris connaissance de la dmarche gnrale et des
diffrentes techniques qui permettent daller du recueil des besoins
jusquau cahier des charges. Pour tre efficace, il devra articuler ces
techniques entre elles, cest--dire sappuyer sur un processus formalis.
Le chapitre16 donne un exemple de processus, que tout consultant ou
assistant la matrise douvrage devra adapter son contexte de travail.
Ce processus peut toujours tre amlior. Le chapitre17 offre quelques
pistes.
Une fois spcifis, les besoins ne sont pas gravs dans le marbre. En
ralit, ils ne vont cesser dvoluer. La gestion des exigences, activit
transversale qui consiste grer les demandes de modification, pendant
et aprs llaboration du cahier des charges, fait lobjet du chapitre18.
Les outils de gestion des exigences progressent et changent rapidement.
Cest pourquoi nous nallons pas lister les outils prsents sur le march,
mais exposer lutilit quils peuvent avoir au cours dun projet et les critres pour les choisir (chapitre19).
Lactivit de lanalyste ou de lassistant la matrise douvrage ne sarrte
pas llaboration du cahier des charges. Ltude de lopportunit, de
la faisabilit ou de lintgrabilit dune solution dans le systme dinformation fait partie de son mtier. Les diffrentes techniques de choix, de
slection dun progiciel et de ltude de son intgration dans le systme
dinformation sont traites au chapitre20.
Enfin, nous donnons au chapitre21 neuf conseils pratiques qui proviennent de lexprience de lauteur.

Livre Constant.indb 2

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Guide de lecture

es
s

le
yc
C

om

Gestion des
Changements

C
r
t
ie

Prparer

&
s
pt
e
c
on
C Structure CdC

ck
- li

Analyser
Prototypage

es
ia
gr
am
m

Contraintes

Sp
c
ifi
er
er
tu
r

s
r it

Formuler

io
Pr

Matriser
Ces chapitres dcrivent la dmarche
de dveloppement des exigences

10

Cas dutilisation

lit
ua
Q

St
ru
c

C
he

tio
ca

13

14

ifi
an

ir
ill
ue
ec

Vrifier

ifs 6
ct

Pl

st
s

et au del 20
je
ob

Le

Ingnierie des
besoins pour le
logiciel

Valider

15

er
r
G

ns
tio
ec
sp
In
Revues

us

de

e
vi

Professionnaliser
Ces chapitres dcrivent
les aspects humains
et organisationnels

p
te
nc
es

Pr
oc

Enjeux

16

Dmarche

18

19
Les outils

Industrialiser
ces chapitres permettent
de comprendre
et damliorer la dmarche

Amlioration

17

11

12

21 Ch. 21 : neuf conseils

Figure1 : La carte de lecture de ce livre

Livre Constant.indb 3

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 4

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Quiz:
tes-vous prt?
Ce test vous permettra de vous situer dans le mtier du business analysis,
quel que soit votre titre (consultant, analyste, AMOA, expert mtier).
Pour chaque question, donnez la rponse qui vous parat la plus juste.
Nous vous suggrons de rpondre aux questions une premire fois avant
de lire ce livre, et de noter vos rponses. Puis une deuxime fois aprs
lavoir lu, de noter les rponses et de comparer les rsultats.
1. Dans la constitution dun cahier des charges, les difficults proviennent surtout:
A. De la complexit technique.
B. Des aspects humains.
C. De la gestion des changements des exigences.
2. Pour laborer un cahier des charges, les qualits requises sont:
A. Une bonne connaissance du domaine dapplication.
B. Des bases solides en informatique.
C. La connaissance des techniques dingnierie des exigences.
3. Lorsque vous devez laborer un cahier des charges, le mieux est:
A. Dutiliser tel quel un modle de cahier des charges prdfini.
B. Dadapter le modle de cahier des charges votre cas.
C. De crer un modle spcifique de cahier des charges.
4. Lessence dun cahier des charges est:
A. Un texte clair en franais.
B. Des schmas rigoureux et lisibles.
C. Une structuration systmatique et mthodique du document.

Livre Constant.indb 5

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

5. On vous demande dlaborer un cahier des charges. Votre premire


tche consiste :
A. Faire prciser les objectifs.
B. Analyser le contexte.
C. Connatre les parties prenantes.
6. Dans le travail dlaboration dun cahier des charges, les deux qualits
indispensables sont:
A. Lempathie et lcoute.
B. La rigueur et lorganisation.
C. La crativit et limagination.
7. Dans le recueil des besoins, tout est dans:
A. La prparation.
B. Lcoute active.
C. Le feedback donn aux intresss.
8. Dans lanalyse des exigences, il faut constamment surveiller:
A. La cohrence entre exigences.
B. La traabilit des exigences.
C. La priorit entre exigences.
9. Sil ne fallait utiliser quun seul type de diagramme, ce serait:
A. Le diagramme de classes (ou entit-association).
B. Le diagramme dtats.
C. Le diagramme de flux.
10. Les exigences qui demandent le plus dattention sont:
A. Les exigences fonctionnelles.
B. Les exigences non fonctionnelles.
C. Les contraintes.

Livre Constant.indb 6

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Rponses au quiz
Voici les rponses au quiz prcdent.
1. Dans la constitution dun cahier des charges, les difficults proviennent surtout
Si vos connaissances techniques sont faibles, il se peut queA soit la
bonne rponse. Mais dans la majorit des cas, les problmes humains
(rponseB) sont les plus dlicats traiter, du moins dans un premier
temps. long terme, lorsquil sagit de maintenir le cahier des charges
ou de faire voluer les exigences, le suivi des modifications des exigences pose de relles difficults.
2. Pour laborer un cahier des charges, les qualits requises sont
Une bonne connaissance du domaine dapplication (rponse A) est
indispensable, et des bases solides en informatique (rponseB) sont
fort utiles. La connaissance des techniques dingnierie des exigences
est aussi importante que les deux autres qualits, mais est trs souvent
nglige.
3. Lorsque vous devez laborer un cahier des charges, le mieux est
Si un modle de cahier des charges prdfini est bien adapt au
contexte et aux objectifs, il ny a pas de raison de sen priver. Sinon, il
faudra adapter le modle de cahier des charges votre cas (rponseB),
en essayant de garder un maximum de cohrence. Il est rare de devoir
crer un modle spcifique de cahier des charges. Mme dans ce dernier cas, on combinera des modles existants.
Cela va sans dire, il vaut mieux investir du temps adapter un modle
existant qu rinventer la poudre.
4. Lessence dun cahier des charges est
Tout dpend du domaine dapplication, de la rponse recherche (choix
de progiciel ou dveloppement spcifique). Mais on oublie trop souvent
que la langue naturelle est une merveilleuse invention et un outil de
spcification universel.

Livre Constant.indb 7

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

5. On vous demande dlaborer un cahier des charges. Votre premire


tche consiste
Sans objectif, vous nirez pas loin. La rponse A est donc a priori la
correcte. Mais qui va vous donner lobjectif ? Celui qui finance, celui
qui dcide ou celui qui rceptionne le produit? Et comment allez-vous
interprter cet objectif en termes oprationnels ? Do la ncessit
danalyser des parties prenantes et le contexte. Les trois tches sont
donc imbriques.
6. Dans le travail dlaboration dun cahier des charges, les deux qualits
indispensables sont
les vtres! L aussi, il ny a pas de meilleure rponse. Si chez vous
certaines qualits sont nettement prdominantes, utilisez-les, bien sr,
et essayez aussi de cultiver les autres.
7. Dans le recueil des besoins, tout est dans
Les trois rponses sont les bonnes, bien sr. La prparation mthodique et systmatique tient une place importante dans cet ouvrage.
Elle vous fera gagner normment de temps et vous vitera de disperser votre nergie et celle des participants. Lcoute est un don du ciel,
le meilleur outil de lanalyste, quil faut toujours cultiver. Le feedback
donn aux intresss est une bonne pratique qui contribue lefficacit
et la fiabilit de lactivit de recueil que vous pouvez tout de suite
mettre en application, tous les niveaux.
8. Dans lanalyse des exigences, il faut constamment surveiller...
vous de deviner la rponse (vous vous en doutiez maintenant) !
Pour savoir ce quil faut surveiller, il suffit dimaginer ce qui se passerait
si vous ne le surveilliez pas!
9. Sil ne fallait utiliser quun seul type de diagramme, ce serait...
Un diagramme nest pas une fin en soi, cest un mode dexpression.
Il sagit dtre le plus clair et prcis possible pour ceux qui vont vous
lire. Ce que vous devez exprimer dpend de vos objectifs, du contexte,
des parties prenantes, du domaine dapplication et du niveau de dtail
exig.
10. Les exigences les plus importantes spcifier sont...
Toutes, bien sr ! La seule chose que lon peut dire est que les exigences non fonctionnelles sont difficiles crire et beaucoup trop souvent ngliges. Pour les contraintes, cela est trs dpendant du type de
prestations que lon attend du fournisseur.

Livre Constant.indb 8

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

PARTIE

Mthodologie
Lingnierie des exigences consiste, dans une large mesure, crer des
modles abstraits partir dun relev de faits gnralement beaucoup
plus concrets, puis les prsenter de manire claire, structure et intelligible par tous les acteurs, donc dans un langage souvent diffrent que
celui de dpart. La capacit effectuer des voyages aller-retour dans
labstraction, laborer des modles, tout en restant proche du mtier
de ses interlocuteurs, constitue la principale difficult, mais aussi tout
lattrait du mtier danalyste des exigences. Pour exercer ce mtier et
mener bien les missions qui lui sont confies, celui-ci va faire appel
ses comptences et son savoir-faire acquis par lexprience, ainsi qu
une dmarche rigoureuse.
Dans cette partie, nous allons introduire, puis dfinir prcisment, les
notions de besoin et dexigence, les enjeux dune bonne dfinition des
besoins, les comptences ncessaires ce travail de dfinition, et sa position dans le cycle de vie du logiciel.
Lefficacit de ces activits dpend dans une large mesure du soin apport
leur prparation. Celle-ci comprend les activits de planification, inhrentes tout projet, et que nous allons dtailler pour le cas particulier du
dveloppement des exigences.
La prparation comprend galement la dtermination prcise des objectifs, du champ de ltude et des parties prenantes. Ces trois activits,
auxquelles nous consacrons un chapitre, sont cruciales.

Livre Constant.indb 9

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 10

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 1

La mthode
en action
Dans ce chapitre, nous allons tenter dintroduire la fois le vocabulaire,
la problmatique et les concepts. La situation prise comme exemple est
fictive, mais prsente toutes les difficults auxquelles est confront un
analyste ou assistant matrise douvrage au cours de sa mission. Ces
difficults rendent ncessaire une approche organise et systmatique,
appele ingnierie des exigences.

Un exemple imaginaire, mais concret


Supposons que la direction du marketing dun constructeur automobile
envisage de mettre sur le march un nouveau vhicule rvolutionnaire,
quip dun pilote automatique. Plus rien faire pour le conducteur, ou
alors si peu Supposons que nous sommes la tte dune quipe charge de spcifier1 ce que le systme de pilotage automatique doit faire,
doit tre ou doit avoir pour tre oprationnel. Supposons que nousmmes ne connaissons rien, ou presque rien, la mcanique automobile,
ni mme aux systmes embarqus dans les vhicules, domaines rservs
des techniciens et ingnieurs. Notre challenge est de dfinir les besoins
et de les spcifier sous forme dexigences.

1. Le challenge:
dcrire le besoin sans
dcrire la solution.

Lanalyste
Le mtier de la dfinition des besoins est dsign en anglais par requirements
analyst ou business analyst. En franais, on parle danalyste, danalyste mtier, de
consultant mtier, parfois danalyste des exigences, et trs souvent de consultant
assistant la matrise douvrage. Dans la suite de cet ouvrage, nous utiliserons
indiffremment ces termes.

Pour nous, la direction du marketing est le matre douvrage oprationnel. Les techniciens et ingnieurs sont le matre duvre. La direction

Livre Constant.indb 11

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

g nrale, ncessairement implique dans un projet dune telle envergure, est le matre douvrage stratgique. Le document que nous allons
produire, et qui sadressera lensemble de ces acteurs, appels parties
prenantes, sappelle cahier des charges.

Lanalyse de lexistant
La premire tche laquelle nous allons nous atteler consiste examiner tout ce qui existe en matire dautomatismes embarqus dans les
vhicules. En effet, bien quaucune voiture actuellement sur le march
ne dispose proprement parler dun pilote automatique, de nombreux
mcanismes, quils soient mcaniques, lectromcaniques, ou informatiss, existent dj. Cette premire tche, donc, appele analyse de
lexistant, est indispensable et va nous occuper pour un bon moment.
Elle est indissociable de lactivit de recueil des besoins, car lexistant
dune automobile pourra servir spcifier les besoins dune automobile
venir.
Concrtement, lanalyse de lexistant va consister :
tudier la documentation des automobiles existantes;
examiner les spcifications des automobiles dj conues, mais qui
nont jamais vu le jour;
visiter les ateliers, les usines, les chanes de montage;
examiner les automobiles de la concurrence;
examiner ce qui se fait, en matire de pilotage automatique, dans
dautres domaines que lautomobile.

Le cahier des charges


Aprs avoir tudi lexistant, nous allons passer la partie la plus longue
et la plus difficile de notre travail, llaboration du cahier des charges.
Comme indiqu, le cahier des charges est un document que tous les
acteurs en prsence doivent tre capables de comprendre facilement, et
qui servira de contrat entre plusieurs parties prenantes. Pour ce faire, il
devra donc tre crit dans un langage clair et concis. Pour lessentiel, il
sera constitu dun ensemble de phrases telles que, par exemple:
En mode automatique, le vhicule doit se conformer au Code de
la route.
Il sagit l de ce que lon appelle une exigence de haut niveau. nonce
ainsi, elle parat vidente, mais doit nanmoins tre spcifie de manire
prcise, non ambige, dans un langage que tous les acteurs comprennent.

12

Livre Constant.indb 12

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 1 La mthode en action

Les rgles de gestion


Plus loin dans le cahier des charges, cette exigence de haut niveau sera
exprime en exigences de plus bas niveau, comme:
En mode automatique, le systme fera en sorte que le
vhicule respecte les limitations de vitesse imposes par la
signalisation.
En mode automatique, le systme fera en sorte que le vhicule
nacclre pas lorsquun vhicule plac derrire lui tente de
le dpasser.
Dans ces phrases, qui constituent un chantillon parmi des centaines
dautres, le marketing (matre douvrage) demande au bureau dtudes (le
matre duvre) que le systme fasse en sorte qu tout moment, lorsque
le vhicule est sous contrle du pilote automatique, le Code de la route
soit respect.
Ces phrases sont des exigences dun type particulier. Dans cet ouvrage, et
dans le vocabulaire consacr de lingnierie des exigences, on les appelle
rgles de gestion (en anglais, business rules).
O stocker les rgles de gestion?
Si les rgles de gestion ne sont ni plus ni moins que des articles de loi, ou des
extraits de textes rglementaires, ou des lments de procdure, faut-il ncessairement les reprendre dans le cahier des charges, ou bien peut-on se contenter dy
faire rfrence?
La question est loin dtre triviale, elle na pas de rponse dfinitive, elle dpend
de plusieurs facteurs: qui lira le cahier des charges? La rglementation est-elle
suffisamment claire pour tre comprise des ingnieurs? Ny a-t-il pas des rglements
qui se contredisent entre eux?

Les contraintes
Il ne suffit pas de recopier le Code de la route, ou de le paraphraser, ou
dy faire rfrence, pour laborer le cahier des charges dun pilote automatique pour automobile. Dans le cahier des charges, on trouvera des
exigences telles que:
Lorsque le rgime du moteur dpasse un seuil maximum not Rs,
le systme devra faire en sorte que le vhicule change de
rgime en passant la vitesse suprieure.
Lorsque le rgime du moteur passe sous un seuil minimum not
Rm, le systme devra faire en sorte que le vhicule change de
rgime et rtrograde.
Notons en passant que ces exigences permettent de percevoir une frontire entre deux mondes: le systme, que nous sommes en train dtudier

13

Livre Constant.indb 13

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

(parfois appel SAE, systme ltude) et le contexte, qui est lensemble


des systmes extrieurs au systme ltude, et avec lesquelles il ragit.
Le contexte peut tre constitu de logiciels, de matriels, et dhumains
(comme le conducteur du vhicule). La dtermination du contexte est
une activit indispensable que nous allons dtailler dans un prochain
chapitre.

Les exigences fonctionnelles


Exigences rglementaires et contraintes techniques sont des exigences
extrieures lorganisation qui exprime les besoins. La majorit des
besoins internes lorganisation vont se traduire par des exigences fonctionnelles. Par exemple:
En labsence dexigences rglementaires et de contraintes
mcaniques, la vitesse du vhicule sera celle dtermine par
lutilisateur.
Si la vitesse na pas t dtermine par lutilisateur,
et en labsence dexigences plus prioritaires, le vhicule
acclrera jusqu atteindre la vitesse maximale autorise par
la signalisation ou la rglementation.

Les exigences mtier


Ni le Code de la route, ni une quelconque contrainte mcanique nobligent un vhicule circuler la vitesse maximale autorise. Lexigence que
nous venons de citer est une exigence mtier (en anglais, business requirement). Dans notre exemple, la direction mtier est le marketing. Cette
dernire exigence, dterminant la vitesse maximale, peut se rapporter
une exigence de plus haut niveau telle que:
En labsence de contraintes mcaniques ou rglementaires, le
vhicule circulera la vitesse maximale possible.
Cette exigence peut elle-mme se rapporter une exigence de niveau
suprieur, cest--dire un objectif:
Les performances du vhicule devront dpasser celles des
vhicules de la concurrence de la mme catgorie.
On remarquera en passant que les exigences peuvent former une cascade,
entre les exigences de plus haut niveau, les objectifs, et les exigences du
niveau le plus oprationnel. Une des difficults de lingnierie des exigences consiste maintenir la traabilit entre les exigences de diffrents
niveaux.

14

Livre Constant.indb 14

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 1 La mthode en action

La ngociation des exigences


Tous les mtiers, linstar du marketing, pourront exprimer des besoins. Il est vident
que des exigences provenant de sources diffrentes pourront tre antinomiques. Par
exemple, la direction du dveloppement durable voudra minimiser la consommation en nergie, alors quune autre voudra maximiser la scurit des passagers. Une
des activits de lanalyse des exigences consiste ngocier les exigences face des
besoins antagonistes. On commence voir une premire distinction entre besoin et
exigence: les besoins sont ceux des personnes ou des organisations, et peuvent tre
contradictoires. Les exigences, formules dans un cahier des charges, ne le sont pas.

Les autres exigences


Les systmes informatiques manipulent des donnes. Les exigences sur
les donnes, comme les formats de donnes, les seuils de dclenchement, les relations entre donnes, constituent une catgorie part.
Les exigences fonctionnelles dcrivent ce que le systme doit faire, en
dautres termes son comportement. Une autre catgorie dexigences,
aises comprendre, mais difficiles dcrire, concerne la qualit du systme. On les appelle exigences non fonctionnelles.
Classer les exigences par catgories
Il y a plusieurs manires de structurer les exigences. Dans ce chapitre, nous avons
illustr la structuration donne par Karl Wiegers. Elle classe les exigences client
dans lune des neuf catgories suivantes:
Exigences mtier (business requirements): elles concernent les avantages, bnfices, intrts stratgiques ou tactiques (augmentation du chiffre daffaires, conomies, gains).
Scnarios et cas dutilisation : ils correspondent des besoins oprationnels
des utilisateurs (avoir la possibilit de saisir, dimprimer, de grer une information).
Rgles de gestion (rgles mtier): le logiciel doit tre conforme une loi, un
rglement, une directive ou une procdure.
Exigences fonctionnelles, relatives au comportement du systme.
Attributs de qualit, galement appels exigences non fonctionnelles: ce sont
des caractristiques exiges du systme (fiabilit, maintenabilit, portabilit, ergonomie) trop souvent ngliges et passes sous silence.
Exigence dinterfaces externes: interface utilisateur, interface avec le matriel
ou un autre logiciel.
Contraintes: elles apportent des restrictions au systme; il sagit souvent de
contraintes lies au matriel (volumes traits, plate-forme). Si trop de contraintes
apparaissent lors du recueil des besoins, cela peut tre un frein la recherche de la
solution adquate; il est utile de connatre les motivations de celui qui les formule.
Dfinitions de donnes, relatives au format des donnes (par exemple, la forme
dun numro de Scurit sociale ou dun numro de srie).

15

Livre Constant.indb 15

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Suggestions de solutions, formules comme des exigences; souvent, un utilisateur a une ide prconue de la solution mettre en uvre. Lors du recueil et de
lanalyse des exigences, il est important de les faire expliciter, puis de rechercher les
motivations de celui qui les suggre.
Dautres exigences peuvent tre formules et concerner le projet, les cots, les
dlais, mais elles sont distinctes des exigences produit.
Nous reviendrons sur ces diffrentes catgories dans la partie de louvrage consacre au dveloppement des exigences.

Le mtier: grer une combinaison dexigences


Une combinaison dexigences (rgles mtier, exigences mtier, contraintes
techniques) peut donner naissance de nouvelles exigences, bien relles,
mais jamais formules comme telles. Cest l une des grandes difficults
de lanalyse des exigences.
Reprenons notre exemple fictif du cahier des charges dun pilote
automatique pour automobile. Le Code de la route, ou du moins son sousensemble concernant la conduite automobile, constitue un ensemble de
rgles mtier. En voici une (pas toujours respecte des automobilistes!):
Article R412-31 du Code de la route
Tout conducteur doit marquer larrt devant un feu de
signalisation jaune fixe, sauf dans le cas o, lors de
lallumage dudit feu, le conducteur ne peut plus arrter
son vhicule dans des conditions de scurit suffisantes.
Le feu de signalisation jaune fixe est ce que lon appelle communment
un feu orange. Pourquoi cette rgle de gestion ne peut-elle pas tre reprise
telle quelle dans le cahier des charges? Il y a cela plusieurs raisons:
Le vocabulaire du Code de la route nest pas le mme que celui du cahier
des charges. Bien sr, on pourrait saligner sur ce vocabulaire juridique,
puisque cest la loi. Mais pourquoi pas sur celui de lindustrie automobile, qui est plus prcis sur le plan de la mcanique?
La rgle nest centre ni sur le systme ltude (le pilote automatique),
ni sur le vhicule, ni sur lutilisateur du systme. Elle est centre sur
le couple conducteur-vhicule, reprsent par le conducteur , seul
responsable, devant la loi, du comportement de son vhicule (en cas
de dfaillance du vhicule, il pourra par la suite se retourner contre
le constructeur automobile, comme cela peut tre le cas lors de toute
dfaillance dun systme automatis).
Surtout, larticle fait rfrence une autre rgle ou contrainte, qui est dcrite
ailleurs ou est cense tre comprhensible par tous. Cette contrainte

16

Livre Constant.indb 16

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 1 La mthode en action

concerne les conditions de scurit suffisantes. Elle est sans doute facile
interprter (quoique) par les automobilistes, qui doivent respecter la
loi, et par les autorits, qui doivent la faire respecter. Mais elle est beaucoup trop floue pour dcrire le comportement attendu dun systme.
En ralit, larticle cit fait appel dautres articles, ainsi qu la jurisprudence, qui permet galement de dterminer ce que sont des conditions
de scurit suffisante, dans quelles circonstances le vhicule pouvait ou
non tre arrt sans danger, etc.
Tentons de traduire cette rgle mtier en exigence systme. Cela donne:
Si
le feu de signalisation dont dpend le vhicule passe
lorange,
et si
le systme dispose du temps ncessaire pour arrter le vhicule
laplomb du signal
et si
en sarrtant, le vhicule ne met pas en danger le conducteur,
les passagers et lenvironnement du vhicule
et si
les conditions de scurit telles que dfinies par [un ensemble de
rgles de gestion pralablement dfinies] sont respectes
alors
le systme fait en sorte que le vhicule ralentisse
progressivement jusqu sarrter laplomb du signal.
Il sagit l dune traduction encore trs approximative de la rgle, quil
faudra certainement retravailler. Le but de lexercice est de montrer
quel point une rgle de gestion qui nous parat simple, par ce que nous
vivons tous les jours avec, se traduit en une exigence systme qui peut
tre extrmement complexe.
En particulier, une analyse rapide de la rgle de gestion, en interaction
avec les contraintes mcaniques, fait merger de nouvelles conditions qui
taient caches ou sous-entendues jusque-l. Dans notre exemple, cest
le facteur temps qui merge.
Dautres contraintes peuvent merger, comme la notion de risque. La
rgle de gestion peut trs bien scrire:
Si, en arrtant le vhicule laplomb du signal, le systme
cause moins de dgts quil nen aurait causs en ne sarrtant
pas, alors le systme doit arrter le vhicule laplomb du
signal.

17

Livre Constant.indb 17

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Cette dernire formulation de lexigence est sans doute moins politiquement correcte, mais beaucoup plus proche de la ralit que larticle
de loi. En effet, un conducteur automobile fait en permanence un calcul
de risques. Il ne se contente pas de sassurer que les conditions de scurit sont vrifies (elles ne le sont jamais 100%), il estime les risques
passer lorange et ne pas passer, puis compare les deux en temps rel
(souvent, il compare aussi le risque de rater son rendez-vous avec celui
de se faire pincer par un agent de la circulation, mais cela nous loigne
du strict respect de la loi).
Selon le niveau de cahier des charges laborer, larticle R412-31 du Code
de la route se traduira par quelques dizaines, centaines, voire milliers
dexigences logicielles, qui tiendront compte dexigences aussi diffrentes
que le Code de la route, la psychologie du comportement des pitons, ou
les contraintes mcaniques.

La notion de partie prenante


Cet exemple fait ressortir la notion de partie prenante, extrmement
importante et trop souvent nglige. Un ingnieur mcanicien, un juriste
et le reprsentant dune association dautomobilistes sont tous trois des
parties prenantes au projet. Considrons chacun de ces acteurs comme
une personne dexprience, de bonne foi, doue de bon sens. Cela ne les
empchera pas dexprimer des besoins contradictoires, car le bon sens
est une question de point de vue.
Lanalyste devra trouver et faire approuver un consensus entre des expressions de besoins conflictuels, en grant des priorits entre exigences. Sa
tche sera grandement facilite si, au lieu de devoir grer des contradictions, voire des conflits tout au long du recueil des besoins, il anticipe sur
ces ventuels conflits en analysant les intrts et les rapports de force des
diffrents acteurs. Cette tche sappelle analyse des parties prenantes.

Le point sur les concepts


Besoin, demande, exigence et spcification
On a vu, grce lexemple prcdent, les diffrences entre besoin,
demande et exigence.
Le besoin est interne une organisation ou une personne. Dans le cas
dune personne physique, il peut tre ressenti, intellectuellement ou physiquement. Il peut tre exprim plus ou moins clairement, sous-entendu,
pass sous silence, ignor ou ni par son auteur.
La demande est lexpression dun besoin. Elle peut tre suprieure au
besoin, en termes de cot, de qualit, de fonctions, ou lui tre infrieure.

18

Livre Constant.indb 18

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 1 La mthode en action

Par rapport la demande, une exigence tient compte des contraintes, et


introduit une notion de consensus, de cible atteindre. Elle est demande par le client et doit tre accepte par le fournisseur. Elle doit tre
mesurable, ou du moins vrifiable.
Enfin, la spcification est la traduction des exigences dans un langage
convenu entre le client et le fournisseur. Elle permet dviter les effets
pervers qui perturbent leurs relations, y compris dans le cas o les deux
parties, client et fournisseur, sont de bonne foi. La spcification des exigences est une dmarche industrielle.

Ingnierie des exigences


Lingnierie des besoins, ou ingnierie des exigences, est donc la discipline, vue comme un ensemble de techniques, consistant recueillir les
besoins, les transformer en exigences, et les spcifier dans un cahier
des charges.
Quand on parle dingnierie, on pense souvent des techniques complexes. Cependant, sur le plan conceptuel, les diffrentes techniques
dcrites dans cet ouvrage sont simples. Comme nous le verrons, les vraies
difficults proviennent essentiellement:
du choix entre plusieurs techniques;
de la ncessit dun suivi rigoureux des exigences;
des aspects humains.

Cahier des charges


Un cahier des charges peut donc tre dfini de trois faons:
Cest lexpression des besoins, aprs quils aient t recueillis, analyss,
ngocis, prioriss, spcifis, classs.
Cest un ensemble de demandes, aprs traitement et arbitrage.
Cest un ensemble structur dexigences, quun client prsente un fournisseur.

19

Livre Constant.indb 19

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 20

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 2

Les enjeux dune


bonne dfinition
des besoins
Le cahier des charges est un document constitu dun ensemble structur
dexigences, transmis dun client un fournisseur, et qui a un caractre
contractuel. Comme nous le verrons tout au long de cet ouvrage, son laboration est un travail collectif ncessitant la collaboration de nombreux
acteurs. Le processus de cette laboration est aussi important que le
document qui en rsulte.

Lutilit dun cahier des charges


Un bon cahier des charges est un document clair, facile lire et comprendre par les diffrents acteurs, qui a t tabli sur la base dun
consensus. tant donne la complexit de certaines situations que ce
document reprsente, il peut tre trs complexe, mais il nest jamais
compliqu : cest un document relativement facile maintenir et
modifier.
Ce document, labor de manire participative, dfinissant clairement les
exigences dun client vis--vis dun fournisseur, sera utile au choix, la
conception, la ralisation, au paramtrage dune application ou dun
systme informatique, ainsi qu sa mise en uvre oprationnelle, sa
maintenance et son exploitation.

Un investissement trs rentable


Lensemble des activits dlaboration qui part du recueil des besoins
et aboutit un cahier des charges est appel dveloppement des exigences.
Les enjeux lis au dveloppement des exigences sont trs importants.
Les personnes qui laborent un cahier des charges pour la premire

Livre Constant.indb 21

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

1. Ces chiffres manent de plusieurs


tudes, en particulier
celles de Boehm
et de Grady.

fois, ou demandent de lassistance pour son laboration, sont rarement


conscientes de limportance de cette phase, et en sous-estiment les
consquences. Plutt quun long discours, voici quelques faits1:
Environ les trois quarts des erreurs dans le choix, la mise en uvre et la
construction dun logiciel sont dues des exigences mal formules ou
un cahier des charges mal construit (nous verrons plus loin ce que cela
signifie).
Le cot de la correction dune erreur produite lors de la phase dexigences
est beaucoup plus important (jusqu cent fois) lorsque cette erreur est
dcouverte en phase dexploitation que pendant la phase dexigences
elle-mme (voir figure2-1).
Ce constat, statistiquement dmontr, est apparemment contre-intuitif,
puisque nombre de donneurs dordres ninvestissent pas suffisamment
de temps et dargent dans cette phase, pensant sans doute que cest du
temps et de largent perdus, et quon pourra toujours corriger le tir et
rattraper les petites erreurs par la suite. Or, corriger le tir cote largement
plus cher que de viser juste du premier coup.

Cot relatif de la correction

100

Exigences

Concept.

Ral.

Tests

Exploit.

Phases de dveloppement

Figure2-1 : Augmentation exponentielle des erreurs

Si le cahier des charges est utilis pour le choix dun logiciel sur tagre
(progiciel), le cot dun mauvais choix est nettement suprieur au cot
dun bon cahier des charges.
Enfin, la rcriture de spcifications ou de programmes (le rework) suite
des spcifications errones ou insuffisamment prcises peut coter
jusqu la moiti du cot total du dveloppement.
Spcifier les besoins de manire scrupuleuse est donc un investissement
extrmement rentable. Il peut rapporter plus de cent fois ce quil aura cot.

22

Livre Constant.indb 22

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 2 Les enjeux dune bonne dfinition des besoins

Retour sur investissement


Sans tre ambitieux, on peut tabler sur un retour sur investissement de 1000%:
la diffrence entre un cahier des charges bien construit et un cahier des charges
mdiocre va rapporter au moins dix fois ce quelle aura cot. Ce cot inclut leffort
dlaboration du cahier des charges lui-mme, le cot du retravail (rework) des
exigences en phase de ralisation, et bien sr la rentabilit du logiciel produit.

Les gains cachs


Les gains que nous venons de mentionner sont les plus visibles.
Mais obtenir de bonnes spcifications ds le dbut apporte de nombreux
bnfices secondaires, et pas seulement sur le plan financier. Russir du
premier coup est beaucoup plus motivant et encourageant pour les utilisateurs que de revenir sur des spcifications.
De plus, le processus mme dlaboration dun cahier dexigences permet
aux diffrentes parties prenantes, commencer par les utilisateurs, de
participer une dmarche collaborative de recueil, de spcification, de
validation des besoins, et de rflchir limpact de la mise en uvre dun
nouveau systme sur les processus actuels.
Dautres gains sont induits par le processus mme de llaboration. laborer un cahier des charges est un travail dquipe qui, bien men, va
souder cette dernire autour dun projet commun. Leffort ultrieur de
mise en uvre du produit, de formation, de conduite du changement en
sera grandement facilit.
Enfin, last but not least, un cahier des charges bien construit cote beaucoup
moins cher quun cahier des charges labor de manire empirique, avec
des allers-retours incessants entre les diffrentes parties prenantes. laborer un cahier des charges nest jamais chose aise, suivre une mthode
rigoureuse et des techniques prouves va grandement faciliter les choses.

Les difficults
Inutile de se voiler la face. Le travail dlaboration est long et difficile.
Mme avec une bonne mthode et des ttes bien faites, cest une preuve,
et on passe toujours par des moments de dcouragement. Il est important de connatre par avance certaines difficults pour mieux pouvoir sen
prmunir.
La premire difficult vient du donneur dordres. Ce peut tre la direction
gnrale dune entreprise, ou une administration centrale dans le secteur

23

Livre Constant.indb 23

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

public. Le donneur dordres doit simpliquer, dfinir les objectifs, donner


une lettre de mission claire lquipe qui va dfinir les besoins. Ce nest
pas toujours le cas. Si la direction ne simplique pas, il faudra tout faire
pour quelle sengage dans ce projet, car sa russite en dpend.
La deuxime difficult provient du rythme de travail, quil convient de
cadencer pour conserver la motivation des acteurs jusquau bout et viter
lessoufflement. En effet, lenthousiasme de dpart ne dure pas ternellement, surtout lorsque la dfinition des besoins devient un exercice
routinier, avec ses lectures croises et ses revues formelles. Linspiration
peut aussi manquer au dmarrage du projet, pendant les phases cratives de recueil des besoins, lorsque les futurs utilisateurs manquent
dides. Dans les deux cas, cest le talent de lanalyste des besoins qui
est requis.
Une autre difficult concerne les pressions extrieures aux groupes de
travail. Le donneur dordres peut tre press davoir des rsultats rapides,
et prfrer un travail vite fait, mal fait, un document conclusif. dautres
moments, le donneur dordres peut au contraire lcher la tension, pris par
dautres priorits. Or, la dfinition des besoins est un exercice qui doit
tre rythm.
Enfin, une difficult importante vient du fait que les gains engendrs
par une bonne dfinition des besoins ne seront visibles qu trs long
terme, cest--dire lorsque le logiciel sera en production. Pourquoi un
dirigeant investirait-il dans une activit qui nest visible que lorsquelle
est dfaillante?

Les risques
Quels que soient la rigueur mthodologique et le talent de lanalyste, les
risques existent et sont nombreux. En voici quelques-uns, parmi les plus
importants.

Les spcifications rampantes


Il est normal que les exigences voluent. Dans un tel cas, les spcifications
du produit changent en consquence, et le produit lui-mme voluera
par la suite. Les spcifications rampantes adviennent lorsque lvolution
des exigences nest pas contrle. Le produit ainsi couvert de rustines
risque de perdre en robustesse et en cohrence.
Souvent, les phases dexigences et de conception sont bien spares.
Cest en particulier le cas des appels doffres publics, o le cahier des
clauses techniques particulires (le CCTP) doit tre finalis et approuv
et o toute modification doit en principe faire lobjet dun avenant au

24

Livre Constant.indb 24

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 2 Les enjeux dune bonne dfinition des besoins

contrat initial. Mme dans ce cas, les spcifications peuvent voluer de


manire incontrle. Le cahier des charges devient alors un patchwork,
avec tous les risques dincohrences que cela peut entraner.
Pour viter cette drive, il faut dune part que les objectifs du logiciel aient
t clairement dfinis, et dautre part que les modifications du cahier des
charges fassent partie dun processus contrl.

Le perfectionnisme (surspcification)
Donner trop de dtails ne sert rien, et peut tre nuisible. Cest en particulier le cas lorsque les utilisateurs ou leurs reprsentants donnent des
dtails sur la manire dont une fonction sera mise en uvre, en particulier en spcifiant linterface utilisateur (comme cliquer avec le bouton
droit de la souris). De tels dtails nont rien faire dans un cahier des
charges. Sil faut absolument spcifier des contraintes techniques, ce sera
dans une annexe, et non dans la description fonctionnelle des exigences.
Une autre forme de surspcification consiste exiger des fonctions superflues. Cela augmentera inutilement le cot du logiciel et les dlais de
livraison. Gnralement, un utilisateur ne connat pas le cot de ses
exigences. Pour viter cette drive, il est indispensable davoir cadr le
projet, en temps, en cot et en qualit. Le travail de lassistant la matrise douvrage consiste alors rappeler son client les objectifs que ce
client a lui-mme fixs.

Les spcifications insuffisamment dtailles


Le risque est ici de dcrire les exigences de manire trs globale (sousspcification), en esprant que les concepteurs et ralisateurs vont avoir
suffisamment de bon sens pour faire un produit conforme ces besoins
sous-entendus. Cest une utopie. Si un besoin est insuffisamment explicit, un dveloppeur fera appel sa crativit, essaiera de deviner ce que
veut le client, avec de fortes chances de se tromper.

Ngliger certains profils utilisateurs


Un mme logiciel sadresse gnralement des types dutilisateurs diffrents2, avec des besoins parfois trs distincts. Bien que pouvant accder
aux mmes informations, un comptable et un conseiller de clientle ne
travaillent pas du tout de la mme faon. Pour construire un logiciel qui
soit au service de plusieurs catgories dutilisateurs, il est indispensable
de tenir compte de leurs besoins particuliers, et pour cela de les faire
participer lexpression des exigences.

2. Voir le Chapitre6,
Analyser des parties
prenantes.

25

Livre Constant.indb 25

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Amliorer les pratiques dlaboration


Des bonnes pratiques dexpression et de gestion des exigences amlioreront considrablement la qualit du cahier des charges, et partant de
lapplication finale. Cela est vrai dans tous les cas, quil sagisse de dvelopper une application sur mesure ou de choisir, paramtrer et installer
un progiciel.
Cet ouvrage na dautre ambition que dtre un manuel de bonnes pratiques qui permettront:
de donner aux personnes en charge de llaboration des spcifications
dexigences (cahier des charges) une approche et des outils qui faciliteront leur travail;
damliorer la communication entre client (matrise douvrage), fournisseur (matrise duvre) et analyste (assistant la matrise douvrage);
dviter le phnomne des spcifications rampantes;
damliorer lefficacit en choisissant la technique adquate de recueil,
danalyse, de spcification des exigences;
de minimiser leffort en vitant deffectuer certaines tches trop tt, ou
de descendre trop vite dans les dtails, ce qui obligera de revenir dessus
une deuxime fois;
de scuriser ce processus, grce des check-lists de fin dtape;
de conserver la motivation des participants tout au long de llaboration;
de prparer le terrain llaboration de cas de test.

26

Livre Constant.indb 26

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 3

Comptences
et savoir-faire
laborer un cahier des charges exige de solides connaissances techniques
et mthodologiques, ainsi que des qualits humaines. Pour cette raison, il
ny a pas un parcours type pour devenir analyste des exigences. On trouve
dans ce mtier des anciens utilisateurs de produit, des ex-dveloppeurs,
des experts du domaine dapplication. Lanalyste doit apprendre, puis
matriser, les techniques de lingnierie des besoins. Cest un animateur,
un ngociateur, un interprte qui va couter les besoins des futurs utilisateurs et les reformuler dans un langage clair (figure3-1).
modlise

conceptualise

observe
spcifie

reformule

MOA

MOE

cre
coute
anime

analyse

synthtise

Analyste
(AMOA)

ngocie

Figure3-1 : Les comptences de lanalyste

Le savoir
La connaissance du mtier du client
Sans tre un expert, lanalyste doit tre familiaris avec le mtier de son
client. En fonction des domaines dactivit, du niveau de dtails attendu

Livre Constant.indb 27

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

et du type dapplication, cette connaissance se doit dtre plus ou moins


approfondie.
Trs souvent, lexpertise est chez le client. Sans tre expert, lanalyste doit
tre capable de faire appel aux experts, de comprendre leur langage, de
se plonger dans leurs procdures, danalyser leurs processus; en dautres
termes, de connatre leur mtier sans pour autant le pratiquer.

La connaissance des techniques de modlisation


La reprsentation graphique des processus, des procdures, des donnes, des traitements sont souvent ncessaires, lorsque le langage crit
ne suffit pas ou manque de prcision. Dans un tel cas, un bon schma
vaut mieux quun long discours.
Cependant, il ne suffit pas de savoir dessiner un schma ou un diagramme
pour savoir modliser. Encore faut-il comprendre la smantique, et les
consquences profondes de certains choix. Ainsi, sans empiter sur le
travail des techniciens, laborer un modle graphique demande quelques
connaissances techniques. Par exemple, pour laborer un modle de
donnes, il est utile de connatre les principes des bases de donnes
relationnelles. Les schmas seront lus par les futurs utilisateurs qui ont
besoin de clart et de simplicit, mais aussi par les futurs dveloppeurs
qui ont besoin de cohrence et de prcision.

La connaissance des mtiers du dveloppement


Lanalyste des exigences ne dveloppe pas de logiciel au sens courant du terme (on a vu que lanalyse des exigences fait partie du cycle
de dveloppement). Avoir pratiqu le dveloppement est cependant un
avantage qui permet de savoir si un besoin exprim est raliste, et quel
prix il peut tre ralis. Cela permet aussi, chaque fois que ncessaire, de
dialoguer avec les dveloppeurs et de se faire comprendre.
Enfin, cela permet de comprendre certaines contraintes et des compromis faire: plus de scurit au dtriment de la facilit dutilisation, plus
de richesse fonctionnelle au dtriment de la fiabilit

La connaissance des technologies


Il nest pas indispensable dtre un bon technicien pour spcifier des exigences et laborer un cahier des charges. Cest souvent linverse qui est
vrai, car un bon technicien a tendance rechercher des solutions techniques plutt que de chercher comprendre le besoin de son client. De
bonnes connaissances techniques constituent nanmoins un srieux
atout. Cela vite de chercher limpossible l o des solutions toutes prtes
sont sur le march. Cela permet aussi de connatre les limites imposes
par certaines techniques.

28

Livre Constant.indb 28

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 3 Comptences et savoir-faire

Le savoir-faire
Lart de poser les bonnes questions
La question est lanalyste ce que le bistouri est au chirurgien: un outil
de travail quotidien, trs simple, mais difficile manier. Comme le bistouri, la question doit tre tranchante, bien affte, et faire le moins de
dgts possible.
Poser la bonne question au bon moment est une affaire de talent, dentranement, mais aussi, et surtout, de logique et de mthode. On peut avoir un
rpertoire de questions gnriques prtes--poser 1 pour viter dtre
pris au dpourvu. Mais un bon analyste parcourt mentalement un arbre
de dcision et sait lier les questions entre elles dans un ordre logique, en
cohrence avec le point quil examine et les objectifs atteindre.

1. Voir en annexe la
liste de questions
gnrales.

Une aptitude ngocier


La personne charge du recueil des besoins et de llaboration du cahier
des charges joue un rle dintermdiaire entre matrise douvrage et matrise duvre. Elle doit tre bilingue ; non seulement connatre le
vocabulaire, comprendre le mtier, mais galement pouvoir se mettre
dans la peau des diffrents acteurs pour comprendre leur point de vue, les
contraintes de chacun, la manire de sexprimer. Spcifier des exigences,
cest avant tout traduire le langage du mdecin, du juriste ou du banquier en un langage intermdiaire compris de tous les acteurs.

Les qualits danimateur


Le talent danimateur est indispensable, car le recueil des exigences est
souvent une activit dquipe. Savoir animer un groupe de travail est une
qualit essentielle. Diffrents moyens vont permettre aux participants de
sexprimer: brainstorming, maquettage sur papier, narration de situations
vcues, discussions, jeux de rle. Certaines techniques sont trs efficaces.
Il faut aussi savoir crer la motivation, puis la maintenir, souvent pendant
de longs mois, au fil des runions.

La qualit dorganisateur et de chef de projet


Dfinir les exigences demande une planification soigne, une prparation minutieuse, une organisation de son propre travail et de celui de son
quipe, en tenant compte des contraintes du client et des autres parties
prenantes. Une fois que le projet est lanc, on doit faire face limprvu.
limage de tout chef de projet, lanalyste des exigences doit tre capable
de mener bien ces deux activits. Plus la planification sera rigoureuse,
et plus il sera facile de parer limprvu.

29

Livre Constant.indb 29

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Lexpression crite
La capacit crire avec aisance et prcision est fondamentale. Parmi
les nombreuses manires de reprsenter les exigences, diagrammes,
tableaux ou schmas, la plus usite, et gnralement la plus efficace,
demeure la langue franaise. Cest en effet la seule reprsentation facilement comprhensible par les gens de tous les mtiers.
La langue franaise (et toute autre langue naturelle , en fonction du
pays o lon se trouve et du milieu professionnel) est un outil extrmement
complexe et puissant, qui demande un long apprentissage et une longue pratique. Nous la matrisons tous, avec plus ou moins de talent, mais laborer
un cahier des charges exige lutilisation dun langage prcis et non ambigu.

Le savoir-tre
Une attitude de chef de projet
Trois dangers menacent lanalyste des exigences:
En manquant de rigueur, vouloir toujours faire plaisir tout le monde;
cela conduit lenlisement du projet.
En manquant de souplesse, se faire un ennemi parmi les parties prenantes; il risque de se faire griller.
Face des besoins mal dfinis, laisser le flou sinstaller, voire lamplifier; or, sa mission exige de la prcision.
Face ces trois menaces, la bonne attitude consiste tre rigoureux sur
le processus et souple avec les personnes. Cest cette neutralit bienveillante qui lui permettra de sen sortir indemne.

La curiosit
Le don dobservation et la crativit vont de pair avec la curiosit. Faire de
la veille technologique est indispensable, et il faut la faire activement. La
curiosit mle de crativit donne envie de piquer des ides et de les
formaliser ensuite. Rappelons que les ides nappartiennent personne.
Copier les ides en y ajoutant les siennes propres est lgitime (surtout si,
par respect du travail des autres, on cite ses sources).

Lcoute
Pour recueillir les besoins, il est plus important de savoir couter que de
savoir bien parler. Une bonne coute est pourtant une qualit rare, et trs
apprcie des utilisateurs.
Un analyste doit tre capable de mettre son interlocuteur en confiance;
de lencourager parler de son mtier ; de formuler une question en

30

Livre Constant.indb 30

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 3 Comptences et savoir-faire

tenant compte du contexte et du mtier de son interlocuteur; de le relancer pour avoir des prcisions; de stimuler son imagination et de le mettre
en situation pour dcrire une situation relle ou imaginer une situation
venir; de lencourager descendre dans les dtails ou, linverse, de
prendre de la hauteur par rapport sa situation.
Une bonne coute est lie au talent, lexprience et la personnalit de
lanalyste. Mais des interviews bien prpares et bien structures aident
le talent sexprimer et les moins talentueux sen sortir honntement.
Nous donnerons quelques rgles simples de prparation des interviews
dans le chapitre consacr au recueil des besoins.

Un excellent relationnel
Cette qualit est principalement utile lors de lanimation de groupes de
travail. Lors dune telle runion, un analyste doit tre capable de maintenir la motivation, de laisser chacun sexprimer, de cadrer et de recadrer
pour rester align sur les objectifs, de rsoudre les conflits, de maintenir
la bonne humeur, de permettre aux plus timides de sexprimer, et de canaliser les plus bavards.
Comme les qualits dcoute, les qualits relationnelles sont grandement
dpendantes du talent et de la personnalit de lanalyste. Et comme pour
lcoute, une bonne prparation et des techniques danimation peuvent
pallier le manque dexprience.

Lobservation
Une des nombreuses manires de recueillir les besoins consiste observer les personnes en train de travailler, dans leur milieu professionnel.
Mais le don dobservation est utile tout moment. Lors dune interview,
il est utile dobserver comment linterlocuteur ragit, et comment les participants une runion interagissent et communiquent entre eux; tout
noter, sur le papier ou dans sa tte, sous forme crite ou sous forme de
croquis. Parfois, deux yeux et deux oreilles ne suffisent pas, et lors de
certaines runions un coanimateur peut tre utile.

La crativit
Lanalyste des exigences nest pas toujours un tre neutre et incolore. Il
est l pour aider le client et lutilisateur dfinir, prciser et formaliser
le besoin. Mais le futur produit peut aussi contenir des caractristiques
nouvelles auxquelles le client seul ne pensera jamais. Lanalyste ou le
consultant, qui est en contact avec des clients parfois trs diffrents,
peut, et doit, apporter des ides nouvelles.
Il peut adapter un domaine des ides tires dun autre domaine. Par exemple,
lexigence fonctionnelle relancer priodiquement les prospects dun

31

Livre Constant.indb 31

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

logiciel commercial peut tre adapte un logiciel de cabinet dentaire


pour relancer les patients. Ce sera ensuite aux futurs utilisateurs (en loccurrence, les dentistes) de dire si cette ide est conserver. Encore faut-il
que cette ide soit propose.
Si tous les concepteurs se contentaient dcouter la voix du client, il
ny aurait que trs peu dinnovations. Cela est particulirement le cas des
clients qui sont des utilisateurs expriments dun produit existant. Souvent, ils demandent ce que le nouveau produit fasse la mme chose
que le prcdent, mais en mieux. Il faut tre capable de leur proposer le
mieux, qui peut aller du simple lifting de linterface graphique des
amliorations fonctionnelles consquentes.

Lesprit danalyse et de synthse


Un cahier des charges est une arborescence dexigences. Il faut tre
capable de travailler sur les branches de haut niveau pour dfinir les
grandes fonctions, puis descendre dans le dtail de chacune jusquaux
branches les plus fines, sans se perdre, puis remonter nouveau pour
donner une vision globale au donneur dordres. Tout cela doit tre fait
avec un scalpel mental la main, qui va permettre de sparer ce qui
appartient lunivers des exigences ( conserver dans un cahier des
charges) de ce qui est de lordre de la solution ( manier avec prcaution).
Lanalyste des exigences doit galement possder une sorte dalarme
intrieure qui le prvient de toutes les contradictions entre exigences
(son bon relationnel doit laider viter que ces contradictions se transforment en conflits de personnes) et un dtecteur de flou, ou plutt
une aversion caractrise pour les formulations floues, ambigus, aux
interprtations multiples.

La clart

2. Chacun appelle
barbarie ce qui nest
pas de son usage,
Montaigne.

Le mtier dexpression des exigences est un mtier de communication. Pour


faire passer des messages entre client et fournisseur, et aussi entre utilisateurs de mtiers diffrents, il est donc primordial de sexprimer avec
aisance et clart, oralement et par crit.
Lingnieur des exigences utilise toute une palette doutils : la parole
dans un premier temps, puis le langage crit ou graphique. Dans tous
les cas, il doit utiliser le moins de jargon possible. Quand un mot nouveau ou barbare2 (cest--dire, appartenant au mtier de lautre,
et qui na pas la mme signification pour toutes les parties prenantes)
doit apparatre dans le discours, il doit devenir pdagogue et clarifier le
concept.
Lanalyste des exigences doit manier plusieurs langages. Le langage
parl et crit en est un et occupe une place prpondrante. Mais il existe

32

Livre Constant.indb 32

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 3 Comptences et savoir-faire

de nombreux langages graphiques, plus ou moins adapts aux interlocuteurs des diffrentes parties prenantes. Il doit savoir les manier avec
discernement. Certaines personnes, de par leur profession, sont trs familiarises avec le langage graphique. Cest le cas des ingnieurs. Dautres
professions, comme les juristes, prfrent lcrit. Un schma qui paratra
limpide lun pourra tre abscons pour lautre. Il en est de mme des
tableaux. Reprsenter les informations sous forme tabulaire va souvent
de soi pour un ingnieur ou un comptable, moins pour un juriste. Inversement, dcrire un processus oprationnel au moyen dun long discours
crit peut couler de source pour un homme de loi et rebuter un ingnieur
qui a besoin de sappuyer sur des schmas pour faciliter sa comprhension. Ces diffrences culturelles doivent tre imprativement respectes
si lon veut viter les incomprhensions, voire les conflits.

33

Livre Constant.indb 33

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 34

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 4

Exigences
et cycle de vie
du logiciel
Dans ce chapitre, nous allons situer les activits de lingnierie des exigences dans le cycle de vie du logiciel. Cela va nous permettre de prendre
la mesure de limportance de ces activits, et de mieux comprendre les
rles et responsabilits des diffrents acteurs, ainsi que ceux du matre
duvre, du matre douvrage, et de lanalyste et de leurs engagements
rciproques.

Le cycle de vie du logiciel


Il existe plusieurs faons de reprsenter le cycle de vie du logiciel. Le
terme de cycle est dailleurs souvent utilis abusivement. Voici (source:
IEEE Std 982.2-1988) un modle de cycle de vie en huit phases:
Objectifs et concepts: dfinition des objectifs du produit construire, et
premire vision du logiciel.
Exigences: recueil, analyse et formalisation des besoins, laboration du
cahier des charges.
Conception: spcifications dtailles fonctionnelles et techniques, en
fonction des objectifs et des exigences prcdemment dfinis.
Ralisation: programmation et tests unitaires.
Tests et validation: tests fonctionnels, dintgration et validation.
Installation: mise en uvre oprationnelle et dploiement.
Exploitation et maintenance: mise disposition auprs des utilisateurs.
Retrait: arrt de lexploitation, ventuellement migration vers un autre
logiciel ou nouvelle version du mme logiciel.
Ce cycle en huit phases est vritablement circulaire, ce qui permet de
prendre conscience que, dans la vraie vie, un logiciel arrive rarement sur

Livre Constant.indb 35

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

un terrain vide, et ne laisse pas souvent un vide en partant (figure4-1).


Bien avant de mettre un logiciel hors service, on se proccupe de son successeur. Cest en gnral loccasion de redfinir le concept et les objectifs,
ainsi que les exigences qui en dcoulent.
Objectifs et
concepts

Retrait

Exploitation et
maintenance

Exigences

Installation et
dploiement

Conception

Tests
et validation

Ralisation

Figure4-1 : Le cycle de vie, modle IEEE982.2

Ce cycle en huit phases donne, bien sr, une vision schmatique de la


ralit (cest prcisment ce qui est demand un modle). Dans la pratique, les phases ne sont gales ni en temps ni en cots, et elles ne sont
pas spares par des cloisons tanches.
Entre deux versions dun mme logiciel, ou entre un logiciel et son successeur, on peut constater un retard de plusieurs phases. Il nest pas rare
que, pendant quun logiciel est encore en validation, on dfinisse dj les
besoins de son successeur.

Matres douvrage et matres duvre


Le cycle de vie ainsi reprsent nous permet de visualiser les relations
et le partage des responsabilits entre parties prenantes. Le matre douvrage est celui qui demande, spcifie, paie ou utilise le systme, ou plus
gnralement en tire un bnfice. Le matre duvre est celui qui le
conoit, le ralise, le met en uvre.
Si on examine le cycle de vie du logiciel au regard de cette distribution
des rles (figure4-2), on saperoit que le matre douvrage (ou client) est
responsable de lhmisphre nord du cycle et que le matre duvre

36

Livre Constant.indb 36

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 4 Exigences et cycle de vie du logiciel

occupe lhmisphre sud. On a donc, dans la partie haute du cycle,


ceux qui dfinissent et utilisent le quoi. Et dans la partie basse, ceux qui
sont responsables du comment.
Les stratges, ceux qui dcident de ce que sera, dans ses trs grandes
lignes, un nouveau produit, sont au ple nord du cycle. Les experts, qui
matrisent dans le dtail les techniques pointues, sont au sud.

Les stratges
Objectifs et
concepts

Retrait

Exploitation et
maintenance
Conflits
potentiels

Installation et
dploiement

Exigences

Matrise douvrage
Matrise duvre

Tests
et validation

Zone de flou

Conception

Ralisation

Les experts
Figure4-2 : Cycle de vie et partage des rles

Bien entendu, une mme personne peut, au cours de sa carrire, se trouver alternativement client ou fournisseur. Mais au cours dun mme projet,
les rles sont en principe spars, ainsi que les manires de travailler.
la frontire de ces deux mondes se trouve le cahier des charges, qui
devient ainsi un contrat entre deux parties. De la qualit de ce document
dpendra grandement la bonne coopration entre client (matrise douvrage, donneur dordres) et fournisseur (diteur, intgrateur, vendeur).
Entre matrise douvrage et matrise duvre, il y a souvent des difficults
de comprhension, dues des diffrences de mtier et de langage. De ce
fait, la tentation est grande de livrer un cahier des charges qui contient du
flou, des zones dombre, destines pallier les difficults de comprhension. Cest ce qui arrive souvent, et ne fait que repousser le problme: les
difficults reviennent la surface au moment de la livraison, gnrant des
tensions, voire des conflits.

37

Livre Constant.indb 37

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Btisseurs et exploitants
Le cycle de vie du logiciel peut tre dcoup verticalement. La partie droite
est celle des btisseurs, qui imaginent, conoivent, ralisent. La partie
gauche est celle des exploitants, qui installent, exploitent, maintiennent.
Entre ces deux populations, cest surtout la motivation qui est diffrente.
Les btisseurs sont attirs vers le nouveau, imaginent toutes les possibilits, veulent crer. La motivation des exploitants est la continuit et la
rgularit du fonctionnement, et la correction des erreurs et anomalies.
Pour cela, ils sappuient sur des procdures rigoureuses. Ici aussi, il faut
trouver un langage commun entre les diffrentes populations.
Objectifs et
concepts

Retrait

Exploitation et
maintenance

Exigences

Btisseurs
Exploitants
Installation et
dploiement

Conception

Tests
et validation

Ralisation

Figure4-3 : Cycle de vie et rpartition des mtiers

La phase dexigences
La phase dexigences sera dcrite trs en dtail dans les chapitres qui
suivent. Elle comporte les activits et tches suivantes:
identifier les diffrents profils utilisateurs de lapplication;
recueillir les besoins de chaque profil utilisateur;
analyser les besoins des utilisateurs, en liminer les incohrences et les
redondances;
traduire les besoins exprims oralement en spcifications;
aligner la spcification des exigences (le cahier des charges) aux objectifs
dfinis par le matre douvrage;
assurer la compltude du cahier des charges;

38

Livre Constant.indb 38

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 4 Exigences et cycle de vie du logiciel

dterminer, avec le matre douvrage et les utilisateurs, la priorit relative


de chaque exigence et son niveau de flexibilit (obligatoire, facultatif);
faire valider par le matre douvrage les exigences spcifies.
Comme on le voit sur la figure4-4, la phase dexigences fait partie de la
construction du logiciel ou du systme, et elle est sous la responsabilit
du matre douvrage.
Objectifs et
concepts

Retrait

Exploitation et
maintenance

Objectifs
formaliss

Zone
Exigences
dintervention
de lanalyste
Cahier des
(AMOA)
charges

valid

Installation et
dploiement

Conception

Tests
et validation

Ralisation

Figure4-4 : La phase dexigences dans le cycle de vie

Dans la pratique, le travail de lanalyste va au-del de la phase dexigences


proprement dite. Il est frquent que les concepts et les objectifs du logiciel ne soient pas clairement dfinis et ce sera lanalyste des exigences
de les formaliser et de les faire valider. Et, bien que cela dpasse le strict
cadre du cahier des charges, lanalyste saventure souvent dans la zone
floue entre les exigences et la conception.

Les engagements rciproques


Llaboration du cahier des charges est sous la responsabilit dune
personne, lanalyste des exigences, souvent appel assistant la matrise
douvrage. tant donn limportance du cahier des charges, son rle est
crucial, et devrait galement tre rgi par un contrat, entre son client et
lui. Cest souvent un contrat moral, mais il gagne tre mis par crit.
Un consultant pourra intgrer ces engagements rciproques une proposition commerciale dlaboration dun cahier des charges. Cependant,
mme sans aucun crit de part et dautre, lanalyste des exigences a tout

39

Livre Constant.indb 39

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

intrt connatre la liste de ces engagements, et de sy tenir. Il devra


galement mettre son client face ses responsabilits.
Voici un modle dengagements rciproques:
Engagements rciproques
Lanalyste (assistant la matrise douvrage) sengage :












aligner son travail sur les objectifs de son client,


se former au mtier du client et se tenir inform et de ses pratiques,
sexprimer en utilisant le vocabulaire de son client,
informer son client de lavancement du cahier des charges,
tenir son client inform des mthodes et outils utiliss,
spcifier les besoins en termes aisment comprhensibles par le client,
choisir les techniques et outils les plus adapts, et les mettre en uvre,
animer une dmarche collaborative respectueuse des utilisateurs,
animer les groupes de travail avec une neutralit bienveillante,
apporter des ides nouvelles, dans le respect de cette neutralit,
estimer les charges, dlais et risques, et en informer son client,
optimiser son temps et ses efforts, et ceux des groupes de travail,
sefforcer spcifier, dans les rgles de lart, un logiciel de qualit.

Le client (matre douvrage) sengage :













exprimer clairement lobjectif,


sinvestir dans lexpression des besoins,
respecter la dmarche dexpression des besoins mise en place,
inciter les parties prenantes participer aux groupes de travail,
informer le consultant sur son mtier et ses pratiques,
exprimer les besoins avec clart, exactitude et prcision,
lever les ambiguts sur lexpression dun besoin,
indiquer les priorits sur les exigences exprimes,
respecter les estimations faites par le consultant ou lexpert,
valider les documents intermdiaires,
valider le cahier des charges,
communiquer sans dlai les modifications dexigences.

Les engagements de lanalyste peuvent faire fonction de charte de dontologie. Les engagements du matre douvrage, mme sils ne sont pas
formaliss, peuvent servir de check-list au matre douvrage. Pour lanalyste,
cest la check-list de ce quil peut lgitimement demander son client.

40

Livre Constant.indb 40

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 5

La
dmarche
Pour tre efficace, la dfinition des exigences doit devenir une activit
systmatique et organise, faisant appel des acteurs dont les relations
sont formalises; en dautres termes, une activit dingnierie. Dans le
chapitre prcdent, nous avons vu comment cette activit sinsre dans
le cycle de vie du logiciel. Nous allons maintenant rentrer un peu plus
dans le dtail et dcrire globalement le processus de dveloppement des
exigences.

Dcrire, documenter, communiquer


Tout au long de cet ouvrage, nous dcrivons des techniques qui, regroupes, sappellent ingnierie des besoins ou ingnierie des exigences. Voil une belle
expression, mais dans quelle mesure le terme dingnierie est-il justifi?
Recueillir, analyser, spcifier les besoins sont en grande partie des actions
de description. Il sagit de dcrire un besoin en le formulant pour la premire fois, en le reformulant diffremment, de manire plus claire, plus
constructive, plus cohrente ; en le montrant sous diffrents angles,
comme un dessin darchitecte montre un btiment selon des vues diffrentes; en le formulant dans un langage que tous (en tout cas tous ceux
qui ont besoin de cette description), comprennent et interprtent de la
mme faon.
Dcomposer un ensemble de besoins en sous-ensembles plus petits,
de manire arborescente, le dcrire sous diffrents aspects va immanquablement gnrer beaucoup de documentation. Il sagit l dun aspect
fondamental de ce mtier. Nous devons grer des masses dinformations
et les prsenter de manire cohrente. Il faudra galement maintenir cette
cohrence dans le temps, grer cette volution. La gestion des versions et
des changements fait partie du mtier.

Livre Constant.indb 41

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Toutes ces informations devront tre partages par tous ces acteurs. La
dfinition des besoins est donc aussi une activit de communication. Cette
communication se fait bien sr dans les deux sens: coute et spcification.
Nous avons dans ce triptyque lessence du mtier danalyste : dcrire,
documenter, communiquer (figure5-1).

Communiquer

120

Documenter

Dcrire

Figure5-1 : Lessence de notre mtier

Les diffrents niveaux dexigences

1. Objectifs: voir au
chapitre6.

Les activits de recueil, danalyse, de spcification et de validation des


exigences peuvent se faire plusieurs niveaux:
Les objectifs stratgiques1 fixs par la direction gnrale ou par le donneur dordres, et dont le recueil et la formalisation demandent un soin
particulier.
Les exigences de haut niveau, lies lorganisation (en anglais business
requirements), dcoulant directement des objectifs ou de contraintes
organisationnelles ou rglementaires.
Les exigences de niveau intermdiaire correspondent au point de vue
dun utilisateur (en anglais user requirements): exigences comportementales, cas dutilisation, exigences de qualit.
Les exigences lmentaires (en anglais atomic requirements), qui dcrivent
sous forme de phrases simples (du type le systme doit) des exigences fonctionnelles ou non fonctionnelles, des contraintes, dordre
technique ou autre, ou des exigences dinterface.
Cette classification (qui peut varier selon les modles de cahiers des
charges) permet de structurer la spcification en couches dexigences
de plus en plus dtailles (figure5-2). Les exigences un niveau doivent
tre alignes aux exigences de niveau suprieur.

42

Livre Constant.indb 42

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 5 La dmarche

Les exigences de haut niveau (les objectifs) feront lobjet dun document
particulier, qui pourra tre repris dans le cahier des charges. En fonction
de sa destination, le cur du cahier des charges descendra plus ou moins
dans les dtails. Par exemple, un cahier des charges destin dvelopper un logiciel contiendra plus dexigences dtailles quun cahier des
charges pour le choix dun progiciel sur tagre.

Objectifs
Exigences
dentreprise ou
organisationnelles
Cas dutilisation, exigences
normatives et rglementaires, rgles
dintroprabilit, de scurit,
Exigences lmentaires fonctionnelles et non
fonctionnelles, contraintes, exigences dinterface

Figure5-2 : Niveaux dexigences

Les tapes de llaboration


laborer un cahier des charges consiste donc avant tout traduire des
besoins flous, imprcis, et parfois inconnus, en exigences structures et
organises; les traduire donc, depuis le langage du client en un langage
comprhensible de tous (client, fournisseur et observateurs extrieurs).
Prsentons les diffrentes tches qui vont du recueil des besoins au
cahier des charges.
La premire tche consiste dcouvrir les enjeux, les objectifs, et les
contraintes du projet. Les enjeux constituent la raison profonde du lancement dun projet, les intentions derrire les objectifs. Certains enjeux seront
clairs et pourront tre exprims dans le prambule du cahier des charges.
Dautres enjeux pourront tre cachs (ambitions personnelles, projet inavou de dpasser un concurrent). Quils soient publics ou tenus secrets, ils
devront tre analyss, pris en compte. Les objectifs, eux, devront tre formaliss. Ils constituent les exigences de plus haut niveau. Les contraintes
ne sont quune forme particulire dexigences, prsentes en creux.
Une tche importante consiste identifier les diffrents acteurs du
projet (les parties prenantes, en particulier les reprsentants des futurs
utilisateurs), connatre les enjeux les plus importants pour chacun
deux, tablir un dialogue, les faire participer au projet dlaboration.

43

Livre Constant.indb 43

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

2. En anglais, le
terme utilis pour le
recueil est elicitation.
Il peut se traduire par
extraction

Recueillir les besoins est une tche beaucoup plus complexe quil ny
parat. Les besoins sont rarement la surface du sol2. Ils sont en gnral
cachs, et diverses techniques permettent de les dterrer : les runions de travail, les interviews des utilisateurs, lobservation directe, la
lecture de documents (y compris dautres cahiers des charges). Il ny a pas
de technique plus efficace quune autre, tout dpend du contexte, et cest
une combinaison de techniques qui permettra un recueil complet.
Ainsi recueillies, les exigences seront analyses. Analyser les exigences,
cest les faire passer par des filtres, les examiner pour dtecter les exigences manquantes, contradictoires, les incohrences divers niveaux.
Une analyse efficace des exigences permet de toujours rester au meilleur
niveau de dtail. Le niveau de dtail ncessaire dpend des intentions du
projet. Par exemple, on nexprimera pas le mme niveau de dtails pour
un projet de dveloppement spcifique et un choix de logiciel sur tagre.
De plus, il faudra tablir des priorits entre exigences.
Il va falloir ensuite rdiger les exigences, gnralement sous forme de
cahier des charges. La forme peut tre textuelle ou graphique. Il ny a
pas de forme a priori meilleure quune autre. Tout dpend de celui qui va
lire le cahier des charges, limportant tant de donner une vision et une
comprhension partages des exigences. La reprsentation graphique
fait appel des techniques de modlisation des donnes ou des traitements informatiques.
Vu du rdacteur, le cahier des charges nest quun lieu de stockage des
exigences. Mais les exigences voluent. Grer les volutions fait galement partie de ce quil est convenu dappeler lingnierie des exigences.
un instant donn, une version du cahier des charges peut tre en cours
dutilisation (par les quipes de concepteurs, par exemple), une autre en
cours dlaboration. Ce sont alors des techniques de gestion des versions
et de la configuration qui seront utilises.
Enfin, les exigences devront tre valides par les diffrentes parties prenantes. Cette validation se fait plusieurs niveaux. Les futurs utilisateurs
valideront souvent au fur et mesure de la rdaction, le donneur dordre
validera gnralement lensemble du document. Le suivi de la validation
des exigences nest donc pas une tche facile.

Description formelle du processus global


Formellement, lingnierie des exigences comporte deux types dactivits:
le dveloppement des exigences, qui consiste dfinir les besoins et
laborer un cahier des charges;

44

Livre Constant.indb 44

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 5 La dmarche

la gestion des exigences, qui consiste grer les changements et les


volutions des exigences dans le temps.
Le dveloppement des exigences comporte quatre tapes trs fortement
imbriques selon un processus cyclique:
le recueil, qui consiste faire exprimer les besoins et rechercher les
besoins dj exprims;
lanalyse, qui consiste examiner les exigences sous diffrentes facettes,
et maintenir la cohrence entre les exigences;
la spcification, qui consiste dcrire et documenter les exigences de
manire la fois formelle et comprhensible par toutes les parties prenantes;
la validation, qui consiste obtenir, de la part de toutes les parties prenantes, un accord formel sur les exigences spcifies.
Comme on peut le voir, il y a des boucles de rtroaction entre les quatre
activits.

Recueil

Analyse

Spcification

Validation

CdC

Figure5-3 : Le processus global

Le dcoupage en quatre tapes permet de mieux comprendre le mtier de


dfinition des exigences. En pratique, ces tapes sont imbriques dans
le temps, chaque tape contenant une partie des autres. Par exemple,
lors dune mme entrevue avec un utilisateur du futur produit (activit
de ltape de recueil), on peut couter les besoins (recueil), tenter de
comprendre comment ce besoin se rattache aux objectifs de la direction
(analyse), essayer de reformuler le besoin de manire claire (spcification)
et demander lutilisateur son opinion sur cette formulation (validation).

Le processus en pratique
Nous avons vu quen pratique les quatre activits de recueil, danalyse,
de spcification et de validation, ne sont ni linaires ni bien distinctes.
ces quatre activits sajoute la gestion des volutions des exigences,
qui en ralit commence ds le dbut du recueil. Sy ajoute une activit
en amont de dfinition des objectifs (en toute rigueur, cest une phase

45

Livre Constant.indb 45

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

3. Voir au chapitre16
un modle de processus qui peut tre
adapt.

prcdente du cycle de vie, mais dans tous les cas, elle devra tre dcline
pendant la phase dexigences). Et, cela va sans dire, une activit transverse de gestion de projet.
Il nexiste cependant pas un modle unique de processus3, autrement dit
aucune recette de cuisine qui nous indiquerait les tches mener
chaque tape, et dans quel ordre.
Chaque projet est diffrent, et la premire tche de lquipe charge
de dfinir les besoins consiste ajuster le processus de dfinition aux
contraintes propres au projet. Ce qui est cependant certain, et vrifi dans
la pratique, cest que les tapes en amont (la prparation), si elles sont
bien menes, facilitent grandement la dfinition des besoins proprement
dite (la production du cahier des charges). En dautres termes, dfinir
les besoins devrait tre une activit descendante (top-down) dont les
tapes sont les suivantes:
tapes en amont (prparation de llaboration du cahier des charges):
dfinir le concept et prciser les objectifs,
analyser les parties prenantes: rles, responsabilits,
dfinir les catgories (classes) dutilisateur,
slectionner, dans chaque catgorie, les reprsentants des utilisateurs,
choisir, en fonction du contexte et des contraintes, les techniques
de recueil mettre en place,
dfinir les contours du futur produit (primtre),
dfinir les changes entre le futur produit (vu comme une bote
noire) et le monde extrieur,
identifier les cas dutilisation mtier (business use cases),
tablir des priorits entre cas dutilisation,
slectionner les cas dutilisation qui seront informatiss.
tapes de dfinition des besoins (production du cahier des charges):
dcrire les cas dutilisation,
dcrire les exigences non fonctionnelles,
dcrire les contraintes,
modliser les donnes,
dfinir les exigences fonctionnelles,
passer en revue les spcifications dexigences,
dvelopper, si ncessaire, des maquettes,
dvelopper, si ncessaire, des prototypes dune partie du futur
systme,

46

Livre Constant.indb 46

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 5 La dmarche

spcifier prcisment les exigences fonctionnelles dans le cahier


des charges,
faire valider le cahier des charges.
tapes transverses:
grer les demandes de changement des exigences,
grer lquipe de dfinition des exigences,
planifier et grer les groupes de travail de recueil, danalyse ou de
validation des exigences,
grer le projet (cots, dlais, relation avec le donneur dordres).

Check-list
La liste des tches effectuer vue au paragraphe prcdent peut servir de
check-list lors de ltablissement dun plan-projet pour llaboration dun
cahier des charges.

47

Livre Constant.indb 47

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 48

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 6

Dfinir
le concept
et les objectifs
Cette tape pralable de dfinition du concept et des objectifs est cruciale pour la suite. Cest un miniprocessus de dfinition des exigences, en
plus dense, plus rapide, et au plus haut niveau. Son livrable est une sorte
de cahier des charges en concentr. Il conditionne la russite du projet.
Elle doit donc tre mene avec le plus grand soin.

Une activit pralable indispensable


La premire activit laquelle doit sattaquer lquipe en charge de dfinir les besoins consiste dfinir le concept et ses objectifs du produit,
les objectifs du cahier des charges lui-mme, ainsi que les exigences au
plus haut niveau. Ces tches seront menes en parallle, car elles sont
pratiquement indissociables. En effet, elles permettent de rpondre aux
quatre questions suivantes:
Concept du produit : en quoi consistera le produit ? De quoi sera-t-il
fait ? En quoi se distinguera-t-il des produits existants, quils soient
concurrents ou complmentaires?
Objectifs du produit: quelle utilisation sera faite du produit? Dans quel
but? Pour servir qui? Pour servir quoi? Pour gagner quoi?
Objectifs du cahier des charges: que veut-on faire du cahier des charges?
Choisir un produit sur tagre, dvelopper une application spcifique,
acqurir un progiciel, le paramtrer et le dployer?
Exigences au plus haut niveau: quelles sont les quatre ou cinq grandes
fonctions que le produit doit remplir ? Quelles sont les deux ou trois
exigences non fonctionnelles (qualit, performance) auxquelles le
produit doit rpondre en priorit ? Quelles seront ventuellement les
contraintes techniques incontournables?

Livre Constant.indb 49

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Cette tape fait dj appel aux techniques classiques de recueil, danalyse, de spcification et de validation des exigences, mais tant donn
son caractre stratgique, nous dcrivons ces techniques spcifiquement
adaptes cette tape prparatoire plus en dtail dans les paragraphes
qui suivent.

Objectifs, primtre et parties prenantes


1. Cadrage. La littrature anglophone
parle de document
de vision et porte
(vision and scope).

Lors de cette tape pralable1, il sagit de dfinir:


lobjectif;
le primtre, ou champ de ltude;
les parties prenantes.
Par parties prenantes nous entendons toutes les personnes ou organisations impactes (positivement ou ngativement) par lintroduction du
systme ou susceptibles dinfluencer son choix, son dveloppement ou
son dploiement.
Ces trois activits sont fortement interdpendantes (figure 6-1). Toutes
les exigences formalises devront tre alignes sur lobjectif prcdemment dfini. Mais qui va exprimer lobjectif? En grande partie, le donneur
dordres. Cependant, en tant que personne physique, il va rarement exprimer un objectif de manire formelle. Il sappuiera sur des experts, il devra
tenir compte dautres parties prenantes (actionnaires, associations, syndicats, socits savantes). Or, linfluence de ces parties prenantes sur
lobjectif dpend du primtre.

Objectif

Parties
prenantes

Primtre

Figure6-1 : Trois activits pralables indissociables

Ces trois activits sont prsentes dans les paragraphes qui suivent. Le
document rsultant de ces activits est un document de cadrage.

50

Livre Constant.indb 50

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 6 Dfinir le concept et les objectifs

Recueillir les objectifs


Les objectifs: des exigences au plus haut niveau
Les objectifs du systme ( choisir, dvelopper ou mettre en uvre) ne
sont rien de plus que des exigences de haut niveau.
Voici un exemple dobjectif, pour un logiciel de prescription de mdicaments:
Assurer la scurit, la traabilit et la qualit des
prescriptions conformment larrt du 31mars1999.
Cet objectif contient en ralit trois exigences de trs haut niveau (scurit, traabilit et qualit des prescriptions de mdicaments). Chacune
delles sera dcline en une multitude dexigences fonctionnelles (quel
scnario suit le mdecin qui prescrit, quelles informations doivent tre
saisies, comment le logiciel vrifie les interactions mdicamenteuses) et
non fonctionnelles (le temps daffichage du nom du mdicament, la prcision des informations affiches) ainsi que des contraintes techniques.
Comme on se limagine aisment, les objectifs daussi haut niveau doivent tre formuls avec le plus grand soin, puis valids au plus haut
niveau hirarchique possible, car ils conditionnent des pans entiers du
systme venir.

Prciser et formaliser lobjectif


Quelle sera la finalit du systme? Sagit-il de choisir un logiciel sur tagre, ou bien de dvelopper un logiciel spcifique? La forme, le contenu
et la structure du futur cahier des charges en dpendent, et donc la faon
dont il sera labor. Le cot de son laboration peut varier dans un
rapport de un dix, le cot du logiciel install de un cent. Il est donc
de premire importance de prciser, en collaboration avec le donneur
dordre, lobjectif atteindre.
Cet objectif sera formul sur une page maximum, et approuv par le donneur dordre.
On peut formaliser lobjectif sous une forme finalit-avantage-mesure.
Par exemple:
finalit: assurer la scurit des prescriptions de mdicaments;
avantage: diminution du nombre derreurs mdicamenteuses;
mesure: diminution de 20% du nombre derreurs.
En fonction du contexte, on pourra conserver cette forme de prsentation
dans le document, ou se servir de cette formulation uniquement pour
recueillir lobjectif auprs du donneur dordres et prfrer une prsentation plus littraire pour le document.

51

Livre Constant.indb 51

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Techniques de recueil: runions et interviews


Les techniques pour recueillir ces objectifs et besoins haut niveau sont
les runions et les interviews. Il peut sagir dune runion de lancement
linitiative du donneur dordre, de runions avec les reprsentants des
utilisateurs, ou dinterviews individuelles.
Quand on est dans le flou, que les rles et responsabilits sont mal dfinis, que les objectifs ne sont pas clairs, linterview est la technique la plus
efficace. la fin de linterview, on demandera la personne interviewe
quelles autres personnes sont susceptibles de nous fournir des informations complmentaires. Cette technique permet de dfinir de proche en
proche les objectifs et le concept, en croisant les informations obtenues
au cours des diffrentes entrevues.

Dterminer le primtre
Le domaine dapplication: lutilit du produit
qui et quoi servira le futur systme, et pour quoi faire ? Ces questions vont dterminer le domaine dapplication. Il est important de le
connatre, car il nous permettra de dterminer quels sont les principaux
acteurs; par exemple, les experts du domaine chez qui on va recueillir des
besoins, et les futurs utilisateurs.
Le domaine large (par exemple, bancaire, sant, industrie automobile)
est simple dterminer. Mais il sagit daller un peu plus dans le dtail,
en partant de lobjectif. Prenons un exemple: si lobjectif est de grer de
manire centralise les demandes de subventions des jeunes cinastes
expatris, on saperoit que lon aura affaire, non un, mais plusieurs
experts de domaines dexpertise trs diffrents.
Si lon ne veut pas tomber dans le pige de la dcomposition fonctionnelle (description des diffrentes fonctions du produit), il est essentiel
de se concentrer sur la question quoi sert le produit, qui, pour quoi
faire?. On a obtenu, lors de la dtermination des objectifs, des rponses
comme : grer au quotidien les demandes de subvention. Savoir o et
par qui sont gres des demandes de subvention de ce type permettra de
dlimiter le domaine dapplication.

Le primtre: les limites du produit


ce stade, il nest pas question de dcrire le systme ltude lui-mme.
Ce quil est possible de dterminer, cest son primtre : quelles sont
les limites du produit, et quelles sont les interfaces qui permettent de
communiquer avec lextrieur. Ce monde extrieur est fait de logiciels, de

52

Livre Constant.indb 52

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 6 Dfinir le concept et les objectifs

matriels et dutilisateurs avec lesquels le systme ltude va communiquer.


Il est essentiel de dcrire le primtre avec le plus grand soin, sous forme
textuelle. Ce texte, qui devra faire lobjet dun consensus entre toutes les
parties prenantes, sera soumis lapprobation du donneur dordre et des
principales parties prenantes.
Dcrire le primtre est un exercice difficile et un investissement trs rentable. Llaboration de ce texte va permettre, non seulement de clarifier
les concepts, mais galement de dcouvrir des contraintes, de dterminer
par la suite les parties prenantes, et de prciser lobjectif.

Le diagramme de contexte
Le diagramme de contexte est un outil de communication intressant, et il
peut tre labor ds cette premire tape, quitte tre affin par la suite.
Un diagramme de contexte nest ni plus ni moins quun diagramme de flux
un niveau trs macroscopique, o le systme ltude est au centre.
Ce diagramme peut tre utilis pour dcrire lexistant (diagramme de
contexte mtier) ou pour situer le futur systme dans ses interactions avec
le monde extrieur (diagramme de contexte produit). Outre sa valeur pdagogique comme outil de communication, il sera trs utile lors de ltape de
recueil des exigences pour dterminer les cas dutilisation (use cases).
La figure6-2 reprsente le diagramme de contexte (ici simplifi) pour un
systme de prise en charge mdicamenteuse pour un centre hospitalier.

Mdecin

Prescription

Prescription

Avis
pharmaceutique

Avis
pharmaceutique

lments de
prescription

Informations
mdicament
Informations
patient

Systme

Informations
patient

Infirmire

Pharmacien

Validation de
ladministration

Informations
patient
lments de
prescription

Dossier
patient

Figure6-2 : Diagramme de contexte

53

Livre Constant.indb 53

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Analyser les parties prenantes


Savoir qui a intrt quoi et quand
2. Partie prenante:
en anglais, stakeholder.

On appelle partie prenante2 toute personne, groupe de personnes ou organisation qui a un intrt (positif ou ngatif) dans le projet ou le produit.
Qui paye pour le dveloppement, la mise en service, lexploitation du
futur logiciel? Qui va le raliser? Qui va lutiliser? Qui va conduire le
projet de ralisation ? Et qui va essayer de torpiller le projet tout
prix? Il est important de le savoir davance.
On identifiera les personnes ou les profils (par exemple,assistante administrative) ayant un intrt dans llaboration du cahier des charges ou
dans les applications qui en font lobjet, le rle que ces personnes pourront jouer pour llaboration des cahiers des charges (par exemple,expert,
conseiller, relecteur, futur utilisateur), leurs rles, intrts et objectifs.
Cette tape danalyse a une faible visibilit court terme et un fort impact
long terme, ce qui fait quil est facile de la rater. dfaut de cette analyse, on court le risque de se focaliser sur quelques partenaires, de passer
ct de besoins importants, et docculter des pans entiers du cahier des
charges. Lanalyse des parties prenantes va permettre, en temps voulu, de
fixer les priorits entre des besoins trs divers et parfois contradictoires,
darbitrer, de grer les conflits, et surtout, de connatre le vritable objectif, de savoir si (et quand) on sen loigne, de manire corriger les carts.

Liste des parties prenantes


Une premire liste des parties prenantes a t tablie lors de la planification du projet de dfinition des besoins. Il sagit maintenant de dresser
une liste complte et dtaille et de noublier personne. La liste peut tre
trs diffrente dun projet lautre. Voici titre indicatif une liste, affiner
pour chaque projet:
le donneur dordres, ou matrise douvrage stratgique, propritaire du
produit, cest--dire celui qui paye pour le produit;
la matrise douvrage oprationnelle, qui reprsente les utilisateurs;
les utilisateurs, qui vont travailler avec le produit, directement ou indirectement (il faudra dtailler les diffrents profils);
lassistant matrise douvrage, analyste ou consultant, qui va recueillir, analyser et spcifier les besoins, et interagir avec lquipe de dveloppement;
les concepteurs, architectes, ralisateurs, qui vont recevoir le cahier des
charges et devront linterprter et le raliser;
lquipe de test et de validation, qui va vrifier que le produit dvelopp
respecte le cahier des charges;

54

Livre Constant.indb 54

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 6 Dfinir le concept et les objectifs

les personnes charges de rdiger la documentation du produit, conformment aux spcifications;


les concepteurs et ralisateurs dautres produits, qui vont interagir avec
le systme ltude;
les personnes charges du support technique ou fonctionnel du produit
choisir ou dvelopper;
le marketing du produit;
les juristes;
les organismes de normalisation (leurs reprsentants);
les experts mtier;
les experts techniques.
Cette liste nest pas exhaustive. Elle sera nominative, du moins en ce qui
concerne les parties prenantes fort pouvoir de dcision.

La grille impact-pouvoir-influence
Aprs avoir dress la liste des parties prenantes, on doit valuer le pouvoir,
lintrt et linfluence de chacun deux, de manire mieux orienter les
efforts de recueil des exigences. Il y a plusieurs manires de reprsenter
linfluence des parties prenantes sur le projet (grilles pouvoir-influence,
pouvoir-impact, pouvoir-intrt, etc.) dont chacune a ses avantages. La
manire la plus utile semble tre la grille impact-pouvoir-influence:
Impact: dans quelle mesure la personne, le groupe ou le profil utilisateur sera-t-il impact (dans son travail, dans son pouvoir) par lintroduction du systme?
Pouvoir: quel est son pouvoir dinfluence?
Influence: cette influence sera-t-elle positive, ngative ou neutre?
Par exemple, le donneur dordres a beaucoup de pouvoir, une influence positive sur le projet et sera gnralement fortement impact. Une association
professionnelle ou un syndicat peuvent avoir beaucoup de pouvoir (positif
ou de nuisance) sans tre directement impacts. Acontrario, un utilisateur
final a gnralement beaucoup dintrt et peu de pouvoir (figure6-3).
Lutilit dune telle grille est multiple:
connatre les intrts de chaque partie prenante, ce qui permet dj de
dtecter des exigences;
en fonction de limpact et du pouvoir, avoir une premire ide des priorits entre exigences;
dtecter les risques potentiels, de manire les limiter;
savoir qui informer, quand, et de quelle manire;
dtecter les freins lavancement du projet.

55

Livre Constant.indb 55

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Fort

Partie 1 Mthodologie

Actionnaires

DG
Mdecins

0 Comptables

Psychologue

+
+

Faible

Pouvoir

Faible

Infirmiers

Support
technique

Impact

Fort

Figure6-3 : Grille impact-pouvoir--influence

Grille de questionnement
La grille de questionnement suivante peut servir de trame (par exemple,
lors dune interview) pour la dtermination des objectifs, du contexte, et
des parties prenantes, et pour anticiper les techniques utiliser:
Demandeur. Qui est lorigine de la demande?
Motivation. Quest-ce qui, daprs vous, a motiv la demande?
Objectif. Quel est lobjectif de lapplication? Quel est lobjectif du cahier
des charges? Que veut-on obtenir? Quel problme veut-on rsoudre?
Critres. Comment saurons-nous que lobjectif est atteint?
Bnfices attendus. Quespre-t-on gagner avec ce projet?
Acteurs. Qui va utiliser le produit? Qui va payer? Qui va dvelopper,
maintenir, exploiter? Quels sont les dcideurs?
Contenu. Que va-t-on mettre dans le cahier des charges? Que va-t-on
exclure: les fonctions? les exigences non fonctionnelles (qualit, performances)? les contraintes techniques? les contraintes de projet? les
contraintes dexploitation?
Porte. Quelles fonctions va-t-on dcrire dans le cahier des charges
(porte fonctionnelle) ? Quest-ce qui sera englob par le cahier des
charges : lentreprise entire, le systme, un composant du systme
(porte de conception)?

56

Livre Constant.indb 56

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 6 Dfinir le concept et les objectifs

Niveau. quel niveau dobservation va-t-on se placer: un niveau stratgique, au niveau utilisateur, ou au niveau trs dtaill? Quel niveau de
dtail ou dabstraction veut-on obtenir?
Usage. Que veut-on en faire du cahier des charges: choix de progiciel,
dveloppent spcifique?
Parties prenantes. Qui sera le correspondant de la personne charge
de rdiger le cahier des charges? Quelles seront les autres parties prenantes?
On adaptera ces questions au contexte et aux interlocuteurs. On pourra
poser toutes les questions chaque interlocuteur, de manire se faire une
ide des demandes, mais il est vident que le poids des rponses sera diffrent en fonction des interlocuteurs. Les utilisateurs ne sont pas les payeurs.
Plus que jamais, la difficult de cet exercice de questionnement est de
ne pas trop descendre dans les dtails. Il ne sagit pas, dans cette tape
prliminaire, de faire le cahier des charges par anticipation, mais dapporter une vision, une conceptualisation de ce que sera le futur systme.

Tableau des parties prenantes


Grce la grille impact-pouvoir-influence et suite aux informations
recueillies au moyen de la grille de questionnement, on peut tablir le
tableau des parties prenantes. La grille du tableau 6-1 est donne en
exemple. Notons que les rubriques des diffrentes colonnes peuvent
varier selon le contenu, la porte, le niveau et lusage du cahier des
charges (voir paragraphe prcdent).
Tableau 6-1 Grille des parties prenantes
Partie
prenante

Rle

Objectifs

Problmatique

Actionnaire

Finance
le projet

Efficience

Cot du
dveloppement

Non

DG

MOA stratgique

Respect de la
rglementation

Non

Mdecins

Utilisateurs directs
Prescripteurs

Prescrire sans perte


Erreurs
Facilit dutide temps
mdicamenteuses
lisation
Aide la prescription

Oui

Infirmiers

Utilisateurs directs
Administrent
les mdicaments

Disponibilit
de
lapplication

Oui

Besoins
particuliers

Apport
dexpertise

57

Livre Constant.indb 57

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Le document de cadrage
Il est important de formaliser lobjectif, le champ de ltude et le tableau
des parties prenantes dans un document unique, et faire valider ce document par les parties prenantes les plus importantes (les dcideurs).
Une fois valid, un tel document a plusieurs vertus:
Cest un cahier des charges en condens.
Cest une aide la gestion de projet: il permet de chiffrer leffort ncessaire pour laborer le reste du cahier des charges, trouver les experts,
planifier.
Il peut faire fonction de lettre de mission pour lanalyste.
Le document de cadrage est le livrable de la phase de prparation du
processus. Il contiendra donc les lments suivants:
le concept;
les objectifs;
les parties prenantes: rles, responsabilits;
les catgories (classes) dutilisateur;
les contours du futur produit et changes avec lextrieur: diagramme
de contexte;
les cas dutilisation mtier (business use cases) dans leurs grandes lignes,
par priorit;
les cas dutilisation quon a dcid dinformatiser.

Check-list
La check-list suivante permet de sassurer que les conditions sont runies
pour russir le projet, quil sagisse de choisir et mettre en uvre un progiciel ou de dvelopper une application. Si toutes les conditions ne sont
pas runies, laborer un cahier des charges sera de peu dutilit.
Les objectifs sont-ils clairement spcifis?
A-t-on identifi, analys et formalis la liste des parties prenantes?
Les objectifs spcifis sont-ils approuvs par les parties prenantes?
Les objectifs sont-ils ralistes, en termes de dlais, de charge, de budget
et aussi de risques?
A-t-on analys les risques?
Y-a-t-il consensus entre parties prenantes sur le primtre?
Le primtre a-t-il t formellement approuv par le donneur dordres?
Les parties prenantes se sont-elles engages participer?

58

Livre Constant.indb 58

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 7

Planifier
le projet
dlaboration
laborer un cahier des charges est un projet en soi. Dans ce cadre, il
ncessite une vritable planification. Aprs avoir dfini les parties prenantes, le champ et lobjectif, nous avons en main tous les lments pour
laborer le plan projet. Celui-ci consiste dterminer les techniques,
mthodes et outils mettre en uvre pour mener bien le projet dlaboration du cahier des charges, avec un maximum defficacit pour un
minimum d
effort. Le livrable de cette tape pralable est un plan projet.

Le plan projet
Ce document vient en complment du document de cadrage et sert de
feuille de route lquipe dlaboration du cahier des charges. Lensemble forme le cahier des charges du projet de cahiers des charges.
Le plan projet contient un devis estimatif des cots et dlais, ainsi quune
description brve (une ou deux pages) de lorganisation et de la mthode
de travail : taille de lquipe, moyens mettre en uvre, formations
prvoir, circuit de linformation, frquence des runions, validation des
documents, en fonction dun certain nombre de paramtres (taille fonctionnelle, maille du cahier des charges).
Cette manire descendante (top-down) de procder prsente plusieurs
avantages:
la fin de cette tape, vous disposez de tous les outils ncessaires
llaboration du cahier des charges.
Vous avez une ide prcise des paramtres du projet: cot, dlais, qualit, ressources ncessaires.
Vous pouvez ainsi ngocier avec le donneur dordres sur des bases
solides.

Livre Constant.indb 59

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Les paragraphes qui suivent dtaillent les activits de cette tude prliminaire: cadrer la mthodologie et laborer le plan projet.

Cadrer la mthodologie
Dfinir le processus global
Le processus de recueil des besoins et dlaboration du cahier des charges
peut varier dun cas lautre. Une bonne pratique consiste dcrire ce
processus et lenchanement de chacune de ses activits (recueil, analyse,
spcification, validation, gestion) selon un schma de processus dtaill.
Cette tape est utile, voire indispensable, lorsque llaboration du cahier
des charges est faite par un consultant externe. Dans ce cas, il doit dcrire
schmatiquement sa mthode de travail dans sa proposition technique
et commerciale.

Choisir les modles de reprsentation utiliser


1. Diagrammes: voir
au chapitre10.

On choisira les modles1 de reprsentation des exigences qui seront


utiliss pour llaboration des cahiers des charges (par exemple, cas
dutilisation, diagrammes de squence). Le choix se fera en fonction du
domaine (technique, administration, banque), des normes et standards
dans lentreprise, mais aussi en fonction de la sociologie des parties prenantes. En effet, en fonction des milieux professionnels, les personnes
sont plus ou moins sensibles une reprsentation plutt qu une autre.

Dterminer et adapter les techniques


2. Ces techniques
sont dcrites dans les
chapitres7 14.

Il ny a pas une mthode unique de gestion des exigences. Les techniques2


classiques dacquisition, danalyse, de spcification, de validation et de
gestion des exigences devront tre adaptes au contexte, aux interlo
cuteurs, au type de systme ltude.

tudier les outils


3. Outils: voir au
chapitre19.

On fera une analyse comparativedoutils3 daide llaboration de cahiers


des charges et de gestion des exigences. Il sagira, dans cette tude de
dfinition, de faire un choix doutils, ou simplement de mieux connatre
loffre du march, de manire mieux adapter les techniques, dterminer les profils des intervenants, anticiper sur les cots de formation, les
charges dlaboration.

60

Livre Constant.indb 60

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 7 Planifier le projet dlaboration

laborer les documents types


Pour chaque modle de reprsentation des exigences choisi, on laborera le
modle de document appropri(modle gnrique); par exemple,modle
de cas dusage (use case).
Cet ouvrage donne plusieurs modles de documents types, ainsi que des
adresses Internet utiles permettant den tlcharger.

Identifier et adapter les modles


Il sagit de dterminer, avec la collaboration des parties prenantes les
plus impactes, la structure4 du document final, son niveau (par exemple,
niveau stratgique, niveau de lutilisateur, ou niveau des sous-fonctions), sa porte (organisation, systme, sous-systme, composant), son
contenu dans les grandes lignes (en dehors des exigences fonctionnelles,
les autres exigences abordes).
On laborera le modle de document (le template) de cahier des charges.

4. Modles de cahiers
des charges: voir au
chapitre14.

laborer le plan projet


Identifier les profils utilisateurs
Cette activit fait suite lanalyse des parties prenantes en la dtaillant
en ce qui concerne les profils utilisateurs. On identifiera et analysera les
profils utilisateurs types pour le logiciel qui fera lobjet de cahiers des
charges, leurs attentes, leurs besoins gnriques, les conflits potentiels
entre types dutilisateurs, leur niveau de matrise des technologies, etc.
Cette activit sera affine lors de ltape de recueil des besoins.

tablir la liste des sources dexigences


Les exigences qui seront formules dans les cahiers des charges proviendront de sources diverses : tudes en amont, tudes thoriques, tude
de la concurrence, et, bien sr, les besoins des diffrentes parties
prenantes, en particulier les utilisateurs.
On tablira dans un premier temps la liste des sources possibles dexigences : tableau comprenant les sources dexigences, leur utilit, les
techniques de recueil dexigences, les ressources ncessaires, la charge
de travail relative. Cette liste sera affine et dtaille lors de ltape de
recueil.

61

Livre Constant.indb 61

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

Estimer les charges et les dlais


Comme pour tout projet, lestimation des charges et des dlais est un
exercice difficile, lissue incertaine, mais nanmoins indispensable.
Lacharge dlaboration dpend de plusieurs paramtres:
la facilit de recueil des besoins : les sources dexigences et les
techniques utiliser en fonction des sources et de lobjectif atteindre;
la taille fonctionnelle du logiciel dfinir: nombre de fonctions et leur
importance;
la destination du cahier des charges: choix dun progiciel ou dvelop
pement dun logiciel spcifique;
le niveau de dtail avec lequel on veut dcrire le produit;
la maturit de lquipe de dveloppement;
lhabitude de collaborer entre matrise douvrage et matrise duvre;
lexprience et lhabilet de lassistant matrise douvrage.
Toute la suite de cet ouvrage sattache optimiser le temps et leffort
dlaboration du cahier des charges, en minimisant les risques et en amliorant la qualit.

Identifier les ressources


Un projet dlaboration dun cahier des charges fait appel plusieurs
comptences. Ces diverses comptences peuvent tre runies chez une
seule personne et, dans de nombreux cas, un consultant seul peut animer le projet dlaboration du cahier des charges, en ralisant plusieurs
tches: recueil des besoins, animation des groupes de travail, rdaction
des spcifications, etc. Cependant, pour les projets denvergure, il sera
peut-tre utile de faire appel, mme ponctuellement, des personnes
diffrentes.
Le directeur de la mission, ou directeur de projet, dassistance la matrise
douvrage pour llaboration du cahier des charges. Cest le correspondant unique du client. Il dfinit et gre le projet et anime les interactions
entre acteurs. Sans tre ncessairement un expert du domaine dapplication. Il suit de bout en bout les oprations dlaboration du cahier des
charges et y participe en grande partie.
Lexpert mtier. Cest un consultant expriment ou senior connaissant
le domaine dapplication, lorganisation du client. Souvent un ancien utilisateur, il connat de prfrence les applications concurrentes de celle
dvelopper. Sans tre informaticien, il connat les diteurs de logiciels du
domaine dapplication.

62

Livre Constant.indb 62

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 7 Planifier le projet dlaboration

Un consultant expert en gestion des exigences. Il apporte lquipe


expertise et conseil mthodologique. Il connat les techniques de recueil
des besoins, de modlisation, de reprsentation de linformation.
Un expert technique, qui pourra se prononcer sur les contraintes
techniques.

Identifier et analyser les risques


Une bonne pratique consiste identifier les risques associs llaboration de tous les cahiers des charges et de mettre au point des stratgies
dattnuation. Il ne sagit pas ici daborder les risques inhrents un projet de dveloppement ou lexploitation dun logiciel, mais aux risques
spcifiques llaboration du cahier des charges.
Parmi les risques les plus frquents, citons lindisponibilit de certains
profils utilisateurs pour participer des groupes de travail dexpression
des besoins. Un autre risque est li la non-implication, ou limpli
cation insuffisante, de la matrise douvrage stratgique.

Contenu du plan projet


Le plan projet contiendra au minimum les lments suivants:
description simple du processus global dlaboration;
techniques de recueil mettre en place: interviews, runions, groupes
de travail, maquettes ou prototypes, etc.;
modles de reprsentation de linformation utiliser;
outils utiliser;
liste des documents types utiliser;
liste des sources dexigences;
reprsentants des utilisateurs retenus pour participer aux diffrents
groupes de travail;
formations ventuellement prvues aux techniques et outils;
ressources ncessaires;
charges;
dlais;
risques.

Enregistrement des charges et des dlais


Une organisation qui souhaite industrialiser le processus de dveloppement et de gestion des exigences aura tout intrt tablir et faire
appliquer un suivi du temps pass aux diffrentes activits. Par exemple,

63

Livre Constant.indb 63

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 1 Mthodologie

recueil, analyse, spcification, validation. Ou mieux (car plus proche de


la pratique):
temps pass en runions avec le matre douvrage;
temps pass en groupe de travail;
rdaction et modifications du cahier des charges;
revues de documents.

Check-list
Lobjectif du projet est-il clair, sans ambigut, sans langue de bois?
Latteinte de lobjectif est-elle vrifiable et mesurable?
Latteinte de lobjectif se traduira-t-elle par un bnfice pour lentreprise
ou lorganisation?
Est-on assur que lobjectif pourra tre atteint avec les moyens allous?
Y a-t-il un accord crit sur le primtre du projet?
A-t-on tudi les risques, en termes dimpact et de probabilit, et seston assur quils sont raisonnables?
A-t-on estim les cots et sest-on assur quils sont raisonnables?
Les parties prenantes sont-elles impliques?
Linvestissement prvu est-il justifi?
Sest-on assur quil ne subsiste aucune zone dombre sur le processus
dlaboration du cahier des charges?

64

Livre Constant.indb 64

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

PARTIE

Dveloppement
des exigences
Le projet dlaboration du cahier des charges tant prpar et planifi,
nous abordons maintenant le cur de notre mtier: le dveloppement
des exigences proprement dit. Nous dcrivons les techniques et mthodes
qui vont nous permettre, en partant des objectifs, de valider un cahier des
charges, en optimisant les cots, les dlais et la qualit.
Souvenons-nous cependant que le processus est itratif, et que les rsultats des tapes prparatoires ne sont jamais gravs dans le marbre. La
planification initiale peut tre remise en cause, comme pour tout projet.
Lobjectif et le primtre peuvent varier. Des parties prenantes restes
dans lombre peuvent toujours se manifester. Aussi est-il important, tout
en gardant lobjectif en tte, de rester toujours lcoute des diffrents
acteurs.

Livre Constant.indb 65

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 66

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8

Ltape de recueil

De toutes les activits de lingnierie des exigences, lactivit de recueil


est celle qui demande le plus de qualits humaines. Il faut trouver la
personne qui dtient linformation, lencourager exprimer, puis couter ce quelle a dire, avec neutralit et bienveillance. Il faut animer des
groupes de travail o des tensions entre individus peuvent apparatre.
Raison de plus pour bien prparer cette tape, en laisser le moins de
choses possibles au hasard.

Lenjeu
Capturer les besoins est a priori chose simple et facile. Il suffit de se runir avec les futurs utilisateurs, interviewer le client, ou compulser normes
et standards pour recueillir les besoins la source. La ralit est bien
loin dtre aussi si simple. moins de vouloir faire dvelopper une petite
application simple pour une demi-douzaine dutilisateurs (et encore),
on se trouve vite confront des difficults diverses: rsistances, contradictions, guerres des clans, dissensions.
Mais plus concrtement, demandez un futur utilisateur du systme
dexprimer ses besoins. Posez-lui la question quel est le besoin ? .
Spontanment, il exprimera, selon le cas:
un problme ou une difficult laquelle il est confront;
une solution (plus prcisment sa solution) ce problme;
la manire dont cette solution sera mise en uvre;
un vrai besoin, cest--dire une fonction attendue du futur systme.
Autrement dit, dans la majorit des cas, lutilisateur interview nexprimera pas spontanment un besoin. Quelle est donc la bonne technique
employer pour recueillir les besoins? Comment aider le futur utilisateur

Livre Constant.indb 67

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

sexprimer? Comment viter que les runions de travail ne sternisent,


ou ne se transforment en pugilat verbal? Il ny a pas de recette miracle,
mais des outils et des techniques. Le reste est affaire dexprience et
dhabilet, pour choisir le bon outil et lutiliser bon escient. Voici donc
quelques techniques et outils, ainsi que des conseils dutilisation.

Le processus de recueil
Il ny a pas de plan type de ltape de recueil, avec un enchanement
immuable de tches prdfinies. Les techniques pour recueillir les exigences sont nombreuses et trs varies, et le choix de telle ou telle
technique dpend du contexte, de lexistant et des contraintes: la disponibilit des personnes et leur niveau dexpertise, les documents pouvant
tre consults, la possibilit dobserver sur le terrain les pratiques existantes ou des systmes analogues celui ltude. Mais comme avec les
autres tapes, la planification et la vrification jouent un rle important.
Prparer
grilles et outils

Planifier le
recueil

Slectionner
les techniques

Recueillir les
besoins

Documenter

Vrifier
Analyse

Figure8-1 : Le processus de recueil

Planifier le recueil des besoins


Cest partir de la liste des sources dexigences et du tableau des parties
prenantes que lon va planifier dans le temps le recueil des besoins, et
prvoir les ressources (humaines et matrielles) et la logistique. Cette
planification doit tre souple, car le volume et la qualit des informations
que lon va recueillir ne sont pas prcisment connus lavance.
Rappelons que ltape de recueil, en pratique, nest pas isole des autres.
Lanalyse, la spcification, et une grande partie de la validation des
besoins se droulent en parallle avec le recueil. Cest une raison supplmentaire pour planifier soigneusement les interviews des diffrentes
parties prenantes, et surtout les runions des groupes de travail. Il faut
souvent une semaine pour obtenir un rendez-vous, et plus dun mois pour

68

Livre Constant.indb 68

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

runir un groupe de travail. La lecture des documents est videmment


plus simple planifier, mais peut tre longue.
Et surtout, ne pas oublier de prvoir limprvu. Des runions supplmentaires sont souvent ncessaires pour claircir des points obscurs.

Prparer les grilles et les outils


En fonction des buts viss (dveloppement de logiciel, ou choix dun
progiciel, par exemple), de la granularit atteindre, des personnes
interviewer, on prparera des guides dentretien ou de runion.
Une partie des grilles dinterview ou des thmes des groupes de travail
devra tre formalise et envoye par avance aux participants.
Pour recueillir des besoins partir de documents crits, il est galement
intressant de se munir de grilles de lecture pour viter dtre submerg
par la masse de documents. La quantit dinformations traiter peut
rendre lopration de recueil complexe, en particulier si lon veut garder
la traabilit des exigences aux tapes suivantes.
Le principe de la construction dune grille est simple. Il consiste partir
de lobjectif pour dcouvrir les exigences qui en dcoulent, et des exigences dj exprimes pour dcouvrir les exigences plus dtailles. Nous
verrons plus loin la mise en application de ce principe.

Recueillir et documenter les besoins


Il existe une multitude de techniques de recueil des besoins, plus ou
moins complexes et consommatrices de temps et de ressources. Elles
sont dcrites dans la suite de ce chapitre.
Quelle que soit la technique choisie, linformation recueillie doit tre
soigneusement rpertorie et stocke en vue dune analyse et dune
spcification ultrieures. Cela est vrai mme si recueil, analyse et spcification ont lieu au cours dune mme runion dun groupe de travail.
Une des difficults dcoule de la surabondance des informations
recueillies, et ce, quelle que soit la technique de recueil. Pour viter de se
noyer sous un flot de paroles ou sous des milliers de pages, il ny a pas de
recette miracle, mais un principe: travailler partir de grilles en gardant
en tte lobjectif.

Vrifier les informations recueillies


On vrifiera lexactitude des informations recueillies au moyen dun
compte-rendu de runion ou dinterview. Il ne sagit pas ici de valider
les exigences, mais dobtenir un feedback sur les informations recueillies.
Cela permettra de corriger les informations au plus prs de la source.

69

Livre Constant.indb 69

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Si le recueil des besoins est fait par une quipe (cest souvent le cas), il
faut prvoir de faire le point pour changer sur les informations recueillies.

Le plan de recueil
Le plan de recueil servira de guide tout au long de ltape de recueil des
besoins. Il contient:
Les objectifs du recueil : en particulier, il est important de savoir sil
sagit de recueillir des exigences haut niveau, ou de descendre dans les
dtails, ou de consolider des exigences dj formalises.
Les livrables et leur forme, ainsi que leur niveau de formalisme ; cela
peut aller dune simple note sous forme textuelle, jusqu des modles
de donnes strictement formaliss.
Les mthodes et techniques de recueil, qui peuvent varier selon les
objectifs, les livrables et les interlocuteurs.
Les risques induits, et les mthodes de contournement et dattnuation
des risques.
La planification du recueil: cots, dates, dlais et ressources.

Risques lis au recueil et attnuation


Les risques lis au recueil proviennent des sources de besoins, plus ou
moins disponibles et fiables, ainsi que de la manire dont ses besoins
sont exprims.
Le premier facteur de risque est lindisponibilit des sources, quil sagisse
de documents auxquels on ne peut accder (dtruits, perdus, corrompus,
confidentiels) ou de personnes qui ne sont pas ou trop peu disponibles.
Les informations errones, intentionnellement ou non, sont un deuxime
facteur de risque. Les interlocuteurs se servent souvent dune tude des
besoins pour servir leurs intrts propres, et non les objectifs viss par le
systme construire. Pour viter ce pige, il faut, dune part, sappuyer sur
les objectifs pralablement formaliss et, dautre part, croiser les sources.
En troisime lieu viennent les besoins non exprims, ou exprims de
manire floue. Cest pour cette raison quil est utile dutiliser les comptences dun expert mtier, qui matrise le vocabulaire de ses interlocuteurs.
De plus, il est indispensable, pour recueillir des besoins oprationnels,
de descendre au plus bas niveau hirarchique possible, de consulter de
vrais utilisateurs, et ne pas se contenter des seuls reprsentants des
utilisateurs.

70

Livre Constant.indb 70

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

Un autre facteur de risque provient de la difficult de se faire une ide


densemble dun besoin. Interroger un seul utilisateur apportera une
image dforme du besoin, et trop peu dinformations sur les pratiques
quotidiennes. Inversement, avec trop de sources, trop dinterlocuteurs, il
est difficile de grer les contradictions sur le fond et sur la forme. Chercher savoir qui a raison pousse descendre dans les dtails, et cest
l un risque supplmentaire.
Recueillir des besoins trop ou insuffisamment dtaills, par rapport aux
objectifs du cahier des charges, est encore un risque. Cest pour cela quil
est indispensable de connatre par avance les objectifs et le niveau de
dtail recherch. Des techniques de recueil, que nous verrons plus loin,
permettent dlever le niveau, ou au contraire, de descendre plus dans le
dtail.

Dtermination des profils utilisateurs


Aprs le donneur dordres, qui a exprim lobjectif, les parties prenantes
qui seront les plus impliques sur le plan oprationnel dans le recueil des
exigences sont les futurs utilisateurs du systme.

La typologie des profils


Pour mener bien le recueil, il est ncessaire de dterminer les profils des
utilisateurs, et de les classer en catgories, de manire pouvoir, par la
suite, dterminer les besoins par catgorie dutilisateurs. Il y a plusieurs
faons dtablir les profils utilisateurs, en fonction de leur mtier, de leur
position hirarchique ou de leur emplacement gographique. Cependant,
le plus efficace est de les grouper en fonction de leur interaction avec le
systme. Ce qui nous intresse ici nest pas lindividu, mais son rle vis-vis du systme, sachant quun individu peut jouer plusieurs rles (par
exemple, dans un restaurant, prendre les commandes et soccuper de la
comptabilit) et donc avoir plusieurs profils.
Les profils utilisateurs seront constitus en fonction:
des fonctions du systme auxquelles ils font appel;
du niveau de scurit requis pour accder certaines fonctions;
de leurs propres exigences de scurit, de fiabilit ou dergonomie;
de leur frquence dutilisation du systme;
de leur pratique de systmes analogues;
de leur connaissance du domaine.

71

Livre Constant.indb 71

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Un exemple
Un centre hospitalier a besoin de choisir et de mettre en uvre un systme
de gestion du mdicament. Les profils utilisateurs suivants ont t dfinis:
prescripteur: mdecin, sage-femme, ou toute autre personne amene
prescrire des mdicaments;
pharmacien;
prparateur en pharmacie;
infirmier;
gestionnaire du systme.
Il ny a videmment pas une correspondance biunivoque entre un groupe
de personnes et un profil utilisateur. Le profil prescripteur peut tre
attribu deux personnes de mtiers trs diffrents (par exemple, un
mdecin et une sage-femme). Inversement, le pharmacien dun hpital
peut, dans certains cas, tenir le rle de gestionnaire du systme.
Le tableau 8-1 des profils reprend, de manire plus dtaille, le tableau
des parties prenantes qui a t labor lors de ltape prparatoire.
Ilpourra tre encore enrichi au fil de leau lors de ltape de recueil.
Tableau 8-1 Grille des utilisateurs
Fonctions
utilises
Mdecin

Prescription

Exigences
particulires
Facilit dapprentissage

Frquence

Pratique

Quotidienne

Assez importante

Pharmacien

Validation pharmaceutique

Quotidienne

Trs importante

Prparateur

Saisie de la
dispensation du
mdicament

Quotidienne

Faible

Infirmier

Saisie de ladministration du
mdicament

Quotidienne

Faible

gestionnaire

Tablette mobile

Paramtrage

Mensuelle

Recherche des sources dexigences


Les parties prenantes, et en particulier les futurs utilisateurs, sont
la premire source dexigence. Tous nont pas le mme domaine de

72

Livre Constant.indb 72

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

c omptences, ni le mme niveau dexpertise. Le tableau des parties prenantes va nouveau nous permettre de trouver les personnes-ressources,
mais cette fois il devra tre utilis pour laborer un tableau nominatif.
Toutes les personnes dun mme profil nont pas le mme niveau dexpertise, ni la mme facilit dexpression. Attention cependant: les opposants
au projet ont parfois autant dinformations utiles nous apporter que les
plus moteurs. Il faudra les inviter sexprimer, en runion ou en interview,
et les couter avec bienveillance.
Les articles, tudes comparatives, tudes de march, forums sur Internet
constituent galement une bonne source. Ces informations ne sont pas
toujours fiables, ni toujours jour. Il faudra donc croiser les informations
entre elles, et avec des sources plus sres.
Les cahiers des charges existants contiennent souvent des exigences qui
peuvent tre reprises, aprs ventuelle mise niveau. Si le cahier des
charges est bien fait, la reprise peut tre trs simple.
On peut remonter au cahier des charges partir de spcifications fonctionnelles gnrales ou dtailles dun logiciel existant (voire dun logiciel
qui na jamais vu le jour), ou directement en observant le comportement
du produit.
Les sous-produits sont galement une mine dinformations pouvant
tre rutilises, aprs analyse, pour laborer les exigences: fiches danomalie, rapports dessais, rapports au help-desk en particulier, les fiches
danomalie sont trs utiles pour recueillir des exigences ngatives ou,
pour formuler les choses plus positivement, des exigences damlioration
de lexistant. Il en est de mme des rapports daudit, des fiches de rclamations, et des demandes de modification, pour examiner ce qui peut
tre amlior et ce qui manque.
Les normes, qui constituent elles seules un recueil dexigences, sont
videmment une source fiable. Il est ncessaire de faire attention la
date de publication, de sassurer pour chaque norme quelle sapplique
au contexte du systme ltude. Il est noter que les normes ne sont pas
toujours compatibles entre elles, ni cohrentes sur le vocabulaire.
Enfin, la documentation dun logiciel existant ( remplacer), ou celle des
concurrents sont des sources ne pas ngliger.

Techniques de recueil
La capture des exigences ncessite une bonne dose de crativit. On
entend par l la crativit oprationnelle, et non artistique. Celle dun
commandant dunit sur le thtre des oprations. condition dtre

73

Livre Constant.indb 73

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

orient vers lobjectif et de respecter la doctrine, vous avez le droit, et


mme le devoir, dtre inventif et dimproviser.
Il en est de mme pour la capture des exigences. Tant que vous avez
lobjectif en vue, que vous respectez les bonnes pratiques, que vous vous
en tenez votre lettre de mission, vous avez la libert dutiliser toutes les
techniques connues de recueil des besoins, et den inventer dautres si
ncessaire. Les techniques doivent tre adaptes aux personnes et aux
circonstances. Ainsi, rien ne vous empche dorganiser un brainstorming
avec certains utilisateurs et des interviews individuelles avec dautres.
Lorsquil sagit de choisir outils et techniques, cest lexprience et lintuition
qui doivent servir de guides, et non les procdures.
Il ny a pas en la matire de recette miracle. Mais il y a des techniques.
Le reste est une affaire dexprience, pour choisir la bonne technique et
lutiliser au bon moment. On trouvera dans les paragraphes qui suivent
quelques techniques qui ont fait leurs preuves, commencer par les plus
classiques, ainsi que leur mode dutilisation.

Lanalyse de documents
Utilit de la technique
Lanalyse de documents est un des moyens les plus directs de recueillir
des exigences. Les documents existants constituent une des principales
sources disponibles dexigences, dont certaines sont pour ainsi dire
prtes lemploi. La difficult provient en gnral de labondance des
documents, quil faut soigneusement trier, et dont il faudra filtrer linformation utile.
Utiliser des informations prexistantes permettra de rduire le nombre
et la dure des interviews et runions, mais pas de les supprimer. Elle
permettra galement dacqurir des connaissances sur le domaine
dapplication, les interviews ultrieures tant un moyen daffiner et de
consolider ces connaissances. Cela vitera aussi de perdre la face en
posant des questions dont on peut trouver la rponse dans des documents disponibles.

Les sources
Les sources sont en gnral abondantes (voire surabondantes):
cahiers des charges et spcifications de produits similaires ou concurrents, de versions antrieures du systme ltude;
normes: sources de rgles de gestion et de contraintes techniques;

74

Livre Constant.indb 74

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

procdures, descriptions partielles de processus mtier;


documents de travail, comptes-rendus de runions: sources de besoins,
contraintes, frustrations des utilisateurs, priorits;
documentation technique: source de contraintes;
documentation conceptuelle ou thorique, source de spcifications
innovantes;
formulaires papier: trs utiles pour connatre les informations saisir,
celles devant apparatre dans un document de sortie;
fiches danomalie, demandes de modifications.

Mode opratoire
Le mode opratoire est le suivant:
1. Commencer par lister les documents existants relatifs au domaine
et/ou au systme ltude.
2. Passer les documents rapidement en revue, de prfrence en quipe,
et noter leur contenu et leur utilit.
3. Faire examiner les documents par un ou plusieurs experts, en fonction
de leur contenu et de lapptence des experts pour la question.
4. Trier les documents : dcider des documents reprendre en ltat,
ceux retravailler, des parties de documents extraire et conserver.
5. Ds que possible, valider la pertinence, la cohrence, la fracheur
des informations fournies.
6. Maintenir un tableau de la documentation existante.

La runion dun groupe de travail


Utilit et difficult
La mthode naturelle, qui consiste runir des volontaires des diffrentes parties prenantes et leur demander dexprimer les besoins, est
aussi la moins efficace. Ainsi, en runissant vingt personnes de mtiers
trs diffrents, en mlangeant utilisateurs, donneurs dordres, matres
douvrage, et autres parties intresses, on risque de ne recueillir que
peu dinformations, et trs peu dexigences exploitables. Dune part, par
ce quau-del de dix ou douze participants, une grande partie dentre eux
sera inactive et risquera mme de perturber les autres, et dautre part, par
ce quil est difficile de dfricher le terrain, dcouter tous les besoins, et
dobtenir un consensus dans un milieu trop htrogne.

75

Livre Constant.indb 75

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Les groupes de travail organiss

1. Dans Requirements
by collaboration,
Ellen Gottesdiener
donne de nombreuses
techniques et
mthodes de recueil
par ateliers de travail.

Une mthode des plus efficaces consiste runir les parties prenantes
par profil : une premire runion avec le matre douvrage stratgique,
puis une runion avec des reprsentants des utilisateurs dun mtier, puis
dun autre mtier. Une fois que les besoins des diffrents contributeurs
seront recueillis, on programmera une runion mixte avec le repr
sentant de chaque mtier ou profil utilisateur.
De tels ateliers1 peuvent galement runir matrise douvrage et matrise
duvre, ou utilisateurs et dveloppeurs, dans un mme lieu.
Lanimation de ces ateliers de travail, qui peuvent durer plusieurs jours,
nest pas chose aise. Au moins deux animateurs sont ncessaires: lanalyste ou assistant la matrise douvrage, et une personne charge de
prendre des notes et de les organiser.
Les ateliers sont sans doute le moyen le plus puissant de recueillir les
besoins, mais ils demandent un important travail de prparation, de la
part de tous les participants, mais surtout de la part de lanimateur. De
plus, certaines rgles doivent imprativement tre respectes:
choisir avec soin un nombre limit de participants (quatre cinq, plus
les animateurs);
faire respecter une bonne discipline de travail tous les participants:
arriver lheure, teindre son tlphone mobile, viter toute conversation
en apart, respecter les divers avis;
rester align avec les objectifs tels quils ont t formaliss;
maintenir la discussion au bon niveau de dtail : viter de descendre
trop dans les dtails, ou au contraire de remettre en cause les objectifs;
si de nouvelles ides apparaissent et semblent intressantes, viter de
dvier, mais conserver ces ides part, de manire y revenir plus tard,
lors dun autre atelier par exemple;
fixer un ordre du jour prcis, avec une dure prcise pour chaque point,
et sy tenir;
maintenir jusquau bout lenthousiasme du dbut.

Linterview structure individuelle


Utilit et technique dinterview
Cette technique est utile, voire indispensable, pour connatre les besoins
individuels des utilisateurs. Elle se focalise sur une partie du processus,
en particulier celle dont lutilisateur est expert ou praticien (mais pas

76

Livre Constant.indb 76

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

seulement). La difficult est de trouver le bon chantillon dutilisateurs,


et de poser les questions adquates en fonction des objectifs atteindre.
Linterview structure permet gnralement de recueillir ou de prciser
des besoins dont les utilisateurs sont conscients. Ce point est noter, car
dautres techniques, comme le brainstorming, lobservation directe, et
dans une large mesure les ateliers de travail, permettent de faire merger
des besoins bien rels dont les utilisateurs nont pas conscience.

Droulement de linterview
Les tapes dune interview sont les suivantes:
1. Prparation. La prparation est indispensable une interview efficace. Elle sera dautant plus longue et importante que lintervieweur
sera novice dans cette technique et son expertise loigne du domaine
dapplication.
Collecte et lecture de documents, relecture des interviews prcdentes, de lexistant, du contexte.
Prparation des questions: questions gnriques, questions gnrales de contexte, questions prcises linterview, questions de
complment dautres interviews.
Planification de linterview et ordonnancement des questions. Une
interview dure environ une heure, maximum une heure et demie.
Les questions doivent apparatre comme une suite logique, allant
du gnral au particulier.
2. Interview sur le terrain, de prfrence prs du lieu de travail de linterview (il sera plus laise), mais pas directement sur son lieu de travail
(il risque dtre interrompu).
Ouverture de linterview: lintervieweur se prsente, rappelle lobjectif et du temps dont on dispose.
Questionnement : lintervieweur pose la question de la grille et
note la rponse. Il reformule si ncessaire et fait prciser les points
qui ne lui paraissent pas clairs. Lopration est rpte jusqu ce
que linterview accepte la reformulation de lintervieweur.
Clture: linterviewer rappelle les points principaux, relit les besoins
tels que formuls par crit et indique sil y aura un compte-rendu et
si ce compte-rendu devra tre formellement valid.
3. Finalisation. Lintervieweur relit ses notes, structure les informations
et rdige le compte-rendu. Il envoie le compte-rendu linterview
pour validation. Ce dernier peut faire ses remarques. Lintervieweur
peut complter linterview en posant des questions supplmentaires,
souvent par tlphone.

77

Livre Constant.indb 77

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Poser des questions efficacement


Linterview contient en modle rduit les quatre tapes du dveloppement des exigences. Et dans le cadre dune interview, chaque question
pose est elle-mme un microprocessus recueil-analyse-spcificationvalidation:
Recueil: lintervieweur pose une question et recueille de linformation.
Analyse: en sance ou froid, lintervieweur cherche prioriser les
rponses et cherche les incohrences. Il peut, en sance, dessiner des
diagrammes pour sassurer que lui et son interlocuteur ont compris la
mme chose.
Spcification: en sance, lintervieweur reformule la rponse ou pose
des questions supplmentaires pour obtenir une exigence bien formule le plus en amont possible. froid, il rdige le compte-rendu dinterview avec prcision.
Validation: en sance, lintervieweur cherche associer chaque exigence des critres dvaluation. Par la suite, il demandera linterview
de valider le compte-rendu.
Cette approche consistant considrer chaque activit et chaque tche
comme un cycle contenant toutes les autres tapes est trs efficace.
Lide est de dcouvrir le plus tt possible les incohrences, incompltudes et insuffisances des exigences, tant dans leur formulation que dans
leur structure.

Les types de questions


Une grille dinterview, prpare lavance, est utile. Elle contient des questions types poser. Les questions ouvertes permettent de comprendre
le contexte de travail, et les besoins immdiats. Ce sont des questions
en comment. Par exemple, comment faites-vous actuellement pour
enregistrer une demande de prt?.
Les questions en quoi permettent de drouler un processus: une
fois que vous avez fini cette action, que faites-vous?. Et ainsi de suite.
Cette manire de procder permet de recueillir les exigences du mme
niveau appartenant une squence.
Les questions en comment permettent dapporter plus de dtails :
concrtement, comment faites-vous ? . Ce type de question permet
donc de descendre des exigences de haut niveau aux exigences oprationnelles.
Inversement, la question pourquoi est utile pour prendre de la hauteur
(figure8-2).

78

Livre Constant.indb 78

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

Objectifs
Pourquoi
N ?
Qui ?
W
Quoi ?

O ?
E
Quand ?
S
Comment
?

Exigences lmentaires

Figure8-2 : Navigation entre niveaux dexigences

Il est possible denchaner les pourquoi pour remonter au niveau de


besoin adquat par rapport lobjectif fix. Voici une squence dinterview
en pourquoi:
Il nous faut une case cocher membre du conseil (expression dune
solution en termes dinterface utilisateur, beaucoup trop bas).
Question
Pourquoi une case cocher?
Rponse
On doit pouvoir indiquer au systme quun de nos adhrents est
membre du conseil dorientation (il sagit l dune exigence fonctionnelle, correctement formule, mais sans doute encore de trop bas
niveau).
Question
Pourquoi doit-on pouvoir indiquer cela au systme?
Rponse
tout moment, un utilisateur qui interroge le dossier dun adhrent
doit savoir sil sagit dun membre du conseil dorientation.
En posant deux questions pourquoi?2, on a ainsi trouv une exigence
globale, qui est un invariant du systme construire. Cela va sans dire,
une exigence formule de cette manire pose les bases dun logiciel
mieux construit et plus maintenable. Lexigence peut tre spcifie dans
le cahier des charges:

2. Exercice: poser
encore deux questions en pourquoi
pour remonter
jusqu un objectif.

tout moment, au cours dune consultation, le systme doit


donner lutilisateur la possibilit de savoir si un adhrent
est membre du conseil dadministration.

79

Livre Constant.indb 79

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

En revanche, la question pourquoi pose titre personnel est proscrire, car elle peut tre ressentie comme une agression. La premire
question de lexemple prcdent devient, en caricaturant mais pourquoi voulez-vous tout prix cliquer sur cette case?. Mme sans aller
jusque-l, une question pourquoi impliquant la personne interviewe
doit tre vite.
Le secret des sept secondes
Parfois, au dtour dune interview, on a la surprise dentendre notre interlocuteur
noncer trs clairement une exigence parfaitement bien formule. Lanalyste na
plus rien faire qu la noter verbatim et linsrer, sans aucune reformulation, dans
le cahier des charges. Cest l une surprise agrable qui a quelque chose de presque
magique.
Que sest-il pass? Si notre interlocuteur formule un besoin avec autant de clart et
de prcision, cest trs probablement quil y a longuement rflchi avant, et la examin sous toutes les coutures. En dautres termes, notre interlocuteur a lui-mme
jou le rle de lanalyste tout en tant un expert du mtier avec les ides claires et
un bon esprit de synthse.
Existe-t-il une technique pour augmenter ses chances davoir des spcifications
spontanes de la part dun interlocuteur? La rponse est oui, la technique est
simplissime sur le principe, mais difficile mettre en pratique. Il suffit dcouter
avec beaucoup dattention, y compris, et surtout, les silences. Lorsque linterview
est en confiance, dans un environnement calme, quil nest pas stress par le temps,
le silence est la meilleure raction de la part de lintervieweur.
Lorsque votre interlocuteur a fini de parler, laissez-lui encore sept secondes, au
moins, avant de reprendre la parole. Sept secondes dcoute du silence, cest l le
secret des meilleurs intervieweurs. Cest aussi le meilleur investissement que peut
faire un analyste. Et surtout, un des moments les plus gratifiants de ce mtier.

De louverture la prcision
Un des secrets de lefficacit du processus de dveloppement des
exigences rside dans la capacit faire passer les besoins par un
entonnoir, cest--dire un tuyau trs large une extrmit et trs troit
lautre. Cela se voit au niveau du macroprocessus: ltape de recueil est
ouverte, et autorise lexpression des besoins sous une forme large, peu
prcise. lautre bout du tuyau, la validation ne laisse passer que des exigences extrmement prcises. Entre les deux, les phases danalyse, puis
de validation, resserrent progressivement la prcision.
Mais lentonnoir peut aussi tre appliqu au niveau du microprocessus.
Une question peut tre pose de manire trs ouverte, puis resserre par
reformulations progressives. Et un des moyens pour y arriver consiste
filtrer les gnralisations, les distorsions et les omissions.

80

Livre Constant.indb 80

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

Les gnralisations
On les dtecte de deux faons.
Par lemploi de quantificateurs universels (tous, toujours, jamais, personne, chaque fois, etc.). Le travail de lanalyste consiste reformuler en
encourageant la prcision. Par exemple:
Interview (utilisateur)
Dans cet tablissement, tout le personnel a accs lapplication par
un identifiant et un mot de passe.
Analyste
Tout le personnel?
Interview (utilisateur)
Enfin, non, pas tous. Le personnel de lentretien des locaux et les intrimaires ny ont pas accs.
Une autre catgorie de gnralisations se manifeste par les oprateurs
modaux (il faut, on doit, etc.) L aussi, cest loccasion de prciser les
besoins, ou de dtecter une faille dans le processus:
Interview (utilisateur)
son embauche, un employ doit sinscrire auprs du service informatique pour obtenir un code daccs.
Analyste
Que se passe-t-il sil ne le fait pas?
Interview (utilisateur)
Eh bien, dans ce cas, il ne pourra pas accder au systme.
La dtection et le traitement des gnralisations sont un bon moyen de
trouver ce qui, dans un cas dutilisation, sappelle le scnario alternatif, ou
les exceptions.

Les omissions
Les omissions passent sous silence une partie de linformation. On trouve
dans cette catgorie:
Les omissions simples
Interview (utilisateur)
Je traite le dossier.
Analyste
Quel dossier? (ou: en quoi consiste le traitement du dossier?)
Les omissions par comparaison
Interview (utilisateur)
Cette application est plus rapide.
Analyste
Plus rapide que quoi?

81

Livre Constant.indb 81

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Interview (utilisateur)
Plus rapide que lapplication X du service Y.
Les omissions par manque dindex de rfrence qui omettent lacteur
Interview (utilisateur)
On accde au systme par un code daccs temporaire.
Analyste
Qui accde par un code temporaire?
Interview (utilisateur)
Les intrimaires et les sous-traitants.
Le traitement des omissions permet de recueillir plus dinformations
quune reformulation simple. Il amliore la prcision et la compltude
des informations recueillies sans attendre la phase danalyse ou de spcifications.

Les distorsions
Enfin les distorsions:
La divination
Interview (utilisateur)
Les secrtaires ne sont pas satisfaites de cette application.
Analyste
Comment cela se manifeste-t-il?
La rponse cette question va peut-tre permettre de comprendre si
les secrtaires sont vritablement insatisfaites de lapplication ou si le
problme est ailleurs.
Le lien de cause effet
Interview (utilisateur)
Le logiciel nest pas utilis, il manque dergonomie.
Analyste
Est-ce vraiment le manque dergonomie qui freine ladoption du logiciel?
Une manire moins abrupte de reformuler la question est de rebondir:
En dehors de lergonomie, que manque-t-il ce logiciel?
Dtecter les distorsions permet gnralement daugmenter la prcision
de la formulation du besoin.

Attention aux effets inattendus


Demander un peu plus de prcision de la part de son interlocuteur est un
bon moyen danticiper, lorsque cela est possible, sur les phases danalyse

82

Livre Constant.indb 82

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

et de spcification3. Plus on anticipe au moment de linterview, plus on


capte dinformations prcises, et plus on limine rapidement les ambiguts, imprcisions, et incompltudes. La recherche de la prcision est un
investissement rentable, car une accumulation dimprcisions et dincohrences cote beaucoup plus cher dtecter et liminer aprs coup.
Cependant, une interview nest pas un interrogatoire de police. Il faut
faire attention ne pas forcer linterlocuteur. Il a le droit dtre imprcis, et mme incohrent. Et surtout, il a le droit davoir son jargon. Cest
lanalyste de sadapter. Il faut donc tre prudent, surtout au dbut de
llaboration du cahier des charges, surtout au dbut dune interview.
En tout tat de cause, il est inutile de rechercher la prcision si cela va
jusqu nerver notre interlocuteur. Mieux vaut patienter, rechercher les
informations une autre source, que de risquer de bloquer le processus.

3. Lors de la phase
de spcification
et de validation,
les imprcisions et
incohrences seront
dtectes au moyen
de check-lists.

Le brainstorming
Technique crative, le brainstorming est surtout utile pour le dveloppement dun nouveau produit, lorsquil sagit de faire jaillir de nouvelles
ides.
Une sance brainstorming bien mene permet de recueillir des exigences
dont les utilisateurs ne sont pas conscients.
Cette technique permet aussi de sattaquer4 un problme qui sort des
catgories habituelles. Cest le cas dun projet qui fait lobjet de trs nombreuses contraintes. Dans un tel cas, une nouvelle ide originale permet
de rsoudre ces contraintes en sortant du cadre habituel de rflexion.
Le brainstorming peut galement savrer utile lorsque matrise douvrage
et matrise duvre sont en conflit (larv ou ouvert) et que les diffrents
intervenants de la matrise douvrage nont pas une ide trs claire de ce
quils souhaitent. Recueillir les diffrentes fonctions ou contraintes sur
des Post-It et les taler sur un mur ou un tableau peut permettre de
clarifier la situation.
Une telle sance de brainstorming peut tre suivie dun diagramme des
affinits ou dune maquette papier.

4. Brainstorming.
Terme invent par
Alex Osborne de
brain, (cerveau), et
to storm, (attaquer,
assaillir). Il ne sagit
donc pas dune
tempte dans un
cerveau, mais de
sattaquer mentalement, collectivement,
une difficult.

Le diagramme des affinits


La mthode du diagramme des affinits est utile lorsquil sagit de faire
le tour de la question, den voir les diffrents aspects, et de les classer
par catgories. Les tapes de la mthode sont les suivantes:
Lanimateur expose le problme aussi clairement que possible.

83

Livre Constant.indb 83

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Chaque participant crit une ou plusieurs rponses au problme, chacune


delle sur une fiche (par exemple, une fiche adhsive de type Post-It).
Lanimateur ramasse les rponses et les expose lensemble des parti
cipants. Il tale les fiches sur une table ou les colle sur un mur.
Les participants regroupent les fiches par catgories, sans avoir se justifier; un participant peut dplacer une fiche dune catgorie une autre.
Le regroupement en catgories continue, jusqu obtention dun consensus.
On peut crer des sous-catgories.
Les participants donnent un nom chaque catgorie et sous-catgorie.
Plusieurs variantes cette technique existent, en fonction du type de problme traiter. Elle est surtout utile lors des premires tapes de recueil
et danalyse des besoins, par exemple, pour connatre les parties prenantes ou pour dterminer les grandes fonctions attendues du systme
(figure8-3).
Administrer
des
mdicaments

Prescrire des
mdicaments
Rdiger la
prescription

Signer la
prescription

Lire la
prescription

Consulter le
dossier du
patient
Rpondre
lavis pharmaceutique

Analyser la
prescription

Donner un
avis pharmaceutique

Valider l
administration

Prparer les
doses

Grer les
stocks de
mdicaments

Figure8-3 : Diagramme des affinits

Lobservation directe
Observer un utilisateur sur le lieu de son travail est souvent le moyen le
plus simple de connatre ses besoins. Cest aussi un moyen de connatre
ses difficults et les problmes quil rencontre (avec le logiciel actuel ou en
labsence de logiciel) de manire formuler des exigences qui aboutiront
un produit bien adapt leurs besoins.

84

Livre Constant.indb 84

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

Certains utilisateurs (ou futurs utilisateurs) sont capables de modliser


eux-mmes leur travail, cest--dire dcrire la succession des tches qui le
constituent. Dautres sont beaucoup plus laise lorsquils sont dans laction. Lobservation peut tre neutre, distance, lobservateur se faisant le
plus discret possible. Elle peut tre plus intrusive, lobservateur posant
lutilisateur des questions sur la manire dont il sy prend.
Cette technique a ses limites. Elle permet de recueillir les besoins
oprationnels pour des oprations visibles, les oprations intellectuelles
tant difficilement observables et analysables de lextrieur. Avec cette
technique, on ne pourra dcrire les besoins gnriques ou de haut niveau
quaprs analyse de nombreuses observations.

Les questionnaires
Le questionnaire est un moyen facile de recueillir des opinions ou des
donnes de la part dun grand nombre de personnes. Cependant, cette
technique nencourage pas la crativit et lmergence de nouvelles
ides.
La technique la plus courante consiste utiliser une chelle de Likert.
Les catgories de rponses, sur une chelle comportant quatre sept
niveaux, sont formules de manire ce que leur signification soit claire
pour tout le groupe de personnes interroges.
Les questions fermes (cases cocher) facilitent lanalyse. Mais llaboration de telles questions est loin dtre un exercice facile. Les questions
doivent tre trs claires, spcifiques, neutres (ne pas induire la rponse)
et formules avec le vocabulaire de celui qui rpond. Il est possible
dajouter quelques questions ouvertes lorsque le questionnaire sadresse
un petit nombre de personnes.
Pour laborer le questionnaire, les questions se poser sont:
Quel est lobjectif du questionnaire? Que veut-on savoir prcisment?
Comment cette information peut-elle tre fournie?
Quel est le degr de prcision recherch?
Quel est le nombre de questions poser pour avoir les informations
recherches?
Combien de questions est-il raliste de poser?
Qui va exploiter les rponses et comment?

85

Livre Constant.indb 85

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

La rutilisation dexigences
Un cahier des charges dun autre logiciel, ou dune version prcdente
du mme logiciel, peut contenir des exigences rutilisables. Souvent, le
recueil consiste alors simplement reprendre les exigences, ventuellement en mettant jour le vocabulaire. On vrifiera sa compatibilit avec
les autres exigences, pour viter redondances et incohrences.

Lanalyse de produits existants


dfaut de cahier des charges existant, on peut examiner un logiciel dj
en production. Il sera trs riche en enseignements.
Il est bien entendu possible dexaminer un produit dj en production, qui
arrive en fin de vie, que lon souhaite remplacer ou redvelopper. Lanalyse dun produit existant permet dans ce cas de dcouvrir des exigences
implicites, des fonctions utilises au quotidien, mais dont les utilisateurs
nont pas conscience.
On peut galement analyser un produit concurrent de celui que lon souhaite dvelopper ou faire dvelopper. Si la loi interdit de dcompiler
un logiciel, rien ninterdit en revanche de lanalyser sur le plan comportemental. ce propos, un diteur dun logiciel pourtant pointu qui
on disait que son produit tait le meilleur du march a rpondu quil
avait achet, install et test tous les produits de la concurrence. Cela
ne lempchait pas de proposer des fonctions innovantes introuvables
ailleurs.

Rechercher linformation l o elle se trouve


Nous avons vu quil y a diffrents niveaux dexigences. chaque niveau,
les exigences seront recueillies auprs dun interlocuteur diffrent, avec
des techniques diffrentes.
Le donneur dordres va apporter les exigences du plus haut niveau, cest-dire les objectifs. On utilisera linterview structure, ou les runions en
petit comit. Les techniques comme le brainstorming ou le diagramme
des affinits peuvent tre trs utiles, mais rarement possibles dans la
pratique. Les objectifs doivent tre recueillis le plus souvent chez des
dirigeants ou les cadres suprieurs, et il est difficile de runir tous ces
dcideurs pendant une heure trente sur le thme brainstorming. Linterview face face est la technique la plus indique dans ce cas.

86

Livre Constant.indb 86

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

Pour recueillir les besoins des utilisateurs, les groupes de travail dune
journe intervalles de deux ou trois semaines, programms longtemps
lavance, sont les plus efficaces.
Lobservation directe, sur site, est consommatrice de temps pour lanalyste. Si celui-ci est habile et discret, un grand nombre dobservations
peuvent tre faites avec un minimum de perturbation des utilisateurs au
travail. Lobservation directe alterne avec les groupes de travail est trs
utile, lune permettant de valider lautre.

Interview individuelle

Objectifs
DG
Exigences
dentreprise

Runions
Matrise douvrage

Rgles de gestion,
Contraintes
techniques
Experts techniques
Exigences
utilisateur

Experts mtier

Groupes de travail utilisateurs

Interviews,
runions
Questionnaires,
interviews,
runions,

Figure8-4 : Recueillir lexigence au bon niveau

Les bonnes pratiques


Que ce soit au cours dune interview ou lors dune runion de travail, un
certain nombre de bonnes pratiques doit tre respect si lon veut travailler
efficacement.

Recueillir les besoins au bon niveau


Comme nous lavons vu, les exigences devront tre recueillies auprs des
interlocuteurs idoines. On recueille les objectifs (exigences du niveau
le plus lev) auprs de la direction gnrale, les exigences les plus
dtailles auprs des utilisateurs sur le terrain.
Ce principe gnral pose la question de lordre dans lequel seront
menes les interviews. Apriori, lordre idal est celui qui consiste partir
des objectifs (donc du matre douvrage stratgique), puis descendre
progressivement vers plus de dtails jusquaux utilisateurs les plus oprationnels. Outre le fait que cela nest pas toujours possible, cela pose
dautres difficults: si lon veut viter de poser au directeur gnral des
questions dont la rponse est facile trouver auprs des oprationnels

87

Livre Constant.indb 87

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

(mais apriori inconnue de lintervieweur), il faudrait les avoir interviews


avant.

Apporter un retour rapide aux interlocuteurs

5. Une astuce: utiliser le mode rvision


dun traitement de
texte (si on matrise
cette technique),
ou utiliser des paragraphes de couleurs
diffrentes pour
visualiser les modifications nouvellement
intgres.

Suite un entretien ou une runion de recueil, il est utile de rdiger un


compte-rendu. Cest une bonne pratique bien connue, et galement une
marque de courtoisie lgard de ses interlocuteurs. Rdiger un compterendu dtaill et prcis prsente aussi quelques inconvnients car cela
prend du temps qui pourrait souvent mieux tre utilis; on se retrouve
avec un grand nombre de comptes-rendus, qui constituent une documentation lourde grer.
Une manire plus efficace de procder consiste :
lors dune interview ou runion, donner aux interlocuteurs un feedback
immdiatement aprs lexpression dun besoin;
suite une interview ou une runion, utiliser le cahier des charges luimme comme compte-rendu.
Trs concrtement, au cours du recueil, il est utile de donner un retour
direct (un feedback) ses interlocuteurs, sous forme de reformulation de
ce qui vient dtre dit, ventuellement en utilisant un moyen de communication diffrent, par exemple un schma. Cela rassure les interlocuteurs
et vite de partir dans une fausse direction.
Puis, suite lentrevue ou la runion, on intgrera ce qui a t formul
dans le cahier des charges, et on le soumettra la validation5 des participants. Attention: il ne sagit en aucun cas de court-circuiter les tapes
danalyse et de spcification, mais de faire une analyse partielle et une
spcification des besoins qui ont t formuls lors de la runion.

Parler le langage du client


De manire gnrale, si on veut faciliter la communication, il faut
apprendre et utiliser le langage du matre douvrage plutt que de forcer
ce dernier utiliser notre jargon technique.
Par langage, on entend bien sr le vocabulaire, mais galement la
manire de reprsenter linformation. Un juriste a lhabitude de travailler
sur du texte. Si un schma simple peut ventuellement laider, un schma
complexe (ceux dont raffolent justement les informaticiens) est viter.
Inversement, si les utilisateurs sont des informaticiens ou des ingnieurs,
un schma sera souvent plus parlant quun texte.

Lever toute ambigut au fil de leau


Les mots ont souvent un sens diffrent dun mtier lautre, mme au
sein dune mme organisation. Rappelons ce sujet que tout terme un

88

Livre Constant.indb 88

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

tant soit peu ambigu devra tre inclus dans un glossaire. Ce glossaire,
qui fait partie du cahier des charges, devra tre enrichi tout au long du
processus de son laboration.

Maintenir la cohrence le plus en amont possible


Les tapes danalyse, de spcification et de validation sont prsentes
dans les chapitres suivants de cet ouvrage. Mais certaines des oprations
de ces tapes peuvent tre effectues en amont, en phase de recueil:
suite une interview, raliser un examen rapide de la cohrence avec
les notes dautres interviews, afin de dtecter des incohrences ou des
manques;
lors dune runion de recueil, reprsenter linformation sous forme de
schma;
la suite dune interview, et si ncessaire, envoyer un bref compte-rendu
la personne interviewe pour validation.
En cas de conflit entre exigences, il est important quil soit rsolu avant de
poursuivre. Lanalyse des parties prenantes qui a t faite pendant ltape
prparatoire permet de savoir qui a plus de poids. Trouver le dcideur qui
tranchera le conflit est important, mais cela demande de lhabilit. Le
dcideur nest pas toujours le futur utilisateur, il nest pas au-dessus des
lois et des rglements, mais il joue un rle cl.
Cette activit relve de la ngociation des exigences (que certains auteurs
considrent comme une tape part entire dans le processus de dveloppement et de gestion des exigences). Si les conflits entre exigences ne
sont pas rgls pendant la phase dexigences (et de prfrence pendant
le recueil, ou juste aprs), qui se chargera de le faire? Les quipes de la
phase suivante, cest--dire les concepteurs-dveloppeurs. Ce nest pas
leur rle.

Recueillir les besoins et non les solutions


Ds ltape de recueil, il est important de ne retenir que les besoins, et
non les solutions. Mme chez les assistants matrise douvrage expriments, exprimer des solutions en lieu et place des besoins est une erreur
frquente. En effet, il existe une zone floue entre les exigences et la
conception, et il nest jamais facile de savoir quand sarrter.

Recueillir les besoins alternatifs et exceptionnels


On a naturellement tendance recueillir le flux normal dun processus, et exprimer les besoins correspondant des conditions normales.
Or, un systme doit traiter les situations dexception, par dfinition rares
et improbables. Trs souvent, pour un seul cas normal dutilisation du
systme, il peut exister de nombreux cas exceptionnels.

89

Livre Constant.indb 89

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Alternatives et exceptions
Les cas exceptionnels sont, par dfinition, des exigences qui se prsentent rarement.
Mais leur recueil peut tre difficile et leur spcification longue. Ce sont eux qui posent
problme, toutes les phases du cycle de vie, depuis les exigences jusqu lexploitation. Raison de plus pour les recueillir, les analyser et les spcifier avec soin.
Penser tous les cas exceptionnels dans le cas dun retrait un distributeur automatique de billets, par exemple en cas derreur ou de malveillance. Penser aussi aux anomalies traiter suite une dfaillance du systme lui-mme.

En plus des cas exceptionnels (par exemple, dpassement dune limite


autorise ou erreur de la part de lutilisateur), il faut penser au comportement que le systme devra adopter en cas danomalie du systme
lui-mme.

Recueillir les besoins positifs, mais aussi ngatifs


Les besoins ngatifs, ou exprims ngativement, sont fort utiles lanalyste. Le questionnement ngatif permet de mettre en lumire des
besoins qui nauraient pu tre exprims que difficilement de manire
positive. Cest aussi un bon moyen de recueillir les besoins des personnes rsistantes au changement. La ngation est souvent la porte de
lamlioration, et les personnes rsistantes au changement peuvent tre
trs cratives.
Recueil des besoins ngatifs
Comme pour les besoins positifs, les besoins ngatifs peuvent tre recueillis par des
questions ouvertes, semi-ouvertes, ou fermes: Quest-ce qui vous drange le plus dans
le systme actuel? Si quelque chose vous drangeait avec le systme actuel, ce serait
quoi? Que voudriez-vous que le systme venir fasse, que le systme actuel ne fait
pas? Faisons la liste de toutes les fonctions que le systme actuel accomplit mal.

couter le silence
Il y a des besoins que lon recueille plus facilement en creux, dans le
non-dit ou dans le presque rien. En posant des questions ouvertes,
gnrales, voire imprcises, vagues, ambiges la rponse vient souvent
spontanment. Le client complte la question imprcise par une phrase
prcise, en employant ses propres mots.
Limprcision dclenche la prcision. Une question imprcise est souvent
un moyen daboutir une formulation prcise.
Le langage flou permet de formuler un discours o chacun entend ce quil
veut bien. Proscrit de ltape de spcifications (cest de la langue de bois),
il est ici utilis pour provoquer de la prcision de la part de linterview.

90

Livre Constant.indb 90

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 8 Ltape de recueil

Questions vagues qui apportent de la prcision


Quelle fiabilit attendez-vous du futur systme?
Quel niveau de richesse fonctionnelle exigez-vous?
En ce qui concerne la fonction X.(laisser un silence)?

Tester la validit des exigences au plus tt


Il ne sagit pas de valider les exigences, mais de les tester au plus tt.
Sont-elles utiles? Refltent-elles les vrais besoins? Sont-elles ralisables
un cot raisonnable?
Il sagit de parcourir, avec linterview, le cheminement mental qui a
conduit lexpression de ce besoin. Parfois, les besoins exprims nont
aucune utilit. Cest en particulier le cas lorsquun utilisateur a pris ses
habitudes avec un systme ancien et veut retrouver les mmes fonctionnalits dans le nouveau systme, alors quelles nont pas lieu dtre.
Un autre moyen consiste, aprs avoir interview un utilisateur et lui
avoir fait prciser un besoin, de lexprimer une autre personne et de
lui demander son avis. Les interviews individuelles sont parfois plus efficaces que les groupes de travail, surtout si un besoin obsolte a t
exprim par un suprieur hirarchique : le subordonn ne sexprimera
que sil a confiance en lintervieweur.

Check-list de fin dtape de recueil


La fin dtape est hypothtique, car les besoins voluent en permanence, quon ne peut jamais tre certain davoir puis la liste potentielle
dexigences, et que les tapes sont imbriques : on aura commenc
analyser, spcifier et valider bien avant davoir coch tous les points de
la check-list.
Cette check-list peut tre utilise tout moment pour connatre lavancement du recueil des exigences et viter de passer ct de points
importants.
On a soigneusement tabli la liste des parties prenantes.
On a formalis les attentes de chaque partie prenante.
Toutes les parties prenantes sont reprsentes et actives.
On a soigneusement tabli la liste des sources dexigences.
Les exigences ont t recueillies chez les vrais utilisateurs.
Toutes les catgories dutilisateurs sont reprsentes.
Toutes les catgories dutilisateur se sont exprimes.

91

Livre Constant.indb 91

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

On a recueilli les exigences positives, et aussi ngatives.


On a donn un feedback tous les participants.
Les participants ont relu ou revu les besoins exprims.
Les exigences drivent des objectifs.
On na retenu que les besoins, non des lments de solution.

92

Livre Constant.indb 92

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 9

Les cas
dutilisation
Les cas dutilisation (use cases en anglais) sont devenus clbres grce,
en particulier, UML (Unified Modeling Language). Cependant, les adeptes
dUML utilisent le plus souvent les diagrammes de cas dutilisation, ce
qui est un peu rducteur. Les cas dutilisation sous forme textuelle offrent,
eux, une grande richesse dexpression.

Quest-ce quun cas dutilisation?


Un cas dutilisation est un contrat de comportement, entre un systme (par
exemple, un logiciel) ou un sous-systme et des acteurs qui interagissent
avec lui. Ces acteurs peuvent tre des utilisateurs (humains) du systme
ou des systmes voisins.
Un cas dutilisation regroupe un ensemble de scnarios (figure9-1) qui peuvent, soit aboutir, soit chouer. Pour formuler un cas dutilisation, on doit
respecter les contraintes suivantes:
Un cas dutilisation se rapporte un objectif et un seul.
Il dcrit un comportement utile latteinte de cet objectif.
La description prend le point de vue dune (ou plusieurs) partie(s)
prenante(s).
Il comporte un acteur principal et un seul.
Il dbute avec un vnement dclencheur.
Il se poursuit jusqu ce que lobjectif soit atteint ou abandonn.

Livre Constant.indb 93

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Mdecin
prescripteur

Systme

Slectionner
un patient
Saisir la
prescription
Modifier la
prescription

Interroger
base md.
Contrler les
posologies
Contrler les
interactions

problme
Non
Signer la
prescription

Alimenter le
plan de soin

Figure9-1 : Scnario de cas dutilisation

Le contenu dun cas dutilisation


1. Le plus connu est
Alistair Cockburn.
Voir Rdiger des cas
dutilisation efficaces
publi aux ditions
Eyrolles.

Un cas dutilisation sexprime essentiellement sous forme textuelle.


Les diffrents items qui le composent varient selon les auteurs1, le type
dapplication, le degr de prcision que lon veut atteindre grce aux
spcifications. Voici une structuration assez classique:
Acteur principal: cest la personne qui, dans le prsent cas dutilisation, interagit avec le systme. eux deux, ils excutent le cas dutilisation.
Autres acteurs: toutes les personnes impactes par la mise en uvre
du cas dutilisation.
Dclencheur: il sagit de lvnement qui dclenche le cas dutilisation.
En principe, cest un vnement mtier (voir le diagramme de contexte).
Description: description courte du droulement du cas dutilisation.

94

Livre Constant.indb 94

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 9 Les cas d utilisation

Prconditions : conditions qui doivent tre vrifies, pour que le cas


dutilisation dmarre.
Postconditions : galement appeles garanties en cas de succs. tat du
systme la fin de lexcution du cas dutilisation.
Garanties minimales: tat du systme lors de lexcution du cas, quelle
quen soit lissue.
Scnario nominal : cest un scnario formul comme une alternance
dactions de lutilisateur et de rponses du systme. Il dcrit lexcution
du cas dutilisation dans des conditions attendues. Lexcution du scnario permettra datteindre lobjectif nonc dans le titre du cas dutilisation. Gnralement, les actions sont numrotes.
Scnario alternatif 2: squence alternative du scnario. La numrotation permet de se raccrocher au flux normal. Par exemple, si on dcrit
une alternative la squence2-5, on notera les actions2-5.a, 2-5.b, etc.

Exceptions: squence dclenche par une anomalie ou une erreur lors


de lexcution du flux normal ou dun flux alternatif.

2. Cockburn utilise
le terme extensions
qui regroupe scnarios alternatifs et
exceptions.

Cas inclus: liste des cas dutilisation inclus dans le cas dutilisation prsent. Les cas inclus sont en quelque sorte des sous-cas (analogues
des sous-programmes). Ils permettent de dcrire des squences qui se
retrouvent dans plusieurs cas dutilisation, ou damliorer la lisibilit.
Frquence dutilisation: nombre estim de fois o ce cas dutilisation
sera excut par les acteurs, dans lunit de temps approprie (jours,
heures).
Rgles mtier: rgles mtier auxquelles ce cas est subordonn.
Exigences particulires : exigences supplmentaires (exigences non
fonctionnelles, contraintes) qui sappliquent ce cas dutilisation.
Notes et questions: remarques particulires.
Cockburn et ses adeptes ajoutent les points suivants:
Porte de conception: cest la largeur du champ de la description; par
exemple lentreprise, le systme, ou un sous-systme.
Niveau dobjectif: dsigne le niveau de lobjectif que lon veut atteindre:
niveau stratgique, niveau utilisateur (intresse lacteur principal), ou
niveau dune sous-fonction.
Ces deux derniers points sont intressants, et pour Cockburn, ils devraient
tre obligatoires pour dcrire un cas dutilisation. Cest ainsi dans les projets importants o lon dveloppe un grand nombre de cas dutilisation.
Ces notions, bien que trs utiles, ne sont pas toujours faciles manier.

95

Livre Constant.indb 95

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Avantages des cas dutilisation


Les cas dutilisation ont un norme avantage: ils concilient les littraires
(au sens large du terme: cest--dire les personnes portes sur le langage
crit plutt que sur les schmas) et les informaticiens. Pour qui a pratiqu la programmation, un cas dutilisation rappelle un algorithme crit
en pseudo-code. Il prsente nanmoins les exigences sous une forme
aisment comprhensible par tous, ce qui permet dobtenir facilement
une vision commune, et donc daboutir un consensus entre parties
prenantes (cest le but du cahier des charges).
Lautre avantage est celui du point de vue. Les cas dutilisation sont crits
dans la langue de lutilisateur, et centrs sur ses actions. Cela augmente
les chances dobtenir un produit lui-mme centr sur lutilisateur.
Enfin, les exigences rdiges de cette manire modlisent une activit
relle, et donc de vrais besoins; avec ce procd, il y a peu de chances
quun utilisateur exprime des besoins gadgets pour se faire plaisir (ce
qui arrive souvent quand on commence par dcrire linterface utilisateur).
Les cas dutilisation offrent plus de chances lquipe de dveloppement
de raliser un logiciel robuste. Ils vitent les zones floues qui pourraient
tre mal interprtes pendant le dveloppement. En dcrivant tous les
scnarios possibles (combinaisons du scnario nominal, des scnarios
alternatifs et des scnarios en cas dchec), on a plus de chances de donner aux concepteurs un document cohrent quen leur fournissant une
liste de fonctions. Enfin, partir des cas dutilisation, il est relativement
facile de dduire les cas de test.
Les cas dutilisation sont donc le couteau suisse de la modlisation des
exigences. Ils peuvent tre utiliss tous les niveaux, depuis les objectifs
stratgiques jusqu la description dun comportement trs dtaill. Ils
permettent de dcrire des processus, de ngocier entre parties prenantes,
de faire ressortir (et donc danticiper) les problmes. partir de l, il sera
possible de faire une premire estimation des cots de dveloppement,
de reboucler sur les objectifs dfinis plus en amont, puis de passer la
phase de conception. Les concepteurs pourront par la suite se servir de
cas dutilisation pour dcrire, non plus les besoins, mais la solution, et
la matrise douvrage reprendre la main pour prciser les scnarios de
recette.

laboration des cas dutilisation


Les cas dutilisation sont un excellent outil danalyse, mais aussi de
recueil et de spcification. Ils savrent utiles pour assembler les besoins

96

Livre Constant.indb 96

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 9 Les cas d utilisation

recueillis auprs de plusieurs acteurs, travailler avec les diffrents


acteurs, interagir avec eux, et faire valider les exigences correspondantes.
En dautres termes, cest un bon moyen de transformer un besoin en
exigence.
Une squence dlaboration dun cas dutilisation peut tre la suivante:
recueillir les besoins de haut niveau auprs de la matrise douvrage;
en dduire les cas dutilisation;
recueillir les besoins auprs de diffrentes sources (documentation
client, produits existants, etc.);
complter le recueil auprs de plusieurs utilisateurs;
consolider lensemble et dgager un ou plusieurs scnarios;
dcrire ces scnarios au moyen dun cas dutilisation relativement simple;
distribuer le cas dutilisation aux participants dun groupe de travail;
travailler en groupe sur le cas dutilisation pour laffiner;
si ncessaire, itrer sur les tapes prcdentes.
Un autre moyen efficace de dterminer les cas dutilisation consiste
partir du diagramme de contexte:
Chaque flche (entrante ou sortante) du diagramme de contexte est un
vnement mtier (business event).
Lvnement mtier est formul sous forme de phrase linfinitif (par
exemple, prescrire un mdicament).
Lvnement mtier devient la description du cas dutilisation.
Une extrmit de la flche pointe vers le systme; lautre extrmit est
lacteur principal (par exemple, mdecin prescripteur).
On travaille avec les parties prenantes, en particulier un reprsentant
des utilisateurs (correspondant lacteur principal et aux acteurs secondaires, par exemple un mdecin et un pharmacien) pour dcrire les scnarios (nominal et alternatif).
Dans la pratique, comme toujours dans la dfinition des besoins, on peut
combiner ces deux approches, par raffinements successifs et allers et
retours entre un diagramme de contexte et des cas dutilisation.
Capturer et spcifier les exigences partir des cas dutilisation
Les cas dutilisation constituent un excellent moyen de recueil et de spcification
dexigences plus dtailles (exigences lmentaires, en anglais atomic requirements).
La mthode consiste se poser les questions suivantes pour chaque tape du scnario:
Quelles sont les donnes en entre, en sortie, ou stockes lors de cette tape?
Quels sont les traitements (calculs, vrifications) faits par le systme cette tape?

97

Livre Constant.indb 97

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Un exemple
Voici un exemple extrait dun cahier des charges du domaine des systmes dinformation hospitaliers. Lacteur principal est le prescripteur
(mdecin ou sage-femme). Les acteurs secondaires, pharmacien et infirmier, traitent la prescription.
Nom du C.U.

Prescrire

Acteur principal

Prescripteur

Autres parties
prenantes

Pharmacien, infirmier

Description

Le prescripteur prescrit des mdicaments un patient hospitalis.

Prconditions

Le prescripteur est identifi.


Le systme dispose des informations utiles sur le patient.
Le patient est admis dans lunit.
Le prescripteur a effectu son observation mdicale.
Le prescripteur a consult le dossier patient.
Le livret thrapeutique est accessible au prescripteur.

Garanties minimales

Le systme tient jour un journal de toutes les oprations.


Les informations saisies par le prescripteur ne seront accessibles
aux autres acteurs quune fois la prescription signe.
La prescription est une opration atomique. Elle ne peut russir
entirement ou chouer.

Garanties en cas
de succs

La prescription peut tre valide par la pharmacie.


Mise jour du plan de soins avec le plan dadministration prvisionnel.
Intgration de lordonnance dans le dossier mdical du patient.

Flux normal

1.Le prescripteur slectionne dans la liste des patients de lunit


de responsabilit mdicale le patient pour lequel une prescription
doit tre faite.
2.Le prescripteur saisit un lment de prescription autant de fois
que ncessaire.
[saisir un lment de prescription est un cas inclus].
3.Le systme contrle les posologies et les interactions mdicamenteuses en interrogeant la base mdicamenteuse.
4.Le systme contrle les interactions physiopathologiques.
5.Le systme signale les ventuelles interactions et anomalies.

98

Livre Constant.indb 98

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 9 Les cas d utilisation

Nom du C.U.
Flux normal
(suite)

Prescrire
6.En cas danomalie, le prescripteur peut modifier la prescription
ou la maintenir et en indiquer les raisons.
7.Le systme inscrit la prescription dans le plan de soins de linfirmire avec un statut en attente danalyse par la pharmacie.
8.Le prescripteur signe la prescription.
9.Le prescripteur peut imprimer lordonnance.

Flux alternatif

[On traite ici dune alternative ltape1]:


1a - Si le prescripteur dcide une hospitalisation immdiate en
consultation:
1a1 - La prescription est faite sur une unit de consultation.
1a2 - Le prescripteur indique lunit dhospitalisation.
1a3 - Le systme affecte la prescription lunit dhospitalisation.
[Autre alternative ltape1]:
1b - Si la mme quipe mdicale et soignante travaille sur deux
units:
1b1 - Le prescripteur consulte une liste de patients comportant
les patients des deux units.

Cas inclus

Saisir un lment de prescription

Frquence
dutilisation

chaque consultation

Les cas dutilisation peuvent tre plus ou moins dtaills, selon le niveau
de prcision du cahier des charges.

Difficults et risques des cas dutilisation


Le premier risque est li lapparente facilit dcriture. On peut faire
lanalogie avec un ouvrage littraire : un cas dutilisation bien crit est
trs facile lire par tous les intervenants dun projet. Son criture est en
revanche beaucoup plus difficile, et demande de savoir matriser les trois
concepts de porte, dacteur principal et de niveau, ce qui demande un certain
entranement.
Les cas dutilisation sont galement difficiles comprendre (et a fortiori
laborer) lorsquils dcrivent un processus qui nexiste pas et qui devra
tre informatis. Par exemple, un mdecin comprendra trs facilement le

99

Livre Constant.indb 99

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

cas dutilisation appel prescrire un mdicament, mais aura du mal ragir


face un cas dutilisation dcrivant une pratique professionnelle quil ne
matrise pas encore.
Dautre part, les cas dutilisation ne sont pas adapts toutes les situations. Ils sont de peu dutilit pour des systmes o les interactions et
transactions sont peu frquentes, comme les programmes de calcul
scientifique ; et galement dans des cas o les interactions sont trs
complexes, comme les systmes temps rel. Il en est de mme pour les
systmes sappuyant sur des rgles de gestion nombreuses et complexes.
Enfin, ils ne sont pas du tout adapts la description des exigences non
fonctionnelles. Dans tous ces cas, il est prfrable dutiliser dautres
modles de description.
Vouloir spcifier la totalit des exigences sous forme de cas dutilisation
est donc inefficace. Et certaines exigences, mme parmi celles pouvant
tre dcrites de cette faon, gagent ltre au moyen de formalismes
diffrents.
Dune manire gnrale, lors de llaboration dun cas dutilisation, il faut
rester simple et utiliser cet outil pour ce quoi il est destin: dcrire un
ensemble de scnarios permettant datteindre un objectif dans lintrt
des acteurs. Les cas suivants doivent tre considrs comme des signaux
de danger:
des cas dutilisation trop nombreux, dans lesquels on se perd;
des cascades de cas inclus;
des cas dutilisation complexes, trop longs, incomprhensibles par
certains acteurs;
des cas dutilisation qui dcrivent linterface utilisateur, ou les donnes:
ils ne sont pas faits pour a.

Les diagrammes de cas dutilisation


Que penser des diagrammes de cas dutilisation? Les adeptes dUML en
font un usage abondant, alors quAlistair Cockburn ne les utilise quavec
grande parcimonie, en mettant le lecteur en garde contre les risques que
prsente leur utilisation.
En ralit, dans les cas simples, les diagrammes de cas dutilisation sont
faciles dessiner et comprendre, mais sont de peu dutilit. Dans les
cas complexes, ils sont peu maniables et ont tendance devenir incohrents et ambigus. Finalement, ils ne sont utiles qu petites doses, titre
illustratif.

100

Livre Constant.indb 100

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 9 Les cas d utilisation

Verbatim
Si vous passez beaucoup de temps tudier les graphiques et les relations, et les
prendre en compte, cest que votre nergie est mal utilise. Placez-la plutt dans la
rdaction de textes facilement lisibles. En prose, les relations entre cas dutilisation
sont directes. Aprs cela, vous aurez du mal comprendre pourquoi certains se font des
nuds au cerveau leur sujet.
[] Ceux qui crivent de bons cas dutilisation textuels ne sont tout simplement pas
confronts aux problmes que rencontrent ceux qui bricolent avec des personnages
styliss, des ellipses et des flches prconiss par UML. Les relations se dgagent naturellement de lcriture du rcit; elles ne deviennent problmatiques que lorsquon
en fait un abcs de fixation. Cette ide fait son chemin mesure quun nombre croissant de consultants accumulent une exprience double des cas dutilisation textuels et
dUML.
Alistair Cockburn, crire des cas dutilisation efficaces, ditions Eyrolles, 2001.

101

Livre Constant.indb 101

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 102

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10

Ltape danalyse

Le matre douvrage, les utilisateurs et autres parties prenantes expriment gnralement leurs besoins en langue naturelle. Dans le cahier des
charges, ces besoins seront reformuls sous forme dexigences, dans la
mme langue naturelle, mais sous une forme diffrente, plus formelle.
Lexpression des exigences est donc une traduction entre le langage (et
souvent le jargon) des utilisateurs et un langage trs prcis, comprhensible par tous les acteurs. Entre les deux, une reprsentation sous forme
graphique, sous forme de scnario, ou sous forme de prototype, permet
dobtenir une comprhension commune, de lever toute ambigut et
incohrence.

Utilit de ltape danalyse


Il est illusoire de penser que lutilisateur ou son reprsentant va nous
prsenter une liste bien ordonne de besoins bien formuls. Les besoins
sont en gnral exprims sous forme de grappes, dont il faudra trier les
grains. Plusieurs besoins trs diffrents peuvent tre formuls dans une
mme phrase, comme on a besoin davoir toutes les informations dun
client sous les yeux, et de pouvoir choisir dans un menu les diffrents
produits lui proposer, et le systme doit ragir trs vite sans jamais se
bloquer.
Dans cet exemple, le client:
Nindique pas lacteur (qui est on?).
Exprime plusieurs besoins dans une mme phrase.
Mlange des besoins fonctionnels et non fonctionnels.
Mlange des besoins gnraux (vision globale) et de dtail (choix).

Livre Constant.indb 103

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Formule une solution (choix dans un menu) la place dun besoin.


Formule des besoins non mesurables (trs vite).
Formule une exigence probablement irraliste (jamais).
Au cours dune runion dun groupe de travail, on peut recueillir une
vingtaine de formulations de ce type. Et llaboration dun cahier des
charges peut ncessiter une quinzaine de runions de travail. On admettra facilement que trois cents phrases de ce type mises bout bout ne
constituent pas un cahier des charges, mais une liste qui deviendra vite
incohrente. Pour travailler efficacement, il sera donc ncessaire danalyser, de reformuler, de trier et de classer les besoins au fur et mesure
quils se prsentent, ou en tout cas le plus tt possible.

Le processus danalyse
Les objectifs de ltape danalyse sont les suivants:
classer et structurer les exigences;
dvelopper une comprhension partage des besoins qui ont t
recueillis;
dtecter les incohrences, redondances et incompltudes et faire le
ncessaire pour les rduire, voire les liminer.
Ces deux objectifs sont indissociables. Pour les atteindre, ltape danalyse fait largement appel lexprience et la crativit, car il ny a pas
de mthode miracle pour dtecter toutes les incohrences et incompltudes. La mthode empirique, qui consiste relire les exigences et en
discuter en groupe de travail, a son utilit, mais on en voit vite les limites.
Ce chapitre va dtailler des techniques spcifiques qui seront mises en
uvre, et en particulier:
structurer et organiser les exigences par types;
tablir un dictionnaire de donnes;
analyser les rgles mtier;
classer les exigences par priorits;
modliser les exigences sous forme graphique;
raliser une maquette papier ou un prototype;
laborer des cas de test;
tester la faisabilit et le cot des exigences.
La figure10-1 prsente le processus gnral de ltape danalyse.

104

Livre Constant.indb 104

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

Prioriser
Recueil

spcification

Modliser

Structurer

tudier cot et
faisabilit

Figure10-1 : Le processus danalyse

Si lanalyste a une formation dingnieur, il sera tent, du moins dans


un premier temps, de concevoir ltape danalyse comme une activit
purement technique. En ralit, il ne sortira rien de bon si les diffrentes
parties prenantes, et en particulier les reprsentants des utilisateurs, ne
sont pas impliques. Lanalyste doit matriser UML (ou un autre langage
graphique), mais il doit tre suffisamment pdagogue pour rendre les
diagrammes comprhensibles par tout lecteur potentiel.

Structurer et organiser les exigences


Les exigences doivent tre classes en catgories, soit au fil de leau lors
du recueil, soit au plus tard pendant llaboration du document dexigences (cahier des charges). La classification qui suit est inspire de
Karl Wiegers (voir bibliographie), mais la plupart des classifications sen
approchent.
Les objectifs sont des exigences de haut niveau. Un objectif est formul
sous forme de phrase avec un verbe linfinitif, par exemple diminuer
de 20% le temps dattente au guichet. Les objectifs sont exprims, dans
la majorit des cas, par le donneur dordre. Le verbe sous-entendu est le
verbe vouloir (ou devoir, dans le sens dune volont): nous (lentreprise)
voulons diminuer le temps dattente (il sagit l de la volont du matre
duvre).
Les cas dutilisation ou scnarios correspondent des besoins des utilisateurs et sexpriment galement comme une phrase linfinitif, par
exemple enregistrer un nouveau client. La phrase sous-entendue est
avoir besoin de, exprime la premire personne: jai besoin denregistrer
tout nouveau client.
Les rgles sont des exigences rglementaires ou des rgles mtier (galement appeles rgles de gestion). Le verbe sous-entendu ou explicite
est devoir: le logiciel doit se conformer telle rglementation, dans des
conditions bien dfinies. Par exemple: un retrait despces ne peut tre
effectu que si le compte est positif (formul autrement, le compte doit
tre positif pour quun retrait puisse tre effectu).

105

Livre Constant.indb 105

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Les exigences fonctionnelles constituent le cur et souvent la partie la


plus importante dun cahier des charges. Elles expriment un comportement
requis de la part du systme. Elles drivent des catgories prcdentes.
Par exemple si le retrait despces nest pas autoris, le systme envoie
un message au client.
Les exigences de qualit, galement appeles exigences non fonctionnelles,
bien quelles nen constituent quune partie. Elles sexpriment sous forme
dadjectif (rapide, facile) ou de la proprit correspondante (rapidit,
facilit).
Les exigences dinterface qui expriment le besoin dune communi
cation entre le systme ltude et le monde extrieur: matriel, logiciel
et personnes.
Les contraintes techniques, comme lutilisation dun systme ou dun
langage particulier, ou de technologies spcifiques, comme un protocole
de communication ou de scurit. Il est important danalyser lorigine de
ces contraintes et leur utilit relle, car elles peuvent avoir des rpercussions ngatives sur la fonctionnalit ou la qualit.
Les exigences sur les formats de donnes, comme un code postal en
cinq chiffres, un code pays, etc.
Les suggestions de solutions qui nont pas lieu de se retrouver en tant
que telles dans un cahier des charges, et quil faudra analyser pour remonter une exigence dun des types prcdemment dfinis. Par exemple,
si lexigence est la somme doit safficher en rouge , il est important
de savoir pourquoi. Cela peut correspondre une rgle mtier (certains
chiffres doivent safficher en rouge dans telle condition), dune rgle dergonomie (homognit: laffichage doit tre le mme dune application
lautre) ou dun souhait personnel.
Dautres informations ou exigences peuvent tre formules. Elles pourront ou non se retrouver dans le cahier des charges, ou en prambule, ou
en annexe de celui-ci: description de lexistant, contraintes sur les dlais,
sur les cots, sur la formation des utilisateurs, le dcoupage en lots lors
dun appel doffres, et toutes informations utiles ceux qui vont rpondre
au cahier des charges.
Il sagit l dune premire classification qui, avec lhabitude, se fait mentalement au cours du recueil des exigences. Une classification plus prcise
se fait lors de la rdaction du cahier des charges, et dpend donc prcisment du modle de cahier des charges utilis. Dailleurs, disposer dun
squelette (ou modle) de cahier des charges sert prcisment cela: cest
une armoire de rangement pour les exigences.

106

Livre Constant.indb 106

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

tablir un dictionnaire de donnes


Comme les exigences fonctionnelles, la description des donnes constitue une passerelle de communication entre matrise douvrage (le
vocabulaire des utilisateurs) et matrise duvre (la comprhension des
concepteurs et dveloppeurs).
Les mmes donnes apparaissant dune exigence lautre, il est utile de
les spcifier une fois pour toutes. Par exemple:
Client = id_client [9chiffres]+nom [15lettres]+prnom
[15lettres]
La syntaxe peut tre plus ou moins complexe, en fonction de lusage
qui sera fait des spcifications dexigences (dveloppement spcifique
ou choix de progiciel). Certaines interfaces (normes dinteroprabilit)
peuvent ncessiter une description extrmement prcise des formats de
donnes changes, mais cest rarement le cas pour un cahier des charges
fonctionnel labor dans le cadre dun appel doffres, par exemple.
Limportant est que toutes les personnes intresses soient daccord sur
le contenu de telle ou telle donne, afin dviter toute ambigut.

Analyser les rgles mtier


Quest-ce quune rgle mtier?
Les rgles mtier, galement appeles rgles de gestion (en anglais
business rules) drivent des lois, rglements, procdures, codes de bonnes
pratiques en vigueur pour un mtier donn, rgles de calcul, etc. Ce sont
l des exigences en puissance, mais elles sont gnralement nonces
sous une forme inapproprie pour apparatre dans un cahier des charges.
Autrement dit, ce sont des intermdiaires entre un texte ou une pratique
(texte rglementaire, pratique professionnelle) et une exigence. Plus
prcisment, une rgle de gestion peut tre:
un fait;
une contrainte (seul un acteur X peut accomplir laction Y);
une rgle daction (un acteur X doit accomplir laction Y);
une infrence (si alors);
une rgle de calcul (par exemple, calcul de la TVA).
Les rgles mtier ne sont pas des besoins utilisateurs et ne sont pas
considres comme des exigences proprement parler. En gnral, elles
napparaissent pas en tant que telles dans un cahier des charges, mais y
sont dclines sous forme dexigences.

107

Livre Constant.indb 107

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Plutt quun long discours, donnons quelques exemples de rgle mtier:


Tout mdicament est livr la pharmacie dans un emballage avec un
code-barres (fait).
Le directeur dun tablissement de sant tablit la liste des personnes
habilites prescrire des mdicaments (rgle daction).
Le pharmacien doit analyser la prescription avant de livrer un mdicament (rgle daction).
Le pharmacien doit sassurer quil ny a pas interaction mdicamenteuse
entre plusieurs mdicaments prescrits (rgle daction).
Si la date de premption inscrite sur lemballage est suprieure la date
du jour, alors le produit est prim (infrence).

1. De fortes
contraintes de
traabilit et de
maintenabilit
peuvent rendre indispensable le recours
un outil de gestion
des exigences (voir
au chapitre19).

Il est clair que toutes ces rgles nont pas se retrouver dans une spcification dexigences. Il serait inutile de les inclure dans le cahier des
charges lui-mme, du moins sous cette forme, car elles nont pas dimpact direct sur le produit. Mais, dune part, elles participent lanalyse
des exigences et, dautre part, il est ncessaire, pour des raisons de traabilit et de maintenabilit, de pouvoir connatre en permanence le lien
entre une rgle mtier et une exigence du cahier des charges1.

De la rgle mtier lexigence


lorigine, les rgles mtier nont pas t crites pour figurer dans un
cahier des charges. Mme si cela peut en choquer certains, on peut dire
que, vis--vis du cahier des charges, ce sont des exigences brutes .
Pour en faire des exigences aptes entrer dans un cahier des charges,
le travail de recueil, danalyse et de spcification est analogue celui de
lanalyse des besoins. Il consiste :
recueillir les rgles de gestion
rechercher les sources des rgles de gestion potentielles (lgislation,
normes, recueils de pratiques professionnelles, protocoles) qui
sont en rapport avec lobjectif et dans le champ de ltude,
recueillir lensemble des rgles, procdures, pratiques, susceptibles
davoir un impact sur les exigences;
analyser ces lments
filtrer en fonction des objectifs,
rechercher les incohrences, redondances et incompltudes,
si ncessaire, reprsenter ces lments en diagrammes, sous la
forme approprie;
traiter les rgles de gestion
formuler les lments prcdents sous forme de rgles mtier,

108

Livre Constant.indb 108

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

stocker ces rgles dans le rfrentiel appropri,


dcider lesquelles de ces rgles mtier seront automatises;
spcifier
formuler ces rgles sous forme dexigences,
inclure ces exigences dans le cahier des charges;
grer
maintenir la traabilit entre les rgles de gestion et les exigences
fonctionnelles en aval,
analyser limpact dune rgle de gestion sur lensemble des exigences
mtier.
La diffrence avec le traitement des besoins rside donc dans le stockage
des rgles mtier dans une zone particulire, en vue de les inclure, si
ncessaire, dans le cahier des charges. Cette zone de stockage peut tre
un simple tableau, une base de donnes, ou mieux, un outil de gestion
des exigences.
Les rgles mtier vont gnralement donner lieu des exigences fonctionnelles de haut niveau, parfois appeles exigences mtier (business requirements).
Elles seront dclines sous forme dexigences plus fines, en fonction du
niveau de dtail requis.

Dfinir les priorits dun projet


Pourquoi et quand dfinir les priorits?
Tout projet est limit par le budget allou, les dlais exigs, le risque
admissible et les ressources disponibles. Il est donc indispensable de
dfinir les priorits entre exigences. La priorisation des exigences est
utile:
lors de la dfinition des objectifs, (dans toute la mesure du possible);
lors du dveloppement des exigences (laboration du cahier des charges);
lors du choix dune solution.
La gestion des priorits permettra de rsoudre les conflits au plus tt, de
faire des compromis, et ventuellement de planifier la mise en uvre de
certaines exigences pour une version ultrieure du systme.
Il est important de dfinir les priorits entre fonctions (ou exigences non
fonctionnelles) le plus tt possible, quitte revoir la liste des priorits
par la suite, avec le recul. Cela minimise le risque de voir des conflits
senvenimer ou de devoir remettre en cause lexistant au dernier moment.

109

Livre Constant.indb 109

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Comment dfinir les priorits?


Grer les priorits est loin dtre une tche facile. Tout utilisateur a
tendance penser que a) toutes ses exigences sont prioritaires sans
exception et que b) ses exigences sont prioritaires sur celles des autres.
Les priorits ne peuvent tre dfinies par les seuls utilisateurs (ou leurs
reprsentants). Elles doivent tre confrontes au rel, cest--dire ce qui
est faisable ou pas, et quel cot. Il est donc ncessaire dorganiser des
runions entre experts mtier (utilisateurs ou reprsentants) et experts
techniques (dveloppeurs, chefs de projet ou leurs reprsentants) et de
confronter les points de vue.
Il ny a pas de mthode miracle, la gestion des priorits reposant sur des
principes de ngociation. En cas de conflit entre priorits, il faut se poser
les questions suivantes:
Qui serait insatisfait si cette exigence ntait pas mise en uvre?
Peut-on satisfaire cette exigence par dautres moyens?
Comment se comporterait le systme sans cette fonction?
Le systme dans son ensemble serait-il mis en cause?
Quelle est la limite acceptable en termes de dlais? de cots?
Est-on prt assumer le risque de supprimer cette fonction?
La priorit dune exigence est fonction de son urgence et de son importance (principe dEisenhower):
les exigences urgentes et importantes seront en haute priorit;
les exigences importantes, mais non urgentes, viendront ensuite;
les exigences urgentes et non importantes sont de priorit faible;
les exigences ni urgentes ni importantes seront mises de ct.
Outre lurgence et limportance, doivent entrer en ligne de compte le
risque faire et ne pas faire (ce que lon gagne en faisant, ce que lon
perd en ne faisant pas), le cot de ralisation, ainsi que le risque li la
ralisation (li au manque de savoir-faire de lquipe de dveloppement,
limmaturit des technologies mises en uvre, etc.).
Il est facile de construire (ou de trouver sur Internet) une matrice de priorisation des exigences, permettant de faire une somme pondre des
diffrents paramtres.

La mthode des cent points: mode opratoire


La mthode des cent points est un grand classique. Elle est trs utilise par les consultants pour animer un groupe de travail de slection
de progiciel. Dans ce dernier cas, les exigences sappellent critres de

110

Livre Constant.indb 110

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

choix, mais lide est la mme. Sous sa forme simplifie, les tapes de la
mthode sont les suivantes:
1. Les participants dressent la liste des exigences prioriser. On utilisera
de prfrence un tableur et la liste ne doit tre ni trop longue, ni trop
courte (rgle du pouce: imprime, la liste doit tenir sur une pageA4).
2. On se fixe la rgle suivante: chaque exigence aura un poids compris
entre1 (peu prioritaire) et4 (trs prioritaire), et la somme des poids
des exigences devra tre gale 100. On peut jouer sur ces chiffres,
mais on vitera de les modifier en cours de route.
3. Les participants attribuent chaque exigence un poids. Ce poids doit
tre attribu par consensus entre participants. Si un consensus ne peut
tre trouv, on vote (cest un pis-aller) ou quelquun doit trancher (cest
un pis-aller de plus). Cest l que les talents danimateur de lanalyste
seront utiles.
4. Lorsque chaque exigence aura reu un poids, si la somme des poids
est infrieure ou suprieure 100, on cherchera augmenter ou
rduire le poids de certaines exigences jusqu atteindre100. Ici aussi,
on cherche le consensus. Si on utilise un tableur, il est facile de jeter
de temps en temps un coup dil sur la somme des poids. Avec un peu
dexprience, lanimateur sait quil doit forcer sur les pondrations ou
au contraire les modrer, bien avant darriver au bout de la liste.
5. Lorsque toutes les exigences sont pondres et que la somme des
poids est gale 100, les exigences sont priorises.
Il est clair que cette mthode demande du doigt de la part de lanimateur (analyste ou consultant) et une atmosphre consensuelle, sinon la
sance tournera vite au pugilat. certains moments, lanimateur peut
assouplir les rgles: ajouter quelques exigences supplmentaires, autoriser les dpassements, ou modifier la liste en cours de route. Ces entorses
sont somme toute normales, la rgle du100 tant plutt arbitraire.
Il arrive dailleurs souvent quen discutant, les participants remettent en
question les exigences elles-mmes, ou fassent merger de nouvelles
exigences. Ce phnomne est normal, voire souhaitable, mais doit tre
contrl pour viter les drives: augmentation exponentielle du nombre
dexigences, spcifications rampantes, ou retours incessants en arrire.
Une variante de la mthode consiste donner chaque participant cent
points, quil pourra utiliser sa guise. Sil y a cinq participants, la somme
pondre des priorits sera gale 500. Le consultant ou analyste qui
anime le groupe na pas de points. Cette variante permet daller plus
vite, mais en vitant la recherche dun consensus, elle nencourage pas la
rflexion sur les exigences elles-mmes.

111

Livre Constant.indb 111

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

La mthode peut tre enrichie, en donnant des poids lis non seulement
au besoin des utilisateurs, mais aussi au cot, au risque, au temps de
dveloppement, etc.

Autres mthodes
Mme avec une matrice simple (somme pondre des bnfices, cots,
risques) on obtient le plus souvent des rsultats satisfaisants. Le plus
important est damener les diffrents acteurs se mettre daccord sur
un processus de priorisation et travailler ensemble pour dfinir les
priorits.

2. En France, la
socit Adexys
commercialise une
gamme doutils dvaluation bass sur la
mthode AHP.

Pour les projets importants, des mthodes plus complexes de priorisation,


comme AHP (Analytical Hierarchical Process) ou QFD (Quality Function Deployment) peuvent tre mises en uvre. La mthode AHP est une mthode
daide la dcision qui consiste comparer deux deux des critres (et
dans le cas des exigences) classs hirarchiquement. Le nombre total
de comparaisons est n x (n-1)/2 o n est le nombre dexigences prioriser chaque niveau hirarchique, ce qui augmente trs vite le nombre
de comparaisons faire. Cette mthode est puissante, mais en pratique
demande tre outille2.

Modliser sous forme graphique


La modlisation graphique est la fois un outil danalyse, de communication entre acteurs, et de validation. Certains traitements ou processus sont
plus simples comprendre lorsquils sont reprsents graphiquement, et
les ventuelles incohrences sautent aux yeux. Un bon schma, cest
bien connu, vaut bien cent pages de texte.
Cependant, ne nous faisons pas dillusions. Contrairement ce que lon
crit parfois, la modlisation sous forme graphique nest pas un outil universel et ne remplace pas le texte crit. Il y a cela plusieurs raisons:
Contrairement ce que lon pense souvent, des schmas qui paraissent
trs simples certains seront difficiles comprendre pour dautres.
Un schma peut tre facile lire, mais beaucoup plus difficile laborer
quun texte.
laborer un schma parat facile, mais cest l une simplicit trompeuse,
car il faut utiliser un formalisme prcis et connatre la smantique sousjacente.
moins dun formalisme extrme, une mme reprsentation peut avoir
des interprtations diffrentes selon les auteurs et lecteurs, et induire
en erreur.

112

Livre Constant.indb 112

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

Il nexiste pas de notation graphique universelle qui permettrait de


reprsenter tous les besoins.
Les diagrammes peuvent tre insrs dans un cahier des charges, en
complment du texte crit. Ils peuvent galement tre trs utiles en tant
que reprsentations intermdiaires, uniquement dans un but danalyse,
sans ncessairement apparatre dans le cahier des charges.
La vraie valeur dun diagramme
Un diagramme ne sert pas seulement communiquer des exigences au matre
duvre, ni mme les faire valider par la matrise douvrage. Il sert aussi, et surtout, changer de point de vue.
En effet, analyser un problme, cest le dcomposer en ses diffrents constituants,
dans le but de mieux le comprendre. Le reprsenter sous diffrents formalismes
oblige lobserver sous plusieurs angles et le dcomposer de plusieurs manires
diffrentes. Et surtout, cela oblige changer de cerveau, car notre cerveau traite
diffremment le texte et les images. Cela augmente considrablement la probabilit de dtecter une incohrence ou une incompltude dans la spcification.

On donne ici quelques diagrammes parmi les plus utiliss. Les paragraphes qui suivent nont pas pour objectif de remplacer un ouvrage sur
lanalyse des systmes dinformation, mais de montrer leur utilit pratique
dans la dfinition des besoins.

Le diagramme dactivits ou carte de processus


Cest le plus classique des diagrammes. On le trouve dans diverses
mthodologies, sous des noms diffrents, avec des symbolismes varis.
Il sappelle process map en anglais, et son quivalent UML est le diagramme
dactivit. Il permet de reprsenter les tapes dun processus mtier, leur
squence, leurs entres et sorties, les acteurs responsables de chaque
tape. Ces diagrammes peuvent tre utiliss pour reprsenter un processus existant ou venir, automatis ou manuel. Cest donc un outil assez
gnraliste.
Les tapes peuvent tre rparties sur des bandes (en anglais swim lanes,
par analogie avec les couloirs dune piscine), chaque bande tant sous la
responsabilit dun acteur. Certains analystes rservent une bande aux
tapes automatises ou automatiser.
En plus dtre le couteau suisse de lanalyste, un diagramme de
processus est un excellent outil de dialogue avec les utilisateurs, et de
ngociation avec la matrise douvrage, condition:
de tenir sur une pageA4;
dtre autoexplicatif;
de ne pas comporter trop dtapes (une douzaine au plus).

113

Livre Constant.indb 113

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Les grands schmas synoptiques sur une grande feuilleA3 ouA2 peuvent
tre utiles aux analystes et concepteurs, rompus aux schmas complexes.
Mais ils ne devraient pas sortir de leurs tiroirs. Une usine gaz risque
deffrayer un interlocuteur et davoir leffet exactement inverse de celui
escompt.
Patient

Mdecin

Infirmire

Pharmacie

Interrogerle
patient
Communiquer
les
informations

Prescrireles
mdicaments
Analyserla
prescription

Modifierla
prescription

Oui

Interactions
Non
Dlivrerles
doses

Administrer
les
mdicaments

Figure10-2 : Carte des processus

Le diagramme de flux de donnes (DFD)


Un diagramme de flux de donnes (ou plus simplement, diagramme de
flux) permet de reprsenter la manire dont les donnes sont traites
(transfres, modifies) par le systme dinformation (personnes et applications).
Plusieurs modles de reprsentation existent. Dans le modle le plus
couramment utilis (figure10-3):
Les processus sont reprsents par des cercles.

114

Livre Constant.indb 114

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

Les entits externes au systme (personnes physiques ou morales,


groupes de personnes ou autres systmes) sont reprsentes par des
rectangles3.
Les flux de donnes sont reprsents par des flches.
Les zones de stockage (bases de donnes, fichiers) sont reprsentes
par deux segments parallles.

8
Consulter le
plan de soins

lments de
prescription

lments de
prescription

Infirmire

3. Remarquons que
les rectangles ne
font pas partie du
systme.

9
Valider
ladministration

Validation administration infirmire

lments de
prescription

Validation

4
Mettre jour
les
informations
patient

lments de
prescription

Plan de soins

Info
patient

Dossier
patient

ls de prescription
Mdecin

Ligne de presc.
Interactions
mdicamenteuses

Infos
md.

Demande
dinfos

Plan de soins

3
Traiter une
ligne de
prescription

Validation

Info
patient

Ligne de
prescription

lts de
Infos
prescription patient

1
Consulter
le dossier
patient

2
Consulter
base mdicamenteuse

7
Valider la
prescription

Informations
mdicament

Infos mdic.

5
Consulter la
prescription

6
Rechercher
des infos
patient

lments de
prescription
Pharmacien

Base
mdicamenteuse

Informations
patient

Informations
patient

Figure10-3 : Un diagramme de flux de donnes

115

Livre Constant.indb 115

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Chaque processus dun diagramme peut tre clat en processus plus


dtaills dans de nouveaux diagrammes de flux. ce propos, remarquons que le diagramme de contexte, dont il a dj t question dans cet
ouvrage, est le plus simple des diagrammes de flux. Il reprsente le processus global correspondant au systme ltude, entour des personnes
ou logiciels avec lesquels il ragit.
Le diagramme de flux met en vidence le partage du travail entre le systme ltude et son environnement. Cest donc un bon moyen de donner
une vision globale des diffrents processus et de leurs relations entre eux,
et il est gnralement bien compris des utilisateurs. Il peut donc tre utilis lors du recueil des besoins dans le but dclaircir ou de valider ce qui
a t formul oralement. Bien entendu, il peut apparatre dans un cahier
des charges.
Quelques rgles dlaboration du diagramme:
Tout processus doit comporter une flche en entre et une flche en
sortie.
Une flche ne peut pas relier directement deux processus.
Quelques rgles pratiques:
Numroter les processus facilite grandement la lecture.
Ne pas mettre trop dentits dans un diagramme. Suivre la rgle du
sept plus ou moins deux. Au-del de neuf, le diagramme est illisible.
Si un processus est complexe, on peut le modliser dans un autre
diagramme. Dans ce cas, on utilisera une numrotation pointe pour
numroter les sous-processus (par exemple, le processus numro4 se
dcomposera en4.1, 4.2, etc.).

Le diagramme de squence
Le diagramme de squence (figure 10-4) permet de modliser les flux
dinformations entre acteurs, en faisant ressortir lenchanement chronologique des activits dun processus.
Horizontalement, de gauche droite, on reprsente les lignes de vie
des diffrents acteurs. Des messages, synchrones ou asynchrones, transitent dun acteur lautre. Verticalement, on peut lire lenchanement des
actions dans le temps.
Le diagramme de squence est un outil danalyse plus que de recueil
ou de spcification. En dehors des domaines techniques o la synchronisation des tches est complexe (tlcoms), il est rare de le rencontrer
dans un cahier des charges. Il est en revanche trs utile pour alimenter la
rflexion permettant de dcider des oprations automatiser et sur les
processus optimiser la suite dune informatisation. Le diagramme de

116

Livre Constant.indb 116

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

la figure 10-4 reprsente un processus manuel. Lautomatisation de ce


processus permettra de supprimer environ la moiti des tches (mises
jour, transmission manuelle dinformations et archivage).
Mdecin

Gestionnaire
dossier patient

Infirmier

Pharmacien

Prparateur

Prescription
Prescription

Mise jour

Notification de non validation

Ordre de
dlivrance

Compte-rendu de dlivrance
Compte-rendu dadministration
Mise jour
du dossier
Relev dadministration
Archivage

Figure10-4 : Un diagramme de squence

Le diagramme entit-association ou diagramme de classes


Ce diagramme, trs technique, peut tre utile dans certains cas, mais na
pas toujours sa place dans un cahier des charges (figure10-5). Il permet
de reprsenter les attributs des donnes et les relations entre les donnes
du systme. Dans le cadre de la phase de dfinition des besoins, laborer
ce modle permet davoir une vision exhaustive des donnes manipules
par le systme. Cest donc un modle conceptuel des donnes, indpendant des
aspects techniques, que lon utilise. Aprs transformation, il aboutira
un modle physique, qui lui, dpend de limplmentation physique (base
de donnes).
Lexprience montre que la lecture (sans parler de llaboration mme)
dun tel modle nest pas toujours aise pour les utilisateurs non informaticiens. Il est utile daccompagner le diagramme de texte explicatif.

117

Livre Constant.indb 117

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Lors du recueil, les questions se poser, et poser aux reprsentants des


utilisateurs, sont:
Quelles sont les donnes manipules par le systme?
Quelles donnes le systme devra-t-il stocker?
Les entits sont des donnes, ou plus gnralement, des ensembles
de donnes: un client, un compte, une facture Elles comportent des
attributs (par exemple, le nom du client). Les entits sont gnralement
reprsentes par des rectangles.
Les relations comportent, pour chaque entit relie, une cardinalit. Par
exemple, la relation entre un client et ses comptes en banque est 1-N,
signifiant que chaque client peut avoir un ou plusieurs comptes, et
chaque compte appartenant un client et un seul. Les relations sont
gnralement reprsentes par des lignes dont la terminaison indique la
cardinalit. Les relations peuvent elles-mmes comporter des proprits
(des ovales avec Merise, des rectangles avec UML).
Les questions supplmentaires poser sont donc:
Quelles sont les donnes contenues dans cette entit?
Quelles sont les relations entre ces deux donnes?
Il y a des dizaines de faons de reprsenter les entits et les relations ( la
Merise, la UML, rectangles, ovales, losanges). Le plus important est
que tous les acteurs utilisent le mme langage graphique. On sadaptera
la culture ou aux standards du client ou de lentreprise pour laquelle on
travaille. La figure10-5 utilise un formalisme proche dUML pour reprsenter les entits et relations dans le domaine de la prescription mdicale.
Patient

Sjour
0

0..*
Bon de livraison

0..*
Prescription

Compte-rendu
danalyse
pharmaceutique

Compte-rendu
dadministration
1

1..*
lment de
livraison

0..*

lment de
prescription

lment
dadministration
1

0..*

Composant livr

Composant
prescrit

lment de
posologie

Composant
administr

Figure10-5 : Un diagramme entit-association

118

Livre Constant.indb 118

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

Les adeptes dUML utilisent des diagrammes de classe. Une classe


dobjets contient la fois des attributs et des traitements (ou oprations).
En principe, un modle de classes devrait tre diffrent dun modle entits-relations. Dans la pratique, on saperoit que les modles UML sont
souvent rduits des entits et des relations (mme dans les ouvrages
consacrs UML).
Lide ici nest pas dentrer dans les dtails de la conception dun modle
de donnes (il y a dexcellents ouvrages pour cela), mais de montrer
comment un tel modle peut tre utilis comme outil danalyse et de
spcification dans le cadre dun cahier des charges. Les six tches (imbriques et cycliques, bien sr) sont les suivantes:
Identifier les entits. Les entits sont des objets ou des agrgations de
donnes. On les reprsente par des rectangles.
Identifier les attributs (proprits). On indiquera celles utiles au systme ltude (rappelons quil ne sagit pas, au stade du cahier des
charges, de modliser une base de donnes). Lun de ces attributs est
lidentifiant (quivalent la cl primaire sur un modle physique).
Dcrire les entits et attributs, de prfrence dans le dictionnaire de
donnes.
Identifier les relations entre donnes. On peut commencer ce travail
tte repose, mais le modle ainsi construit (ou plutt, en cours de
construction) sera ds que possible soumis lavis des reprsentants
des utilisateurs.
Dfinir les cardinalits des relations.
Vrifier la cohrence de lensemble et remonter la premire tape si
ncessaire.
Au risque de nous rpter, rappelons-le : il sagit ici de modliser les
besoins, et non la solution. Au fur et mesure que lon dcrira de nouvelles exigences fonctionnelles, on les confrontera au modle de donnes,
en cherchant liminer les incohrences. Le processus de construction
est donc itratif et imbriqu aux autres processus.
Principe de simplicit
Le principe de simplicit a t nonc par plusieurs philosophes. Une des formulations les plus connues de ce principe est le rasoir dOckham, qui snonce ainsi:
Entia non sunt multiplicanda praeter necessitatem, littralement Les entits
ne doivent pas tre multiplies par-del ce qui est ncessaire. On gagne utiliser
ce principe sur tous les types de diagramme, et particulirement sur le diagramme
entits-associations. Inutile de procder un dcoupage fin en microentits si cela
naide pas la rflexion sur les besoins. Parfois, ce principe gagne mme tre
pouss jusqu sa limite : ne pas faire de diagramme l o cela ne savre pas
ncessaire.

119

Livre Constant.indb 119

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Le diagramme tats-transitions
Rappelons quun diagramme tats-transitions reprsente, sur le plan
informatique, un automate dtats finis. De ce fait, il permet de reprsenter des processus de manire concise, prcise et non ambigu, facilement
comprhensible par les concepteurs et ralisateurs du systme.
On retrouvera ce type de schma dans des cahiers des charges pour des
logiciels temps rel, mais pas seulement. Il peut tre trs efficace pour
dcrire un processus administratif, par exemple. La figure10-6 prsente
un diagramme dtats-transitions pour un logiciel de gestion de dossier.
Il a t labor par un groupe de travail compos de fonctionnaires de
ladministration publique, anim par un assistant la matrise douvrage.

Dossier
complet

En attente de la
commission
technique

En cours
dinstruction

Complment
dinstruction
Inscription

Inscription
directe

Inscrit en
commission
technique

Avis OK

Sursis
statuer

Vrifi pour
commission
plnire

Inscription

Inscrit en
commission
plnire
dcision
OK
En attente de
ralisation

Rejet

Ralisation

Figure10-6 : Un diagramme tats-transitions

120

Livre Constant.indb 120

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

Voici une squence classique dlaboration de ce type de diagramme:


1. Lors dune premire runion du groupe de travail avec le donneur
dordre (direction, administration centrale), lanalyste recueille des
informations sur les tapes du cheminement du dossier. Il ne prsente
pas de diagramme (risque de confusion).
2. En interviews individuelles dutilisateurs sur le terrain, lanalyste
recueille les pratiques (qui peuvent diffrer sensiblement de la procdure officielle).
3. Seul, le consultant labore le diagramme tats-transitions, en notant
les incohrences, en tentant de les rsoudre si possible.
4. Lanalyste parcourt les textes rglementaires. nouveau, il note les
carts et les incohrences. Il complte ou modifie le diagramme.
5. Lors dune deuxime runion du groupe de travail, lanalyste prsente
le diagramme tats-transitions au donneur dordres et lui demande
son avis. Si aucun consensus nest trouv, on peut remonter aux
tapes2 4.
6. Lanalyste met le diagramme au propre. Il demande au groupe de travail
de le valider.
7. Si cela est possible, le diagramme est envoy la matrise duvre
pour avoir son avis.
Les questions poser aux diffrents acteurs sont:
Quel est le cheminement (du dossier, dun objet)?
Dans quels tats peut se trouver (le dossier, lobjet)?
Quel vnement va modifier (le dossier, lobjet)?
Que se passe-t-il suite cet vnement?
Que se passe-t-il si cet vnement na pas lieu? (exception)
Comme pour les autres types de diagramme, le diagramme tats-transitions peut servir modliser un processus existant ou un processus
informatiser. Il est souvent long constituer, surtout lorsque les interlocuteurs sont plus familiariss avec des procdures crites (procdures
administratives) quavec des schmas.

Les organigrammes, arbres et tables de dcision


Des rgles de gestion fort complexes, par exemple sur le plan juridique,
peuvent parfois sexprimer trs facilement, et devenir trs claires pour la
matrise duvre, si elles sont exprimes sous forme de tables ou darbres
de dcision, ou sous forme dorganigramme.
Lors de llaboration dun cahier des charges pour une application de
porte nationale, nous avions dtermin 24 rponses la question de
savoir qui, parmi le pre, la mre ou autre reprsentant lgal droit

121

Livre Constant.indb 121

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

linformation sur un enfant, en fonction de la situation. Un tableau


24 lignes et 10 colonnes a rendu la situation beaucoup plus facile
comprendre. Quant aux informaticiens, selon leurs propres termes, ils
navaient plus qu coder.

La bote outils
La modlisation sous forme graphique est une bote outils. Pour reprsenter la mme information, on a parfois le choix entre plusieurs outils.
Inversement, un outil peut avoir plusieurs usages. Il ne sagit pas de
tout reprsenter avec le mme outil, ni dutiliser tous les outils tout
prix. Rappelons que lobjectif premier est ici de se faire comprendre de
tous les acteurs et dajouter de la prcision au texte. Par exemple, dans un
cahier des charges pour une application de gestion, on pourra utiliser un
diagramme tats-transitions pour montrer le circuit dune demande, suivi
dun diagramme de squence, ou un seul diagramme de flux. La question
se poser est: comment reprsenter linformation de manire ce quelle
soit comprhensible de tous, sans ambigut?
Il y a un travers dans lequel nous avons tous tendance tomber: nous
nutilisons que les outils que nous matrisons. Et comme nous matrisons
mieux les outils que nous utilisons souvent, nous finissons par nutiliser
quun outil ou deux. Pour ne pas tomber dans ce travers, il ne faut pas
hsiter exprimenter.

Maquettes et prototypes
La maquette papier

4. Maquette faible
fidlit (low-fi) compare un prototype.

Une maquette est un modle qui prfigure un produit futur. Rappelons


qu la diffrence dun prototype, la maquette est toujours un produit
jetable. Le but ici nest pas de commencer dvelopper le produit, ni
mme le spcifier, mais de visualiser son aspect ou son comportement.
Il ne sagit pas de spcifier le produit, et encore moins de dvelopper un
prototype. Plus le support sera temporaire4 (tableau blanc, notes auto
adhsives), et moins on sera tent de faire des spcifications dtailles et
de concevoir le produit.
La maquette papier est un moyen de recueillir des exigences, de les
analyser interactivement et de les faire valider rapidement par les interlocuteurs. Concrtement, cela consiste schmatiser sur le papier, ou
sur un tableau blanc, un dessin dcran, par exemple. Plusieurs dessins
dcrans sur feuilles de papierA4 disposs sur une grande feuille de papier
blanc permettent de simuler des enchanements dcrans et des interactions avec les utilisateurs. On peut utiliser des moyens dexpression plus

122

Livre Constant.indb 122

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

riches, comme des outils de prsentation, HTML, voire un dessin anim.


Mais lide est toujours la mme.
Une maquette papier est utile pour faire visualiser les fonctions attendues
des personnes peu habitues travailler sur des modles abstraits, de
les aider imaginer eux-mmes une prfiguration du futur produit. Une
fois que les participants se sont mis daccord, il est plus facile de formaliser
ces exigences, sous forme de cas dutilisation par exemple.

Le prototypage
Contrairement la maquette papier, un prototype est vivant. Cest du
logiciel. Il peut tre jetable ou au contraire rutilisable, si on a lintention
de lintgrer dans le produit fini. Prototyper, cest donc entrer provisoirement (et par exception) dans la phase de ralisation pour exprimenter
un fragment du produit venir.
Plusieurs formes de prototypes sont envisageables, en particulier:
Le prototype horizontal: il simule lapplication visuellement (enchanement dcrans), sans que toutes les fonctions soient prsentes. Il est
utilis en particulier pour montrer et tester les enchanements dcrans.
Il est visuellement proche de lapplication venir, mais les crans sont
creux ou muets : les fonctions ne sont pas dveloppes et ne
seront pas excutes.
Le prototype vertical: une seule fonction est compltement dveloppe. Ce type de prototype est utilis pour tester une fonction ou
une proprit du logiciel, comme la fiabilit, la scurit, ou le temps
de rponse.
En pratique, le prototypage est faisable si une quipe de dveloppement
est prsente et interagit avec la matrise douvrage. Cest le cas dans une
grande entreprise ou une administration qui dveloppe une application
en interne. Immanquablement, il y aura un moment o les reprsentants
des utilisateurs vont se trouver face face avec les dveloppeurs. Cest
lassistant la matrise douvrage qui doit grer le choc des cultures. Un
talent danimateur et de modrateur est requis, car il peut y avoir des
tensions.
Quel que soit le type de prototype dvelopp, il risque de driver vers un
dbut de dveloppement. Cela peut tre intentionnel (mthodes agiles),
mais cela doit tre contrl. Avant de faire dvelopper un prototype, il
faut estimer les risques que comporte cette incursion dans la phase de
ralisation: spcifications informelles et rampantes, court-circuitage invitable entre matrise douvrage et matrise duvre, et illusion, de la part
de la matrise douvrage, que le dveloppement du produit est presque
fini (alors quil na pas encore commenc).

123

Livre Constant.indb 123

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Matrices CRUD et RACI


Un des moyens de dtecter les incohrences et incompltudes est la
matrice CRUD (de langlais Create, Read, Update, Delete). Une entit doit pouvoir tre cre, lue, mise jour et supprime du systme. Si lune de ces
oprations ne peut tre effectue par le systme pour une entit donne,
il faut pousser lanalyse et comprendre pourquoi. Ce nest pas ncessairement une incompltude (par exemple, on peut vouloir que certaines
entits ne soient jamais supprimes), mais il faut sen assurer.
Une autre matrice que lon peut utiliser est celle des responsabilits, ou
matrice RACI (Responsible, Accountable, Consulted, informed) dfinissant le rle
des acteurs par rapport aux fonctions. Comme pour la matrice CRUD, il
ne sagit pas de dtecter 100% des incohrences, mais daffiner lanalyse.

valuer la faisabilit et le cot


Il est rare que le demandeur (matrise douvrage ou utilisateur) connaisse
le cot de ses exigences. Dune part, par ce que ce qui est simple lexcution peut tre trs complexe implmenter sous forme de logiciel
(linverse est galement vrai: certains utilisateurs nosent pas demander
une fonction en pensant que leur demande est irraliste, alors quelle
est trs simple raliser). Dautre part, par ce que le cot dune fonction
dpend du contexte, de ce qui a t ralis par ailleurs.
Il est donc important de conseiller le demandeur sur le cot estim de
sa demande. Ce cot nest pas seulement financier. La ralisation dune
exigence peut ncessiter des dlais supplmentaires, une formation des
utilisateurs, une nouvelle organisation, ou avoir des rpercussions dans
dautres domaines.
Par faisabilit, on entend aussi lestimation des risques. Une nouvelle
fonction peut avoir des consquences sur le dlai de livraison de lensemble de lapplication, ou sur ses performances, ou sa scurit.
Cest au matre douvrage de dcider de lopportunit de raliser une exigence, aprs avoir t inform des consquences. Le diagramme de Kano
(figure10-7) permet de chercher le rapport entre le degr de ralisation
dune caractristique et le degr de satisfaction du client. Le principe est
de ranger chaque caractristique du produit (fonction ou caractristique
non fonctionnelle) dans une des trois catgories:

124

Livre Constant.indb 124

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 10 Ltape danalyse

Fonction obligatoire (indispensable): son absence cre de linsatisfaction chez le client, mais sa prsence napporte pas de satisfaction particulire (souvent considre comme vidente, donc passe sous silence
lors dune interview).
Fonction satisfaction proportionnelle: le niveau de satisfaction est
proportionnel la prsence de la fonction ou la performance de la
caractristique (gnralement, elles mergent les premires lors dune
interview ou dune enqute).
Fonction attractive : son absence ne cre pas de frustration, mais sa
prsence apporte une satisfaction supplmentaire (rarement exprimes
lors dinterviews, mais surtout avec des techniques de crativit).
Pour savoir dans quelle catgorie cette fonction doit tre range (du point
de vue de lutilisateur, bien sr) il faut lui demander comment il ragirait si ce besoin tait combl et sil ne ltait pas, puis de lui proposer,
pour chaque question, quatre rponses possibles: jaime, cest normal de lavoir, je suis indiffrent et je naime pas. On consigne
ensuite les rsultats dans une matrice (tableau) quatre lignes et quatre
colonnes, correspondant ces quatre rponses aux deux questions. Ils
permettent de dterminer, pour chaque besoin exprim, sil est indispensable, de base, ou constitue un plus.
Satisfaction client

es
ctiv
ttra
a
les
s
nel
tion
c
n
n
o
ti
Fo
por
p ro

Exigence
non ralise

nc
Fo

s
tion

es
atoir
oblig
s
n
tio
Fonc

Exigence
ralise

Insatisfaction client

Figure10-7 : Diagramme de Kano

125

Livre Constant.indb 125

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Check-list danalyse
Il ny a pas vritablement de fin dtape danalyse, il ne sagit donc
pas ici de vrifier quun objectif a t atteint. Cette check-list est utiliser
priodiquement pour vrifier que lon avance dans la bonne direction et
que les moyens ncessaires et suffisants sont mis en uvre pour amliorer la cohrence, la compltude des exigences. Il sagit aussi dviter le
phnomne de lanalyse interminable (en anglais analysis paralysis). Cette
liste peut donc donner limpression quelle fait double emploi avec les
check-lists du recueil et des spcifications.
On a examin, revu, affin et si ncessaire modifi le diagramme de
contexte.
Le dictionnaire de donnes a t cr, et il est rgulirement enrichi.
Les exigences ont t dcomposes de manire suffisamment fine pour
reflter les besoins les plus proches du terrain (utilisateurs).
Les exigences ont t dcomposes de manire suffisamment fine pour
tre comprhensibles sans ambigut par le matre duvre.
On na pas dcompos les exigences au-del du strict ncessaire.
Les diffrents acteurs ont activement particip lanalyse.
Chaque cas dutilisation a un acteur dfini.
Chaque fonction a un utilisateur dfini.
Il y a une traabilit entre les exigences de diffrents niveaux.
On a dfini des priorits entre exigences.
On a utilis des modles graphiques lorsque cela tait ncessaire.
On a utilis une matrice CRUD.
On a utilis une matrice RACI.

126

Livre Constant.indb 126

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 11

Les exigences
non fonctionnelles
Difficiles recueillir, analyser et spcifier, lies la fois au matriel, au
logiciel et lusage qui en est fait, les exigences non fonctionnelles sont
souvent ngliges. Pourtant, cest la satisfaction de ces exigences qui fait
la qualit, et donc dans une large mesure, la valeur dun logiciel.

Les caractristiques de qualit


Un logiciel ne peut tre dcrit ni par ses seules fonctions (point de
vue du matre douvrage), ni par ses seules caractristiques techniques
(contraintes de la matrise duvre). Le cahier des charges doit ncessairement comporter des caractristiques relatives la qualit du logiciel,
appeles exigences non fonctionnelles.
Comme les exigences fonctionnelles, celles-ci doivent tre structures
selon leur typologie. Plusieurs typologies existent pour dcrire la qualit
du logiciel. La plus ancienne est celle de McCall, qui permet de caractriser la qualit du logiciel selon un certain nombre de facteurs et de
critres.
Dans les paragraphes qui suivent, nous dcrivons les exigences non
fonctionnelles en utilisant la structuration par caractristiques et souscaractristiques de qualit selon la norme ISO/CEI 25000. Cette norme a
lavantage de dcrire la qualit du logiciel de la manire la plus complte
et la moins redondante possible.
Dans la pratique, pour laborer un cahier des charges, on ne suivra pas
ncessairement ce mme schma. Chaque modle de cahier des charges
structure les exigences non fonctionnelles selon un schma qui lui est
propre. ISO25000 pourra servir de trame et de liste de contrle lors de
llaboration dun cahier des charges ou de lutilisation dun modle de
cahier des charges.

Livre Constant.indb 127

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Qualit du
logiciel

Capacit
fonctionnelle

Fiabilit

Facilit
dutilisation

Rendement

Facilit de
Comportement
Aptitude
Maturit
comprhension
vis--vis du
Exactitude
Tolrance aux
Facilit d
temps
Conformit
fautes
apprentissage
Comportement
rglementaire Possibilit de
Facilit
vis--vis des
Interoprabilit rcupration
dexploitation
ressources
Scurit
Conformit
Attractivit
Conformit
Conformit

Maintenabilit

Portabilit

Facilit
danalyse
Facilit de
modification
Stabilit
Testabilit
Conformit

Facilit
dadaptation
Facilit
linstallation
Interchangeabilit
Conformit

Figure11-1 : Caractristiques et sous-caractristiques ISO25000

La norme ISO/CEI25000
1. La srie normative
ISO/CEI25000
rsulte de la fusion
entre plusieurs
normes dont ISO/
CEI9126 et ISO/
CEI14598.

La norme ISO250001, relative la qualit du produit logiciel, donne des


outils pour, dune part valuer la qualit du logiciel, et dautre part pour
construire la qualit. Selon cette norme, la qualit du logiciel peut tre
perue sur trois niveaux:
La qualit interne (internal quality) correspond au niveau structurel danalyse, et peut tre value par examen du code source, de larchitecture,
des spcifications; cest la perspective de larchitecte de lapplication,
du concepteur, du dveloppeur.
La qualit externe (external quality) correspond au niveau comportemental, visible et mesurable en particulier lors de tests; cest la qualit vue
avec la perspective du chef de projet et des quipes de validation.
La qualit de fonctionnement (quality in use) correspond au point de vue
de lutilisateur. Elle se dcompose en quatre caractristiques: lefficacit
(relative latteinte des objectifs de lutilisateur), la productivit (conomie de temps, defforts) la scurit (risques sur lutilisateur, le logiciel,
lenvironnement), et la satisfaction de lutilisateur.
La norme se rfre galement la qualit du processus de dveloppement, sans dfinir ce processus (il y a dautres normes pour cela). Ces
diffrents niveaux de qualit du produit et du processus sont interdpendants : la qualit de fonctionnement dpend de la qualit externe,
qui dpend de la qualit interne, qui elle-mme dpend de la qualit du
processus de dveloppement.

128

Livre Constant.indb 128

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 11 Les exigences non fonctionnelles

Cette reprsentation tage de la qualit pourra tre mise profit pour


structurer les exigences dans un cahier des charges2, par exemple, selon
le schma:
qualit en utilisation exigences utilisateur;
qualit externe exigences produit;
qualit interne contraintes techniques;
qualit du processus contraintes projet.
Les contraintes lies au projet et les contraintes techniques seront abordes plus loin. Examinons ici les exigences de qualit interne et externe
telles que dfinies par la norme, cest--dire sous forme de caractristiques et sous-caractristiques.

2. Voir au chapitre13
comment formuler
les exigences non
fonctionnelles, et
au chapitre14 leur
place dans les diffrents modles de
cahiers des charges.

Capacit fonctionnelle
La capacit fonctionnelle (ou fonctionnalit) est lensemble dattributs portant
sur lexistence dun ensemble de fonctions et leurs proprits donnes. Les proprits
sont celles qui satisfont aux besoins exprims ou implicites (norme
ISO/CEI25000).
Elle se dcompose en cinq sous-caractristiques:
Aptitude: attributs du logiciel portant sur la prsence et ladquation
dune srie de fonctions pour des tches donnes.
Exactitude: ensemble des attributs de logiciel portant sur la fourniture
de rsultats justes ou convenus.
Conformit rglementaire : respect des normes, conventions et rglementations de droit.
Interoprabilit: capacit interagir avec des systmes donns.
Scurit: aptitude empcher tout accs non autoris (accidentel ou
dlibr) au programme ou aux donnes.
En pratique, dans un cahier des charges, la section exigences fonctionnelles dcrira laptitude, et rien de plus. La conformit rglementaire sera
dfinie dans la section rgles de gestion. Les trois autres sous-caractristiques (exactitude, conformit rglementaire, scurit) seront dcrites
dans des paragraphes correspondants, dans la section exigences non
fonctionnelles.
Pour spcifier les exigences dinteroprabilit et de scurit, un moyen
pratique et efficace consiste faire rfrence des normes relatives ces
sous-caractristiques.

Fiabilit
La fiabilit est lensemble dattributs portant sur laptitude du logiciel maintenir
son niveau de service dans des conditions prcises et pendant une priode dtermine.

129

Livre Constant.indb 129

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Ce critre se dcline en:


Maturit: frquence de dfaillances dues des dfauts du logiciel.
Tolrance aux fautes: aptitude du logiciel maintenir un niveau de service acceptable en cas de dfaut du logiciel ou de violation de son interface.
Possibilit de rcupration: capacit rtablir son niveau de service et
de restaurer les informations directement affectes en cas de dfaillance,
et sur le temps et leffort ncessaires pour le faire.
Parmi les mesures utilises pour la fiabilit, citons le temps moyen entre
deux dfaillances (MTBF, mean time between failures), la dure moyenne de
dfaillance (mean down time), ou le temps mis par le systme pour redmarrer. Nous sommes l la limite entre les exigences produit (trs
dpendantes du matriel) et les exigences de service. Formuler ces
exigences dans un cahier des charges est tout fait possible, mais la formulation est trs dpendante des fournitures attendues (logiciel seul,
matriel et logiciel, services, etc.).

Facilit dutilisation (utilisabilit)


La notion dutilisabilit est proche de celle dergonomie. Lergonomie est
ltude des situations de travail et des relations entre ltre humain et
un systme. Elle a pour objectif damliorer le confort, voire le plaisir, de
lutilisateur et par voie de consquence lefficacit dans le travail et dans
lutilisation dun produit (en loccurrence, un logiciel). Le terme dutilisabilit englobe un primtre plus large, qui comprend lefficacit. De plus,
le mot ergonomie a t largement galvaud par les informaticiens, qui le
mettent un peu toutes les sauces, et par les utilisateurs, qui ne sont pas
suffisamment prcis dans leurs exigences.
La norme ISO/CEI 25000 dfinit la facilit dutilisation (ou utilisabilit)
comme lensemble dattributs portant sur leffort ncessaire pour lutilisation et sur lvaluation individuelle de cette utilisation par un ensemble
dfini ou implicite dutilisateurs. Elle se dcline en:
Facilit de comprhension: attributs du logiciel portant sur leffort que
doit faire lutilisateur pour reconnatre la logique et sa mise en uvre.
Facilit dapprentissage: attributs du logiciel portant sur leffort que doit
faire lutilisateur pour apprendre son application (par exemple, matrise
de lexploitation des entres, des sorties).
Facilit dexploitation: attributs du logiciel portant sur leffort que doit
faire lutilisateur pour exploiter et contrler son application.
Attractivit : capacit du produit logiciel tre attrayant pour lutili
sateur.

130

Livre Constant.indb 130

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 11 Les exigences non fonctionnelles

Lutilisabilit est difficile dfinir. Une faon de faire consiste exiger


la conformit des standards dutilisabilit ou une charte dergonomie. De tels documents imposent des rgles, comme par exemple sur le
nombre maximal de boutons par cran, le nombre dobjets sur une liste
ou les combinaisons de couleurs autorises.
Une autre manire de faire consiste formuler les exigences dutilisabilit
un plus haut niveau, en loccurrence au niveau de lutilisateur. Voici par
exemple comment peuvent sexprimer quatre exigences dutilisabilit,
correspondant aux quatre sous-caractristiques (facilit dapprentissage,
de comprhension, dexploitation et dattractivit):
Pour 80% des mdecins, une formation initiale de 2heures sera
suffisante lappropriation des fonctions de prescription.
Aprs un mois dutilisation quotidienne, 80% des utilisateurs
forms loutil pourront lutiliser sans faire appel une
aide extrieure.
Le temps moyen mis par un mdecin form au logiciel pour
prescrire un mdicament avec le module de prescription ne doit
pas excder de 10 % le temps moyen mis par un mdecin pour
effectuer cette action manuellement.
Aprs un mois dutilisation quotidienne, 80% des utilisateurs
devront se dclarer satisfaits ou trs satisfaits par le
systme.
Remarquons cette proportion de 80%. On ne peut pas exiger quune fonction faisant intervenir des tres humains soit ralise 100 %. Quatre
utilisateurs sur cinq efficients et satisfaits est beaucoup plus raliste.

Rendement
La norme ISO/CEI25000 dfinit le rendement comme lensemble dattributs
portant sur le niveau de service dun logiciel et la quantit de ressources utilises, dans
des conditions dtermines. Celui-ci se dcline en:
comportement vis--vis du temps, portant sur les temps de rponse et
de traitement, ainsi que sur les dbits lors de lexcution de sa fonction;
comportement vis--vis des ressources, portant sur la quantit de ressources utilises et sur la dure de leur utilisation lorsquil excute sa
fonction.
Dans un cahier des charges, il est rare que lon spcifie directement le
comportement vis--vis des ressources (mmoire ou espace disque).
En gnral, il est plus utile de spcifier lexigence un plus haut niveau
(nombre dutilisateurs simultans). Le comportement vis--vis du temps
sera galement dcrit comme une exigence non fonctionnelle de niveau

131

Livre Constant.indb 131

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

utilisateur (temps de rponse). Ces deux exigences sont interdpendantes. Cela donne:
Le systme pourra tre utilis simultanment par 150
utilisateurs.
pleine charge, le temps daffichage dun cran complet sera
infrieur ou gal 1,5seconde.
Remarquons que cette la premire exigence de rendement est la dclinaison dune contrainte organisationnelle, voire dun objectif stratgique.
La seconde exigence drive dune exigence dutilisabilit, et correspond
un seuil psychologique. Ces deux exigences sont interdpendantes: avec
150 utilisateurs simultans, le systme rpondra en moins dune seconde
et demie.

Maintenabilit
La maintenabilit est formellement dfinie comme lensemble dattributs portant sur leffort ncessaire pour faire des modifications donnes
(ISO/IEC25000). Elle se dcompose en:
Facilit danalyse : attributs du logiciel portant sur leffort ncessaire
pour diagnostiquer les dficiences ou les causes de dfaillance, ou pour
identifier les parties modifier.
Facilit de modification: attributs du logiciel portant sur leffort ncessaire pour modifier, remdier aux dfauts, ou changer denvironnement.
Stabilit: attributs du logiciel portant sur le risque des effets inattendus
des modifications.
Testabilit: attributs du logiciel portant sur leffort ncessaire pour valider
le logiciel modifi.
La maintenabilit est une caractristique essentiellement interne, invisible de lutilisateur. On peut cependant spcifier des contraintes de
service lutilisateur. Le modle Volere (voir chapitre14) regroupe dans
un mme paragraphe les exigences de maintenabilit et de support. Il
sagit en ralit dexigences de maintenance plutt que de maintenabilit.

Portabilit
La portabilit est lensemble dattributs portant sur laptitude du logiciel
tre transfr dun environnement lautre (norme ISO/CEI 25000).
Elle se dcompose en:
Facilit dadaptation: elle concerne les attributs du logiciel portant sur
la possibilit de son adaptation diffrents environnements donns
sans avoir recours dautres actions ou moyens que ceux prvus cet
effet pour le logiciel considr.

132

Livre Constant.indb 132

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 11 Les exigences non fonctionnelles

Facilit linstallation: effort ncessaire pour installer le logiciel dans


un environnement donn.
Conformit relative aux rgles de portabilit: attributs du logiciel permettant celui-ci de se conformer aux normes ou conventions ayant
trait la portabilit.
Interchangeabilit : aptitude du logiciel tre utilis la place dun
autre logiciel dans le mme environnement.
La portabilit stricto sensu (facilit dadaptation) induit une contrainte
trs forte sur le dveloppement et larchitecture du logiciel. Aussi, on ne
lexigera que si cela savre ncessaire, aprs une ventuelle tude dopportunit. En revanche, la facilit dinstallation est une exigence forte
valeur ajoute, surtout si le logiciel doit tre install sur des postes individuels. Il faudra la spcifier dans tous les cas.

Zoom sur lutilisabilit


Il y a au moins trois manires de spcifier lutilisabilit dans un cahier
des charges. La premire sappuie sur les quatre sous-caractristiques
dutilisabilit de la norme ISO25000 dj mentionne: facilit dapprentissage, facilit de comprhension, facilit dexploitation (utilisation au
quotidien) et attractivit.
La deuxime faon de structurer les exigences dutilisabilit sappuie galement sur ISO25000, cette fois sur la qualit de fonctionnement (en anglais,
quality in use). Celle-ci se dfinit par quatre critres:
Lefficacit : capacit du logiciel permettre aux utilisateurs datteindre
leurs objectifs avec exactitude et exhaustivit.
La productivit: capacit optimiser le temps et leffort de lutilisateur.
La scurit: capacit du produit logiciel limiter les risques sur la sant,
les activits ou lenvironnement des utilisateurs, en particulier suite
une dfaillance(ici, le terme innocuit, traduction de langlais safety, serait
sans doute plus appropri).
La satisfaction: correspond une attitude positive de lutilisateur lors de
linteraction avec le produit.
La troisime manire de structurer les exigences sappuie sur les critres
dergonomie dfinis par la norme AFNOR Z-67-133-13, base sur les travaux de Bastien et Scapin. Cette norme dfinit lergonomie du logiciel par
sept critres (figure11-2):
la compatibilit;
le guidage;
lhomognit;

3. AFNORZ67-133-1.
Dfinition des critres ergonomiques
de conception et valuation des interfaces
utilisateurs, 1991.

133

Livre Constant.indb 133

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

la souplesse;
le contrle explicite;
la gestion des erreurs;
la concision.

Compatibilit
Concision

Guidage

Ergonomie

Gestion des
erreurs

Homognit

Contrle
explicite

Souplesse

Figure11-2 : Sept critres dergonomie

Examinons chacun de ces critres et la manire de les dcliner sous forme


dexigences.

Compatibilit
La compatibilit est la capacit sintgrer dans lactivit des utilisateurs. Elle concerne laccord pouvant exister entre les caractristiques
professionnelles et psychologiques de lutilisateur (mmoire, perceptions, habitudes, etc.) et lorganisation du dialogue entre lutilisateur et
lapplication. Une bonne compatibilit rduit considrablement le temps
dapprentissage dune application.
On doit exiger que le logiciel sadapte au mtier de chaque profil utilisateur. Le systme doit non seulement intgrer les procdures, qui relvent
plutt dexigences fonctionnelles, mais sadapter la psychologie et la
physiologie de lutilisateur. Un exemple typique est celui de lutilisation
de la souris, exclue pour les utilisateurs qui saisissent des donnes en
masse, mais ncessaire pour les dcideurs sur une application intranet.
La segmentation des profils utilisateurs et lanalyse de leurs tches sont
donc ncessaires avant toute spcification.

134

Livre Constant.indb 134

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 11 Les exigences non fonctionnelles

Guidage
Le guidage est lensemble des moyens mis en uvre pour conseiller,
orienter, informer et conduire lutilisateur lors de ses interactions avec
lordinateur. On distingue le guidage explicite, qui se traduit par laide
en ligne, les messages derreur, davertissement ou dinformation, et le
guidage implicite, qui concerne les formats de saisie des informations, la
disposition des informations sur lcran, etc.
Le guidage est li la navigabilit. Lutilisateur doit savoir tout moment
quel point du processus il se trouve, et comment passer une autre
tche. Le systme doit canaliser le travail de lutilisateur en lui laissant un
maximum de libert tout en lempchant dentreprendre des actions qui
nuisent sa scurit, sa productivit ou son efficacit.

Homognit
Lhomognit est la capacit dun systme conserver une logique
dusage constante. Elle se rfre la faon avec laquelle des choix dobjets de linterface sont conservs pour des contextes identiques, et des
objets diffrents pour des contextes diffrents. Elle facilite lapprentissage et rduit leffort de mmorisation.
Lhomognit concerne la localisation dun objet sur lcran, son format
et sa prsentation, ainsi que la syntaxe et le vocabulaire employs. Les
crans de saisie et la logique des actions doivent tre analogues dans
toute lapplication, et mme, si possible, dune application lautre.
Un bon moyen dexiger lhomognit consiste imposer une charte dergonomie, prexistante ou adapte au logiciel. Cependant, des exigences
particulires certaines tches doivent tre labores.

Souplesse
La souplesse est la capacit de linterface sadapter aux diffrentes
exigences de la tche, aux diverses stratgies, aux habitudes et niveaux
de connaissances des diffrents utilisateurs.
Contrairement la compatibilit, qui revient adapter davance le logiciel aux diffrents profils utilisateurs, la souplesse permet un logiciel
de sadapter ses habitudes, ainsi qu son exprience ou son niveau
dexpertise.
Exemple de souplesse : les modes expert et dbutant. Les utilisateurs
dbutants auront les commandes prsentes sous forme de menu, les
expriments auront des raccourcis clavier leur disposition. Autre
exemple, la facilit pour lutilisateur paramtrer le logiciel pour ladapter son mtier tout en respectant lexigence dhomognit, ce qui
montre quel point lergonomie nest pas chose aise.

135

Livre Constant.indb 135

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Contrle explicite
Le contrle explicite est lensemble des moyens du dialogue qui permettent lutilisateur de matriser le lancement et le droulement des
oprations excutes par le systme informatique. Cest ce qui permet
lutilisateur de matriser le systme. Ce contrle se manifeste en parti
culier par le feedback que fournit le systme. En pratique, les ractions du
systme doivent tre prvisibles.
Cette exigence apporte lutilisateur lautonomie quil est en droit dattendre du systme, ainsi quun confort li une sensation de contrle sur
lapplication. Cette agrable sensation de piloter le produit (plutt que
dtre malmen par lui) facilite lappropriation de loutil par lutilisateur et
minimise les erreurs.

Gestion des erreurs


La gestion des erreurs rassemble tous les moyens permettant dune part
dviter ou de rduire les erreurs, et dautre part de les corriger lorsquelles
surviennent. Elle prvient le stress et augmente la sensation de scurit
(et la scurit effective). Comme exemples dexigences, citions:
la possibilit dannuler une action (touche undo);
la demande de confirmation des actions dont les effets sont irrversibles;
les messages davertissement.

Concision
La concision est lensemble des moyens qui, pour lutilisateur, contribuent la rduction de ses activits de perception et de mmorisation et
concourent laugmentation de lefficacit du dialogue. Elle a des effets
positifs sur la productivit et contribue diminuer la charge mentale et
donc la fatigue et le stress.
Exemple dexigence:
minimiser le nombre de menus et de clics pour excuter une tche;
limiter le nombre de possibilits offertes (tout en respectant les exigences de souplesse et de contrle explicite).

136

Livre Constant.indb 136

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 12

Exigences projet
et contraintes
techniques
Les exigences projet et les contraintes techniques ne sont ni des exigences
fonctionnelles, ni des exigences non fonctionnelles. Elles ne concernent
pas le produit, mais sa mise en uvre. Elles occupent un chapitre part
dans le cahier des charges. La difficult consiste les dcrire sans tomber
dans le pige classique de la description dune solution en lieu et place
dun besoin.

Contraintes de projet
La formulation de ces contraintes dpend beaucoup du type de solution
(progiciel, dveloppement spcifique) et du rapport entre client et fournisseur (dveloppement par des quipes internes, ou au contraire appel
doffres public).

Charges, cots et dlais


Ces exigences imposes la matrise duvre dcoulent des contraintes
de budget et durgence au niveau de la matrise douvrage. Il faut savoir
quune diminution du dlai a toujours une rpercussion importante sur
les cots, voire mme sur la faisabilit, (neuf femmes ne font pas un
enfant en un mois dit-on parfois), et souvent sur la qualit.
Lexpression de contraintes de cot peut tre utile dans le cadre dun
dveloppement en interne, elle lest beaucoup moins lorsquon sadresse
un fournisseur externe, et en principe interdite dans le cadre dun appel
doffres public.

Installation, mise en exploitation, recette


Les exigences doivent indiquer (ou demander au fournisseur dindiquer) si
le produit est autoinstallable, si linstallation est la charge du fournisseur

Livre Constant.indb 137

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

ou du client, la charge dinstallation pour le fournisseur et/ou le client, les


dlais prvoir, et la disponibilit des diffrents acteurs par profil.
Le cahier des charges peut dtailler les modalits de recette ou demander
la matrise douvrage de les proposer.

Migration
Comme pour lintgration, la migration peut tre plus ou moins complexe et coteuse, jusqu ncessiter une vritable tude. Pour que le
fournisseur puisse rpondre cette contrainte, il faut lui indiquer aussi
prcisment que possible, au minimum le format et le contenu des donnes changes, le support physique et/ou logique (par exemple, base de
donnes, disque dur), la structure (fichiers plats, tables de base de donnes
relationnelle) et le volume de donnes reprendre.
Le cahier des charges doit indiquer clairement les engagements mutuels
du fournisseur et du client, qui sont trs interdpendants. Par exemple,
on peut exiger du fournisseur quil reprenne les donnes prsentes sous
forme de fichier plat, le client sengageant fournir ce fichier aprs avoir
attaqu lui-mme la base de donnes de lancienne application. Les
charges, dlais, disponibilits des acteurs sont galement des exigences
indiquer.

Environnement de dveloppement
Imposer lenvironnement de dveloppement, en termes doutils, langages, mthodes, etc., est parfois ncessaire, mais induit des contraintes
trs fortes sur le matre duvre. Il faudra donc bien peser le pour et le
contre avant de formuler cette exigence, ventuellement aprs discussion ou ngociation, ou laisser dans le cahier des charges louverture
la ngociation.

Contraintes denvironnement
Environnement matriel et logiciel
Ces exigences ou contraintes concernent la plate-forme matrielle, le systme dexploitation, les bases de donnes, les navigateurs sur (ou sous)
lesquels la solution devra fonctionner.
La premire contrainte concerne le type de fourniture. Trois cas peuvent
se prsenter:
Seul le produit logiciel est livr. Le client dispose de la plate-forme.
Dans ce cas, cest au client de dcrire lenvironnement, qui devient de
facto une contrainte. Le fournisseur devra prciser dans sa rponse ses
propres contraintes en termes de matriels et logiciels de base.

138

Livre Constant.indb 138

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 12 Exigences projet et contraintes techniques

Le client demande la fourniture du produit logiciel seul, mais na pas


encore acquis linfrastructure ncessaire pour lhberger. Lexigence
consiste demander au fournisseur de spcifier ses propres exigences
en termes dinfrastructure. Le client peut galement exiger du fournisseur quil maintienne son produit pour tenir compte de lvolution du
matriel ou du logiciel de base.
Le client demande une solution complte, matriel et logiciel. Il exige
du fournisseur de dtailler la liste des matriels et logiciels fournis, et de
lister ses propres contraintes denvironnement (salle, etc.).
Toutes les nuances et variations sont possibles. Les autres contraintes
denvironnement matriel et logiciel dpendent troitement de cette
premire contrainte.

Interfaces
Ce paragraphe dtaille les protocoles, formats dchange de donnes,
appels de procdures entre applications, messages changs. Si lon descend dans des dtails techniques, ce qui est souvent ncessaire, il faudra
faire appel des experts. En fonction du niveau de dtail, il sera utile
dexpliciter les exigences sous forme de diagrammes de squence ou de
diagrammes dtat.
Chaque fois que cela sera possible, on sappuiera sur des normes et
standards dinteroprabilit existants. La rfrence des standards est
infiniment plus sre et conomique en efforts de spcification que la description dtaille dinterfaces. Elle a des consquences trs positives sur
le cot et la qualit de la solution.

Services daccompagnement
Les services daccompagnement doivent tre spcifis avec beaucoup de
soin, clart et prcision, car cest souvent sur ces services que le fournisseur fait sa marge. Une spcification imprcise peut donner lieu
des litiges, voire des conflits entre client et fournisseur, avec des risques
financiers.
Il y a deux manires de formuler les exigences de service: imposer des
contraintes ou demander au fournisseur de prciser sa rponse (propo
sition technique et commerciale).
Lorsque le fournisseur est une socit externe et que le client doit passer
par un appel doffres public (tat, collectivit), cest souvent la deuxime
option qui est choisie, voire ncessaire.

139

Livre Constant.indb 139

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Exigences dintgration
Lintgration du produit lenvironnement du client est un point trs dlicat. Pour que le fournisseur puisse rpondre aux exigences dintgration,
il doit bien connatre lenvironnement du client, en particulier les applications partenaires avec lesquelles le produit fourni devra communiquer.
Souvent, une vritable tude dintgrabilit doit avoir lieu. Elle peut tre
faite par le client, le fournisseur, et le plus souvent par une collaboration des deux parties. Lexercice est dautant plus difficile que, lorsque le
client tablit son cahier des charges, il ne connat pas encore la solution
propose par le fournisseur. Cest la situation dans laquelle se trouve,
en particulier, lAdministration lorsquelle tablit un appel doffres public
pour choisir un progiciel du march.

Support utilisateurs, support technique


La qualit du support aux utilisateurs est souvent une des cls de la
russite dun projet. De plus, le support est un gros consommateur de
ressources. Il est donc indispensable de spcifier prcisment les conditions de support ou de demander au fournisseur de les spcifier.
Les diffrents niveaux de support doivent tre dcrits, ainsi que le profil
des intervenants chaque niveau de support, et les ressources ddies.
Par exemple, le support premier niveau pourra tre fait par le client, et le
deuxime niveau par le fournisseur.

Maintenance
Les exigences de maintenance ne doivent pas tre confondues avec les
exigences de maintenabilit. La maintenabilit est une proprit du
logiciel, alors que la maintenance est un service rendu au client.
En dehors de cas trs rares, un logiciel install devra tre maintenu. Le
client ne pourra pas se passer de ce service, qui lui sera factur, parfois
trs cher. De plus en plus frquemment, la maintenance cote plus cher
que lachat du produit (cette tendance sacclre avec larrive de produits
open source). De plus, les oprations de maintenance peuvent elles-mmes
induire des contraintes pour le client et lutilisateur, avec des arrts
dexploitation pour monte de version ou pour correction de bogues.
Un client a donc intrt bien spcifier les conditions et les modalits de
la maintenance. Les exigences dpendent bien sr du domaine dapplication, du type dapplication, de lenvironnement informatique et mtier.
Voici quelques exemples dexigences de maintenance:
frquence des installations de versions majeures;
modalits dinstallation (par le client, par le fournisseur, etc.);

140

Livre Constant.indb 140

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 12 Exigences projet et contraintes techniques

processus de maintenance, tout particulirement pour la maintenance


corrective;
obligations respectives du client et du fournisseur concernant la maintenance de linfrastructure sous-jacente (serveurs, base de donnes, etc.);
compatibilit ascendante entre versions (peut aussi tre considre
comme une exigence de maintenabilit).

Documentation
Rappelons que la documentation fait partie intgrante du produit. Les
contraintes gnrales sappliquant au produit sappliquent donc ipso
facto sa documentation. Cest en particulier le cas de la livraison dune
documentation suite un changement de version du produit. Cela va
sans dire, mais cela va mieux en le disant, et encore mieux en le stipulant
par crit.
Les exigences de documentation peuvent tre extrmement varies. Elles
peuvent concerner le volume de la documentation, sa forme physique
(papier, mdia, documentation en ligne), la frquence de sa mise
jour, son contenu, la facilit de lecture et dapprentissage ou son mode
de distribution.

Formation des utilisateurs


La formation des utilisateurs est trs importante pour la russite du projet. La plupart des fournisseurs ont, paralllement leur offre produit,
des offres de formation standard. Le prix de ces formations peut tre trs
lev.
Il est tout fait possible, mme dans le cadre dappels doffres publics, de
ngocier ces prix au moyen du cahier des charges. En particulier, on
sait que certains utilisateurs nutilisent quun trs petit nombre de fonctions. La formation standard gnraliste peut tre trononne en
fonction du profil utilisateur. Rien nempche de stipuler que telle catgorie dutilisateurs doit pouvoir tre forme en deux heures (en lieu et
place dune formation gnrale de trois jours, par exemple). En fonction
de la manire dont elle est formule, cette exigence peut aussi trouver
sa place dans la rubrique facilit dutilisation (chapitre des exigences
non fonctionnelles).

Environnement physique dutilisation


Il ne sagit pas ici denvironnement informatique, mais bien de lenvironnement physique au sens large. Par exemple, une solution (matriel et
logiciel) peut ncessiter dtre utilise en milieu tropical, strile (bloc
opratoire), humide, bruyant, etc. Dcrire cet environnement est important, car il induit des contraintes sur le matriel informatique, mais aussi

141

Livre Constant.indb 141

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

sur lergonomie du produit. En indiquant, par exemple, que le logiciel sera


utilis au service des urgences dun hpital, on donne une information
trs importante au fournisseur, en lui laissant la libert (et la responsabilit) dimaginer la solution qui convient le mieux (affichage trs sobre) ou
de faire une tude dergonomie.
Le fait de dcrire lenvironnement dutilisation et dexiger du fournisseur que son produit respecte cette contrainte denvironnement reporte
leffort de recherche et dtude (en particulier dergonomie) sur le fournisseur. Dans le cas dun logiciel critique, cela risque dtre plus coteux
pour le fournisseur, mais aussi plus stimulant. On devra donc tudier
lopportunit de formuler les exigences, soit sous forme de contraintes
physiques dutilisation, soit sous forme de rgles dergonomie, ou mme
dexigences fonctionnelles. Lexercice nest pas facile.

142

Livre Constant.indb 142

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 13

Ltape
de spcification
Le processus de spcification
Le schma ci-dessous prsente une vision simplifie du travail de spcification.

Analyse

Formuler

Structurer

Vrifier

Validation

Figure13-1 : Le processus de spcification

Les trois tches consistant formuler, structurer et vrifier les exigences


sont trs interdpendantes et le processus est naturellement itratif.

Formuler
Le comportement (exigences fonctionnelles) et les proprits (exigences
non fonctionnelles) doivent tre formuls avec beaucoup de soin et de
prcision, de manire tre compris par tous ceux qui liront le cahier des
charges. Une bonne matrise de la langue crite est ncessaire, mais non
suffisante. Une bonne formulation sera facilite si les tapes prcdentes
ont t respectes.
La spcification graphique est un cas particulier de formulation. Un
graphique peut faciliter la comprhension, mais si lon veut quil soit
comprhensible de tous les acteurs, il est encore plus difficile crire
quun texte.

Livre Constant.indb 143

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Structurer
Structurer le cahier des charges consiste ranger les exigences sous
forme arborescente, afin de rendre la lecture, la comprhension et la
maintenance du document la plus aise possible. Le modle de cahier
des charges nous donne un premier niveau de structuration, mais certains sous-chapitres devront tre subdiviss, parfois trs finement. Cest
en particulier le cas des exigences fonctionnelles.
Pour un logiciel dune grande richesse fonctionnelle, la structuration est
loin dtre vidente. Dans un tel cas, on prsente en gnral les exigences
de deux niveaux diffrents dans deux chapitres diffrents:
exigences utilisateur (par exemple, sous forme de cas dutilisation);
exigences produit (sous forme dexigences lmentaires).

Vrifier
Il sagit ici de vrifier, en particulier au moyen de check-lists, que les exigences qui viennent dtre rdiges rpondent un certain nombre de
critres. Elles doivent, en particulier, tre alignes sur les objectifs et les
exigences de plus haut niveau, correspondre au besoin des utilisateurs,
tre ralistes et bien formules.
Les activits de structuration, de formulation et de vrification sont itratives.
Lactivit de vrification fait partie intgrante de la spcification et est
distincte de ltape ultrieure de validation, qui sintresse autant au
contenu qu la structure ou la formulation.

La formulation
Appliquer des rgles de bonne formulation peut apparatre contraignant,
mais est trs avantageux terme. Un cahier des charges bien formul est
beaucoup plus maintenable. Noublions pas que sa maintenance commence trs tt, toute exigence tant susceptible dtre modifie tout
moment (mais pas nimporte comment).
Nous donnons dans les paragraphes qui suivent un ensemble de principes
et de rgles de bonne formulation. La liste peut paratre longue, mais avec
lexprience, la formulation correcte devient une seconde nature.

La structure grammaticale
Une exigence lmentaire correctement formule rpond aux critres
suivants:
Elle est grammaticalement correcte.

144

Livre Constant.indb 144

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 13 Ltape de spcification

Elle est rdige la forme active: sujet, verbe, complment.


Le sujet est ncessairement un utilisateur, un systme ou un attribut du
systme.
Un mme terme a la mme signification pour tout lecteur potentiel.
Les termes ambigus ont t dfinis dans un glossaire.
Il est ncessaire dutiliser des phrases du type le logiciel doit. Par
exemple: Le logiciel doit afficher le cot des mdicaments prescrits
plutt que: Affichage du cot.
Pour exprimer une exigence, il est prfrable dutiliser une phrase courte
et claire. On vitera les phrases comportant des propositions relatives,
ou des conjonctions de coordination. Lidal (pas toujours ralisable) est
que chaque exigence tienne sur une seule phrase et que chaque phrase
exprime une seule exigence.

Check-list de bonne formulation


La liste suivante servira de check-list appliquer chaque exigence. Une
exigence bien formule doit tre:
lmentaire (en anglais, atomic). Elle ne doit comporter quun lment inscable. Pour vrifier si une exigence est lmentaire, essayez
de lacouper en deux ( en gnral au niveau des conjonctions de coordination).
Ncessaire. Lexigence doit servir au moins un profil utilisateur ou
une partie prenante. Un moyen de vrifier cette rgle est de se poser la
question: que se passera-t-il si cette exigence est supprime?
Mesurable, ou du moins vrifiable. Dans le cas contraire, le matre
duvre peut faire ce quil veut, cest un vu pieux. Les adjectifs et
adverbes non mesurables (tels que rapide, performant, fiable, nombreux)
rendent lexigence non mesurable. Il en est de mme pour les phrases
la voix passive, lemploi du etc. et des points de suspension.
Concis. Plus la formulation est courte, plus lexigence sera robuste.
Mthode: liminer systmatiquement tous les mots qui ne servent rien.
Traable, vis--vis dexigences de plus haut niveau ou de plus bas
niveau. Au-del dun certain volume de spcifications, lutilisation
doutils spcifiques est ncessaire pour que ce critre soit respect.
Ralisable et modifiable. Dans le cas contraire, cest un vu pieux.
Cest ici que la comptence technique de lanalyste peut tre utile. Il
peut avertir son client de la difficult ou de limpossibilit de mettre en
uvre une exigence, et aider la ngociation.
Autosuffisante. Dans la mesure du possible, elle doit tre lue et comprise indpendamment des autres. Dans une exigence, un pronom per-

145

Livre Constant.indb 145

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

sonnel comme il ou elle se rapporte gnralement une exigence


prcdente. Il faut remplacer le pronom personnel par le sujet, quitte
se rpter (un cahier des charges nest pas une uvre littraire).
Indpendante de la solution. Rappelons quune exigence doit dcrire
un besoin ou une contrainte, et non une solution. De plus, certaines
rgles rgissent les relations entre exigences. Un ensemble dexigences
doit tre:
Complet. Lensemble doit dcrire tous les cas possibles. Par exemple,
si on dcrit le comportement du systme en cas dacceptation, on doit
aussi dcrire son comportement en cas de refus.
Cohrent. Une exigence ne doit pas entrer en conflit avec les autres.
Une forme plus subtile dincohrence advient lorsquun ensemble
dexigences entre en contradiction avec un autre ensemble.
Non redondant. Deux exigences ne doivent pas se recouvrir ou se
rpter, mme partiellement.
La rgle des 5 C
La rgle dite des 5 C est une check-list condense, un moyen mnmotechnique
simple qui permet de vrifier rapidement quune exigence est bien formule. Cette rgle
sapplique galement au document dexigences dans sa totalit.
Toute exigence doit tre:
Correcte: elle respecte les rgles de la grammaire, les lois, les rglements, les bonnes
pratiques de la profession.
Complte: elle dfinit lacteur, dcrit laction, et prcise si ncessaire les conditions
de laction.
Claire: elle ne comporte pas de flou, pas dambigut, pas de termes sens multiple; tout lecteur la comprend demble, sans explication supplmentaire.
Concise: elle est formule avec le moins de mots possibles.
Cohrente: elle nentre pas en conflit avec dautres exigences.

La langue de bois: quand et comment lliminer?


Qui na jamais us de la langue de bois? Quant aux sous-entendus, il est
impossible de sen passer dans la vie courante, ne serait-ce que pour la
brivet du discours. Le flou est gnralement largement compens par
la communication non verbale.
Par ailleurs, le langage flou a sa place lors de ltape de recueil. Nous
laissons du flou dans nos questions pour permettre linterlocuteur de
sexprimer. Cest dailleurs une technique dinterview souvent utilise,
consciemment ou non.
Lors de la spcification, la langue de bois, et de manire gnrale le langage flou, est proscrire. Lanalyste lliminera sans piti, soit en faisant

146

Livre Constant.indb 146

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 13 Ltape de spcification

la correction lui-mme ( valider plus tard), soit en demandant des prcisions complmentaires. Le flou peut arriver:
Pendant le recueil des besoins (interview): cest normal, la prcision doit
venir progressivement. Reformuler en douceur.
Pendant lanalyse : cest le moment de chercher lliminer. Un bon
schma peut mettre au jour une incohrence du discours.
Lors des spcifications (rdaction du cahier des charges): la tche sera
plus difficile; il faudra chercher prciser lexigence, la corriger, et vrifier
la cohrence densemble.
Lors de la validation (revue de spcifications) : cest un indicateur de
non-qualit lors des tapes prcdentes. Prvoir une charge de travail
supplmentaire, et chercher samliorer.

Amliorer la formulation: exemples


Voici quelques exigences mal formules, suivies dune explication et de
la reformulation amliore. Elles proviennent dun cahier des charges,
en cours dlaboration, pour un progiciel de gestion du circuit du mdi
cament dans un tablissement de sant.

Exemple1: la fois trop et pas assez


Voici comment une exigence tait initialement formule dans un cahier
des charges pour linformatisation du circuit du mdicament dun hpital:
Les stocks seront grs au niveau du code produit, du produit
et du numro de lot, dans tous les lieux de stockage : la
pharmacie et larmoire pharmacie des units de soins.
Un analyste expriment dtecte tout de suite quil ne sagit pas dune
exigence. Nimporte quel lecteur muni de la check-list de formulation correcte sen apercevra galement en essayant de faire passer la phrase de
la voix passive la voix active: on ne sait pas qui est lacteur et que fait
le systme.
Dautre part, le texte apporte une surabondance dinformations concernant les lieux de stockage. Ils doivent tre dcrits, soit en intention: quel
que soit le lieu de stockage, soit en extension: la pharmacie et dans les units de soins.
Lexigence lmentaire devient alors:
Le systme doit permettre au pharmacien de suivre les stocks
dun mdicament donn, par son code produit et par son numro
de lot.
Le systme doit permettre le suivi de mdicaments en pharmacie.
Le systme doit permettre le suivi des mdicaments en units
de soins.

147

Livre Constant.indb 147

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

On obtient donc, non pas une, mais trois exigences lmentaires. Cela
peut sembler lourd, mais cest beaucoup plus clair.

Exemple2: amliorer la clart dune exigence


Voici une exigence extraite dun cahier des charges pour un logiciel
hospitalier:
Le progiciel doit comporter un prparamtrage de ces donnes
(au niveau de lhpital ou dune spcialit), prparamtrage
modifiable par le prescripteur.
On comprend de quoi il sagit, mais lexigence peut tre grandement
amliore. Lexpression comporter un paramtrage ne prcise pas
lacteur. Lexpression au niveau de est ambigu : on ne sait pas
qui, de lhpital ou de la spcialit, est lacteur de ce paramtrage, ou
le bnficiaire, ou les deux. Ces donnes fait allusion une exigence
prcdente, spcifiant les informations quun prescripteur peut saisir.
Lexigence amliore devient:
Le progiciel doit permettre ladministrateur du progiciel
de paramtrer, pour lensemble de lhpital, les informations
quun prescripteur peut saisir, et le caractre obligatoire
de cette saisie.
Le progiciel doit permettre ladministrateur du progiciel
de paramtrer, pour chaque spcialit, les informations quun
prescripteur peut saisir, et le caractre obligatoire de cette
saisie.
Le progiciel doit permettre un prescripteur de paramtrer,
pour toutes les prescriptions venir, les informations quil
pourra saisir.
Cette formulation en trois exigences lmentaires est videmment plus
lourde, mais elle ne laisse plus aucune ambigut quant aux actions autorises pour chaque acteur.

Exemple3: beaucoup de mots pour rien


Lnonc de lexigence est le suivant:
Le progiciel doit pouvoir supporter les diffrentes
organisations existantes dans ltablissement au niveau des
units de soin.
Le verbe supporter , en loccurrence un anglicisme, est ici ambigu.
Grce au contexte, le lecteur pourra comprendre quil faut linterprter
dans le sens de rpondre aux besoins de. Lexpression les diffrentes
organisations au niveau des units de soins signifie ici les diffrents
types dorganisation que lon peut rencontrer dans un tablissement.
Lexigence devient donc:

148

Livre Constant.indb 148

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 13 Ltape de spcification

Le progiciel doit rpondre aux besoins des diffrents modes


dorganisation dune unit de soin.
La formulation est un peu plus claire, cependant, rpondre aux besoins
est imprcis: on ne sait pas quel besoin le progiciel doit rpondre. Si le
besoin est diffrent dun mode dorganisation lautre, il faudra rdiger
une exigence pour chacun deux. Sinon, lexigence devient:
Le progiciel doit tre utilisable dans toute unit de soins de
ltablissement, quel que soit son mode dorganisation.
On saperoit maintenant que limprcision vient du mode dorganisation.
Il faudrait donc lister et expliciter les diffrents modes dorganisation de
ltablissement, soit en intention (rfrence une description de tous les
modes dorganisation) soit en extension (faire la liste des modes dorganisation).
Or, ce qui est plus simple et plus efficace, cest de dcrire les diffrents
modes organisationnels dans un chapitre prliminaire, dcrivant le
contexte. Lexigence devient alors:
Le progiciel doit tre utilisable dans toute unit de soins.
Mais cest l une tautologie. Cette exigence peut donc tre purement et
simplement supprime moins den dduire une exigence non fonctionnelle dutilisabilit: le progiciel doit tre adaptable (ou dj adapt?)
aux diffrents modes dorganisation de ltablissement.

La structuration
Structuration: adopter et adapter les modles
Il existe plusieurs modles de cahiers des charges1, comme X50-151,
IEEE830, ou le modle Volere. Ces modles sont extrmement utiles: ils
servent de check-lists et vitent doublier certains points indispensables.
Ils ont une structure cohrente, descendante (top-down) et complte
(toutes les catgories dexigences et autres rubriques sont reprsentes).
Ils constituent donc un bon dpart pour la spcification des exigences, et
mme plus que la spcification: ils servent de check-lists pour le recueil.

1. Voir au chapitre
suivant les diffrents
modles de cahiers
des charges.

Une organisation pourrait choisir un de ces modles et ladapter sa


situation particulire. Par exemple, une entreprise soumise au code des
marchs publics peut y ajouter un chapitre sur les aspects juridiques. Si
ce nouveau modle ne correspond pas toutes les situations dune organisation, il pourra tre raffin au niveau dune direction ou dun service,
et ainsi de suite.

149

Livre Constant.indb 149

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Rappelons que le modle de dveloppement et de gestion des exigences,


tel que dcrit dans cet ouvrage, peut (et souvent doit) tre adapt au cas
particulier de chaque entreprise. Il ny a pas de modle parfait.

Rutiliser autant que possible


Une exigence bien formule cote cher obtenir. Elle doit passer par
le cycle complet de recueil, analyse, spcification et validation. long
terme, il est donc beaucoup plus efficace de rdiger des exigences rutilisables dun projet lautre que de les rinventer et de les reformuler. Cest
en particulier le cas des exigences non fonctionnelles, telle la scurit.
Rendre les exigences rutilisables ou, mieux encore, laborer du premier
coup des exigences rutilisables, exige un bon niveau dorganisation. Il
faut retrouver des exigences existantes, les adapter, et ventuellement les
rinjecter dans un pot commun et, ce qui est plus difficile, conserver
la cohrence densemble. Au-del dune certaine complexit, les outils de
gestion des exigences deviennent quasiment indispensables.
En pratique, cela ncessite:
davoir une base dexigences, bien tenue, cest--dire contenant des
exigences correctes (cohrentes, non ambigus, etc.);
davoir le moyen de les retrouver rapidement en fonction dun certain
nombre de critres;
une fois lexigence rutilise, cest--dire utilise dans plus dune spcification, davoir les moyens de suivre son volution et de rpercuter les
modifications sur plusieurs occurrences;
de pouvoir grer la traabilit sur chaque occurrence.

Choisir la forme de description


Les exigences peuvent tre dcrites sous plusieurs formes : cas dutilisation, modles graphiques (traitements, donnes, flux, processus) et
exigences lmentaires.
Le choix de la forme (textuelle ou graphique), du niveau de dtail (la
granularit dune exigence) en fonction des acteurs et du domaine
dapplication est un art plutt quune science.
Il ny a pas de dogme en ce qui concerne les modes de reprsentation. Par
exemple, pour certains auteurs (comme Alistair Cockburn), les cas dutilisation se suffisent eux-mmes dans 90% des cas. Pour dautres, ils ne
sont quun moyen de dcouvrir les exigences fonctionnelles et nont pas
apparatre dans un cahier des charges. Pour dautres enfin, cas dutilisation et exigences fonctionnelles peuvent coexister au sein dun mme
document.

150

Livre Constant.indb 150

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 13 Ltape de spcification

En tout tat de cause, le type incontournable dexigence est lexigence


lmentaire.

Spcifier les exigences lmentaires


Les exigences lmentaires constituent le cur de la plupart des cahiers
des charges. Par exigence lmentaire (en anglais, atomic requirement) on
entend toute exigence formule en langue naturelle sous forme de phrase
qui se suffit elle-mme. Il peut sagir l dune exigence fonctionnelle ou
non fonctionnelle, ou dune contrainte produit ou projet. Par exemple:
Le systme prsentera la liste des couleurs disponibles.
Le temps maximum dindisponibilit du systme sera de 20minutes par
jour.
Le systme sera accessible au moyen dun navigateur HTML4.0.
Une exigence lmentaire peut dcouler directement dun objectif, dune
rgle de gestion, dun cas dutilisation, ou de toute exigence de plus haut
niveau. Les exigences lmentaires sont regroupes sous forme arbo
rescente.

Cas des exigences non fonctionnelles


Les exigences non fonctionnelles sont particulirement difficiles
formuler. En fait, chaque caractristique non fonctionnelle (fiabilit, maintenabilit) prsente des difficults de description particulires. En toute
rigueur, il est ncessaire de spcifier (par exemple, ici, pour la fiabilit):
la dfinition de la mesure (par exemple, la dfinition du temps dindisponibilit ou du temps de rponse);
lunit de mesure (par exemple, minutes);
la valeur minimale ou maximale (par exemple: 20minutes dinterruption
maximum);
la mthode de mesure (par exemple, chronomtre);
la valeur optimale;
la valeur nominale et la tolrance;
les valeurs admises par exception (par exemple, le dimanche, une interruption de 30minutes est autorise).
Certains auteurs prconisent des modles de structuration des exigences.
Tom Gilb2 propose un langage spcial de spcification des exigences
non fonctionnelles, appel planguage (planning language) qui permet de les
dcrire avec prcision. Elle peut cependant tre vue comme trop complexe et trop formelle pour la plupart des projets. Rien nempche de la
simplifier, ou dutiliser une description moins formelle.

2. Tom Gilb, Competitive Engineering,


Butterworth-Heinemann, 2005.

151

Livre Constant.indb 151

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Dans de nombreux cas, on peut se contenter dune description beaucoup


moins formelle, comme:
Lapplication doit pouvoir fonctionner 24 heures sur 24 et
7jours sur7 avec un taux dindisponibilit maximal de:
- 15minutes par jour dans la priode comprise entre 7heures
et 23heures;
- 30minutes par jour dans la priode comprise entre 23heures
et 7heures;
- 3heures par an pour maintenance.
Rien nempche, dailleurs, de sinspirer de la norme ISO25000 (plus prcisment, les normes ISO/CEI25020 25024, qui reprend les lments de
la norme ISO/CEI9126-4). Cette norme donne une dfinition trs prcise
dun grand nombre dindicateurs de qualit et de leurs mtriques. Voici
un exemple:
Nom: temps moyen dindisponibilit.
But : temps moyen pendant lequel le systme demeure indisponible
entre une dfaillance et la remise en ordre de marche graduelle.
Formule de mesure: X=T/N, o T est le temps total dindisponibilit et
N le nombre de dfaillances observes.
Interprtation de la valeur mesure: 0 < X; la plus petite valeur mesure
est la meilleure.
Type dchelle: ratio (rapport de valeurs).
Type de mesure: T=temps, N=nombre, X=temps/nombre.
Origine de la mesure: rapport de test, rapport dintervention.
Rfrence une description de processus (ISO/IEC 12207) : 5.3 int
gration, 5.3tests de qualification, 5.4opration, 6.5validation.
La norme dcrit ainsi des centaines de mtriques sur presque cent pages,
pour chacune des vingt-sept sous-caractristiques ISO25000. Elle pourra
servir de check-list pour vrifier que toutes les exigences non fonctionnelles ont t intgres. Elle apportera galement des ides sur la
manire de formuler une exigence et den fixer les critres de satisfaction.

Check-list de spcification dune exigence


La check-list qui suit concerne chaque exigence individuellement.
Lexigence est aligne sur un objectif nonc, une exigence de plus haut
niveau, ou un besoin dun type dutilisateur.
Lexigence dcrit un besoin ou une contrainte, et non un lment de
solution.

152

Livre Constant.indb 152

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 13 Ltape de spcification

Lexigence doit satisfaire au moins un besoin dau moins un type dutilisateur.


Lexigence est spcifie au niveau adquat, ni trop dtaill, ni trop
gnral, pour tre comprise par toutes les parties prenantes.
Lexigence mane dune source reconnue et lgitime, partie prenante ou
texte de rfrence.
Lexigence est spcifie avec le formalisme (textuel, graphique) adquat
pour tre comprise par tous les lecteurs.
Si lexigence est spcifie textuellement, elle lest sous forme active :
sujet (acteur) verbe (action) complment (prcisions).
Les termes ambigus sont dfinis dans le glossaire.
Lexigence est traable. Il est possible, partir dune exigence donne,
de remonter une exigence de plus haut niveau ou de plus bas niveau.
Lexigence est complte. Elle reprsente une fonction lmentaire.
Lexigence lmentaire est atomique : elle reprsente une seule
fonction lmentaire inscable.
Lexigence est grammaticalement correcte.
Lexigence est formule selon le modle en vigueur.
Lexigence nentre pas en conflit avec une exigence de plus haut niveau.
Lexigence est utile. Elle a t valide par au moins un reprsentant des
utilisateurs.
Lexigence est ralisable. Elle a t valide par un expert technique,
concepteur ou dveloppeur.
Lexigence est non ambigu. Elle a une seule interprtation possible,
quel que soit le lecteur.
Lexigence est concise. Elle est crite de la manire la plus simple
possible, avec le moins de mots possibles.
Lexigence est vrifiable. Une fois le produit dvelopp, il sera possible
de vrifier objectivement et sans quivoque quelle est satisfaite.

Check-list dtape de spcification


Cette check-list est relative aux diffrentes activits de spcification: elle
liste les conditions remplir avant de passer la prochaine tape (validation). Pour la formulation des exigences elles-mmes, voir la check-list
prcdente, ainsi que la check-list relative au cahier des charges.
Le modle de cahier des charges a t accept par tous les acteurs.
Le modle de cahier des charges a t adapt lorganisation.

153

Livre Constant.indb 153

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Le modle de cahier des charges a t adapt au projet. Les modles


graphiques utiliss sont comprhensibles par tous.
Chaque rubrique du modle de cahier des charges a t remplie, ou laisse vide avec justification.
La formulation de chaque exigence a t vrifie laide de la check-list
adquate.
Telles que formules, les exigences seront utiles la ralisation.

154

Livre Constant.indb 154

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 14

Structure
du cahier
des charges
Choisir, adapter et utiliser un modle de cahier des charges est une des
cls de lefficacit de son laboration et de la qualit du livrable. En effet,
un modle est la fois un guide pour agir, une check-list pour valider et
un support pour communiquer sur les exigences. On trouve dans la littrature et sur le Web des modles de cahier des charges prts utiliser,
que lon peut ventuellement adapter. Visite commente.

Le modle de cahier des charges


Les lments du contenu
Un bon modle de cahier des charges contient toutes les rubriques qui
seront ncessaires la description et la comprhension des exigences,
et rien de plus. On peut adapter le modle aux contraintes particulires
du domaine dapplication et des technologies mises en uvre. Cette opration nest pas triviale. Malgr leur apparente simplicit, les modles de
cahiers des charges prsents dans ce chapitre rsultent dune longue
rflexion, dun travail collaboratif entre experts, et dune exprimentation
sur le terrain, parfois sur des centaines de projets.

Larborescence des paragraphes


La plupart des modles de cahiers des charges (normes ou standards)
comportent cinq dix parties, dcoupes en dix trente paragraphes.

Livre Constant.indb 155

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Lordre dapparition des paragraphes est important. Il doit correspondre


idalement lordre de lecture, et aussi, dans la mesure du possible, la
squence des tapes du processus dlaboration du cahier des charges.

Les diffrents modles existants


Nous prsentons dans les paragraphes qui suivent diffrents modles
de cahiers des charges, et leurs domaines dapplication possibles. Pour
chacun deux, nous exposons sa structure, son contenu, ses avantages
et inconvnients. La plupart sont tlchargeables, souvent gratuitement
ou moyennant une somme modeste. Il est important dinvestir du temps
bien choisir, bien comprendre et si ncessaire adapter un modle. Cet
investissement correspond une fraction minime de leffort qui sera par
la suite consacr llaboration du cahier des charges.

Le modle IEEE830
Orientation
1. IEEE Std8301998. IEEE
Recommended
Practice for Software
Requirements Specifications, Software
Engineering Standards Committee, of
the IEEE Computer
Society.

La norme de spcification des exigences IEEE 830 (1998)1 donne un


modle gnraliste, plutt orient vers le dveloppement spcifique et
assez technique.
Le modle ne fournit pas une structure fige de cahier des charges, mais
propose un ensemble de recommandations (emploi du verbe should) sur la
manire de structurer le cahier des charges, et les diffrentes parties dont
il doit se composer. Il fournit un squelette de cahier des charges. Enfin,
une annexe informative donne huit manires de structurer les exigences,
en particulier fonctionnelles.

Structure du modle
Le tableau14-1 donne les lments du document avec leur traduction en
franais.

156

Livre Constant.indb 156

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 14 Structure du cahier des charges

Tableau14-1 Modle IEEE830


1. Introduction

1. Introduction
1.1 Purpose

1.1 Objectif

1.2 Scope

1.2 Primtre (porte)

1.3 Definitions, acronyms,


and abbreviations

1.3 Dfinitions, acronymes,


et abrviations

1.4 References

1.4 Rfrences

1.5 Overview

1.5 Vue densemble


2. Description gnrale

2. Overall description
2.1 Product perspective

2.1 Perspective du produit

2.2 Product functions

2.2 Fonctions du produit

2.3 User characteristics

2.3 Caractristiques utilisateurs

2.4 Constraints

2.4 Contraintes

2.5 Assumptions and dependencies

2.5 Suppositions et dpendances

3. Specific requirements

3. Exigences spcifiques

Appendixes

Annexes

Index

Index

Contenu du document
Le modle IEEE est un grand classique et contient tous les lments
que lon sattend trouver dans un cahier des charges, du moins sur
le plan technique. La norme prcise que les exigences concernant la
solution peuvent exceptionnellement y figurer, sous forme restrictive
(contraintes).
La norme prcise que les exigences fonctionnelles (paragraphe2.2) peuvent contenir des diagrammes, ainsi que le paragraphe de perspective
(2.1) dans le cas o le produit serait connect dautres (ce qui, de nos
jours, est presque toujours le cas). Un diagramme de contexte y trouverait
sa place.
Le paragraphe3 (exigences spcifiques) constitue le corps du document.
La partie fonctionnelle doit contenir toutes les entres et sorties du systme (stimulus et rponses), et la description des fonctions en rponse
une entre ou sortie. Les exigences non fonctionnelles (attributs) sont
organises en fiabilit, disponibilit, scurit, maintenabilit, et porta
bilit.
La norme donne de nombreuses explications sur les diffrentes manires
de structurer les exigences fonctionnelles : par mode, par classes ou

157

Livre Constant.indb 157

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

e ntits, par caractristiques utilisateur, par stimulus et rponse, par


hirarchie fonctionnelle, ou par une combinatoire de ces types de structuration.

Avantages et inconvnients de la norme


Le modle a une forte orientation arborescence fonctionnelle , les
autres lments (modle de donnes, exigences non fonctionnelles)
tant traits rapidement, voire passs sous silence. Lensemble est donc
assez technique, avec une coloration gnie logiciel . Il fait dailleurs
explicitement rfrence la norme IEEE12207 (cycle de vie du logiciel)
avec laquelle il est compatible.
Le point fort de la norme est plutt dans son annexe informative sur les
diffrentes manires de structurer la dcomposition des fonctions, qui
donne des pistes de rflexion. Dans le cas dun systme de grande taille
fonctionnelle (nombre important de fonctions lmentaires) le problme
est loin dtre trivial, et les autres normes, plus rcentes, le passent sous
silence.

Le modle AFNORX50-151
Orientation de la norme
La norme AFNORX50-151 donne un modle de cahier des charges trs
gnraliste, qui nest pas spcifique linformatique et aux systmes dinformation. Il fait partie dune srie normative sur lanalyse de la valeur et
lanalyse fonctionnelle. Il donne donc une place importante louverture
sur le dialogue entre client et fournisseur.

Structure du modle
Le tableau 14-2 donne le plan dun cahier des charges selon la norme
AFNORX50-151.

158

Livre Constant.indb 158

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 14 Structure du cahier des charges

Tableau14-2 Modle AFNORX50-151


1. Prsentation du problme
1.1 Le produit et son march
1.2. Contexte du projet, les objectifs
2. nonc fonctionnel du besoin
2.1. Cycle dutilisation du produit et identification de son environnement
2.2 nonc des fonctions de service et des contraintes

Fonctions de service attendues

Contraintes

Classement ou notation des fonctions

2.3. Caractrisation des fonctions de service et des contraintes


Critres dapprciation

Niveaux des critres dapprciation

Flexibilit des niveaux: classe de flexibilit, limites dacceptation

Taux dchange

3. Appel variantes
4. Cadre de rponse

Contenu du document de spcifications


Les notions de niveau, de flexibilit et de taux dchange sont des concepts
danalyse de la valeur. Le principe est que pour permettre au fournisseur
doptimiser sa solution (apporter le maximum de satisfaction au cot le
plus faible), il est ncessaire dindiquer la priorit entre exigences, car
les exigences formules par le client dans le cahier des charges nont pas
toutes la mme importance ou la mme urgence.
La classe de flexibilit (niveau de flexibilit de chaque exigence: nulle,
faible, bonne, forte), indique dans quelle limite une contrainte est ngociable.
La limite dacceptation dfinit, pour chacune des caractristiques fondamentales du produit, une valeur minimale de la mesure du critre
dapprciation. En de de cette valeur, le besoin sera dclar insatisfait.
Le taux dchange indique les compensations fixes a priori au cas o
certains critres dacceptation, jugs essentiels par le demandeur, ne
seraient pas satisfaits (par exemple, les pnalits de retard, dans le cas
o le fournisseur ne respecterait pas ses dlais de livraison).

159

Livre Constant.indb 159

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Enfin, lappel des variantes permet de stimuler la crativit du fournisseur. Le client peut solliciter des propositions damlioration qui, dans
le cas dun logiciel, seront fonctionnelles (cration, modification ou suppression de fonctions) ou non fonctionnelles (performances, ergonomie).
Les variantes peuvent tre soit des supplments, soit des alternatives au
scnario prconis.
Enfin, la norme prvoit explicitement un cadre de rponse, utile dans le
cadre des marchs publics.

Avantages et inconvnients
Avec les notions de niveau, de flexibilit, de limite dacceptation et de
taux dchange, la norme X50-151 nous donne des pistes de rflexion
intressantes. Ces concepts sont assez difficiles utiliser en pratique
dans le contexte des systmes dinformation, mais on peut sen inspirer
pour construire un modle adapt.
Le modle nest pas adapt aux spcificits du logiciel et des systmes
dinformation. La structure est incomplte et le vocabulaire utilis nest
pas celui du gnie logiciel. Si on dcide de lutiliser, il faudra ncessairement le complter avec des lments dautres modles de cahiers des
charges.

Le modle de Wiegers
Orientation
Le modle prconis par Karl Wiegers est gnraliste, simple et pragmatique, orient vers le dcoupage fonctionnel. Il nest pas trs dtaill. Il
pourra tre utilis pour spcifier des exigences pour un dveloppement
spcifique, mais galement pour un progiciel.

Structure du modle
2. Le modle peut
tre tlcharg sur le
site de Karl Wiegers
http://www.processimpact.com/
goodies.shtml.

Remarquons un certain nombre de particularits concernant ce modle2


de document:
Les interfaces avec le matriel, le logiciel et lutilisateur sont regroupes
dans un mme chapitre. La spcification est centre sur le produit, qui
interagit avec des acteurs externes.
Les modles danalyse (diagrammes de flux, de classes, etc.) sont mis en
annexe. Les diagrammes ne sont pas un but mais un moyen darriver aux
spcifications sous forme textuelle.

160

Livre Constant.indb 160

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 14 Structure du cahier des charges

Tableau14-3 Le modle propos par Karl Wiegers


1. Introduction

1. Introduction
1.1 Purpose

1.1 Objectif

1.2 Document Conventions

1.2 Conventions documentaires

1.3 Intended Audience and Reading


Suggestions

1.3 qui sadresse ce document;


guide de lecture

1.4 Project Scope

1.4 Primtre du projet


1.5 Rfrences

1.5 References

2. Description gnrale

2. Overall Description
2.1 Product Perspective

2.1 Perspective du produit

2.2 Product Features

2.2 Caractristiques du produit

2.3 User Classes and Characteristics

2.3 Profils utilisateurs et caractristiques

2.4 Operating Environment

2.4 Environnement dopration

2.5 Design and Implementation


Constraints

2.5 Contraintes de conception et de


ralisation

2.6 User Documentation


2.7 Assumptions and Dependencies
3. System Features

2.6 Documentation utilisateur


2.7 Hypothses et dpendances
3. Caractristiques du systme

3.1 System Feature1

3.1 Caractristique1

3.2 System Feature2 (and so on)

3.2 Caractristique2 (etc.)

4. External Interface Requirements

4. Exigences dinterface externe

4.1 User Interfaces

4.1 Interfaces utilisateur

4.2 Hardware Interfaces

4.2 Interfaces avec le matriel

4.3 Software Interfaces

4.3 Interfaces avec le logiciel

4.4 Communications Interfaces

4.4 Interfaces de communication

5. Other Nonfunctional Requirements

5. Autres exigences non fonctionnelles

5.1 Performance Requirements

5.1 Exigences de performance

5.2 Safety Requirements

5.2 Exigences de scurit (innocuit)

5.3 Security Requirements

5.3 Exigences de scurit

5.4 Software Quality Attributes

5.4 Attributs de qualit du logiciel

6. Other Requirements

6. Autres exigences

AppendixA: Glossary

AnnexeA: Glossaire

AppendixB: Analysis models

AnnexeB: Modles danalyse

AppendixC: Issues lists

AnnexeC: Liste de problmes

161

Livre Constant.indb 161

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Contenu du document de spcifications


Dans ses ouvrages, Wiegers insiste sur la ncessit de dcrire prcisment la vision et la porte du projet (vision and scope) dans un document
particulier, lors de la phase de prparation. Sil ne dtaille pas ce point
dans son modle de document, cest par ce quil prconise de se rfrer
au document en question, ou de le recopier.
Chaque rubrique (chapitres et paragraphes) est commente en
quelques lignes. Ces diffrents points sont repris avec plus de dtails
dans louvrage Software Requirements, une lecture utile tout analyste des
exigences.

Avantages et inconvnients
De par sa simplicit, ce modle pourra tre utilis par tout analyste ou
consultant charg dlaborer un cahier des charges, mme dbutant. Ce
dernier pourra enrichir le modle pour traiter des cas plus complexes.
Sans ngliger lessentiel, le modle est un peu pauvre en ce qui concerne
les exigences non fonctionnelles. On pourra enrichir le paragraphe sur les
attributs de qualit, par exemple en reprenant des lments de la norme
ISO25000 dj dcrite.

Le modle Volere (Robertson & Robertson)


Orientation
3. Le modle Volere
est tlchargeable
sur www.volere.co.uk.

Utilis sur de trs nombreux projets informatiques (plus de deux mille,


daprs leurs auteurs), le modle Volere3 est fortement orient vers le
dveloppement de logiciels spcifiques. Cest nanmoins un modle suffisamment complet pour tre utilis sur quasiment tout type de projet
(choix de progiciel et mise en uvre, dveloppement spcifique) quel
que soit le domaine dapplication.

Structure du modle
Le modle est structur de manire descendante, les paragraphes correspondent lordre de lecture et, dans une trs large mesure, lordre
dlaboration du cahier des charges, depuis la dfinition des objectifs
jusquaux dtails les plus fins.
Le tableau14-4 donne la structure du modle et sa traduction en franais.

162

Livre Constant.indb 162

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 14 Structure du cahier des charges

Tableau14-4 Le modle Volere


PROJECT DRIVERS

MOTIVATIONS DU PROJET

1. The Purpose of the Project

1. Objet du projet

2. Client, Customer and other Stakeholders

2. Clients et autres parties prenantes

3. Users of the Product

3. Les utilisateurs du produit

PROJECT CONSTRAINTS

CONTRAINTES DU PROJET

4. Mandated Constraints

4. Contraintes obligatoires

5. Naming Conventions and Definitions

5. Conventions de noms et dfinitions

6. Relevant Facts and Assumptions

6. Faits et hypothses dterminants

FUNCTIONAL REQUIREMENTS

EXIGENCES FONCTIONNELLES

7. The Scope of the Work

7. Primtre de luvre

8. The Scope of the Product

8. Primtre de louvrage

9. Functional and Data Requirements

9. Exigences sur les fonctions et donnes

NON-FUNCTIONAL REQUIREMENTS

EXIGENCES NON FONCTIONNELLES

10. Look and Feel Requirements

10. Exigences dinterface utilisateur

11. Usability and Humanity Requirements

11. Exigences dutilisabilit

12. Performance Requirements

12. Exigences de performance

13. Operational Requirements

13. Exigences oprationnelles

14. Maintainability & Support Requirements

14. Exigences de maintenabilit et support

15. Security Requirements

15. Exigences de scurit

16. Cultural and Political Requirements

16. Exigences culturelles et politiques

17. Legal Requirements

17. Exigences lgales

PROJECT ISSUES

QUESTIONS SUR LE PROJET

18. Open Issues

18. Questions ouvertes

19. Off-the-Shelf Solutions

19. Solutions sur tagre

20. New Problems

20. Problmes nouveaux

21. Tasks

21. Tches

22. Cutover

22. Finalisation

23. Risks

23. Risques

24. Costs

24. Cots

25. User Documentation and Training

25. Documentation utilisateur et formation

26. Waiting Room

26. Questions mises en attente

27. Ideas for Solutions

27. Ides de solutions

163

Livre Constant.indb 163

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Le modle Volere est rgulirement revu et amlior par ses auteurs, avec
la contribution des analystes qui lutilisent sur les projets. La dernire
version est tlchargeable sur le site de Volere.
Le tlchargement du document en version anglaise est payant, et son
utilisation sur un ou plusieurs projets est soumise au paiement dune
redevance. On trouve sur le site plusieurs traductions, dont une traduction
partielle en franais (tlchargement gratuit).

Contenu du document de spcifications


Le modle de cahier des charges de Volere contient tous les lments
indispensables la spcification des exigences pour un logiciel, quil
sagisse dune application spcifique ou du choix dun progiciel. Dans le
modle fourni sur le site, chaque lment de la structure est abondamment
comment et justifi.
Notons que les contraintes, au sens large du terme, prcdent les exigences fonctionnelles. Cest une manire de baliser le terrain et de rappeler
que les exigences fonctionnelles sont limites par des contraintes inamovibles. Autre particularit: les exigences non fonctionnelles, ailleurs
traites comme le parent pauvre, occupent huit grands paragraphes.

Avantages et inconvnients
Test sur plus de deux mille projets, rgulirement mis jour, le modle
est dune solidit toute preuve ou presque. Son principal dfaut (qui
nen est pas un, bien sr) est dtre trop riche pour la plupart des projets.
Pour ladapter, il suffit la plupart du temps de tailler cette arborescence
un peu trop touffue.
De par sa complexit et sa compltude, les diffrentes rubriques sont parfois difficiles interprter. Lutilit de certains paragraphes ne saute pas
immdiatement aux yeux. Plutt que de les supprimer, nous recommandons de les laisser sans objet, du moins en phase dexprimentation,
car ils pourraient se rvler trs utiles par la suite.
Les aspects juridiques sont volontairement exclus par ses auteurs, et
devront tre rajouts pour faire du document un CCTP (cahier des clauses
techniques particulires) utilisable dans le cadre des marchs publics.

Construire son propre modle


moins de travailler dans un laboratoire de recherche, inutile de rinventer la poudre. Construire son propre modle de cahier des charges
consiste adapter un modle, essentiellement par limination de paragraphes inutiles, ventuellement par un apport venu dun autre modle.

164

Livre Constant.indb 164

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 14 Structure du cahier des charges

La mthode est donc la suivante:


1. Examiner les diffrents modles parmi les plus classiques.
2. Pour chaque modle, cocher les rubriques qui seront utiles dans le
cadre du (ou des) projets traiter.
3. Choisir le modle le plus proche.
4. liminer les paragraphes inutiles.
5. Si cela savre ncessaire, introduire avec prudence de nouveaux paragraphes, de prfrence partir de paragraphes repris sur dautres
modles.
6. Vrifier et assurer la cohrence de lensemble.
7. Exprimenter le modle, et ventuellement le modifier si ncessaire,
en faisant valider les modifications.
Rappelons-le, un modle de document est un investissement long
terme, particulirement lorsquil sagit dun document comme un cahier
des charges, et plus particulirement si lon a lintention dlaborer plusieurs cahiers des charges dans des domaines proches. Il ne faut donc pas
hsiter investir quelques heures quelques jours sur cette adaptation.

Check-list: cahier des charges


Contrairement la check-list du chapitre prcdent, qui concernait une
exigence individuelle, cette check-list sapplique au document de spcification des exigences (cahier des charges) dans sa totalit.
Compltude. Le document est complet. Lensemble des exigences qui le
composent couvre la totalit du problme.
Cohrence. Il ny a pas de conflit entre deux exigences, ni de redondance.
Traabilit. Toute exigence peut tre trace vis--vis dune exigence de
plus haut niveau ou dun objectif.
Maintenabilit. Le document est maintenable. Un historique des modifications, ou tout mcanisme quivalent, permet de rcrire une exigence
sans perte de cohrence.
Priorisation. Entre deux exigences de mme niveau, il est possible dindiquer laquelle des deux est prioritaire.
Monosmie. Tout terme utilis a la mme signification pour tous les
lecteurs dans tout le document.
Fonctions de persistance (CRUD). Toute entit du systme peut tre
cre (C=create), consulte (R=read), mise jour (U=update) et supprime (D=delete) (ou labsence de cette fonction justifie).

165

Livre Constant.indb 165

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 166

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 15

Ltape
de validation
La validation des exigences permet de sassurer que le document dexigences est complet, correct et cohrent, que les exigences correspondent
des objectifs du matre douvrage ou des besoins des utilisateurs,
et que ces exigences sont correctement formules. Concrtement, la
validation consiste en des revues de document, des inspections et des
check-lists. Le principe est simple et la mthode efficace. Le reste est une
question de discipline.

Intrt de la validation
La validation des exigences nest pas quune formalit bureaucratique.
Lorsquelle est mene avec srieux par des gens de terrain, elle multiplie
considrablement lefficience du processus dexigences. Cest un investissement extrmement rentable.
Les raisons sont faciles comprendre:
Les exigences sont systmatiquement relues par dautres que ceux qui
les ont crites, do une meilleure dtection des incohrences.
La matrise douvrage (ou le marketing) ne perd pas de temps interprter
des exigences floues et se concentre sur le contenu.
Le processus dlaboration est mieux gr, car il fournit des indicateurs
davancement (un pourcentage dexigences valides est plus parlant que
le nombre total dexigences produit).
Le niveau de qualit des exigences devient prvisible, ce qui permet de
planifier plus prcisment le dveloppement et les tests.
Aprs validation, les exigences refltent, dans une large mesure, les vrais
besoins (on naura pas recommencer le dveloppement).

Livre Constant.indb 167

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Il est rare que la validation soit la tasse de th dun groupe de travail


ou dun analyste. Cette activit en rebute plus dun, car la plupart des
personnes prfrent aller de lavant et voient donc les sessions de validation comme du temps perdu. Pour viter de tomber dans ce pige, il
faut planifier et organiser les sessions de validation et les inclure dans le
processus et dans les plannings.

Le processus de validation
La validation (figure 15-1) est essentiellement faite de vrifications par
check-lists et de revues et inspections.
Revues

Spcification

Maquettage
Prototypage

Livraison
CdC

Check-lists

laboration de
cas de test

Figure15-1 : Le processus de validation

Une validation formelle doit avoir lieu pour valider la totalit des spcifications (cahier des charges). Cependant, des validations partielles
peuvent avoir lieu divers moments, par exemple pour un ensemble de
fonctions. On peut prvoir des minivalidations suite une session dun
groupe de travail, soit par les membres du groupe lui-mme, soit en organisant des validations croises.
Des formes simples et rapides de validation (check-lists) peuvent avoir lieu
quasiment tout moment. Les diffrentes formes de reformulation dune
exigence lors dune interview sont en quelque sorte des microvalidations.

Les techniques
Les techniques de validation des exigences sont:
la revue de document, plus ou moins formelle, qui est la technique de
validation proprement parler;

168

Livre Constant.indb 168

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 15 Ltape de validation

le maquettage et le prototypage, dj mentionns, qui sont galement


des techniques de recueil et danalyse;
llaboration de cas de test partir des exigences, qui constitue leur
preuve du feu.
Ces trois familles de techniques peuvent, bien entendu, tre combines.
Dans ce chapitre, nous dcrirons dans les dtails les diffrentes formes de
revue, depuis la liste de contrle jusqu la revue formelle.

Vrification par check-lists


Check-lists de proprits
Le moyen le plus simple de valider les exigences consiste les confronter
une liste de contrle (check-list). Cest aussi la premire tape de la
validation, qui permet de dgrossir la vrification. Les check-lists peuvent
tre utilises par lauteur du document valider (premire vrification) et
doivent tre utilises par tous les autres.
On trouve dans la littrature des dizaines de variantes de check-lists, mais
le principe est toujours le mme. Il sagit de vrifier les exigences individuellement (atomicit, non-ambigut, concision) et le cahier des charges
en tant quensemble dexigences (compltude, cohrence). Le lecteur
pourra utiliser les diffrentes check-lists dj prsentes dans cet ouvrage.

Check-lists de contenu
Ces check-lists permettent de vrifier que le document de spcifications
(cahier des charges) contient toutes les rubriques ncessaires. Ce sont
des check-lists arborescentes qui reprennent la structure du cahier des
charges. Par exemple : le document contient-il la liste des parties prenantes? A-t-on spcifi la fiabilit? Etc.
Nous conseillons de se servir du modle de cahier des charges lui-mme
comme check-list. Si on a bien choisi et bien adapt le modle de cahier
des charges, on na besoin de rien dautre. Il suffit de vrifier que tous
les paragraphes ont t correctement remplis et quil ne reste pas de
paragraphe vide. De plus, la plupart des modles de cahier des charges
contiennent non seulement lensemble des rubriques utiles, mais galement des instructions sur comment les remplir. Cette autodocumentation
dispense de toute check-list supplmentaire.

169

Livre Constant.indb 169

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Relecture simple
Cest, comme son nom lindique, la forme la plus simple de contrle dun
document. Elle fait intervenir deux personnes: lauteur et le lecteur. Les
tapes sont les suivantes:
1. Lauteur fournit le document au lecteur.
2. Le lecteur parcourt le document, y cherche les erreurs ou non-conformits, et note ses remarques (le plus souvent, sur le document
lui-mme).
3. Le lecteur retourne le document annot lauteur.
4. Lauteur prend en compte les remarques.
Ce type de relecture relve plus de la vrification que de la validation. Il
est utile pour passer rapidement en revue un ensemble de spcifications
assez court (une dizaine de pages de cahier des charges est un maximum).
Laction doit tre brve, le cycle complet ne devrait pas dpasser 48heures.
La revue simple est efficace si lauteur et le lecteur sont du mme niveau
hirarchique. Il ne sagit ni de se faire approuver par son suprieur, ni
de sous-traiter une tche de relecture son subordonn. La lecture ellemme devrait tre rapide (cinq minutes par page, pour fixer les ides).
Les annotations peuvent parfaitement se faire sur papier.
De telles revues se font souvent spontanment, bases sur le donnantdonnant (je relis ton document en esprant que tu reliras le mien). La
difficult nest pas de les faire, mais de les institutionnaliser et de les budgter. Autrement, elles dpendent dune initiative individuelle et risquent
de se faire rares lorsque les projets ou les collgues sont sous pression.

Relecture croise
La relecture croise est un peu plus formelle que la lecture simple et fait
intervenir un plus grand nombre dacteurs : un rdacteur et plusieurs
relecteurs. La procdure est la suivante:
1. Lors dune runion, lauteur fait une prsentation gnrale du document plusieurs lecteurs et leur fournit le document.
2. Chaque lecteur lit le document isolment, y cherche les erreurs ou
non-conformits, et note ses remarques.
3. Les participants se runissent. Le document est parcouru pas pas.
Chaque participant indique les points qui lui semblent critiques. Un
des participants note la liste des modifications apporter.
4. Lauteur prend en compte les remarques et apporte les corrections.

170

Livre Constant.indb 170

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 15 Ltape de validation

Cette procdure est plus longue, plus coteuse et plus efficace. Le cycle
complet ne devrait pas dpasser deux semaines. Lquipe de relecture
(auteur et relecteurs) doit tre compose de trois six personnes.

Revue formelle et inspection


Une revue formelle est plus complexe, plus coteuse et plus longue quune
simple relecture du document. Cela demande une certaine discipline et
un investissement important en temps, mais le retour sur investissement
est beaucoup plus consquent.
Une revue doit ncessairement avoir lieu toute nouvelle version du
cahier des charges, avant sa publication ou sa diffusion. On pourra aussi
organiser des revues intermdiaires, sur un extrait du document, la fin
de certaines tapes.
On indique ici la procdure formelle, sachant que celle-ci peut tre simplifie en fonction des mthodes de travail, du budget-temps imparti et
de la criticit du systme.
Planification

Prsentation

Modifications

Lecture

Retour

Runion de
revue
OK
Suivi

Figure15-2 : Le processus de revue

La revue des spcifications dexigences est analogue toute revue de


document. Les tapes dune inspection sont: la planification, la runion
de prsentation, la prparation, la runion de revue, les modifications et
le suivi.
Les participants une revue sont:
lanimateur (ou modrateur) de la revue, dans lidal diffrent de lauteur
du document;
lauteur du document;
les relecteurs;
le secrtaire, de prfrence diffrent de lanimateur.

171

Livre Constant.indb 171

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Lobjectif dune revue est dobtenir un consensus sur le document, et


non corriger des erreurs ou des non-conformits sur lesquelles tout le
monde saccorde. Si on veut viter que les participants gaspillent leur
temps et leur nergie sur des dtails, il faut pralablement toiletter le
document, selon la check-list:
Le document est conforme au modle.
Les fautes dorthographe les plus grossires ont t corriges.
La formulation est conforme aux rgles de bonne prsentation (voir
check-list).
On a prpar une liste des points discuter en sance.
Le document a t relu par une autre personne que lauteur, qui ny a pas
trouv de dfauts majeurs.
La revue comprend les tapes suivantes:
Planification. Choix des participants, du temps consacrer par chaque
participant, des dates de runion, du nombre de runions. La revue est
une dmarche itrative que lon pourrait affiner linfini, il est prfrable
de fixer des limites par avance.
Runion de prsentation. Lauteur du document explique aux participants le contenu du document et ce quil attend de la revue. Cette
tape peut tre supprime si les participants ont lhabitude de travailler
ensemble.
Lecture. Cest ltape la plus importante; chaque participant passe en
revue le document, la recherche de dfauts; il peut saider dune checklist et/ou sappuyer sur son exprience. Il remplit une fiche de revue de
document ou coche une check-list.
Retour. Les participants renvoient leur fiche lauteur, qui prendra en
compte les remarques.
Runion de revue. Les participants se runissent pour discuter des
points obscurs ou de dsaccord. Chaque paragraphe est lu, et tout participant peut faire ses remarques. Les participants dcident si une nouvelle runion doit tre programme.
Modifications. Lauteur du document prend en compte les remarques et
fait les modifications convenues.
Suivi. Un participant vrifie que toutes les remarques et points obscurs
ont t pris en compte.
On peut boucler sur ces tapes jusqu obtenir un niveau de qualit satisfaisant. Pour dcider sil faut planifier une nouvelle tourne de revue ou
sarrter, on pourra utiliser la check-list suivante:
Toutes les remarques ont t prises en compte:
soit le document a t modifi;
soit la remarque a t rejete avec une justification.

172

Livre Constant.indb 172

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 15 Ltape de validation

Le document modifi est correct sur la forme.


Tous les points obscurs ont t levs.
Le document est gr (nom et version, stockage, etc.).
Longue et coteuse, mais utile et rentable, linspection formelle doit
tre institutionnalise haut niveau, dautant plus que les participants
peuvent faire partie dentits trs diffrentes et ne sont pas toujours des
parties prenantes actives (il peut sagir dexperts extrieurs). La difficult
est ici de retenir lintrt de relecteurs qui ne participent pas llaboration
du document.

laboration de cas de test


laborer des cas de test correspondant des exigences, cest dj mettre
ces exigences lpreuve. Pour laborer un cas de test, il faut imaginer le
comportement rciproque de lutilisateur et du systme, ce qui fait ressortir toutes les incohrences qui taient auparavant passes inaperues.
Cest donc un excellent moyen de faire merger les dfauts dans un
document de spcification.
Les cas de test qui sont labors ce niveau concernent videmment des
tests de validation et non des tests de vrification. Comme leur pendant
au niveau des spcifications, ils dcrivent le quoi, et non le comment.
Il est utile dlaborer les cas de test le plus en amont possible. Plutt
que dattendre davoir un cahier des charges entirement boucl, il est
plus intressant danticiper et de commencer llaboration des cas de test
ds que lon dispose dun ensemble suffisamment autonome (cest--dire
cohrent et complet) dexigences. Dtecter des failles rapidement est trs
avantageux: cela vite de refaire les mmes erreurs sur dautres parties
du cahier des charges.
Avant dlaborer ces cas de test, nous conseillons de passer les check-lists
concernant toutes les autres proprits des spcifications (compltude,
cohrence, etc.). Llaboration de cas de test constitue pour ainsi dire
lpreuve du feu pour un ensemble dexigences. Elle dmontre leur
testabilit, qui suppose que les autres proprits (compltude, cohrence,
non-ambigut, etc.) sont vrifies.
Une variante de cette technique consiste laborer, partir des exigences,
la documentation du logiciel. Llaboration de cette documentation peut
tre confie une autre quipe que celle responsable de llaboration du
cahier des charges, ce qui permet de tester quelle est comprhensible
par un lecteur extrieur. On procdera par la suite une relecture croise.

173

Livre Constant.indb 173

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Contrle qualit des exigences


1. V. S. & J. Robertson, Mastering the
Requirements Process,
Addison-Wesley.

Lide est davoir un ou plusieurs points de passage obligs par lesquels


toute exigence passe systmatiquement et sans exception. Robertson1
parle de quality gateway que lon pourrait traduire par passage niveau
de la qualit.
On peut dcider que toute exigence peut se trouver dans lun des deux
tats suivants: non valide ou valide. Le point de bascule dun tat
lautre dpend bien sr du niveau de rigueur du processus dlaboration,
et en particulier de validation.
Les variantes sont videmment possibles. On peut imaginer un systme
trois tats ou plus, par exemple:
0. Propose.
1. Vrifie (check-list minimale).
2. Formellement accepte (par le comit de validation).
La gestion de ces changements dtat est facilite avec les outils de gestion des exigences. Avec de tels outils, tat est une des proprits de
lexigence. Certains outils permettent de dfinir une baseline, ou version de
rfrence dun ensemble dexigences, o toutes les exigences sont valides.

Impliquer les personnes concernes


Ces actions de validation ne serviraient rien si elles ntaient faites par
les personnes adquates au moment adquat. De plus, les diffrentes
parties prenantes doivent simpliquer vritablement. Cest tout lart de la
validation. Le reste nest que procdure.
Cest l que lanalyse des parties prenantes, qui a t faite lors de ltape
pralable, va savrer utile. Par exemple, le cahier des charges en version finale sera sign par le directeur gnral, aprs que de nombreuses
validations partielles ont eu lieu, par dautres analystes puis par les reprsentants des utilisateurs. Le matre duvre devra sengager raliser,
ce qui est aussi une forme de validation. Auparavant, des experts auront
vrifi que les exigences sont effectivement ralisables.
Il sagit l dun cas parmi dautres. Russir impliquer tous les acteurs au
bon niveau au bon moment demande un minimum dorganisation:
avoir dfini une carte des acteurs, cest--dire un schma ou un graphe
des parties prenantes;
ds que possible, procder des validations informelles de spcifications
partielles par les personnes du terrain (reprsentants des utilisateurs);

174

Livre Constant.indb 174

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 15 Ltape de validation

au fur et mesure que les spcifications se consolident, procder des


validations de plus en plus formelles;
tenir informes les parties prenantes de plus haut niveau de responsabilit sans leur demander une validation formelle;
lorsque le document est finalis, revu par toutes les parties prenantes,
faire signer au plus haut niveau (par exemple, directeur gnral).
Cette manire de procder ne garantit pas le succs, mais elle y contribue
grandement. La pire des choses est dobtenir un accord purement formel,
une signature les yeux ferms.
Champagne!
A contrario de la signature de pure forme sans relle implication, lapprobation du
cahier des charges au plus haut niveau de responsabilit peut lgitimement apporter
une grande satisfaction professionnelle lanalyste. Cette satisfaction est dautant plus
importante que le dcisionnaire de haut niveau tait, au dpart, neutre, voire rticent.
Un directeur va signer sil a compris que le cahier des charges qui vient dtre produit
reflte sa stratgie, et la dcline sur le plan oprationnel, en termes plus ou moins
techniques, mais comprhensibles par tous.
Pour arriver ce rsultat, il ny a pas de miracle, pas de secret. Lanalyste doit suivre, de
bout en bout, un processus structur de dveloppement des exigences. Ainsi, chaque
acteur y gagne en termes de cots, de dlais, de qualit. Rien de magique. Cela sappelle lingnierie des exigences.

Check-list: validation






Le rdacteur a pass la check-list de bonne formulation.


Le rdacteur a pass la check-list de structuration.
Une personne extrieure a relu les spcifications.
Les diffrentes parties prenantes ont particip la validation.
Une revue au moins a t effectue.
Un consensus sur les exigences a t obtenu.
Les exigences sont aptes tre communiques pour ralisation.

175

Livre Constant.indb 175

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 176

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 16

Un modle
de processus
Jusquici, nous avons dcrit trs globalement la dmarche gnrale de
dveloppement des exigences puis, plus en dtail, les tapes qui la composent et les techniques que lanalyste peut mettre en uvre chaque
tape. Nous proposons ici un processus, que chacun pourra adapter son
environnement.

Un processus-type
Nous donnons donc ici un modle gnrique, simple, facile utiliser. Il
devra tre adapt et complt en fonction des particularits du projet et
du produit, en particulier:
les objectifs atteindre;
le type de produit (spcifique, adaptation ou choix de progiciel);
le mode de dveloppement en interne ou en externe;
la taille et complexit du produit attendu;
la structure des parties prenantes;
lorganisation de la matrise douvrage et de la matrise duvre;
les procdures dj existantes dans lorganisation;
les risques.
On fera particulirement attention adapter le vocabulaire, trs diffrent
dun domaine dapplication lautre. Des expressions comme comit de
pilotage, comit directeur, ou plan projet peuvent avoir des significations
sensiblement diffrentes selon les organisations. En cas de divergences
entre le vocabulaire de la matrise douvrage et celui de la matrise
duvre, cest gnralement celui de la matrise douvrage (votre client)
qui prime.

Livre Constant.indb 177

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Attention: la carte nest pas le terrain


Rappelons la phrase du clbre statisticien, George Box: Tous les modles sont faux,
certains modles sont utiles. La carte est utile pour comprendre le terrain, mais la
carte nest pas le terrain. Une laboration relle de cahier des charges ne comportera
probablement pas ces sept tapes. Elles sont l pour baliser la route. Chaque analyste
responsable de llaboration dun cahier des charges doit donc interprter, et le plus
souvent adapter, ce processus. En aucun cas, ce modle de processus ne devra tre
suivi la lettre et en ltat. Sous sa forme actuelle, cest une check-list et une aide la
rflexion, et non une procdure.
Ce chapitre donne une carte de processus de dveloppement des exigences. Le lecteur
doit adapter cette carte en ajoutant, en modifiant ou en supprimant des tapes. Au
niveau de chaque tape, il devra adapter les paragraphes pour en faire des fiches de
procdure.

La figure16-1 donne la carte du processus modle.


Itration ventuelle

Lettre
de
mission

1. Cadrer

3. Analyser
lexistant

2. Planifier

Approbation du plan
4. Recueillir
et analyser le
besoin

5. Spcifier les
exigences

Cahier
des
charges

6. Valider le
cahier des
charges

CdC
complet

CdC incomplet : Ritrer

7. Capitaliser

Figure16-1 : Modle de processus

tape 1: cadrer
Entre
Le seul lment crit en entre est ventuellement une lettre de mission.
Ce document nest pas ncessairement une lettre. Mais en tout tat
de cause, cest un document sign par le donneur dordres (matre douvrage stratgique) et adress lassistant la matrise douvrage (matre
douvrage dlgu).

178

Livre Constant.indb 178

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 16 Un modle de processus

Lapprobation formelle du donneur dordres est parfois difficile obtenir.


Si elle ne peut tre obtenue cette tape, elle devra ltre au plus tard
dans la note de cadrage.

Actions
Il sagit davancer autant que possible sur le triangle objectifs-parties prenantes-primtre. Les actions sont:
Recueillir les objectifs, par interview des parties prenantes ct client
(matre douvrage) au plus haut niveau de responsabilit.
Analyser les parties prenantes, du ct du client et du fournisseur,
directes (utilisateurs et dveloppeurs) et indirectes (impactes par le
produit), stratgiques et oprationnelles.
Dfinir le primtre du projet et du produit, au moyen de runions,
dont une runion formelle. Au plus tt, il faudra entamer llaboration
du diagramme de contexte de lexistant, et ventuellement de la cible.
On peut ce stade laborer les en-ttes des cas dutilisation mtier.

Sortie
Le document en sortie de cette tape est la note de cadrage. Il contient
les lments suivants:
objectifs du projet;
structure des parties prenantes;
diagramme de contexte;
liste des vnements mtier;
cas dutilisation mtier;
description des cinq dix exigences de haut niveau;
chiffrage grossier de la ralisation du produit.

Conditions de sortie
La note de cadrage ne doit pas ncessairement faire lobjet dune validation formelle. On peut attendre la sortie de ltape 2 (planification)
pour faire approuver ce cadrage par le donneur dordres. Il est cependant
utile de le formaliser pour en discuter entre analystes et le soumettre au
donneur dordres pour avis.

tape 2: planifier
Entres
Lettre de mission.
Note de cadrage.

179

Livre Constant.indb 179

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Actions
Choisir et adapter le processus de dveloppement des exigences.
Choisir et adapter le modle de cahier des charges.
Choisir et adapter les techniques.
Choisir les outils.
Dterminer les profils utilisateur.
Planifier les jalons importants (comits de pilotage).
Planifier les plages de travail pour les interviews.
Planifier les groupes de travail.

Sortie: le plan projet


Profils utilisateurs types.
Sources dexigences.
Tableau des charges, dlais et planning.
Fiches de risques.

Conditions de sortie
ce stade, le donneur dordres devra avoir approuv la note de cadrage
et le plan projet. Ces deux documents peuvent dailleurs tre runis en
un seul.

tape 3: analyser lexistant


Entres
Liste des documents existants.
Tableau des parties prenantes.
Documentation de lorganisation existante.
Documentation du systme existant.

Actions
Rassembler la documentation sur lexistant.
Analyser le cadre organisationnel.
Examiner les services impacts par le fonctionnement du systme.
Si ncessaire, enrichir le diagramme de contexte de lexistant.
Si ncessaire, enrichir le tableau des parties prenantes.
Analyser les processus actuels.

180

Livre Constant.indb 180

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 16 Un modle de processus

Dresser un diagramme de flux de processus prsentant le circuit des


informations entre services.
Dcrire les fonctions dans leur tat actuel.
Dresser le bilan de la situation actuelle:
inefficience des processus et leurs causes : circuits trop complexes, documents inutiles, rgles de gestion obsoltes, moyens
inadquats;
fonctions inadaptes, manquantes, inutilisables;
difficult dutilisation;
performances du systme: temps de rponse trop longs, consommations;
faiblesse des attributs non fonctionnels : fiabilit, portabilit,
maintenabilit;
support aux utilisateurs insuffisant, faible efficacit de la maintenance.
Mentionner par sous-systme ou domaine:
les principes ou les mthodes remettre en cause;
les processus ou procdures revoir;
les facteurs de qualit revoir;
les informations prciser.
Examiner, pour chacun des points prcdents:
ce qui est conserver, voire amplifier;
ce qui est supprimer ou remplacer;
ce qui est modifier.
Analyser lexistant en termes doffre sur le march.
Si ncessaire, tudier les scnarios dvolution (redveloppement,
migration, choix de progiciel).

Sorties
Panorama de ltat actuel du systme.
Organigramme des services concerns.
Liste des fonctions, en leur tat actuel.
Diagrammes de processus, de squence, dtats.
Vision organisationnelle (postes de travail, nature des traitements, types
de traitements).
Solution technique actuelle: procdures, matriels et logiciels de base,
logiciels applicatifs, progiciels.

181

Livre Constant.indb 181

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Bilan de la situation actuelle : principaux axes damlioration ncessaires au systme actuel.


Axes dvolution (si une tude dvolution a t mene):
liste (non dtaille) des diffrents types de solutions fonctionnelles envisageables;
brve prsentation des scnarios tudis;
justification du scnario retenu;
mesures envisages pour conduire le changement;
mesures envisages pour faciliter lappropriation du nouveau systme par les utilisateurs.
Comptes-rendus dinterview ou note de synthse.

Conditions de sortie
On peut passer ltape suivante lorsque les documents de sortie sont
jugs suffisamment complets et lorsquun consensus sest fait autour des
scnarios dvolution.
Lanalyse de lexistant peut remettre en cause lobjectif ou le primtre,
avec ventuellement des rpercussions sur les charges ou le planning. Si
tel est le cas, il faudra obtenir lapprobation formelle du donneur dordres,
aprs passage ventuel par les tapes1 et/ou 2.

tape 4: recueillir et analyser les besoins


Entres
Les entres de cette tape sont les lments de sortie des trois tapes
prcdentes, en particulier:
lettre de mission;
note de cadrage;
plan projet;
tude de lexistant.
ce stade, labsence dune lettre de mission donnant formellement
lanalyste les moyens et lautonomie de mener sa mission est un facteur
de risque important.

Actions
Planifier le recueil.
Assembler la documentation.

182

Livre Constant.indb 182

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 16 Un modle de processus

Recueillir les besoins organisationnels:


inventorier les rgles de gestion;
inventorier les contraintes.
Recueillir les besoins utilisateurs:
mener les interviews;
animer les groupes de travail;
lire les documents.
Synthtiser et classer les informations recueillies:
exigences mtier;
cas dutilisation;
exigences fonctionnelles;
exigences non fonctionnelles;
contraintes produit;
contraintes projet;
faits et hypothses pertinents.
Reformuler les exigences recueillies (cf. check-list de formulation des
exigences).
Distribuer les exigences recueillies aux participants aux groupes de travail.
Analyser les exigences en groupe de travail:
discuter, en runion de groupe, les informations recueillies;
enrichir, si ncessaire, le diagramme de contexte;
laborer tout diagramme mme de faciliter la comprhension
commune;
raliser, si ncessaire, des maquettes papier;
raliser, si ncessaire, un prototype.
Vrifier les exigences (check-list de recueil et danalyse).

Sorties
Comptes-rendus dinterview ou note de synthse.
Exigences reformules.
Diagrammes.

Conditions de sortie
Lorsque les exigences recueillies forment un tout cohrent, les inclure
dans le cahier des charges en cours dlaboration (tape5).

183

Livre Constant.indb 183

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

tape 5: spcifier les exigences


Entres
Modle de cahier des charges.
Exigences formules.

Actions
Reformuler si ncessaire les exigences recueillies ltape prcdente.
Passer la check-list de formulation des exigences.
Enrichir le cahier des charges avec les exigences recueillies ltape
prcdente.
Passer la check-list de ltape de spcification.

Sorties
Cahier des charges enrichi.
Plan projet ractualis.

Conditions de sortie
Aprs passage russi des check-lists, passer ltape suivante.

tape 6: valider les exigences


Entres
Lors de la premire itration, cest uniquement le squelette de cahier
des charges qui devra tre valid. Pour les itrations suivantes, on devra
valider le contenu, sauf si le squelette a d tre modifi. Les lments
dentre sont donc:
cahier des charges;
note indiquant quelles parties du cahier des charges sont ltat
valider;
modle de fiche de lecture, vierge.
Les indications sur les parties du cahier des charges valider peuvent se
trouver dans le cahier des charges lui-mme, par exemple sous forme de
texte en couleurs, surlign, ou en utilisant le mode rvision dun outil de
traitement de texte.

Actions
Appliquer la procdure de validation, selon le protocole convenu:
revue ou inspection de document;

184

Livre Constant.indb 184

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 16 Un modle de processus

maquette, prototype;
laboration de cas de test.

Sorties
Exigences valides.
Fiches de relecture remplies.

Conditions de sortie
Les validations chaque itration peuvent tre formelles ou informelles.
La dernire itration donnera lieu une validation formelle.
Sil reste des exigences recueillir, repasser ltape4.
Si le cahier des charges est exhaustif, mais que les parties prenantes ont
fait des remarques, repasser ltape5.
Si la totalit du cahier des charges est valide par la totalit des parties
prenantes concernes (donneur dordres, matrise douvrage), le processus dlaboration du cahier des charges est termin. Ltape suivante
(capitalisation) permettra damliorer le processus dlaboration luimme.

tape 7: capitaliser
Entres
Tous les documents labors lors des tapes prcdentes.

Actions



Lors dune runion, solliciter un feedback des parties prenantes.


Modifier, si ncessaire, le modle de cahier des charges.
Modifier ou enrichir les check-lists.
Modifier, si ncessaire, les procdures dlaboration du cahier des
charges.
Remercier les participants.
Clbrer la fin de la mission.

Sorties
Nouveau modle de cahier des charges.
Procdures modifies ou enrichies.
Rapport de mission.

185

Livre Constant.indb 185

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 186

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 17

Amliorer
le processus
Dans les chapitres prcdents, nous avons vu que le processus de dveloppement des exigences doit tre adapt lorganisation, aux objectifs
et au type de projet. Et comme tout processus, il y a des moyens pratiques de lamliorer. Pour rendre le processus plus efficace, il faut
chercher o se trouvent les gisements defficacit. Aprs une explication des facteurs damlioration, nous donnons quelques conseils
pratiques1.

1. La lecture de ce
chapitre nest pas
indispensable la
comprhension des
chapitres qui suivent.

Pourquoi le processus peut tre amlior?


Quelle que soit la dmarche choisie, le processus comporte, dans
ses grandes lignes, toujours les mmes tapes : recueil, analyse, spcification et validation. Peuvent sy ajouter, selon les auteurs, ltape
pralable de cadrage ou prparation, et ltape supplmentaire de capitalisation.
Les ouvrages sur lingnierie des exigences nous disent que les quatre (ou
cinq, ou six) tapes du processus sont imbriques. Et tout praticien
de la mthode sait que ce processus nest ni linaire ni ferm. Comprendre comment et pourquoi ces tapes sont imbriques va nous
permettre damliorer le processus. Or, il y a trois raisons pour lesquelles
les tapes sont interdpendantes:
Le processus nest pas linaire: il contient des boucles de rtroaction.
Le processus est rcursif: chaque tape contient les autres.
Le processus est itratif: on travaille par couches successives.

Livre Constant.indb 187

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

Nous allons dcrire ces trois mcanismes et voir comment ils peuvent
influencer, positivement ou ngativement, lefficience du processus.
Aprs cette analyse, nous aurons en main les moyens damliorer cette
efficience.

Rtroactions
2. Retravail (rework).
Formellement, cest
ltape de prise
en compte des
remarques suite
une inspection ou
une revue formelle.

Le premier mcanisme est facile comprendre: les retours une tape


prcdente2 sont invitables. Ainsi, si au cours dune tape, il manque
des informations (incompltude), on remontera ltape de recueil. Si
lon dcouvre une incohrence, on remontera ltape danalyse. Cela
na rien de dramatique, bien sr, mais occasionne des pertes de temps et
dnergie. Rappeler une personne au tlphone pour lui demander des
prcisions est plus coteux en temps et en effort que, par exemple, reformuler ce quil vient de dire. Ainsi, pour optimiser le processus, il faudra
faire en sorte que les retours aux tapes prcdentes soient les moins
frquents possibles.
Objectifs

Remise en cause de lobjectif


Incohrences
incomprhensions
Analyse

Recueil

Spcification

Validation

CdC

Imprcisions

Incompltudes
Incompltudes

Incohrences, incompltudes, incomprhensions

Figure17-1 : Rtroactions

Rcursions
La deuxime raison pour laquelle les quatre tapes sont imbriques
tient la nature rcursive du processus. Dit plus simplement, chaque
tape contient des lments des autres tapes. Par exemple, lorsque lon
recueille les exigences, on ne va pas se contenter dcouter et de transcrire. On va aussi analyser, voire spcifier, cette exigence. On va pouvoir
anticiper sur les tapes suivre. Cette anticipation peut acclrer le processus, mais aussi le dgrader.

188

Livre Constant.indb 188

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 17 Amliorer le processus

Recueil
Recu
eil

Anal
yse

Spc

Spcification

Analyse
Valid

Recu
eil

Anal
yse

Spc

Valid

Recu
eil

Anal
yse

Spc

Validation
Valid

Recu
eil

Anal
yse

Spc

Valid

Analyse
Recu
eil

Anal
yse

Spc

Valid

Figure17-2 : Rcursivit du processus

Itrations
La troisime raison, cest que le processus est itratif: les spcifications
sont produites par couches successives. Examinons, par exemple, ce qui
se passe lors de la phase de cadrage. Nous allons recueillir les objectifs, les analyser, les spcifier et les faire valider. Ltape pralable nest
ni plus ni moins quun minicycle de la phase dexigences. Il est possible
de systmatiser cette approche et de fournir, par itrations, des cahiers
des charges de plus en plus prcis. Ici aussi, cette faon de travailler peut
acclrer le processus ou le dgrader.
Recueil

Analyse

Spcification

Validation

CdC de
cadrage

Validation

CdC V1

Validation

CdC V2

Itration 1

Recueil

Analyse

Spcification
Itration 2

Recueil

Analyse

Spcification

Figure17-3 : Processus itratif

Comment le processus peut tre amlior


En rsum, trois moyens sont notre disposition pour optimiser le
processus de dveloppement des exigences:
minimiser les retours en arrire chaque fois que cela est possible;

189

Livre Constant.indb 189

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

anticiper sur les tapes suivantes, lorsque cela est utile;


considrer loption de travailler de manire itrative, par couches
successives.
Voyons comment, de manire pratique, ces moyens peuvent tre mis en
uvre.

Minimiser le retravail (rework)


Nous avons introduit, tout au long de cet ouvrage, un outil simple et
efficace pour minimiser les retours en arrire : la check-list. Un simple
contrle nous permet de savoir si nous avons fait tout ce qui devait ltre
une tape donne. Le prsent ouvrage contient plusieurs check-lists,
plusieurs niveaux, mais dautres check-lists peuvent tre labores pour
enrichir le rfrentiel mthodologique dune quipe danalystes.
Remarquons que les documents types sont galement des check-lists
dune forme plus labore. Cest en particulier le cas du modle de cahier
des charges.

La technique de lanticipation
Anticiper ne signifie pas, bien sr, brler les tapes (cela aurait leffet
contraire celui escompt), mais bien prparer chaque sous-tape ou
micro-tape pour analyser, spcifier ou faire valider au plus tt ce qui
peut ltre.
Pour anticiper sur les tapes suivantes, nous avons dj donn quelques
trucs dans les diffrents chapitres. Cette technique danticipation peut
tre systmatise.
Anticiper sur les tapes venir a des avantages et des inconvnients.
Parfois, il est intressant dapporter de la prcision le plus vite possible,
et de sortir dune interview avec des exigences dj clairement formules. dautres moments, il sera inutile de spcifier avec prcision des
exigences qui seront remises en cause la prochaine interview.
Prenons lexemple dun outil de recueil bien connu: linterview. Suite
linterview proprement dite, lanalyste peut mener les actions suivantes:
mini-analyse: confronter les notes dinterview avec les autres lments
recueillis et chercher lever les ambiguts et les incohrences;
minispcification: les notes dinterview peuvent tre structures et bien
formules au lieu dtre laisses telles quelles;
minivalidation: lanalyste envoie la (ou aux) personne(s) interviewe(s)
ces spcifications partielles pour validation.
Ces oprations peuvent tre menes pour la plupart des activits de
recueil: runion de groupe de travail, brainstorming, et mme analyse de
la documentation.

190

Livre Constant.indb 190

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 17 Amliorer le processus

Cette dmarche de pranalyse, prspcification et prvalidation peut se


faire au niveau des microtapes. Par exemple, lors dune interview sur
le terrain, suite une rponse apporte par linterview une question,
lanalyste peut, si les circonstances le permettent, faire en temps rel
une:
microanalyse: confronter la rponse donne dautres exigences; utiliser
des diagrammes et en discuter avec son interlocuteur;
microspcification: reformuler le plus prcisment possible la rponse
de linterview, sous une forme claire et cohrente, prte tre insre
dans le cahier des charges;
microvalidation: lexigence ainsi spcifie par crit est montre sance
tenante aux interlocuteurs pour validation.
Plus rapidement on liminera les erreurs, et plus on pourra sappuyer sur
un terrain solide pour continuer. Cet ouvrage donne plusieurs exemples
de mini-anticipations, comme les check-lists, et de microanticipations,
comme la reformulation. Cependant, ces microanticipations ne sont pas
toujours ralisables, ni mme souhaitables. Cest lexprience qui permet de savoir sil est opportun de les mettre en uvre. Lanalyste doit
mettre en balance le bnfice apport par une analyse ou une formalisation immdiate, et sa possible remise en question par la suite (lors dune
autre interview, par exemple).

Le travail itratif
Travailler par couches horizontales peut tre trs intressant. Mais l
aussi, il ny a pas de rgle absolue. Dans son ouvrage sur le travail collaboratif sur les exigences3, Ellen Gottesdiener consacre un chapitre entier
aux diffrentes manires de naviguer entre les exigences avec les groupes
de travail, soit horizontalement, par couches successives, soit verticalement, en descendant dans les dtails au cours dune runion, soit mme
en zigzag.
La premire couche horizontale, celle de la dfinition des objectifs et du
cadre, sera gnralement bien spare des autres. Nous lavons dcrite en
dtail au chapitre6. Elle donne lieu un livrable particulier. Rien nempche dailleurs dutiliser ce livrable comme premier chapitre du cahier
des charges.

3. Ellen Gottesdiener,
Requirements by
collaboration, Addison-Wesley, 2002.

La mthode du document navette


Un principe simple
La technique consiste mener les travaux, du premier recueil des objectifs jusqu la validation finale, autour de la cration et de la tenue jour

191

Livre Constant.indb 191

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 2 Dveloppement des exigences

dun document unique, le cahier des charges. Cette dmarche simple et


efficace prsente plusieurs avantages:
Le cahier des charges devient le fil directeur du projet. Il est la fois le
matriau sur lequel on travaille et lobjectif atteindre.
La progression est visible de tous. Lenrichissement progressif dun document partag permet chacun de constater les progrs en temps rel.
Les acteurs ont un seul et unique document grer. Ce document central va devenir un vritable outil de communication entre les parties prenantes.
Avant de partager le document, il faudra figer, autant que possible, le
modle de cahier des charges, qui va couvrir les diffrents aspects du projet et faciliter la structuration des ides et des activits. Le sommaire du
document va constituer un guide pour le recueil et lanalyse des besoins,
la dfinition fonctionnelle et les orientations de solution. Toute modification ultrieure devra faire lobjet de ngociations. Cette tape est sous la
responsabilit de lanalyste, qui est le garant de la forme et de la mthode.
En stoffant, le document va permettre de contrler la couverture et la
progression de tous les aspects, au fur et mesure de lavancement du
projet. Bien entendu, cela nempche pas de prvoir des documents complmentaires (comptes-rendus de runions du comit de pilotage, par
exemple). Mais cest toujours le document navette qui fait foi.
De manire optimiser ses travaux danimation et de conseil la matrise
douvrage, lanalyste va enrichir le cahier des charges de faon continue au
cours des tapes de recueil, danalyse et de spcification, ce qui rduira
leffort de rdaction et de validation. Le document changera de version au
cours du projet, en passant dun tat exploratoire un tat provisoire, pour
se figer, aprs validation par les parties prenantes, ltat de rfrence.
Cette manire de procder permet le partage du contrle de la qualit
des livrables pour ainsi dire en temps rel, et un dialogue plus fluide
entre matrise douvrage et matrise duvre. Le modle de cahier des
charges, puis les versions successives de celui-ci serviront de support
ce dialogue. Cette coconstruction permet de dterminer prcisment les
priorits en termes dexigences non fonctionnelles, car matrise douvrage
et matrise duvre construisent ensemble un vocabulaire commun et
non ambigu.

Une pratique simple et efficace


La technique du document unique ne rsout pas tous les problmes. Elle
minimise le nombre de documents et demande beaucoup de rigueur dans
la gestion des versions du cahier des charges. Plutt que de grer une
multitude de documents (gnralement non versionns), on devra grer
les versions multiples, et gnralement arborescentes, dun document

192

Livre Constant.indb 192

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 17 Amliorer le processus

central. Cest tout aussi complexe, mais plus efficace lorsque lon matrise
la technique. Par exemple, le cahier des charges est mi-parcours:
Lors de la runion dun groupe de travail, lanimateur note les exigences
au fur et mesure du recueil, soit sur papier, soit directement sur le
document lui-mme. Il peut utiliser une couleur diffrente pour les diffrentes modifications apportes (vert pour un nouveau texte, rouge pour
un texte supprimer, violet pour un texte revoir, etc.). Il peut galement utiliser le mode rvision du traitement de texte (attention, certains
ont beaucoup de mal avec le mode rvision, dautres ne le supportent
tout simplement pas).
la fin de la runion, ou dans les deux jours qui suivent, lanimateur
envoie le document aux diffrents acteurs, pour validation.
Les remarques sont prises en compte et une nouvelle version du document est cre.
Cette manire de procder peut galement tre mise en uvre si lon
utilise des outils de gestion des exigences. En fonction des circonstances
et de la typologie des acteurs, loutil sera soit directement utilis par les
groupes de travail, soit uniquement utilis par le consultant ou les animateurs. La plupart des outils permettent de gnrer un document de
spcifications (cahier des charges en devenir) qui est le reflet de la base
dexigences. Ici, il ny a pas de mthode unique, elle est trs dpendante
des outils utiliss et de la culture de lentreprise.

193

Livre Constant.indb 193

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 194

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

PARTIE

Faire vivre
les exigences
Il est bien sr illusoire de penser que les exigences, une fois formules,
vont rester graves dans le marbre. En ralit, les exigences voluent tout
au long du cycle de vie du logiciel, cest--dire avant, pendant, et aprs
la phase dexigences. Les changements dans les exigences vont donc
impacter non seulement le cahier des charges, mais le produit en cours
dcriture ou dj crit. La gestion des exigences est donc trs lie la
gestion des versions et de la configuration du logiciel. Dans ce cadre, les
outils de gestion des exigences peuvent amliorer lefficacit et la scurit de ce processus.

Livre Constant.indb 195

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 196

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 18

La gestion
des exigences
Dans cet ouvrage, il a t essentiellement question de ce quil est convenu
dappeler le dveloppement des exigences, processus qui permet, en
partant dun objectif, daboutir un cahier des charges. En ralit, les
demandes et contraintes voluent tout au long du cycle de vie du logiciel: pendant la phase dexigences, mais galement pendant les phases
ultrieures : conception, ralisation, intgration et maintenance. Il est
illusoire de penser que les exigences sont un jour stabilises. Ce chapitre
est consacr la gestion des demandes de changement, activit appele
gestion des exigences.

La gestion des changements


La gestion des changements des exigences est la frontire de plusieurs
activits dingnierie du logiciel, en particulier la gestion des versions, la
gestion de la configuration logicielle, et la gestion de projet. En effet, tout
changement dans les exigences aura un impact sur:
la configuration du logiciel1;
les cots et les dlais de livraison des diffrentes versions;
les ressources engages pour oprer les modifications.
Ltude de ces disciplines (gestion de configuration et gestion de projet)
dpasse le cadre de cet ouvrage. Nous nen aborderons ici que les aspects
en relation directe avec lvolution des exigences.
Le changement en lui-mme est invitable. Il doit tre contrl de
manire :

1. Gestion de configuration: discipline


qui consiste grer
les divers composants
dun systme, ainsi
que les modifications
apportes au cours
de son volution.

conserver la cohrence entre demandes manant dutilisateurs ou


dacteurs diffrents et non concerts;

Livre Constant.indb 197

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Faire vivre les exigences

matriser le cot induit par une modification (une modification en apparence lgre, pourra induire un impact trs important en termes de
cots, de dlais, darchitecture du produit);
viter les spcifications rampantes, suite une demande initiale souvent mal formule et peu formalise, avec des drives sur les dlais, les
charges et la qualit du produit;
contrler le circuit de dcision, viter de court-circuiter les parties
prenantes qui ont la lgitimit pour dcider ou conseiller;
tracer les modifications demandes et les modifications faites.

Les activits
Cette gestion du changement est donc essentielle, et vite que leffort
initial de recueil, danalyse et de structuration des exigences soit perdu.
Les activits de gestion consistent :
valuer limpact dune exigence sur les exigences existantes, et limpact
de sa mise en uvre sur le produite dvelopp ou en cours de dveloppement;
estimer limportance, lurgence et la difficult de ralisation dune modification, qui peuvent tre trs diffrentes lorsquelles sont estimes par
le demandeur (qui a une vision partielle de la situation) ou par les dveloppeurs (qui voient surtout les contraintes techniques);
ngocier les modifications et grer les exigences selon les priorits ainsi
dfinies, aprs obtention dun consensus;
suivre les modifications, et mettre jour les plannings;
enregistrer les demandes et les modifications;
mettre jour les documents (cahier des charges, spcifications, documentation du produit).

La commission de contrle des changements (CCB)


2. Le plus difficile:
constituer une commission de contrle
des changements
qui soit lgitime et
institutionnaliser
le processus de
contrle de manire
le rendre incontournable.

Afin que les changements soient grs plutt quimposs ou subis, la


bonne pratique consiste mettre en place une commission de contrle
des changements (en anglais, CCB, change control board). Cette commission
devra tre un passage incontournable pour toute demande de modification des exigences2. Toute demande de changement, mme minime,
devra tre formalise au moyen dun formulaire ad hoc, puis passer par
cette commission. La commission dcide de la suite donner, en fonction des priorits de lentreprise, des impacts sur les cots et les dlais,
des modalits de prise en compte dun changement dans les exigences.
Plusieurs modles dorganisation sont possibles, en fonction de la taille
de lorganisation et du nombre de projets en cours. Lorganisation la plus

198

Livre Constant.indb 198

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 18 La gestion des exigences

classique consiste mettre en place une commission par projet, prside


par le chef de projet matrise duvre.
La commission est forme au minimum dun reprsentant de la matrise
duvre et dun reprsentant de la matrise douvrage, ainsi que dun
expert et dun gestionnaire de configuration. Elle se runit dates fixes,
ou en cas de besoin. Ses prrogatives sont:
la revue les demandes de changement;
lanalyse dimpact (dlgue un dveloppeur ou expert);
la priorisation des demandes;
la dcision de faire, de ne pas faire, ou de reporter le changement, en
fonction des impacts sur les cots et les dlais;
le suivi de la mise en uvre du changement;
en cas de difficult, lescalade du problme au plus haut niveau de dcision.

La runion de la commission
La gestion des changements sur les exigences est un processus rigoureux,
illustr par la figure18-1.
Objectifs

Enregistrement

Analyse
dimpact

Dcision

OK

Ordre de
modification

Modification

Clture

OK

approbation

Figure18-1 : Le processus de gestion des changements

199

Livre Constant.indb 199

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Faire vivre les exigences

Chaque demande de changement est enregistre, puis examine par la


commission de contrle des changements qui, en fonction de la nature, de lurgence et de limportance du changement apporter, la transmettra un
expert (concepteur, dveloppeur, souvent plusieurs personnes) qui va
analyser limpact de la modification. Suite cette analyse, la commission de contrle des changements peut, soit rejeter la demande, soit
dcider de demander une ou plusieurs modifications. Cette modification
peut tre planifie pour la version en cours de dveloppement, ou pour
une version ultrieure. Lorsque toutes les modifications relatives une
demande de changement ont t effectues et approuves, la demande
est close.

Lanalyse dimpact
Lanalyse dimpact peut tre effectue par un ou plusieurs experts
(assistant matrise douvrage, dveloppeur, testeur), mais elle est sous
la responsabilit dune seule personne, nommment dsigne. Elle se
concrtise par une fiche (le tableau18-1 est un exemple de fiche danalyse
dimpact).

Les attributs des exigences


Afin de pouvoir tre gre, chaque exigence doit comporter un certain
nombre dattributs:
date de cration;
numro de version;
demandeur (partie prenante lorigine de la demande);
auteur (personne qui a formalis la demande);
son statut (provisoire, mise en uvre, supprime, ajourne);
priorit;
degr de stabilit;
version du logiciel impact par le changement;
et composant du logiciel o lexigence est mise en uvre.
Pour grer tous ces attributs avec rigueur, mais sans surcharge excessive
de travail, les outils de gestion des exigences deviennent vite indispensables.

200

Livre Constant.indb 200

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 18 La gestion des exigences

Tableau 18-1 Un modle de fiche danalyse dimpact


Rapport danalyse dimpact
Numro de demande de changement
Intitul de la demande
Description prcise de lexigence

Pris en charge par:


Le:

Risques encourus si le changement est mis en


uvre

Risques encourus si le changement


nest pas mis en uvre

Estimation du cot du changement


(jours*hommes)

Estimation de leffort perdu (cot de


la suppression dune fonction dj
existante+cot dun dveloppement
qui sera abandonn)

Impact sur le planning global du projet

Impact du changement sur les charges


totales

Impact sur la qualit finale des livrables (performances, maintenabilit )


Autres exigences impactes
Tches affectes si le changement est mis en uvre
Problmes dintgration estims
Liste des documents qui seront touchs par une modification
Liste des modules de code qui seront touchs par une modification
Liste de tous les autres lments qui seront touchs par une modification

Lvolution des demandes de changement


La figure18-2 prsente le diagramme dtats des demandes de changement et dordres de modification.

201

Livre Constant.indb 201

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Faire vivre les exigences

MOA

MOE

Demande
enregistre

Modification
demande

Demande
value

Modification
effectue

Dcision prise

Modification
approuve

Changements
effectus

Demande close

Figure18-2 : Diagramme dtat des demandes de changement

Une demande de changement pourra donner lieu plusieurs ordres de


modification (en effet, une demande peut impacter plusieurs composants
du logiciel et faire appel des expertises diverses).
Toute demande de changement va passer par des tats successifs:
propose : enregistre, soit sur une fiche prvue cet effet, soit au
moyen dun outil de gestion des changements ou dun outil de gestion
des exigences;
approuve par la commission de contrle des changements, elle a donn
un ou plusieurs ordres de modification;

202

Livre Constant.indb 202

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 18 La gestion des exigences

modifie: les modifications correspondant la demande ont t prises


en compte;
vrifie: les tests correspondant la demande de changement ont t
effectus;
supprime ou rejete: la demande peut avoir t retire par le demandeur
ou rejete (avec justification) par la commission.

Une discipline ncessaire et rentable


Le processus de gestion des changements des exigences que nous venons
de dcrire est complexe et demande de la rigueur et de la discipline :
procdures, commission, fiches remplir, analyses dimpact, suivi et traabilit. Ces oprations ne sont pas si consommatrices de temps que lon
pourrait penser. Et contrairement ce que lon pense souvent, elles ne
sont pas un frein la crativit des dveloppeurs, elles ne servent qu
canaliser cette crativit.
Mettre en place cette bureaucratie de projet ncessite un changement
culturel. La mise en place et linstitutionnalisation dun tel processus
peuvent prendre plusieurs mois. Il faudra surtout viter de sembarquer
dans des processus usines gaz, disproportionns la taille des projets et au type de produit dvelopp. En revanche, cette discipline, mme
lgre, devra tre incontournable.
Cette discipline permet de prserver une grande partie de leffort consenti
en amont, en phase de dveloppement des exigences. La cohrence des
exigences, et donc du produit livr, est ce prix. Remarquons que cet
effort de gestion sera de toute faon ncessaire aux autres activits de
dveloppement, en particulier:
valuation prcise des charges;
gestion optimale des ressources (dveloppeurs, testeurs);
alignement entre produit, spcification et documentation.

203

Livre Constant.indb 203

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 204

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 19

Les outils

partir dune certaine complexit, le besoin de mettre en uvre des


outils de dfinition ou de gestion des exigences se fait sentir. Utiliss
bon escient par des personnes comptentes, ils vont contribuer efficacement au processus. Mais attention, il y a aussi de fausses raisons de les
utiliser et des piges viter.

Check-list: votre projet en a-t-il besoin?


Comme nous lavons vu, pour grer les exigences et leurs volutions, il
est ncessaire de tenir jour un certain nombre dattributs pour chacune
delles. Le besoin est fonction de limportance du projet, cest--dire du
primtre fonctionnel, de la taille des quipes et des besoins de traabilit exigs. Sur un projet dimportance, la gestion dinformations telles
que la date de cration ou de modification dune exigence et ses liens de
traabilit deviennent un vrai casse-tte. Il est difficile, voire impossible,
de grer toutes ces informations la main.
Lutilit des outils de gestion des exigences est fonction, entre autres:
du nombre dexigences traiter, qui dpend du primtre fonctionnel et
du niveau de dtail;
du nombre dattributs grer pour chaque exigence, qui dpend de la
rigueur demande au processus;
du nombre de personnes en charge de recueillir, analyser, spcifier,
modifier les exigences;
du temps dhistorisation prvu pour ces donnes, de la prennit dans
le temps des exigences;
du degr de rutilisation des exigences dun projet lautre;
de la volatilit des exigences (ncessit de les modifier souvent);

Livre Constant.indb 205

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

du nombre de rgles de gestion dont dpendent ces exigences;


de la possibilit dinvestir du temps se former aux outils.
Cette liste peut servir de check-list pour estimer grossirement (mais
rapidement) le besoin doutiller.

Les bonnes raisons dutiliser les outils


La premire raison dacqurir un outil est lie au processus de dfinition
et de gestion des exigences elles-mmes. Un bon outil facilite lapplication des bonnes pratiques de dveloppement (utilisation dun modle,
mise en forme du texte) et de gestion des exigences (traabilit des changements, gestion du cycle de vie des modifications).
La seconde raison dutiliser les outils concerne la gestion des changements dans leur ensemble. Dans un monde o tout va trs vite et o les
changements sont constants, les exigences sont rarement stables. Cela
est vrai quil sagisse des besoins (manant des clients) ou des contraintes
(lies aux technologies), et mme des rgles de gestion. Tout changement
dans les exigences aura des rpercussions sur lensemble des autres activits: conception, ralisation, tests, maintenance.
La troisime raison est la conformit. Les changements eux-mmes
devront tre tracs. En effet, de nos jours, les entreprises sont soumises
des contrles de plus en plus nombreux : audits, certifications (ISO
ou autres), valuation des pratiques professionnelles, accrditations,
normes et standards de conformit, de traabilit, de scurit... le logiciel
lui-mme nchappe pas, bien sr, ces obligations: scurit, interoprabilit, conformit des rgles de gestion de toute sorte font partie du lot
quotidien des analystes et dveloppeurs. On se dit que bientt, la fort
de la conformit va cacher larbre de la fonctionnalit. Quoi quil en soit,
il faudra faire avec.

Fonctions de base et fonctions avances


Fonctions de rfrentiel
Un outil de gestion des exigences est avant tout un rfrentiel. Il permet
de stocker, et de retrouver facilement, lensemble des exigences, leurs
attributs et leurs liens de traabilit. Il arrive avec un certain nombre de
fonctions de cration, de retrait, de modification, et de suppression des
exigences ou de leurs attributs. Il permet de contrler laccs ces informations, do son utilit pour le travail de groupe.

206

Livre Constant.indb 206

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 19 Les outils

Stockage. Les exigences sont stockes, gnralement dans une structure arborescente, sous une forme indpendante du document final de
spcifications (cahier des charges). Le rfrentiel stocke, en plus des
attributs, ltat de chaque exigence (propose, en cours, valide, etc.).
Filtrage. Il est possible dutiliser des filtres pour visualiser une partie
seulement de larborescence.
Traabilit des accs. Loutil trace tous les accs une exigence ou
un attribut.
Gestion des liens entre exigences, et possibilit de suivre les liens de
traabilit horizontale ou verticale.

Traabilit horizontale et verticale


Les exigences sont relies entre elles de plusieurs faons. On dnombre
au moins deux types de traabilit:
La traabilit verticale lie les exigences et leur volution au long du
cycle de vie du logiciel, depuis les exigences de haut niveau jusquaux
composants du logiciel.
La traabilit horizontale lie les versions successives dune mme exigence.

Traabilit verticale

Objectif X

Exigence
mtier Y

Exigence
utilisateur Z
(V0)

Exigence
utilisateur Z
(V1)

Exigence
lmentaire
V0

Exigence
utilisateur Z
(V2)

Exigence
utilisateur Z
(V3)

Traabilit horizontale

Figure19-1 : Traabilit horizontale et verticale

Ces deux types de lien de traabilit sont indispensables si lon veut


contrler et grer long terme les demandes de changements. Or, au-del
dune certaine taille de projet, le maintien de ces liens de traabilit est
quasiment impossible sans la mise en uvre doutils adquats.

207

Livre Constant.indb 207

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

Gestion des attributs


Seul un outil permettra de renseigner facilement tous ces attributs, dont
certains (date, auteur, etc.) de manire automatique. Avec un document
texte, cet exercice est un vritable casse-tte. Lutilisation dun tableur
est une solution de contournement, mais ne permet pas de stocker (ou
trs difficilement) les exigences qui se prsentent sous forme de tableau
ou de graphique. La plupart des outils permettent un administrateur
de paramtrer les attributs et de crer des types dattributs diffrents en
fonction du type dexigence. Tout utilisateur pourra visualiser les attributs
de chaque exigence, et certains utilisateurs pourront modifier des attributs
en fonction de leur habilitation.
Une multitude dattributs
Un trs grand nombre dattributs peuvent tre accols chaque exigence. En voici
quelques-uns:
date de cration;
version actuelle;
auteur (le rdacteur);
responsable de la mise en uvre;
demandeur (pas ncessairement utilisateur du produit);
bnficiaire (en gnral, un profil utilisateur);
priorit;
justification de lexigence;
version du produit o lexigence sera mise en uvre;
statut (provisoire, en cours dtude, valide);
volatilit (exigence provisoire ou prenne);
tests faire pour la vrifier;
seuils de tolrance (pour les exigences non fonctionnelles);
traabilit horizontale et verticale.
Sy ajoutent les attributs concernant la modification apporte une exigence: date,
auteur, demandeur, justification, etc.

Travail dquipe
Ces fonctions favorisent un travail dquipe sr et efficace, qui est pnible
et risqu (voire impossible) lorsque lon partage un document sous
traitement de texte.
Traabilit. Loutil garde la trace de toutes les modifications faites sur
une exigence ou un attribut, ainsi que de la date et lauteur de chaque
modification.

208

Livre Constant.indb 208

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 19 Les outils

Contrle daccs. Loutil gre les accs aux exigences et aux diffrents
attributs, en fonction de droits daccs paramtrables.
Scurisation des modifications. Loutil bloque laccs en criture des
exigences en cours de modification, nautorisant que les accs en lecture.
Communication de projet. Loutil envoie un message aux diffrents
utilisateurs lorsquune exigence ou un ensemble dexigences viennent
dtre modifies. Il garde la trace dune discussion concernant une
exigence particulire.
Gestion de projet. Loutil conserve ltat de chaque exigence (en cours,
valider, modifier). Cela facilite le suivi.

Gestion des versions et des changements


Ces fonctions rendent ce type doutil proche des outils de gestion des
versions et de la configuration (ils peuvent dailleurs sinterfacer avec
certains dentre eux).
Versionnement. Loutil garde la trace des changements faits sur une
exigence et incrmente son numro de version.
Mise en rfrence (baselining). Loutil permet de figer une configuration de rfrence (baseline) et de crer de nouvelles versions dune spcification dexigences en sappuyant sur une configuration de rfrence
existante.
Automatisation du processus. Certains outils facilitent le processus
de gestion des changements dexigences en liaison avec la gestion des
versions des exigences.

Rdaction et documentation
On constate donc quun outil de gestion des exigences est beaucoup plus
intressant quun traitement de texte. Il nempche quune large partie du
travail consiste rdiger et que le livrable final est souvent un texte avec
toutes les contraintes de rdaction et de typographie en vigueur. Loutil
doit donc tre capable de faciliter la rdaction et la prsentation documentaire. Entre autres fonctions, on trouve les suivantes:
Respect du modle de spcifications. Il est possible de paramtrer
la structure des exigences selon un modle prdfini. On force ainsi le
respect dun modle de cahier des charges.
Glossaire. Loutil permet dalimenter et maintenir un glossaire des
termes, et chercher les occurrences dun terme du glossaire.
Respect des rgles dcriture. Outre le classique correcteur orthographique, loutil possde des fonctions de recherche contextuelle de
termes flous, de phrases ambigus, de mots inconnus, de certaines incohrences.

209

Livre Constant.indb 209

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

Gnration automatique de documents. partir dun modle de document prdfini, du contenu du rfrentiel et dun ensemble de filtres,
loutil gnre automatiquement le cahier des charges ou tout autre
document de spcifications.
Intgration de graphiques. Loutil permet de crer ou dintgrer des
exigences sous forme graphique: scnarios, modles de donnes, etc.
Import de documents. Loutil permet dintgrer des exigences contenues dans un cahier des charges dans le rfrentiel, en fonction de
rgles paramtrables ; par exemple, niveau de titre ou style de paragraphe c orrespondant un niveau ou type dexigence.

Attention aux mirages


On le voit, les avantages de ces outils sont certains. Prenons garde, nanmoins, ne pas tomber dans le pige des outils. lui seul, aucun outil ne
se substituera une bonne organisation et une discipline rigoureuse. Si
les exigences sont mal gres, un outil ny fera rien. Il pourra mme avoir
un effet contre-productif.
Citons quelques-unes des fausses bonnes raisons dacqurir un outil:
Il gre mieux les spcifications et la documentation des exigences.
Cest faux. La rdaction du cahier des charges se fait par des personnes
comptentes. Un traitement de texte pourra les aider, bien mieux quun
outil de gestion des exigences.
Il gre mieux les changements des spcifications et de la documentation. Cest vrai, mais partiellement. La gestion des changements est
une affaire de processus et de personnes. En termes doutils, un tableur
pourra faire laffaire. Ce nest que sur la combinatoire gestion des changements et gestion de la documentation quun outil apportera sa pleine
puissance, car il permet de lier automatiquement les deux.
Il facilite le travail de vrification et de validation. Ce nest que trs
partiellement vrai. Effectivement, certains outils disposent de fonctions de recherche en plein texte et de dtection de phrases douteuses,
mais le gros du travail est intellectuel et ne peut tre pris en charge par
quelque outil que ce soit.

Quand et comment choisir un outil?


Inutile de choisir un outil si lon na pas, dj, un modle de document
peu prs stable et un processus rigoureux de dfinition et de gestion des
exigences. Comme nous lavons dit plus haut, un bon outil ne peut pallier

210

Livre Constant.indb 210

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 19 Les outils

un processus dfaillant, il ne peut quempirer la situation. De plus, il vaut


mieux choisir un outil en fonction du processus que linverse.
Un outil de gestion des exigences doit tre slectionn comme tout
logiciel:
en analysant lexistant et le contexte de lorganisation;
en prcisant les objectifs (par exemple, amliorer la productivit, scuriser les accs, automatiser la production de documents, rutiliser les
exigences);
en recueillant les besoins, en les analysant, en les spcifiant dans un
cahier des charges;
en prparant une grille de slection efficace (on sinspirera des fonctions
dcrites plus haut);
en tant rigoureux jusquau bout.
Pour un analyste des exigences, ces actions semblent aller de soi, mais
lexprience montre quil est plus difficile dtre rigoureux quand on travaille pour sa propre organisation (pour savoir pourquoi, analysons les
parties prenantes: celui qui finance mon outil est aussi celui qui me paye
la fin du mois).
Une fois loutil slectionn, acquis, install, il faudra le traiter comme tout
autre logiciel. En particulier, il faudra se former loutil, tre conseill
par lditeur (attention: la conduite du changement cote gnralement
beaucoup plus cher que loutil lui-mme), et travailler sur le paramtrage.
Dune manire gnrale, il faut viter de se prcipiter, et avoir un processus bien rd avant de lembarquer dans loutil. Ce que lon ne peut
pas accomplir avec un papier et un crayon, inutile de tenter de le faire avec
loutil, car sa complexit peut perturber. Acontrario, si lon sest pris la
tte de nombreuses reprises, avec un traitement de texte, larrive de
loutil sera vcue comme un soulagement et ses bnfices vite apprcis.

211

Livre Constant.indb 211

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 212

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 20

Au-del
des exigences
Le travail de lanalyste consiste spcifier les exigences, mais aussi valuer les solutions proposes, et leur adquation aux exigences spcifies.
Pour y parvenir, nous pouvons utiliser diverses techniques, en complment ou la place de llaboration dun cahier des charges. Nous sommes
ici aux confins de la phase dexigences, et pntrons parfois dans la zone
floue entre exigences et conception.

tude de choix
Pour une tude comparative ou une tude de choix, la dmarche parfois
appele en entonnoir (figure20-1) est la plus classique: elle permet
daller du gnral au particulier et du global au dtaill.

Les tapes
Les tapes de la dmarche sont les suivantes:
Screening. Une dizaine de fournisseurs de logiciels, dont les produits
correspondent, dans les grandes lignes, aux besoins du client, sont identifis, et leurs produits sont passs en revue. On peut inclure dans cet
ensemble des logiciels qui ne prsentent pas toutes les caractristiques
requises, mais dont lexamen peut apporter des informations intressantes, ou rvler de nouveaux critres de choix.
Prslection. En collaboration avec le client, nous examinons les cinq
progiciels qui correspondent au mieux aux critres dfinis par le client;
paralllement, la liste des critres est affine. On dtermine les critres
obligatoires et les critres liminatoires.
Short-list. Toujours en collaboration avec le client, une liste restreinte
(gnralement trois logiciels) est fixe; ces logiciels sont examins de

Livre Constant.indb 213

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

prs ; paralllement, et indpendamment, les critres sont pondrs


lors dune runion avec les responsables, chez le client.
Approfondissement. Les trois logiciels short-lists sont examins
de prs. Une note est attribue chaque critre. On aboutit, selon la
demande du client, soit la slection dun produit unique, soit un
tableau comparatif permettant une prise de dcision efficace.
Screening

Prslection

Shortlist

Approfondissement

Figure20-1 : La mthode de lentonnoir

tude comparative complexe


Il y a plusieurs faons de traiter les rponses un cahier des charges. On
peut procder une analyse comparative tenant compte de contraintes
multiples, non seulement fonctionnelles, techniques et organisationnelles, mais galement stratgiques ou politiques. Une fois ltude faite,
le challenge est de donner un dcideur de haut niveau, non spcialiste, une vision trs claire des potentialits des diffrentes solutions en
prsence, et ce, souvent en moins de cinq minutes.
Ltude se fera comme prcdemment, et inclura des lments supplmentaires dexpertise sur des points particuliers (intgrabilit, dploiement,
conduite du changement, etc.). La prsentation des rsultats devra tre
percutante. Pour cela, on devra fournir aux dcideurs des tableaux et
des schmas extrmement simples, contenant le minimum dinformations.
Linformation plus dtaille sera jointe si ncessaire en annexe.

Tableau de B.O.R.D.
Le tableau de B.O.R.D. (Bnfices, Opportunits, Risques, Dangers) est
une variante du tableau SWOT (Strengths, Weaknesses, Opportunities, Threats,

214

Livre Constant.indb 214

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 20 Au-del des exigences

cest--dire forces, faiblesses, opportunits et menaces) en plus contrast.


Lide est de prsenter un tableau trs synthtique, lusage des dcideurs.
Ce tableau indique, pour chaque solution prsente, les:
Bnfices: avantages procurs de faon certaine ou trs probable par
lacquisition du produit, court ou moyen terme, sans investissement,
ou avec un investissement faible.
Opportunits : avantages apports par le produit, au prix dun effort
financier ou organisationnel raisonnable.
Risques : difficults pouvant surgir, avec une probabilit faible ou
moyenne, suite la mise en place du produit, et pouvant tre surmontes
avec un investissement financier ou organisationnel raisonnable.
Dangers: difficults lourdes de consquences, ayant une forte probabilit de surgir suite la mise en place du produit, et ne pouvant tre
jugules que par un effort financier ou organisationnel important.
Dans lexemple1 donn au tableau20-1, la solutionY a t choisie, car elle
apporte un vritable avantage concurrentiel sans risques insurmontables.
La solution X semble moyennement bien place, la solution Z risque.
Cependant, le choix revient au dcideur, qui aurait pu en dcider autrement.
Tableau20-1 Tableau de B.O.R.D
Solution X

Solution Y

Solution Z

1. Lexemple prsent
ici correspond un
cas rel (outil de
workflow pour le systme dinformation
administratif dans
lindustrie automobile).

Exprience dans au
moins un projet denvergure et de nature
similaires. Excellente
capacit de conseil et de
gestion de projet.

Possibilit pour le client


de dvelopper sa propre
solution.

Solution ouverte, en
particulier extensible
(workflow).
Possibilit de tirer profit
de lexprience chez un
autre client.

Possibilit de tirer profit


de lexprience de lentreprise W.

Manque dexprience
du fournisseur sur des
projets denvergure
similaire.

Produit complexe,
exigeant une bonne formation et un bon suivi
de projet.

Solution ferme, difficilement extensible;


ngociations techniques
difficiles.

Solution trs contraignante pour lutilisateur


final

215

Livre Constant.indb 215

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

Graphique de synthse
Le graphique de la figure20-2 fait la synthse des lments mentionns
dans le texte du rapport et les tableaux, et permet de comparer les diffrentes solutions proposes en mettant en balance les bnfices apports
et les difficults pressenties. Il permet de comparer:
les bnfices, qui se dcomposent en:
rponse de loffre aux exigences du cahier des charges,
potentiel dvolution de la solution propose,
capacit de service du fournisseur: conseil, support, et assistance
technique;
et les cots pour le client, qui se dcomposent en:
prix dachat et cot de la mise en uvre,
cots de la phase transitoire (baisse initiale de la productivit du
personnel),
conduite du changement (formation, information et accompagnement).
Solution X

Solution Y

Solution Z

Bnfices

Capacit de service
Potentiel dvolution
Rponse aux exigences

Cots

Achat et mise en uvre


Phase transitoire
Conduite du changement

Figure20-2 : Graphique comparatif de synthse cots/bnfices

tude dopportunit complexe


Un exemple dtude
Une tude dopportunit peut tre trs complexe et faire appel des
comptences et des savoir-faire trs divers. Dans lexemple qui suit, nous

216

Livre Constant.indb 216

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 20 Au-del des exigences

allons dcrire une tude quun cabinet de conseil a effectue pour une
grande ville franaise. Il sagissait dtudier lopportunit de remplacer
toute la bureautique existante par du logiciel libre. Ltude a mobilis
deux consultants sniors (un consultant matrise douvrage et un expert
technique) pendant trois mois, avec une charge totale de 50 jourshommes.
tape1: lancement.
Il sagit ici de dfinir le primtre de la mission, didentifier les acteurs
(trs nombreux), et de figer le plan dtaill des livrables
tape2: tude de la stratgie dvolution.
Lobjectif est de dfinir lordre et la stratgie de mise en place dun
projet de passage au logiciel libre dans ladministration de la ville.
tape3: tat des lieux fonctionnel et technique sur lexistant.
Elle consiste en une consultation de lAdministration (France) au
moyen dinterviews des responsables informatiques (dveloppement,
maintenance et exploitation).
tape4: tude de lexprience dans une autre ville europenne.
Lobjectif de cette tape est davoir un retour dexprience dans une
administration analogue, dans un autre pays europen, et de connatre
les avantages, inconvnients, cots, contraintes, difficults rencontres
suite au passage au logiciel libre.
tape5: tude des besoins des dcideurs et utilisateurs.
Ce nest qu cette tape quintervient ltude des besoins, trs grosses
mailles. Lobjectif nest pas de dfinir des besoins fonctionnels, mais
davoir un avis des dcideurs et futurs utilisateurs. Une majorit dentretiens a t faite par tlphone.
tape6: tude des produits disponibles et de leur utilisation.
Lobjectif est ici de connatre les contraintes techniques inhrentes au
passage au logiciel libre, les avantages, inconvnients, le potentiel de
ces outils.
Ltape a consist examiner les diffrents types de produits logiciels
libres sur le march (rseaux, systmes dexploitation, applicatifs).
On a essentiellement examin lutilisation qui en tait faite. Cela a
ncessit de rencontrer la fois les utilisateurs et les industriels. cette
tape, les aspects techniques taient secondaires.
tape7: tude des contraintes techniques.
On a examin les contraintes techniques sur le matriel et le logiciel,
et analys limpact li au renouvellement du parc informatique (mises
niveau, migration ou portage des applications, impacts sur la scurit).

217

Livre Constant.indb 217

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

Lanalyse a permis de mettre en regard les contraintes et les produits


disponibles.
tape8: tude des aspects financiers.
On a examin les aspects financiers sur plusieurs critres: utilisation,
mise en uvre, conversion de fichiers, cots des mulateurs (pour les
applications qui nont pas dquivalent dans le monde du logiciel libre),
mise en uvre de la scurit, migration des applicatifs et formation.
tape 9 : synthse tenant compte des aspects techniques, organisationnels et financiers.
Cette synthse comprend : les scnarios cibles de passage, lanalyse
technique, lanalyse conomique, lanalyse des risques. Elle est formalise par un tableau de synthse pour lestimation du cot de la migration, et un tableau de bord avantages et inconvnients pour chaque
scnario.

Une mission la limite


Une mission de conseil de ce type est la frontire entre la dfinition
des besoins et une tude pralable un schma directeur. Dans cette
mission, ltude des besoins proprement dite, au sens de lingnierie des
exigences, noccupe quune place modeste.
Ltude a t mene par un consultant senior et un expert technique.
Les trs forts enjeux politiques ont constitu une difficult supplmentaire. Cependant, si le consultant snior avait eu le rflexe de mener une
analyse formalise des parties prenantes, certains cueils auraient probablement t vits.
Une autre difficult provient de la dichotomie opre entre les aspects
techniques et les autres, accentue par le fait que les consultants taient
de profils trs diffrents. Tout au long de cet ouvrage, nous avons pu
voir que les exigences pouvaient tre structures en couches, depuis
les exigences stratgiques (en loccurrence, politiques) jusquaux exigences fonctionnelles et techniques. Les consultants ont examin ces
deux aspects extrmes, sans consacrer le temps ncessaire lexamen
des exigences de niveaux intermdiaires (exigences mtier et exigences
utilisateurs).

tude dintgrabilit et design


Tout au long de cet ouvrage, nous avons rpt cette recommandation
la manire dun dogme: il faut spcifier des besoins, et non une solution. Cela reste toujours vrai lorsque lon labore un cahier des charges.

218

Livre Constant.indb 218

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 20 Au-del des exigences

Cenest qu la phase suivante, la phase de conception, que lon spcifie


la solution.
Or, la frontire entre dfinition des besoins et conception de la solution
nest pas toujours tanche. Prenons un cas frquent: nous avons labor
un cahier des charges pour une application de gestion complexe. Plus
prcisment, nous avons dfini les exigences pour un systme dinformation (sans mme parler dapplication, puisque nous cherchons une
solution). Ce cahier des charges, nous lavons labor dans les rgles
de lart, dans le plus strict respect de la mthodologie. Puis nous avons
labor une grille de dpouillement qui reprend point par point chaque
exigence.
Cependant, les offres des fournisseurs ressemblent ce que lon peut voir
dans la figure20-3: malgr leurs qualits respectives, aucun produit ne
correspond parfaitement la demande. Cependant, le besoin peut tre
couvert par une intgration entre deux des logiciels, ou les trois logiciels.

Cahier
des
charges

Grille de
dpouillement
Exigence 1
Exigence 2
Exigence 3
Exigence 4
Exigence 5
Exigence 6
Exigence 7
Exigence 8

Offre A
Exigence 1
Exigence 2
Exigence 3
Exigence 4
Exigence 5
Exigence 6
Exigence 7
Exigence 8
Offre C
Exigence 1
Exigence 2
Exigence 3
Exigence 4
Exigence 5
Exigence 6
Exigence 7
Exigence 8

Offre B
Exigence 1
Exigence 2
Exigence 3
Exigence 4
Exigence 5
Exigence 6
Exigence 7
Exigence 8

Figure20-3 : Des exigences larchitecture de la solution

Nous venons de franchir la frontire qui spare les exigences de la conception. Nous sommes face un problme de design, darchitecture du systme
dinformation. Nous devons faire un choix entre trois scnarios:
choisir un produit parmi les trois et faire dvelopper en spcifique les
fonctions manquantes;
faire dvelopper une interface entre les deux produits;
faire intgrer les trois produits.

219

Livre Constant.indb 219

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

Ltude de lintgration entre diffrentes briques du systme dinformation doit se faire non seulement sur le plan technique, mais aussi sur
le plan conomique, et aussi sur le plan de lergonomie. Deux produits
peuvent trs bien communiquer entre eux sur le plan technique et aboutir
une catastrophe en ce qui concerne lutilisabilit, la fiabilit, et bien sr
la maintenabilit de la solution.
Aprs tude, nous devrons reformuler notre demande vis--vis dun, de
deux ou de trois fournisseurs, et donc laborer un nouveau cahier des
charges. Et nous voil de nouveau passs de lautre ct de la frontire,
nouveau dans la phase dexigences. Voil pourquoi on dit que la frontire
entre la phase dexigences et la phase de conception est souvent floue.

220

Livre Constant.indb 220

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 21

Neuf conseils

Nous avons dcrit le processus, la dmarche dlaboration, les tapes,


techniques et outils. Nous avons montr pourquoi et comment le processus peut tre adapt aux diffrents contextes, et pourquoi et comment
il peut tre amlior. Voici quelques conseils pour russir encore mieux,
plus efficacement.

1. Ayez toujours lobjectif en tte


En principe, vous connaissez lobjectif de votre client, et si ce nest pas
le cas, votre premire tche consiste le dcouvrir et le dfinir avec prcision. Votre objectif est align sur celui de votre client, mais il nest pas
identique celui du client.
Votre objectif vous, analyste des exigences, est de livrer votre client,
lheure convenue avec lui, un cahier des charges labor selon les rgles
de lart. Vous pouvez affiner cette formulation et la mettre par crit. Il
faudra la garder en tte et avancer. Vous devez tenir le cap contre vents
et mares.
Il est parfaitement normal que le client lui-mme retarde le projet, change
davis, en demande trop ou au contraire nexprime rien. Il est normal que
les ides divergent dun acteur lautre, que la motivation passe par des
hauts et des bas, que lanalyste devienne lexutoire de tous les conflits.
Pour filer la mtaphore de la navigation, cest lorsque le bateau tangue
quil est utile de savoir clairement o lon va. Vous devez garder le cap
malgr les drives.
Cette vision claire de lobjectif vous permettra de planifier llaboration
du cahier des charges, et guidera vos dcisions lors de vos interventions
sur le terrain.

Livre Constant.indb 221

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

2. Analysez et validez au plus tt


Dans les chapitres prcdents, nous avons indiqu plusieurs raisons
danalyser et de valider au plus tt, et nous avons donn quelques techniques pour y parvenir. Mais il y a aussi des raisons psychologiques,
qui sont complmentaires aux raisons techniques. Lanalyse au plus tt
apporte une visibilit qui permet de mieux matriser la situation et encourage les diffrents participants travailler ensemble. La validation au plus
tt donne un feedback rapide et une vision claire qui encouragent aller
de lavant.

3. Lancez-vous un dfi et donnez-vous les moyens


de le russir
La dfinition des besoins ne devrait jamais tre une routine, car deux
clients nont jamais le mme objectif, les mmes besoins, le mme
pass, les mmes acteurs. laborer un cahier des charges est un travail difficile, mme pour les plus dous et les plus expriments dentre
nous.
Certains consultants font du travail la chane, en brlant les tapes.
Ils vendent leur client un cahier des charges prfabriqu, en spcifiant de manire approximative des exigences valides en vitesse par
une minorit dacteurs. Malgr les apparences, la valeur ajoute dun tel
document est faible. La satisfaction professionnelle, elle aussi, est faible.
Dautres baissent les bras devant les difficults. Ils pensaient que la
tche serait facile. Elle ne lest quen apparence. Les vraies difficults
sont humaines et concernent la rsolution de conflits et la gestion des
priorits. La tentation est grande alors de faire de lanalyse des besoins
une tche purement technique, et de court-circuiter certaines parties
prenantes. Au premier abord, la qualit du livrable semble satisfaisante.
Lensemble est en apparence correct et complet. Mais le vritable besoin
na pas t cern.
Le challenge est de concilier la rigueur et la souplesse, et de fournir un
livrable dans un temps court et au moindre cot, sans que cela se fasse au
dtriment de la qualit. Pour y arriver, il faut utiliser la bonne dmarche
et les bonnes techniques, sy entraner encore et encore, et aussi clbrer
les russites.

222

Livre Constant.indb 222

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 21 Neuf conseils

4. Conciliez concepts et action de terrain


Supposons que vous ayez lu un ou plusieurs ouvrages sur lingnierie des
exigences ou llaboration du cahier des charges pour le logiciel. Vous
avez appris une dmarche, des concepts, sans rien mettre en pratique.
Supposons maintenant quaprs cela, vous partez sur le terrain avec un
consultant aguerri pour laborer un cahier des charges. Il est fort probable
que vous constatiez un fort dcalage entre ce que vos avez lu et ce que
vous voyez et entendez. Vous commencez avoir des doutes. Ce que vous
avez lu est-il pure thorie, ou bien est-ce le consultant qui sy prend mal?
La vrit doit se situer entre les deux. Sans doute le consultant utilise sa
mthode, qui a fait ses preuves, sans chercher loptimiser outre mesure.
Peut-tre a-t-il pris quelques mauvais plis en mme temps quil a pris
de lassurance vis--vis de ses clients. Mais le plus probable est quil utilise de nombreuses techniques dcrites dans cet ouvrage de manire trs
souple. Pour un petit projet, les objectifs peuvent tre dcrits en quelques
lignes et apparatre dans le compte-rendu dune runion de lancement.
De mme, lanalyse des parties prenantes peut tre faite rapidement et
son rsultat tenir en quelques lignes.
Lorsquon est dbutant, il vaut mieux aller lentement, formaliser et tracer dans la mesure du possible, pour des raisons pdagogiques et pour
scuriser leur relation avec le client. Lorsque les bonnes pratiques sont
devenues des rflexes, on peut prendre de lassurance et de la vitesse.
Dans le feu de laction, quand le processus est optimis, les concepts et
la pratique sont une seule et mme chose.

5. Concentrez-vous sur votre livrable


Le dsir datteindre un livrable de qualit est le meilleur moteur de laction. En pratique, cela signifie que les livrables intermdiaires, cest--dire
les versions intermdiaires du cahier des charges, mme en chantier
doivent, toutes proportions gardes, tre irrprochables. Un document
navette nest pas un document poubelle. Les parties complter, retravailler, valider doivent tre clairement signales au moyen de conventions
connues de tous. Si des paquets dexigences, en provenance de sources
diverses, doivent tre intgrs au document intermdiaire, cela doit se
faire selon des rgles strictes, mais simples mettre en uvre.
Avec cette manire de procder, lquipe danalystes et leurs clients ont
leur disposition un document toujours prsentable, sur lequel on peut
discuter, qui demandera le moins de remaniement possible. Dans le cas
contraire, lquipe passera son temps bricoler et rafistoler, ce qui
consomme beaucoup de temps et dnergie.

223

Livre Constant.indb 223

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

Sur le plan psychologique, cette mthode prsente aussi de nombreux


avantages. On a plaisir travailler sur un document bien clair, on voit
le travail avancer, et cela tire tous les participants dans une spirale
vertueuse. Dans le cas contraire, cest lnervement permanent.

6. Sachez russir presque coup sr


Savoir que lon ne court aucun risque, ou presque, de rater un cahier des
charges, est trs scurisant et permet de travailler dans de bonnes conditions. Encore faut-il savoir sy prendre.
Il y a un secret pour russir de cette manire: la mission dlaboration
dun cahier des charges doit tre structure de telle sorte que, quoi quil
arrive, elle ne soit jamais un chec complet, et toujours une russite ou
une quasi-russite. Mais comment faire?
Daprs la loi de Pareto, 20% de leffort dlaboration permettra datteindre 80 % du rsultat escompt. En dautres termes, si tout se met
aller mal alors que vous nen tes qu un cinquime du parcours, le
cahier des charges, lui, sera prt aux quatre cinquimes.
La loi de Pareto se vrifie si lon choisit le bon modle de document, les
bonnes mthodes, le bon rythme, et quon travaille de manire mthodique pour faire les choses dans le bon ordre. Il ny a pas de rgle absolue
pour savoir quel est le bon ordre dlaboration, mais le plus souvent, il
vaut mieux travailler de manire descendante, par raffinements successifs, depuis les objectifs jusquaux dtails les plus fins.
Dans le cas contraire, o nous sommes face un existant, (par exemple
une spcification existante), le bon ordre consiste consolider cet existant en le (re)formalisant, puis remonter jusquaux objectifs, puis
redescendre nouveau dans les dtails de plus en plus fins.
La loi de Pareto sapplique galement en ce qui concerne le champ de
ltude, les objectifs et les parties prenantes. Do lintrt de bien les
connatre ds le dbut, et de connatre les priorits. Si on ne peut pas
tout faire ou satisfaire tout le monde, il vaut mieux savoir qui satisfaire en
premier et quels sont ses objectifs prioritaires.

7. Mettez en avant votre client


Cest votre client, la matrise douvrage, qui labore le cahier des charges,
pas vous. Effacez-vous devant lui et valorisez son travail. Vous tes animateur, facilitateur, expert, mais cest votre client qui exprime un besoin, et
il lexprime sa matrise duvre. Se mettre en avant nest ni fair-play, ni
efficace. Lorsque vous parlez au matre duvre, vous tes le porte-parole

224

Livre Constant.indb 224

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Chapitre 21 Neuf conseils

du matre douvrage, vous ne faites que traduire ses besoins. Lorsque vous
faites une prsentation brillante en comit de pilotage, rappelez-vous :
votre prsentation est une reprsentation des besoins de votre client.
Lorsque le cahier des charges sera livr, si tout se passe bien, si votre client
est gnreux et bon joueur, il reconnatra peut-tre que vous avez fait du
bon travail et vous remerciera pour le service que vous lui aurez apport.
Cela fait trs plaisir et encourage faire encore mieux la prochaine fois.
Mais au cours de llaboration, votre ego doit rester au vestiaire.

8. Perdez un peu de temps pour en gagner


beaucoup
Le temps perdu nest pas toujours celui que lon croit. Faire limpasse
sur le recueil dun objectif, laisser de ct une partie prenante pour,
soi-disant, gagner du temps, est purement et simplement un manque
de professionnalisme. Bien sr, votre hirarchie, votre client, le matre
duvre ou toute autre partie prenante peut faire pression pour vous
pousser aller plus vite. Il est de votre responsabilit dexpliquer vos
interlocuteurs quil faut consolider les fondations avant de sattaquer aux
murs, et que le temps investi sera rcupr au dcuple.
Il ne faut donc pas hsiter consacrer du temps aux tapes en amont de
llaboration: dfinition de lobjectif, des parties prenantes et du champ
de ltude. Si un de ces points est mal dfini, il faudra aprs coup dfaire
le travail et le refaire. Et parfois, tout reprendre du dbut. Cela occasionne
beaucoup de temps perdu, de fatigue inutile, de stress et de dcouragement.
Ce qui est vrai pour le macroprocessus dlaboration lest aussi au niveau
des microprocessus. Le temps pass prparer une interview ou une runion nest pas du temps perdu. Parfois, il vaut mieux passer beaucoup de
temps discuter autour dun schma que davancer. Cest lexprience
qui permet de distinguer linvestissement en temps, de la perte de temps
pure et simple. Aussi, est-il important dobserver sa propre manire de
procder et dessayer de samliorer en permanence.

9. Faites de la dfinition des besoins un projet


en soi
Dfinir les besoins est un vrai mtier, avec ses mthodes, ses techniques,
ses outils, avec des experts et un savoir-faire propre. Les analystes ont
leur propre rythme de travail, leurs rgles et leur code de bonne conduite,

225

Livre Constant.indb 225

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Partie 3 Gestion des exigences

qui diffrent de ceux des ralisateurs ou des testeurs. Voil pourquoi il


faut considrer llaboration dun cahier des charges comme un projet en
soi, avec son livrable bien dfini. De plus, avoir une vision globale de la
mission de dfinition des besoins est beaucoup plus valorisant et pousse
laction.
Considrer la dfinition des besoins seulement comme un sous-projet, et
non un projet en soi, nest pas trs motivant. Vous avez acquis un savoirfaire, ou vous tes en train de lacqurir, cest votre mtier, vous tes pay
pour a, vous portez le projet.
Bien sr, vous devez vous assurer que les exigences que vous spcifiez
sont ralisables, que les contraintes techniques sont elles aussi spcifies, que lensemble est cohrent. Bien sr, vous pouvez, et parfois vous
devez, dialoguer avec la matrise duvre. Mais ce qui adviendra du systme aprs la livraison du cahier des charges ne fait pas partie de votre
mission. Cela peut lgitimement vous intresser, mais ne doit en aucun
cas consommer votre nergie.

226

Livre Constant.indb 226

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Annexe

Les questions
large spectre
Comment utiliser ces questions?
Ces questions peuvent servir constituer un guide dentretien de dernire minute, ou dfricher un terrain inconnu, en vitant langoisse de la
page blanche. Il ne sagit en aucun cas de les grener de la premire la
dernire: cela ne ferait que mettre linterlocuteur mal laise (ou sil lest
dj, de le mettre encore plus mal laise). Et de toute faon, elles sont
redondantes. Quoi quil en soit, ces questions gnriques peuvent tre
une aide; elles ne sont pas une panace.

Liste de questions
Questions de situation, questions gnriques
Ces questions permettent de connatre le contexte.
En quoi consiste votre activit actuelle? (Cette question permet de dfinir ou de cerner la partie du processus qui va impacter le futur utilisateur
interview.)
Pouvez-vous dcrire la manire dont votre service (bureau, organisation,
entreprise) fonctionne actuellement?
Quel est votre rle actuel?
Dans quelle mesure votre activit sera-t-elle impacte par le futur
systme?
Les questions suivantes sont trs gnrales. La premire, trs (trop)
gnrique, est utiliser avec modration.
Quattendez-vous du futur systme?

Livre Constant.indb 227

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

Que souhaitez-vous que le systme fasse?


En quoi le futur systme va-t-il amliorer votre activit?

Questions dobjectif
Ces questions sont poser au matre douvrage stratgique et aux parties
prenantes dcisionnaires.
Quel problme voulez-vous rsoudre?
Quattendez-vous de la solution future, du futur logiciel?
Comment saurez-vous que la solution propose aura atteint son objectif?
Une fois que votre systme sera oprationnel, que va-t-il vous apporter?
Quelles seront les retombes positives de la mise en place de la solution
future, du futur logiciel?
Quelles seront les consquences ngatives de la mise en place de la
solution future, le logiciel?

Questions de manque
Par dfinition, un manque est un besoin. Chercher les manques est donc
une bonne faon de faire exprimer les besoins.
Quest-ce qui manque au systme actuel?
Comment ce manque qui pourrait-il tre combl par le futur systme?
Quest-ce qui est dfaillant avec le systme actuel?
Quest-ce qui vous drange le plus dans le systme actuel?
Si une chose vous drangeait avec le systme actuel, ce serait quoi?
Que voudriez-vous que le systme venir fasse et que le systme actuel
ne fait pas?
Peut-on faire ensemble la liste de toutes les fonctions que le systme
actuel accomplit mal?

Questions sur le systme ltude


Pour connatre les donnes:
Quelles sont les donnes manipules par le systme?
Quelles donnes le systme devra-t-il stocker?
Quelles sont les donnes contenues dans cette entit?
Quelles sont les relations entre ces deux donnes?
Pour identifier les tats et transitions dun objet:
Quel est le cheminement du dossier, dun objet?
Dans quels tats peut se trouver le dossier, lobjet?

228

Livre Constant.indb 228

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Annexe Les questions large spectre

Quel vnement va modifier le dossier, lobjet?


Que se passe-t-il suite cet vnement?
Que se passe-t-il si cet vnement na pas lieu? (Exception)

Questions de perspective
On demande au futur utilisateur ou toute autre partie prenante de se
projeter dans lavenir.
Quattendez-vous du futur systme?
Que voudriez-vous que le systme venir fasse?
Que voudriez-vous que le systme venir fasse mieux que le systme
actuel?
Quest-ce qui doit tre amlior par le futur systme? (Sans ncessai
rement dfinir une solution, cette question approfondit le besoin.)
Quel critre doit-on utiliser pour prouver que le systme satisfait cette
exigence?
Pouvez-vous dcrire le futur systme, tel que vous limaginez?

Questions de prcision
Oui? (Se taire et attendre que linterview prcise spontanment la
pense.)
Oui, et plus prcisment? (viter oui, mais; prfrer oui, et.)
Un de vos collgues (si ncessaire, prserver la confidentialit) a exprim
le besoin davoir []. tes-vous du mme avis que lui? (Rassurer linterlocuteur: il a le droit davoir un avis diffrent.)
Comment faites-vous? (Apporte du dtail.)
Pourquoi[]? (Remonte des exigences de plus haut niveau; utiliser avec prudence, et ne jamais impliquer linterview avec ce type de
questions.)

Critres de priorisation et de validation


On demande maintenant lutilisateur de dfinir ses priorits et des
critres de validation de lexigence.
En quoi cette exigence est-elle importante pour vous?
Quest-ce qui fera que vous serez satisfait avec le futur systme?
Comment saurez-vous que le futur systme est satisfaisant?
Pouvez-vous indiquer les trois fonctions indispensables du futur systme?
Si vous ne deviez conserver que trois fonctions parmi celles dcrites,
lesquelles conserveriez-vous?

229

Livre Constant.indb 229

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 230

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Glossaire franais
Besoin. Ncessit ou dsir prouv par un utilisateur (AFNORX50-150).
Cahier des charges. Document par lequel le demandeur exprime son
besoin (ou celui quil est charg de traduire), en termes de fonctions de service
et de contraintes. Pour chacune delles, sont dfinis des critres dapprciation
et leurs niveaux. Chacun de ces niveaux doit tre assorti dune flexibilit
(AFNORX50-150).
Client. Le client (ou matre douvrage) sera le propritaire de lobjet du
cahier des charges. Il est responsable de la dfinition des exigences, du
financement, et de lapprobation de la solution.
Contrainte. Limitation la libert de choix du concepteur ralisateur du
produit (AFNORX50-150).
Critre dapprciation. Caractre retenu pour apprcier la manire dont
une fonction est remplie ou une contrainte respecte (AFNORX50-150).
Demande. Expression, encore subjective et partielle, de la perception
dun besoin, un instant donn.
Dveloppement de logiciel. Processus par lequel les besoins des utilisateurs sont transforms en spcifications, les spcifications en conception,
la conception en code, et le code test, document et valid en vue dun
usage oprationnel (dfinition IEEE).
Domaine fonctionnel. Ensemble dactivits cohrentes concourant une
finalit de lorganisme.
lmentaire (exigence). Se dit dune exigence qui ne peut tre dcompose, inscable (en anglais, atomic).
Ergonomie. Discipline scientifique qui vise la comprhension fondamentale des interactions entre les tres humains et les autres composantes
dun systme, et la mise en uvre dans la conception de thories, de
principes, de mthodes et de donnes pertinentes afin damliorer le
bien-tre des hommes et lefficacit globale des systmes (Association
Internationale dErgonomie).

231

Livre Constant.indb 231

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

Exigence. Description formelle dun objectif. Lapprciation de la satisfaction dune exigence peut tre mesure.
tat de lart. Ensemble des rgles respectes implicitement par les professionnels dune activit.
Fonction. Action dun produit, ou de lun de ses constituants, exprime
exclusivement en termes de finalits (AFNORX50-150).
Fonction de service. Action attendue dun produit (ou ralise par
lui) pour rpondre un lment du besoin dun utilisateur donn
(AFNORX50-150).
Fournisseur. Le fournisseur (ou matre duvre) sengage sur les conditions quil accepte : chancier des livraisons, matrise des cots,
satisfaction des exigences.
Ingnierie du logiciel ou gnie logiciel (en anglais, Software Engineering).
Approche systmatique du dveloppement, de lexploitation, de la maintenance et de la mise la retraite dun logiciel (dfinition IEEE).
Logiciel. La somme des programmes, procdures, rgles de gestion, en
rapport avec le fonctionnement dun ordinateur, ainsi que la documentation et les donnes qui leur sont associes (dfinition IEEE).
Maquette. Objet destin aider un client spcifier ses demandes.
Processus. Ensemble dactivits corrles ou interactives qui transforme
des lments dentre en lments de sortie (ISO9000).
Produit. Ce qui est (ou qui sera) fourni un utilisateur pour rpondre
un besoin. Le produit peut tre un objet, un fluide, une prestation de
service, un processus industriel ou administratif (procd, logiciel, procdure, etc.) ou toute combinaison de ceux-ci (AFNORX50-150).
Prototype. Objet destin vrifier la faisabilit dune solution sous un
aspect particulier : conceptuel, organisationnel ou technique. Un prototype enchane des parties relles (celles dont on veut montrer la
faisabilit) et des parties fictives (en gnral, celles qui correspondent
des fonctions dont la ralisation ne semble poser aucun problme).
Qualit. Ensemble des proprits et caractristiques dun produit, ou
service, qui lui confrent laptitude satisfaire des besoins, exprims ou
implicites. La matrise douvrage et lutilisateur sintressent principalement la qualit du produit, alors que la matrise duvre sintresse
la qualit du processus. Cette dernire contribue la qualit du produit.
Solution. Ensemble coordonn de moyens matriels, logiciels, humains,
organiss pour satisfaire un ensemble dexigences.
Spcification. Traduction dexigences en lments techniques.

232

Livre Constant.indb 232

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Glossaire franais

Systme. Ensemble cohrent dlments matriels et logiciels en interaction dynamique, destin assurer une finalit pralablement dfinie.
UML (Unified Modeling Language). Langage standard de reprsentation
de linformation (donnes, traitements), principalement sous forme de
diagrammes.
Utilisateur. Personne ou entit pour qui le produit a t conu, qui
exploite au moins une des fonctions du produit. (AFNORX50-150).

233

Livre Constant.indb 233

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 234

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Glossaire bilingue
La littrature anglophone sur les exigences (en anglais, requirements) est
trs riche et le vocabulaire sy rapportant fait lobjet dun large consensus entre auteurs. Ce nest pas le cas en franais, o lon emploie des
mots diffrents pour dsigner les mmes objets ou concepts. De plus,
les termes et expressions varient en fonction du pays (France, Canada,
Belgique, Suisse), du mtier (informatique technique, systmes dinformation, ingnierie systme) et des auteurs.
Le lecteur ne devra donc pas stonner si les termes employs dans cet
ouvrage sont diffrents de ceux avec lesquels il a t familiaris. Malgr
notre effort de minimiser le nombre de termes flous et dutiliser autant
que possible les mmes mots pour dsigner les mmes concepts, certaines ambiguts nont pu tre vites.
Voici une liste dquivalence (non exhaustive) entre les termes anglophones et le(s) quivalent(s) utilis(s) en franais dans cet ouvrage.
Analyst ou requirements analyst. Littralement analyste des exigences.
Analyste fonctionnel; analyste mtier; assistant la matrise douvrage,
conseil la matrise douvrage.
Business requirements. Exigences mtier (au Qubec: exigences daffaires).
Client, customer. Client; matrise douvrage (stratgique ou oprationnelle).
Elicitation (requirements). Recueil des besoins, ou capture des besoins ou
des exigences.
Need. Besoin. Dans le cadre de lanalyse des besoins, terme beaucoup
moins usit que requirement.
NFR, non-functional requirements: exigences non fonctionnelles.
Owner. Littralement propritaire . Matre douvrage stratgique,
donneur dordres.
Requirement. Besoin ou exigence (cet ouvrage fait explicitement le distinguo
entre ces deux termes).

235

Livre Constant.indb 235

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

Requirements engineering. Ingnierie des besoins ; ingnierie des exigences.


Software requirements. Exigences logicielles, exigences du logiciel.
SRS, Software requirements specification. Spcification du besoin, spcification
des exigences.
SRS document, Software requirements specification document. Cahier des
charges ; cahier des charges fonctionnel ; spcifications fonctionnelles
gnrales; spcification des exigences.

236

Livre Constant.indb 236

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Bibliographie
Alistair Cockburn, Rdiger des cas dutilisation efficaces, Eyrolles, 2001.
Yves Constantinidis, Le logiciel valeur ajoute, la perspective de lutilisateur,
Hermes Science, 2001.
Yves Constantinidis, Dfinition des besoins pour le logiciel, Hermes Science,
2006.
Tom Gilb, Competitive Engineering: Ahandbook for systems engineering, requirements engineering, and software engineering management using planguage,
Butterworth-Heinemann, 2005.
Ellen Gottesdiener, Requirements by collaboration, Addison-Wesley, 2002.
Ellen Gottesdiener, Software requirements memory Jogger, Goal/QPC, 2005.
International Institute of Business Analysts, Aguide to Business Analysis Body
of Knowledge (BABOK Guide), version 2.0, 2010.
Soren Lauesen, Software Requirements Styles and Techniques, Addison-Wesley, 2002.
Hugues Marchat, La gestion de projet par tapes, tude des besoins, Eyrolles, 2008.
Paul-Hubert des Mesnards, Russir lanalyse des besoins, Eyrolles, 2007.
Suzanne and James Robertson, Mastering the Requirements Process, AddisonWesley, 1999.
Karl Wiegers, Software requirements, Microsoft Press, 2003.
Karl Wiegers, More About Software requirements, Microsoft Press, 2006.

Livre Constant.indb 237

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Livre Constant.indb 238

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Index
A
accompagnement (services d~)
139
acteurs 12, 18, 43, 93
activits (diagramme d~) 113
affinits (diagramme des ~) 83
Afnor X50-151 (modle) 158
AHP (Analytical Hierarchical Process) 112
ambiguts 32, 83, 88
amlioration du processus dlaboration 26, 187
analyse 107
check-list d~ 126
comparative Voirtude
comparative
de documents 74
de lexistant 12, 180
de produits existants 86
des besoins 182
des exigences 16, 44, 45
des rgles mtier 107
des risques 63, 218
dimpact 199, 200
tape 103
tape d~ 54
parties prenantes 54
processus 104
analyste 9, 11, 18, 24, 27, 28, 54
activit 2
comptences 27
engagements de l~ 40
savoir-tre 30
savoir-faire 29

Livre Constant.indb 239

Analytical Hierarchical Process


(AHP) 112
animateur (qualits d~) 29
anticipation (technique de l~)
190
arbres de dcision 121
assistant
matrise douvrage Voiranalyste
assistant, matrise douvrage
Voiranalyste
atomic requirements Voirexigences lmentaires
attributs
de qualit 15
des exigences 200
automate dtats finis 120

B
besoins
alternatifs 89
concept 18
exceptionnels 89
ngatifs 90
B.O.R.D. (tableau de ~) 214
Box, George 178
brainstorming 29, 83
business requirement Voirexigence mtier

C
cadrage
document 58
tape 178

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

cahier
des charges 12, 19
modle 106, 155
utilit 21
des clauses techniques
particulires (CCTP) 164
capacit fonctionnelle 129
capitalisation (tape de ~) 185
caractristiques de qualit 127
carte de processus 113
cas dutilisation 15, 42, 93, 105,
126
avantages 96
contenu 94
diagramme 100
difficults et risques 99
laboration 96
modlisation 96
catgories dexigences 15, 105
CCB (Change Control Board) 198
CCTP (cahier des clauses
techniques particulires) 24, 164
cent points (mthode des ~) 110
Change Control Board (CCB) 198
changement
demandes de ~ 201
gestion des 197, 209
charges
enregistrement 63
et dlais, estimation 62
check-list
cahier des charges 165
danalyse 126
de bonne formulation 145
de contenu 169
de ltape de validation 175
de proprits 169
de slection doutils 205
de spcification dune exigence
152
dtape de spcification 153
tape de concept et objectifs 58
tape de recueil 91
plan projet 47, 64

rgle des 5 C 146


vrification par ~s 169
classes (diagramme de ~) 117
classification des exigences 42
Cockburn, Alistair 94, 95, 100, 101
cohrence 89
commission de contrle des changements 198
compatibilit (ergonomie) 134
concept
check-list 58
et objectifs 49
concision (dergonomie) 136
contexte (diagramme de ~) 14,
53, 58, 94, 97, 116, 126, 157, 179,
180, 183
contraintes 13, 15
de cot 137
de maintenance 140
denvironnement 138
de projet 137
de support 140
organisationnelles 42
rglementaires 42
techniques 16, 25, 49
contrle explicite (ergonomie)
136
cot
contraintes de ~ 137
de correction dune erreur 22
des exigences 25
des exigences (valuation) 124
crativit 25, 31, 73
CRUD (matrice) 124
cycle de vie du logiciel 35

D
dlais, enregistrement 63
demandes
concept 18
de changement 201
dveloppement des exigences
21, 44, 65

240

Livre Constant.indb 240

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Index

diagramme
dactivits 113
de cas dutilisation 100
de classes 117
de contexte 53, 58, 94, 97, 116,
126, 157, 179, 180, 183
de flux de donnes 114
de Kano 124
des affinits 83
de squence 116
entits-associations 117
tats-transitions 120
process map 113
UML 113
dictionnaire de donnes 107, 126
directeur
de mission 62
de projet 62
documentation
des besoins 69
des exigences 41
exigences de ~ 141
documents
analyse de ~ 74
de cadrage 58
navette (mthode du ~) 191
documents-types 61
domaine dapplication (dtermination) 52
donneur dordres 23, 54, 86

E
chelle de Likert 85
coute (qualit d~) 30, 80, 90
Eisenhower (principe d~) 110
lmentaires (exigences) 42
entits-associations (diagramme)
117
entonnoir
dmarche de recueil 80
mthode de slection 213
environnement
contraintes 138

de dveloppement (contraintes)
138
physique dutilisation 141
estimation
charges et dlais 62
tape
danalyse 54, 103, 182
danalyse de lexistant 180
de cadrage 178
de capitalisation 185
de planification 179
de recueil 67, 182
de spcification 143, 184
de validation 167, 184
planification 59
processus dexigences 43
tats-transitions (diagramme ~)
120
tude
comparative 60, 214
de choix 213
design 218
dintgrabilit 218
dopportunit 216
vnement mtier 94, 97
exigences 11, 19
comportementales 42
de haut niveau 42
de qualit 42, 106
dintgration 140
dinterface 106
dinterfaces externes 15
lmentaires 42, 97, 151
fonctionnelles 14, 15, 106
formulation 147
mtier 14, 16, 108
non fonctionnelles 15, 106, 127,
151
caractristiques de qualit 127
norme ISO25000 128
processus de dveloppement 44
spcifications rampantes 111
sur les donnes 15
sur les formats de donnes 106

241

Livre Constant.indb 241

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

expert
mtier 62
technique 63
expression crite (aptitude) 30

F
facilit dutilisation (utilisabilit)
130
faisabilit des exigences (valuation) 124
feedback 69, 88
fiabilit 129
finalit-avantage-mesure (objectifs) 51
flux de donnes (diagramme de
~) 114
fonction
satisfaction proportionnelle
125
attractive 125
obligatoire 125
fonctionnalit 129
formalisation des objectifs 51
formation (exigences de ~) 141
forme de description des exigences 150
formulation des exigences 143, 144

G
gains 23
gnralisations 81
gestion
de configuration 197
de projet 197
des attributs 208
des changements 197, 209
des erreurs (ergonomie) 136
des exigences 45, 63, 195, 197
des versions 209
Gottesdiener, Ellen 76, 191
grille pouvoir-impact 55
groupe de travail 75, 87
guidage (ergonomie) 135

H
homognit (ergonomie) 135

I
IEEE 830 (modle) 149, 156
IEEE 982 (cycle de vie du logiciel)
35
impact (analyse d~) 200
ingnierie
des besoins 27
des exigences 9, 11, 13, 14, 19,
35, 41, 44, 67
du logiciel 197
installation 137
intgrabilit (tude d~) 140
intgration (exigences d~) 140
interface
contraintes 139
exigences d~ 106
interview
droulement 77
distorsions 82
structure individuelle 76
types de questions 78
ISO 25000 (norme) 128, 152
itrations, processus dexigences
189

J
jurisprudence 17

K
Kano (diagramme de ~) 124

L
langue de bois 90, 146
lettre de mission 24, 58, 74, 178
Likert (chelle de ~) 85
liste des parties prenantes 54
logiciel 35
loi de Pareto 224

242

Livre Constant.indb 242

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Index

M
maintenabilit 132
maintenance
contraintes de ~ 140
phase de ~ 35
matre duvre 11, 36
matre douvrage 36
engagements du ~ 40
oprationnel 11
stratgique 12
matrise douvrage 54
maquette 29
matrice
CRUD 124
RACI 124
McCall (typologie de ~) 127
mthode des cent points 110
mthodologie 60
migration 138
mise en exploitation 137
modle
Afnor X50-151 158
de cahier des charges 155
de document 61
de processus dexigences 177
de Wiegers 160
IEEE 830 149, 156
Volere 132, 149, 162
modlisation 9, 44, 63
cas dutilisation 96
graphique 112
bote outils 122
maquette 122
prototype 122
techniques de ~ 28
MTBF, mean time between failures 130

norme ISO 25000 128, 152


norme ISO/CEI25000 128

O
objectifs 50, 105
stratgiques 42
observation directe 84
observation (qualit d~) 31
Ockham (rasoir d~) 119
omissions 81
oprateurs modaux 81
organigrammes 121
outils 60, 205
choix 210
fonctions de base et avances
206

P
Pareto (loi de ~) 224
parties prenantes 12, 43, 50
analyse 18, 54
concept de ~ 18
liste 54
tableau 57
primtre 50, 52
phase dexigences 38
plan de recueil 70
planguage (planning language)
151
planification 59
aptitude 29
tape 179
recueil des besoins 68
plan projet 59
check-list 47, 64
contenu 63
laboration 61
portabilit 132

ngociation des exigences 15, 29,


89, 110, 192
niveau dexigences 42

pouvoir-impact (grille ~) 55
principe dEisenhower 110
principe de simplicit 119

243

Livre Constant.indb 243

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Expression des besoins pour le systme dinformation

priorisation, projet 109


processus
carte de ~ 113
danalyse 104
dlaboration 185
de recueil 68
de spcification 143
de validation des exigences 168
dveloppement des exigences
45
dexigences
amlioration 187
processus dexigences 60
amlioration 189
description formelle 44
description pratique 45
tapes 43
itrations 189
modle 177
rcursions 188
rtroactions 188
profils utilisateurs 25
dtermination 71
exemple de typologie 72
identification des ~ 61
segmentation (ergonomie) 134
typologie 71
projet
dlaboration 59
mthodologie 60
priorits (dfinition des ~) 109
prototypage 123

Q
QFD (Quality Function Deployment) 112
qualit
contrle des exigences 174
Quality Function Deployment 112
quantificateurs universels 81
questionnaires (recueil par ~) 85
questionnement (recueil dobjectifs; grille de ~) 56

R
RACI (matrice) 124
rasoir dOckham 119
recette 137
recueil 44
bonnes pratiques 87
check list 91
de planification 68
des besoins 182
des exigences 45
des objectifs 51
entonnoir 80
tape 67
grille de questionnement 56
par observation directe 84
par questionnaires 85
plan de ~ 70
processus 68
risques 70
techniques 73
vrification 69
rcursions sur le processus dexigences 188
rgles
analyse 107
de gestion 13, 15, 105, 107
mtier 15, 16, 105, 108
traabilit 109
relationnelle (qualit ~) 31
relecture
croise (vrification par ~) 170
simple (vrification par ~) 170
rendement 131
ressources (identification des ~)
62
retour sur investissement 23
retravail 190
rtroactions, processus dexigences 188
rutilisation des exigences 86, 150
rework 188, 190
risques 24
analyse 63
Robertson, James 174

244

Livre Constant.indb 244

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Index

Robertson, Suzanne 174


Robertson, Suzanne et James 162

S
SAE (systme ltude) 14
savoir-faire 27
screening 213
segmentation des profils utilisateurs 134
squence (diagramme de ~) 116
services daccompagnement 139
short-list 213
simplicit (principe de ~) 119
solutions (suggestions de ~) 106
souplesse (ergonomie) 135
sources dexigences 61, 72, 74
sous-spcification 25
spcification
concept 18
des exigences 45, 184
tape 184
processus de ~ 143
rampante 24, 26, 123, 198
structuration des exigences 105,
144, 149
suggestions de solutions 106
support (contraintes de ~) 140
surspcification 25
SWOT (analyse) 214
systme 13

T
tableau
de B.O.R.D. 214
des parties prenantes 57
tables de dcision 121
techniques
de lanticipation 190
de recueil 73
de recueil des objectifs 52
de validation 168
template 61
traabilit des exigences 207
typologie de McCall 127

U
UML (Unified Modeling Language) 93, 100, 105, 113, 118
Unified Modeling Language
VoirUML
use cases Voircas dutilisation
utilisabilit 130
utilisateurs
besoins des ~ 15
participation des ~ 23
profils 25

V
validation
check-list 175
des exigences 44, 45, 184
tape 167, 184
processus de ~ 168
vrification
cas de test (laboration de ~)
173
contle qualit des exigences
174
croise 170
des exigences 144
inspection 171
par check-lists 169
par relecture
croise 170
simple 170
revue formelle 171
simple 170
versions (gestion des) 209
Volere (modle ~) 132, 149, 162

W
Wiegers, Karl 15, 105, 160
Wiegers (modle de ~) 160

Z
zone floue 39, 89, 213

245

Livre Constant.indb 245

user 189 at Fri Nov 19 12:40:28 +0100 2010

14/10/10 14:07

Lauteur
Consultant en systmes dinformation, Yves
Constantinidis a dirig avec succs llaboration de plusieurs cahiers des charges de porte
nationale (ministre de la Sant, ministre de
lducation nationale). Informaticien de formation, il intervient sur des missions de choix de solutions, de diagnostic du systme dinformation et
damlioration du processus de dveloppement.
Son expertise la amen publier trois ouvrages
sur lingnierie du systme dinformation et la
qualit du logiciel (ditions Herms), et intervenir comme formateur auprs dtablissements
denseignement suprieur (Epita, cole des hautes
tudes en sant publique).
Michel Volle est prsident dhonneur du Club des
Matres dOuvrage des Systmes dInformation.

omment recueillir tous les besoins des acteurs du systme dinformation, et rien que leurs besoins rels ? Comment se mettre
daccord sur la spcification des exigences ? Comment aboutir
un cahier des charges clair, complet et consensuel ? Phase cruciale
dans le choix, le dveloppement ou la mise en uvre dune solution
dentreprise, la dfinition des besoins conditionnera en effet la russite du projet, notamment son cot et sa qualit. Mais cette tape
est complexe et dlicate, en raison du nombre et de la diversit des
parties prenantes, des demandes souvent divergentes, des contraintes
varies et, last but not least, du facteur humain.
Vritable guide de terrain, nourri par la grande exprience de son auteur,
cet ouvrage prsente une dmarche et des techniques prouves pour
recueillir et formaliser les vrais besoins, afin dlaborer un cahier des
charges dune qualit irrprochable, dans des dlais raisonnables et au
moindre cot. partir dun exemple permettant de mieux saisir les
enjeux, la premire partie expose les prrequis, puis dcrit le processus
et les activits prparatoires indispensables : dfinition des objectifs et
du primtre, analyse des parties prenantes, planification de llaboration. La deuxime partie dtaille les quatre grandes tapes de cette
mthode (recueil, analyse, spcification et validation), avec la cl des
modles de documents, des grilles et des check-lists. Enfin, la troisime
partie porte sur les techniques et les outils de gestion des exigences, et
sachve par des conseils pour samliorer encore. Grce cet ouvrage
dune clart exceptionnelle, le lecteur sera ainsi prt relever les dfis
que pose toute mission de dfinition des besoins.

qui sadresse ce livre ?

Au sommaire

Aux assistants la matrise


douvrage (AMOA)

Mthodologie. La mthode en action. Les enjeux dune bonne


dfinition des besoins. Comptences et savoir-faire. Exigences
et cycle de vie du logiciel. La dmarche. Dfinir le concept et
les objectifs. Planifier le projet dlaboration. Dveloppement
des exigences. Ltape de recueil. Les cas dutilisation. Ltape
danalyse. Les exigences non fonctionnelles. Exigences projet
et contraintes techniques. Ltape de spcification. Structure
du cahier des charges. Ltape de validation. Amliorer le processus. Faire vivre les exigences. La gestion des exigences. Les
outils. Au-del des exigences. Neuf conseils.

Aux consultants en systmes


dinformation
Aux experts techniques et mtier
Aux architectes du systme
dinformation
tous ceux qui sont impliqus dans
llaboration dun cahier des charges

user 189 at Fri Nov 19 12:40:28 +0100 2010

pour le systme dinformation

dinformation

Expression des besoins

pour le systme

YVES
CONSTANTINIDIS

Expression des besoins

Y V E S C O N S T A N T I N I D I S
P r f a c e
d e
M i c h e l
V o l l e

Expression
des besoins

pour le systme

information

Guide dlaboration
du cahier des charges

Gratuit !

60 modles de livrables
prts lemploi
un outil de cration
de business plan