Expression Des Besoins Pour Le Système D'information

{\rtf1{\info{\title index}{\author Unknown}}\ansi\ansicpg1252\deff0\deflang1033
{\fonttbl{\f0\froman\fprq2\fcharset128 Times New Roman;}{\f1\froman\fprq2\

fcharset128 Times New Roman;}{\f2\fswiss\fprq2\fcharset128 Arial;}{\f3\fnil\fprq2\
fcharset128 Arial;}{\f4\fnil\fprq2\fcharset128 MS Mincho;}{\f5\fnil\fprq2\
fcharset128 Tahoma;}{\f6\fnil\fprq0\fcharset128 Tahoma;}}
{\stylesheet{\ql \li0\ri0\nowidctlpar\wrapdefault\faauto\rin0\lin0\itap0 \rtlch\
fcs1 \af25\afs24\alang1033 \ltrch\fcs0 \fs24\lang1033\langfe255\cgrid\langnp1033\
langfenp255 \snext0 Normal;}
{\s1\ql \li0\ri0\sb240\sa120\keepn\nowidctlpar\wrapdefault\faauto\outlinelevel0\
rin0\lin0\itap0 \rtlch\fcs1 \ab\af0\afs32\alang1033 \ltrch\fcs0 \b\fs32\lang1033\
langfe255\loch\f1\hich\af1\dbch\af26\cgrid\langnp1033\langfenp255 \sbasedon15 \
snext16 \slink21 heading 1;}
rin0\lin0\itap0 \rtlch\fcs1 \ab\ai\af0\afs28\alang1033 \ltrch\fcs0 \b\i\fs28\
lang1033\langfe255\loch\f1\hich\af1\dbch\af26\cgrid\langnp1033\langfenp255 \
sbasedon15 \snext16 \slink22 heading 2;}
rin0\lin0\itap0 \rtlch\fcs1 \ab\ai\af0\afs23\alang1033 \ltrch\fcs0\b\i\fs23\
lang1033\langfe255\loch\f1\hich\af1\dbch\af26\cgrid\langnp1033\langfenp255 \
sbasedon15 \snext16 \slink24 heading 4;}
snext16 \slink26 heading 6;}}
{
înformation Guide d'\u233?laboration du cahier des charges EYROLLES\par\pard\
plain\hyphpar} {
Pr\u233?Face D'apr\u232?s le Standish Group, les projets informatiques connaissent
un taux d'\u233?chec qui ne saurait \u234?tre tol\u233?r\u233? dans aucun autre
domaine de l'ing\u233?nierie : de ses enqu\u234?tes, on peut retenir qu'en gros 25
% des projets \u233?chouent. 50 % aboutissent avec un d\u233?lai et un co\u251?t
tr\u232?s sup\u233?rieurs \u224? la pr\u233?vision, 25 % seulement sont
convenablement r\u233?ussis. En cas d'\u233?chec, on entend souvent dire \u171?
c'est la faute de l'informatique \u187?. mais en fait, il convient de dire que, par
principe, c'est toujours la faute du m\u233?tier que le produit informatique devait
outiller (ma\u238?trise d'ouvrage. MOA). Certes, il arrive que le r\u233?alisateur
du produit (ma\u238?trise d'oeuvre. MOE) soit d\u233?faillant, mais alors la MOA
aurait d\u251? prendre en temps utile des mesures pour redresser la situation.
Souvent d'ailleurs, le seul tort de la MOE sera d'avoir accept\u233? un contrat
impossible, car l'ing\u233?nierie des besoins a \u233?t\u233? d\u233?faillante et
le projet \u233?tait donc condamn\u233? d\u232?s le d\u233?part : la MOA s'est
lanc\u233?e dans le projet sans savoir ce qu'elle voulait faire, sans avoir exprim\
u233? ses priorit\u233?s ni lev\u233? les ambigu\u239?t\u233?s du vocabulaire, puis
par la suite elle a \u233?t\u233? versatile, etc. Une expression de besoin bien
faite garantit le succ\u232?s ou du moins (car on ne peut jamais se pr\u233?munir
contre toutes les surprises) une probabilit\u233? de succ\u232?s de l'ordre de 90 %
: on mesure l'enjeu si l'on compare ce taux aux donn\u233?es du Standish Group.
lean-Pierre Meinadier est l'un des ma\u238?tres fran\u231?ais les plus respect\
u233?s en ing\u233?nierie des syst\u232?mes industriels1. Invit\u233? \u224?
participer \u224? un projet de syst\u232?me d'information (SI), il fut imm\u233?
diatement cong\u233?di\u233? pour avoir pos\u233? une question jug\u233?e incongrue
: \u171? qui est responsable ? \u187?. Il a alors compris que contrairement \u224?
un projet d'automobile ou d'avion, dont les enjeux techniques sont mesurables et <
froids \u187?. un SI est \u171? chaud \u187? : chaque projet comporte implicitement
de tels enjeux \u171? politiques \u187? de l\u233?gitimit\u233?, de d\u233?coupage
des pouvoirs et de responsabilit\u233?, que l'entreprise pr\u233?f\u232?re souvent
laisser implicites les donn\u233?es n\u233?cessaires \u224? son succ\u232?s. C'est
cette \u171? chaleur \u187? du SI qui explique le taux d'\u233?chec extravagant des
projets. Les acteurs ne manquent ni de bon sens ni d'intelligence, mais ils les
mettent au service de priorit\u233?s qui ne sont pas celles de l'efficacit\u233? de
la production de l'entreprise ni de la qualit\u233? de ses produits - objectifs
qui, en revanche, sont pr\u233?cis\u233?ment ceux que sert un SI. 1. Jean-Pierre
Meinadier, Ing\u233?nierie et int\u233?gration des syst\u232?mes, Herm\u232?s,
1998.\par\pard\plain\hyphpar} {
ion des besoins pour le syst\u232?me d'information L'enjeu de l'ing\u233?nierie des
besoins n'est donc pas purement technique : il s'agit de promouvoir des priorit\
u233?s (efficacit\u233?, qualit\u233?) qui sans doute devraient \u234?tre celles de
toute entreprise, mais \u224? qui s'opposent d'autres formulations de sa mission
(produire < de l'argent \u187? ou \u171? de la valeur pour l'actionnaire \u187?)
ainsi que les int\u233?r\u234?ts des corporations professionnelles. Pour pouvoir
agir dans les sables mouvants de la sociologie et de l'id\u233?ologie, il faut des
id\u233?es claires et des principes fermes : c'est ce que nous propose ici Yves
Constantinidis. On peut en effet d\u233?samorcer les pi\u232?ges de la \u171?
politique \u187? si l'on sait s'y prendre \u224? temps, dans l'\u233?tape pr\u233?
liminaire et relativement < froide \u187? de l'expression de besoins, si l'on se
donne la peine d'\u233?liminer les d\u233?fauts du vocabulaire et les malentendus
qu'ils provoquent, si l'on s'est enquis de la pertinence des besoins et priorit\
u233?s, si l'on a obtenu les validations qui. \u233?tant authentiques, scellent
l'accord ult\u233?rieur des dirigeants et leur soutien au projet. Le pivot de cette
affaire, c'est la personne morale que Constantinidis nomme \u171? assistance \u224?
ma\u238?trise d'ouvrage \u187? et que je pr\u233?f\u232?re nommer < ma\u238?trise
d'ouvrage d\u233?l\u233?gu\u233?e \u187? (MOAD), car elle a re\u231?u du directeur,
strat\u232?ge et responsable supr\u234?me de la MOA qu'il engage par sa signature,
d\u233?l\u233?gation du soin de l'expertise en SI. La MOAD a trois interlocuteurs :
les strat\u232?ges (celui du m\u233?tier et le DG. strat\u232?ge de l'entreprise),
les utilisateurs (qui se subdivisent en plusieurs cat\u233?gories) et
l'informatique (c'est-\u224?-dire la MOE qui peut \u234?tre, selon les cas. soit la
DSI de l'entreprise, soit un fournisseur). Elle doit savoir parler les langages de
ces divers interlocuteurs et assurer entre eux la fonction d'interpr\u232?te. La
MOAD est donc une vraie sp\u233?cialit\u233?, et celui qui a exerc\u233? cette
fonction pendant quelques ann\u233?es acquiert une connaissance approfondie de
l'entreprise et du m\u233?tier pour lesquels il travaille, y compris dans leurs
dimensions < politiques \u187? et symboliques qu'il sait g\u233?rer avec souplesse
et discr\u233?tion. Malheureusement, les entreprises n'ont pas encore toutes
compris la n\u233?cessit\u233? de cette fonction, ni per\u231?u les comp\u233?
tences qu'elle exige : sa d\u233?nomination change d'une entreprise \u224? l'autre,
et cela montre bien la perplexit\u233? des DRH. L'outil fondamental de la MOAD est
un mod\u232?le, une mise en forme qui concr\u233?tise l'expression de besoin en
sch\u233?matisant le m\u233?tier tel qu'il fonctionnera une fois outill\u233? par
le SI. Tout comme une base de donn\u233?es, ce mod\u232?le est un \u234?tre que
personne ne peut voir en entier, mais qui pr\u233?sente \u224? chaque cat\u233?
gorie d'acteurs la vue qui lui convient : \u224? l'informaticien, le diagramme de
classe, \u233?tape initiale de la programmation dans un langage \u224? objets (et
quelques autres diagrammes) : au strat\u232?ge, le diagramme d'activit\u233? qui d\
u233?crit le processus. Pour les utilisateurs, la vue pourra \u234?tre
audiovisuelle : en pla\u231?ant sur l'intranet un dessin anim\u233? compl\u233?t\
u233? par une documentation et un outil d'autoformation, on aide chacun \u224?
percevoir la finalit\u233? du syst\u232?me et l'\u233?tendue de sa responsabilit\
u233? personnelle,\par\pard\plain\hyphpar} {
Pr\u233? Face on \u233?lucide le processus de production dans lequel il intervient.
Le cahier des charges est, sur ce mod\u232?le, la vue qui pr\u233?cise et r\u233?
capitule toutes les exigences auxquelles le produit doit satisfaire, qu'elles
soient propres au m\u233?tier ou \u224? la plate-forme technique de l'informatique.
Ce document peut prendre une forme contractuelle, mais mieux vaut le concevoir
comme une \u233?tape n\u233?cessaire de la coop\u233?ration entre la MOE et la
MOAD. Pour prendre une m\u233?taphore dans la vie courante, supposons que vous
fassiez construire une maison. Vous avez \u233?tabli son plan avec l'aide d'un
architecte et dites : \u171? dans cette pi\u232?ce, il faudra quatre prises de
courant et une applique command\u233?e par un interrupteur \u187?. Ce sont l\u224?
des sp\u233?cifications g\u233?n\u233?rales, produites par la MOAD avec le conseil
de la MOE et valid\u233?es par le strat\u232?ge. Puis la MOE demande \u224? la MOA
de dire o\u249? installer les prises, les interrupteurs et l'applique. Marquer ces
emplacements sur le plan, c'est \u233?tablir les sp\u233?cifications d\u233?taill\
u233?es, produites par la MOE et valid\u233?es par la MOAD. Enfin, la MOE fera le
plan de c\u226?blage qui pr\u233?cise le parcours des goulottes et saign\u233?es :
ce sont des sp\u233?cifications techniques qui n'int\u233?ressent pas la MOA. mais
qui sont indispensables pour passer \u224? la r\u233?alisation. Il importe de
respecter cette progression : comme le dit Donald Knuth. \u171? l'optimisation pr\
u233?matur\u233?e est la racine de tous les maux \u187? et certains projets
s'enlisent parce que l'on se pr\u233?occupe, d\u232?s une phase initiale, de choix
techniques qui devraient intervenir plus tard. Il faut, nous l'avons dit, que les
validations soient authentiques : chacun des responsables doit pouvoir comprendre
les documents qu'on lui soumet, et se savoir engag\u233? par sa signature. Il ne
convient pas, par exemple, de soumettre le diagramme de classe \u224? un strat\
u232?ge, car cette vue sur le mod\u232?le n'est pas faite pour lui : comme il ne la
comprendra pas, sa signature sera passive et il n'h\u233?sitera pas par la suite \
u224? remettre le mod\u232?le en question alors que les travaux sont d\u233?j\u224?
engag\u233?s. La MOAD doit donc lui pr\u233?senter \u224? l'appui du diagramme
d'activit\u233? une synth\u232?se en fran\u231?ais, claire et en quelques pages,
qui indique ce qu'il s'agit de faire, comment on envisage de le faire et pourquoi
il ne convient pas de le faire autrement. Il sera \u233?galement utile de lui pr\
u233?senter le processus sous la forme d'un dessin anim\u233?, m\u234?me si
certains strat\u232?ges prennent cela comme une atteinte \u224? leur \u171? s\u233?
rieux \u187?. Entre le strat\u232?ge et la MOAD, le rapport est celui qui existe
entre le d\u233?cideur et l'expert. La d\u233?cision revient au strat\u232?ge qui,
ayant la vue d'ensemble, peut tenir compte de contraintes et d'opportunit\u233?s
que l'expert ignore ; mais le strat\u232?ge doit \u233?couter l'expert qui, mieux
que lui. se tient au courant de l'\u233?tat de l'art des SI. Il ne suffit pas de r\
u233?ussir des projets : il faut encore que l'informatique soit bien utilis\u233?e.
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. QD\par\pard\plain\hyphpar} {
ion des besoins pour le syst\u232?me d'information la MOAD doit \u234?tre un client
comp\u233?tent qui sait ce qu'il veut et qui conna\u238?t assez l'informatique pour
en comprendre les contraintes, mais qui se garde d'imposer des choix techniques.
Enfin, et m\u234?me si le cahier des charges pr\u233?cise les obligations de
chacun, la relation entre la MOAD et la MOE doit \u234?tre plus partenariale que
contractuelle. Il convient qu'elles travaillent en tandem d\u232?s le d\u233?but du
projet, la responsabilit\u233? du travail passant de l'une \u224? l'autre selon l'\
u233?tape consid\u233?r\u233?e. Certains SI sont \u233?tonnamment bien r\u233?
ussis. Lorsqu'on interroge les utilisateurs, ils disent < on sait ce qu'on a \u224?
faire \u187?, < le travail est clair \u187?, \u171? l'entreprise est bien dirig\
u233?e \u187?, \u171? on est bien outill\u233?s \u187?. etc. Et si l'on s'en-
quiert de la cause de cette r\u233?ussite, on re\u231?oit toujours la m\u234?me r\
u233?ponse : \u171? le DG (ou le directeur) s'est impliqu\u233? personnellement, il
a mis le poids de son autorit\u233? dans la balance, il a r\u233?gl\u233? les
probl\u232?mes politiques \u187?. Un SI n'est pas en effet seulement une affaire
d'informatique : sa conception inclut la d\u233?finition du travail humain,
l'organisation du processus de production et de son contr\u244?le. C'est pourquoi
il faut consid\u233?rer que la responsabilit\u233? globale du SI appartient \u224?
la MOA. personne morale, et nomm\u233?ment \u224? son directeur, personne physique
qui engage la MOA par sa signature. Nos entreprises auront fait un grand pas
lorsqu'elles sauront qu'un directeur ou un DG qui dit \u171? c'est la faute de
l'informatique \u187? r\u233?v\u232?le une incomp\u233?tence... Michel Volle, pr\
u233?sident d'honneur du Club des Ma\u238?tres d'Ouvrage des Syst\u232?mes
d'Information CI\u207?\u207?\u207?\par\pard\plain\hyphpar} {
Remerciements le tiens \u224? remercier les confr\u232?res qui m'ont apport\u233?
leurs remarques et leurs id\u233?es, en particulier Dominique Le p\u232?re,
Benjamin Lemoine, losselin Coupard et Jean-Fran\u231?ois Goglin. Merci \u224? tous
mes clients, ma\u238?tres d'\u339?uvre, ma\u238?tres d'ouvrage et utilisateurs qui,
en se pr\u234?tant \u224? des interviews ou en participant \u224? des groupes de
travail, m'ont permis d'am\u233?liorer ma d\u233?marche. Merci \u224? Suzanne
Robertson et Karl Wiegers. qui m'ont encourag\u233? lors de l'\u233?criture de cet
ouvrage. Merci \u224? Michel Voile, qui en a \u233?crit la pr\u233?face. Merci \
u224? Nicolas, M\u233?lina et Karin pour leurs id\u233?es fra\u238?ches et leur
soutien moral.\par\pard\plain\hyphpar} {
(fable des mati\u232?res) Guide de lecture 1 Quiz : \u234?tes-vous pr\u234?t ? 5 R\
u233?ponses au quiz 7 Partie 1 - M\u233?thodologie Chapitre 1 - La m\u233?thode en
action 11 Un exemple imaginaire, mais concret Il Le point sur les concepts 18
Chapitre 2 - Les enjeux d'une bonne d\u233?finition des besoins 21 L'utilit\u233?
d'un cahier des charges 21 Un investissement tr\u232?s rentable 21 Les gains \u171?
cach\u233?s \u187? 23 Les difficult\u233?s 23 Les risques 24 Am\u233?liorer les
pratiques d'\u233?laboration 26 Chapitre 3 - Comp\u233?tences et savoir-faire 27 Le
savoir 27 Le savoir-faire 29 Le savoir-\u234?tre 30 Chapitre 4 - Exigences et cycle
de vie du logiciel 35 Le cycle de vie du logiciel 35 Ma\u238?tres d'ouvrage et ma\
u238?tres d'ceuvre 36 B\u226?tisseurs et exploitants 38 La phase d'exigences 38 Les
engagements r\u233?ciproques 39 O\par\pard\plain\hyphpar} {
Expression des besoins pour le syst\u232?me d'information Chapitre 5 - La d\u233?
marche 41 D\u233?crire, documenter, communiquer 41 Les diff\u233?rents niveaux
d'exigences 42 Les \u233?tapes de l'\u233?laboration 43 Description formelle du
processus global 44 Le processus en pratique 45 Check-list 47 Chapitre 6 - D\u233?
finir le concept et les objectifs 49 Une activit\u233? pr\u233?alable indispensable
49 Objectifs, p\u233?rim\u232?tre et parties prenantes 50 Recueillir les objectifs
51 D\u233?terminer le p\u233?rim\u232?tre 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 d'\u233?laboration 59 Le plan
projet 59 Cadrer la m\u233?thodologie 60 \u201?laborer le plan projet 61 Check-list
64 Partie 2 - D\u233?veloppement des exigences Chapitre 8 - L'\u233?tape de recueil
67 L'enjeu 67 Le processus de recueil 68 Le plan de recueil 70 Risques li\u233?s au
recueil et att\u233?nuation 70 D\u233?termination des profils utilisateurs 71
Recherche des sources d'exigences 72 Techniques de recueil 73 L'analyse de
documents 74 La r\u233?union d'un groupe de travail 75\par\pard\plain\hyphpar} {
Table des mati\u232?res L'interview structur\u233?e individuelle 76 Le
brainstorming 83 Le diagramme des affinit\u233?s 83 L'observation directe 84 Les
questionnaires 85 La r\u233?utilisation d'exigences 86 L'analyse de produits
existants 86 Rechercher l'information l\u224? o\u249? elle se trouve 86 Les bonnes
pratiques 87 Check-list de fin d'\u233?tape de recueil 91 Chapitre 9 - Les cas
d'utilisation 93 Qu'est-ce qu'un cas d'utilisation ? 93 Le contenu d'un cas
d'utilisation 94 Avantages des cas d'utilisation 96 \u201?laboration des cas
d'utilisation 96 Un exemple 98 Difficult\u233?s et risques des cas d'utilisation 99
Les diagrammes de cas d'utilisation 100 Chapitre 10 - L'\u233?tape d'analyse 103
Utilit\u233? de l'\u233?tape d'analyse 103 Le processus d'analyse 104 Structurer et
organiser les exigences 105 \u201?tablir un dictionnaire de donn\u233?es 107
Analyser les r\u232?gles m\u233?tier 107 D\u233?finir les priorit\u233?s d'un
projet 109 Mod\u233?liser sous forme graphique 112 Maquettes et prototypes 122
Matrices CRUD et RACI 124 \u201?valuer la faisabilit\u233? et le co\u251?t 124
Check-list d'analyse 126 Chapitre 11 - Les exigences non fonctionnelles 127 Les
caract\u233?ristiques de qualit\u233? 127 La norme ISO/CEI 25000 128 Zoom sur
l'utilisabilit\u233? 133 CTTI\par\pard\plain\hyphpar} {
Expression des besoins pour le syst\u232?me d'information Chapitre 12 - Exigences
projet et contraintes techniques 137 Contraintes de projet 137 Contraintes
d'environnement 138 Services d'accompagnement 139 Chapitre 13 - L'\u233?tape de sp\
u233?cification 143 Le processus de sp\u233?cification 143 La formulation 144 La
structuration 149 Cas des exigences non fonctionnelles 151 Check-list de sp\u233?
cification d'une exigence 152 Check-list d'\u233?tape de sp\u233?cification 153
Chapitre 14 - Structure du cahier des charges 155 Le mod\u232?le de cahier des
charges 155 Le mod\u232?le IEEE 830 156 Le mod\u232?le AFNOR X50-151 158 Le mod\
u232?le de Wiegers 160 Le mod\u232?le Volere (Robertson & Robertson) 162 Construire
son propre mod\u232?le 164 Check-list : cahier des charges 165 Chapitre 15 - L'\
u233?tape de validation 167 Int\u233?r\u234?t de la validation 167 Le processus de
validation 168 Les techniques 168 V\u233?rification par check-lists 169 Relecture
simple 170 Relecture crois\u233?e 170 Revue formelle et inspection 171 \u201?
laboration de cas de test 173 Contr\u244?le qualit\u233? des exigences 174
Impliquer les personnes concern\u233?es 174 Check-list : validation 175 Chapitre 16
- Un mod\u232?le de processus 177 Un processus-type 177 \u201?tape 1 : cadrer 178\
par\pard\plain\hyphpar} {
Table des mati\u232?res \u201?tape 2 : planifier 179 \u201?tape 3 : analyser
l'existant 180 \u201?tape 4 : recueillir et analyser les besoins 182 \u201?tape 5 :
sp\u233?cifier les exigences 184 \u201?tape 6 : valider les exigences 184 \u201?
tape 7 : capitaliser 185 Chapitre 17 - Am\u233?liorer le processus 187 Pourquoi le
processus peut \u234?tre am\u233?lior\u233? ? 187 Comment le processus peut \u234?
tre am\u233?lior\u233? 189 La m\u233?thode du document navette 191 Partie 3 - Faire
vivre les exigences Chapitre 18 - La gestion des exigences 197 La gestion des
changements 197 Une discipline n\u233?cessaire et rentable 203 Chapitre 19 - Les
outils 205 Check-list : votre projet en a-t-il besoin ? 205 Les bonnes raisons
d'utiliser les outils 206 Fonctions de base et fonctions avanc\u233?es 206
Attention aux mirages 210 Quand et comment choisir un outil ? 210 Chapitre 20 - Au-
del\u224? des exigences 213 \u201?tude de choix 213 \u201?tude comparative complexe
214 \u201?tude d'opportunit\u233? complexe 216 \u201?tude d'int\u233?grabilit\u233?
et design 218 Chapitre 21 - Neuf conseils 221 1. Ayez toujours l'objectif en t\
u234?te 221 2. Analysez et validez au plus t\u244?t 222 3. Lancez-vous un d\u233?fi
et donnez-vous les moyens de le r\u233?ussir 222 4. Conciliez concepts et action de
terrain 223 5. Concentrez-vous sur votre livrable 223 6. Sachez r\u233?ussir
presque \u224? coup s\u251?r 224 7. Mettez en avant votre client 224\par\pard\
plain\hyphpar} {
Expression des besoins pour le syst\u232?me d'information 8. Perdez un peu de temps
pour en gagner beaucoup 225 9. Faites de la d\u233?finition des besoins un projet
en soi 225 Annexe - Les questions \u224? large spectre 227 Comment utiliser ces
questions ? 227 Liste de questions 227 Glossaire fran\u231?ais 231 Glossaire
bilingue 235 Bibliographie 237 Index 239 GD\par\pard\plain\hyphpar} {
Guide de lecture ) Cet ouvrage pr\u233?sente une d\u233?marche structur\u233?e
d'ing\u233?nierie des exigences pour les syst\u232?mes d'information, en suivant
une logique qui va des concepts g\u233?n\u233?raux jusqu'aux conseils pratiques. Il
a l'ambition de guider le lecteur depuis les objectifs strat\u233?giques jusqu'\
u224? la validation finale du cahier des charges, et au-del\u224?. Il gagne donc \
u224? \u234?tre lu d'un bout \u224? l'autre, dans l'ordre des chapitres. Parall\
u232?lement, cet ouvrage a pour vocation de servir de guide de terrain que tout
consultant ou analyste, quelle que soit son exp\u233?rience, peut utiliser dans sa
pratique quotidienne. Il doit donc \u234?tre consultable de mani\u232?re non lin\
u233?aire. La carte heuristique de la figure I page 3 tente de concilier ces deux
approches, en permettant au lecteur de naviguer plus facilement entre les \u233?
tapes et les techniques. La premi\u232?re partie de ce livre d\u233?crit le m\u233?
tier, la d\u233?marche et les \u233?tapes pr\u233?paratoires \u224? la d\u233?
finition des besoins, n\u233?cessaires pour mener \u224? bien une mission d'\u233?
laboration d'un cahier des charges. Le premier chapitre donne un exemple concret
(bien que fictif) qui permet de mettre en situation tout lecteur, qu'il soit d\
u233?butant ou exp\u233?riment\u233?. Il introduit les notions de base et le
vocabulaire, qui n'est pas encore bien stabilis\u233? dans notre m\u233?tier. Le
chapitre 2 est le seul \u224? s'occuper du pourquoi. Il pr\u233?sente les enjeux,
les co\u251?ts, les gains et les risques. Le chapitre 3 \u233?num\u232?re et d\
u233?taille les comp\u233?tences n\u233?cessaires \u224? l'\u233?laboration d'un
bon cahier des charges. Il faut la voir comme une check-list qui sert \u224? s'am\
u233?liorer, voire \u224? recruter un consultant. Le chapitre 4 situe l'ing\u233?
nierie des exigences dans le cycle de vie du logiciel ; il permet de mieux
comprendre les enjeux et met en lumi\u232?re les rapports de force entre les diff\
u233?rents acteurs. On pr\u233?sente au chapitre 5 la d\u233?marche de d\u233?
veloppement des exigences, qui part de l'objectif et va jusqu'au cahier des
charges. Cette d\u233?marche est g\u233?n\u233?rique : elle concerne la quasi-
totalit\u233? des activit\u233?s d'\u233?laboration O\par\pard\plain\hyphpar} {
ion des besoins pour le syst\u232?me d'information d'un cahier des charges. L'enjeu
est de l'adapter \u224? son organisation pour ensuite pouvoir l'optimiser. Le
chapitre 6 d\u233?taille l'\u233?tape pr\u233?alable de d\u233?finition des
objectifs et du concept, cruciale et souvent n\u233?glig\u233?e, dont d\u233?pend
grandement la r\u233?ussite d'un projet. D\u233?finir les besoins pour un logiciel
est un projet \u224? part enti\u232?re. Le chapitre 7 parle de gestion de projet,
sp\u233?cifiquement pour la phase d'exigences. La deuxi\u232?me partie de cet
ouvrage d\u233?crit les quatre activit\u233?s de d\u233?veloppement des exigences :
recueil (chapitre 8), analyse (chapitre 10), sp\u233?cification (chapitre 13) et
validation (chapitre 15). Des chapitres interm\u233?diaires permettent de faire un
zoom sur des techniques tr\u232?s utiles, comme les cas d'utilisation (chapitre 9).
Le chapitre 11 est enti\u232?rement consacr\u233? aux exigences non fonctionnelles,
beaucoup trop souvent n\u233?glig\u233?es. Le chapitre 14 donne la description de
plusieurs mod\u232?les de sp\u233?cification d'exigences (cahier des charges)
qu'une organisation pourra reprendre en y apportant les adaptations n\u233?
cessaires. Le lecteur aura alors pris connaissance de la d\u233?marche g\u233?n\
u233?rale et des diff\u233?rentes techniques qui permettent d'aller du recueil des
besoins jusqu'au cahier des charges. Pour \u234?tre efficace, il devra articuler
ces techniques entre elles, c'est-\u224?-dire s'appuyer sur un processus formalis\
u233?. Le chapitre 16 donne un exemple de processus, que tout consultant ou
assistant \u224? la ma\u238?trise d'ouvrage devra adapter \u224? son contexte de
travail. Ce processus peut toujours \u234?tre am\u233?lior\u233?. Le chapitre 17
offre quelques pistes. Une fois sp\u233?cifi\u233?s, les besoins ne sont pas grav\
u233?s dans le marbre. En r\u233?alit\u233?, ils ne vont cesser d'\u233?voluer. La
gestion des exigences, activit\u233? transversale qui consiste \u224? g\u233?rer
les demandes de modification, pendant et apr\u232?s l'\u233?laboration du cahier
des charges, fait l'objet du chapitre 18. Les outils de gestion des exigences
progressent et changent rapidement. C'est pourquoi nous n'allons pas lister les
outils pr\u233?sents sur le march\u233?, mais exposer l'utilit\u233? qu'ils peuvent
avoir au cours d'un projet et les crit\u232?res pour les choisir (chapitre 19).
L'activit\u233? de l'analyste ou de l'assistant \u224? la ma\u238?trise d'ouvrage
ne s'arr\u234?te pas \u224? l'\u233?laboration du cahier des charges. L'\u233?tude
de l'opportunit\u233?, de la faisabilit\u233? ou de l'int\u233?grabilit\u233? d'une
solution dans le syst\u232?me d'information fait partie de son m\u233?tier. Les
diff\u233?rentes techniques de choix, de s\u233?lection d'un progiciel et de l'\
u233?tude de son int\u233?gration dans le syst\u232?me d'information sont trait\
u233?es au chapitre 20. Enfin, nous donnons au chapitre 21 neuf conseils pratiques
qui proviennent de l'exp\u233?rience de l'auteur.\par\pard\plain\hyphpar} {
Guide de lecture V Industrialiser ces chapitres permettent de comprendre \u187? et
d'am\u233?liorer la d\u233?marche - I Professlonnallser Ces chapitres d\u233?
crivent les aspects humains et organisationnels Ma\u238?triser Ces chapitres d\
u233?crivent la d\u233?marche de d\u233?veloppement des exigences Ch. 21 : neuf
conseils Figure 1 : La carte de lecture de ce livre\par\pard\plain\hyphpar} {
r Quiz : \u234?tes-vous pr\u234?t ? Ce test vous permettra de vous situer dans le
m\u233?tier du business analysis. quel que soit votre titre (consultant, analyste.
AMOA. expert m\u233?tier...). Pour chaque question, donnez la r\u233?ponse qui vous
para\u238?t la plus juste. Nous vous sugg\u233?rons de r\u233?pondre aux questions
une premi\u232?re fois avant de lire ce livre, et de noter vos r\u233?ponses. Puis
une deuxi\u232?me fois apr\u232?s l'avoir lu, de noter les r\u233?ponses et de
comparer les r\u233?sultats. 1. Dans la constitution d'un cahier des charges, les
difficult\u233?s proviennent surtout : A. De la complexit\u233? technique. B. Des
aspects humains. C. De la gestion des changements des exigences. 2. Pour \u233?
laborer un cahier des charges, les qualit\u233?s requises sont : A. Une bonne
connaissance du domaine d'application. B. Des bases solides en informatique. C. La
connaissance des techniques d'ing\u233?nierie des exigences. 3. Lorsque vous
devez \u233?laborer un cahier des charges, le mieux est : A. D'utiliser tel quel un
mod\u232?le de cahier des charges pr\u233?d\u233?fini. B. D'adapter le mod\u232?le
de cahier des charges \u224? votre cas. C. De cr\u233?er un mod\u232?le sp\u233?
cifique de cahier des charges. 4. L'essence d'un cahier des charges est : A. Un
texte clair en fran\u231?ais. B. Des sch\u233?mas rigoureux et lisibles. C. Une
structuration syst\u233?matique et m\u233?thodique du document.\par\pard\plain\
hyphpar} {
Expression des besoins pour le syst\u232?me d'information 5. On vous demande d'\
u233?laborer un cahier des charges. Votre premi\u232?re t\u226?che consiste \
u224? : A. Faire pr\u233?ciser les objectifs. B. Analyser le contexte. C. Conna\
u238?tre les parties prenantes. 6. Dans le travail d'\u233?laboration d'un cahier
des charges, les deux qualit\u233?s indispensables sont : A. L'empathie et l'\u233?
coute. B. La rigueur et l'organisation. C. La cr\u233?ativit\u233? et
l'imagination. 7. Dans le recueil des besoins, tout est dans : A. La pr\u233?
paration. B. L'\u233?coute active. C. Le feedback donn\u233? aux int\u233?ress\
u233?s. 8. Dans l'analyse des exigences, il faut constamment surveiller : A. La
coh\u233?rence entre exigences. B. La tra\u231?abilit\u233? des exigences. C. La
priorit\u233? entre exigences. 9. S'il ne fallait utiliser qu'un seul type de
diagramme, ce serait : A. Le diagramme de classes (ou entit\u233?-association). B.
Le diagramme d'\u233?tats. C. Le diagramme de flux. 10. Les exigences qui demandent
le plus d'attention sont : A. Les exigences fonctionnelles. B. Les exigences non
fonctionnelles. C. Les contraintes. O\par\pard\plain\hyphpar} {
R\u233?ponses au quiz) Voici les r\u233?ponses au quiz pr\u233?c\u233?dent. 1. Dans
la constitution d'un cahier des charges, les difficult\u233?s proviennent
surtout... Si vos connaissances techniques sont faibles, il se peut que A soit la
bonne r\u233?ponse. Mais dans la majorit\u233? des cas. les probl\u232?mes humains
(r\u233?ponse B) sont les plus d\u233?licats \u224? traiter, du moins dans un
premier temps. \u192? long terme, lorsqu'il s'agit de maintenir le cahier des
charges ou de faire \u233?voluer les exigences, le suivi des modifications des
exigences pose de r\u233?elles difficult\u233?s. 2. Pour \u233?laborer un cahier
des charges, les qualit\u233?s requises sont... Une bonne connaissance du domaine
d'application (r\u233?ponse A) est indispensable, et des bases solides en
informatique (r\u233?ponse B) sont fort utiles. La connaissance des techniques
d'ing\u233?nierie des exigences est aussi importante que les deux autres qualit\
u233?s, mais est tr\u232?s souvent n\u233?glig\u233?e. 3. Lorsque vous devez \u233?
laborer un cahier des charges, le mieux est... Si un mod\u232?le de cahier des
charges pr\u233?d\u233?fini est bien adapt\u233? au contexte et aux objectifs, il
n'y a pas de raison de s'en priver. Sinon, il faudra adapter le mod\u232?le de
cahier des charges \u224? votre cas (r\u233?ponse B). en essayant de garder un
maximum de coh\u233?rence. Il est rare de devoir cr\u233?er un mod\u232?le sp\u233?
cifique de cahier des charges. M\u234?me dans ce dernier cas. on combinera des mod\
u232?les existants. Cela va sans dire, il vaut mieux investir du temps \u224?
adapter un mod\u232?le existant qu'\u224? \u171? r\u233?inventer la poudre \u187?.
4. L'essence d'un cahier des charges est... Tout d\u233?pend du domaine
d'application, de la r\u233?ponse recherch\u233?e (choix de progiciel ou d\u233?
veloppement sp\u233?cifique). Mais on oublie trop souvent que la langue naturelle
est une merveilleuse invention et un outil de sp\u233?cification universel. O\par\
pard\plain\hyphpar} {
ion des besoins pour le syst\u232?me d'information 5. On vous demande d'\u233?
laborer un cahier des charges. Votre premi\u232?re t\u226?che consiste \u224?...
Sans objectif, vous n'irez pas loin. La r\u233?ponse A est donc a priori la
correcte. Mais qui va vous donner l'objectif ? Celui qui finance, celui qui d\u233?
cide ou celui qui r\u233?ceptionne le produit ? Et comment allez-vous interpr\u233?
ter cet objectif en termes op\u233?rationnels ? D'o\u249? la n\u233?cessit\u233?
d'analyser des parties prenantes et le contexte. Les trois t\u226?ches sont donc
imbriqu\u233?es. 6. Dans le travail d'\u233?laboration d'un cahier des charges, les
deux qualit\u233?s indispensables sont... ... les v\u244?tres ! L\u224? aussi, il
n'y a pas de meilleure r\u233?ponse. Si chez vous certaines qualit\u233?s sont
nettement pr\u233?dominantes, utilisez-les. bien s\u251?r, et essayez aussi de
cultiver les autres. 7. Dans le recueil des besoins, tout est dans... Les trois r\
u233?ponses sont les bonnes, bien s\u251?r. La pr\u233?paration m\u233?thodique et
syst\u233?matique tient une place importante dans cet ouvrage. Elle vous fera
gagner \u233?norm\u233?ment de temps et vous \u233?vitera de disperser votre \u233?
nergie et celle des participants. L'\u233?coute est un don du ciel, le meilleur
outil de l'analyste, qu'il faut toujours cultiver. Le feedback donn\u233? aux int\
u233?ress\u233?s est une bonne pratique qui contribue \u224? l'efficacit\u233? et \
u224? la fiabilit\u233? de l'activit\u233? de recueil que vous pouvez tout de suite
mettre en application, \u224? tous les niveaux. 8. Dans l'analyse des exigences, il
faut constamment surveiller... ... \u224? vous de deviner la r\u233?ponse (vous
vous en doutiez maintenant) ! Pour savoir ce qu'il faut surveiller, il suffit
d'imaginer ce qui se passerait si vous ne le surveilliez pas ! 9. S'il ne fallait
utiliser qu'un seul type de diagramme, ce serait... Un diagramme n'est pas une fin
en soi. c'est un mode d'expression. Il s'agit d'\u234?tre le plus clair et pr\u233?
cis possible pour ceux qui vont vous lire. Ce que vous devez exprimer d\u233?pend
de vos objectifs, du contexte, des parties prenantes, du domaine d'application et
du niveau de d\u233?tail exig\u233?. 10. Les exigences les plus importantes \u224?
sp\u233?cifier sont... Toutes, bien s\u251?r ! La seule chose que l'on peut dire
est que les exigences non fonctionnelles sont difficiles \u224? \u233?crire et
beaucoup trop souvent n\u233?glig\u233?es. Pour les contraintes, cela est tr\u232?s
d\u233?pendant du type de prestations que l'on attend du fournisseur.\par\pard\
plain\hyphpar} {
PARTI E M\u233?thodologie L'ing\u233?nierie des exigences consiste, dans une large
mesure, \u224? cr\u233?er des mod\u232?les abstraits \u224? partir d'un relev\u233?
de faits g\u233?n\u233?ralement beaucoup plus concrets, puis \u224? les pr\u233?
senter de mani\u232?re claire, structur\u233?e et intelligible par tous les
acteurs, donc dans un langage souvent diff\u233?rent que celui de d\u233?part. La
capacit\u233? \u224? effectuer des voyages aller-retour dans l'abstraction, \
u224? \u233?laborer des mod\u232?les, tout en restant proche du m\u233?tier de ses
interlocuteurs, constitue la principale difficult\u233?, mais aussi tout l'attrait
du m\u233?tier d'analyste des exigences. Pour exercer ce m\u233?tier et mener \
u224? bien les missions qui lui sont confi\u233?es, celui-ci va faire appel \u224?
ses comp\u233?tences et \u224? son savoir-faire acquis par l'exp\u233?rience, ainsi
qu'\u224? une d\u233?marche rigoureuse. Dans cette partie, nous allons introduire,
puis d\u233?finir pr\u233?cis\u233?ment, les notions de besoin et d'exigence, les
enjeux d'une bonne d\u233?finition des besoins, les comp\u233?tences n\u233?
cessaires \u224? ce travail de d\u233?finition, et sa position dans le cycle de vie
du logiciel. L'efficacit\u233? de ces activit\u233?s d\u233?pend dans une large
mesure du soin apport\u233? \u224? leur pr\u233?paration. Celle-ci comprend les
activit\u233?s de planification, inh\u233?rentes \u224? tout projet, et que nous
allons d\u233?tailler pour le cas particulier du d\u233?veloppement des exigences.
La pr\u233?paration comprend \u233?galement la d\u233?termination pr\u233?cise des
objectifs, du champ de l'\u233?tude et des parties prenantes. Ces trois activit\
u233?s, auxquelles nous consacrons un chapitre, sont cruciales.\par\pard\plain\
hyphpar} {
Chapitre 1 La m\u233?thode en action Dans ce chapitre, nous allons tenter
d'introduire \u224? la fois le vocabulaire, la probl\u233?matique et les concepts.
La situation prise comme exemple est fictive, mais pr\u233?sente toutes les
difficult\u233?s auxquelles est confront\u233? un analyste ou assistant \u224? ma\
u238?trise d'ouvrage au cours de sa mission. Ces difficult\u233?s rendent n\u233?
cessaire une approche organis\u233?e et syst\u233?matique, appel\u233?e ing\u233?
nierie des exigences. Un exemple imaginaire, mais concret Supposons que la
direction du marketing d'un constructeur automobile envisage de mettre sur le
march\u233? un nouveau v\u233?hicule r\u233?volutionnaire, \u233?quip\u233? d'un
pilote automatique. Plus rien \u224? faire pour le conducteur, ou alors si peu...
Supposons que nous sommes \u224? la t\u234?te d'une \u233?quipe charg\u233?e de sp\
u233?cifier1 ce que le syst\u232?me de pilotage automatique doit faire, doit \u234?
tre ou doit avoir pour \u234?tre op\u233?rationnel. Supposons que nous- m\u234?mes
ne connaissons rien, ou presque rien, \u224? la m\u233?canique automobile, ni m\
u234?me aux syst\u232?mes embarqu\u233?s dans les v\u233?hicules, domaines r\u233?
serv\u233?s des techniciens et ing\u233?nieurs. Notre challenge est de d\u233?finir
les besoins et de les sp\u233?cifier sous forme d'exigences. 1. Le challenge: d\
u233?aire le besoin sans d\u233?aire la solution. Le m\u233?tier de la d\u233?
^ffion des besoins est d anafystou business unizrj^ consultant m\u233?tier, parfo\
u232?d"^ assistant \u224? la niaftrise d'ouvrage r^^ indifl\u233?
ienirneiit<r^tefme& Pour nous, la direction du marketing est le ma\u238?tre
d'ouvrage op\u233?rationnel. Les techniciens et ing\u233?nieurs sont le ma\u238?tre
d'\u339?uvre. La direction\par\pard\plain\hyphpar} {
ie 1 - M\u233?thodologie g\u233?n\u233?rale, n\u233?cessairement impliqu\u233?e
dans un projet d'une telle envergure, est le ma\u238?tre d'ouvrage strat\u233?
gique. Le document que nous allons produire, et qui s'adressera \u224? l'ensemble
de ces acteurs, appel\u233?s parties prenantes, s'appelle cahier des charges.
L'analyse de l'existant La premi\u232?re t\u226?che \u224? laquelle nous allons
nous atteler consiste \u224? examiner tout ce qui existe en mati\u232?re
d'automatismes embarqu\u233?s dans les v\u233?hicules. En effet, bien qu'aucune
voiture actuellement sur le march\u233? ne dispose \u224? proprement parler d'un
pilote automatique, de nombreux m\u233?canismes, qu'ils soient m\u233?caniques, \
u233?lectrom\u233?caniques, ou informatis\u233?s, existent d\u233?j\u224?. Cette
premi\u232?re t\u226?che, donc, appel\u233?e analyse de l'existant, est
indispensable et va nous occuper pour un bon moment. Elle est indissociable de
l'activit\u233? de recueil des besoins, car l'existant d'une automobile pourra
servir \u224? sp\u233?cifier les besoins d'une automobile \u224? venir. Concr\u232?
tement, l'analyse de l'existant va consister \u224? : \u8226? \u233?tudier la
documentation des automobiles existantes ; \u8226? examiner les sp\u233?cifications
des automobiles d\u233?j\u224? con\u231?ues, mais qui n'ont jamais vu le jour ; \
u8226? visiter les ateliers, les usines, les cha\u238?nes de montage : \u8226?
examiner les automobiles de la concurrence : \u8226? examiner ce qui se fait, en
mati\u232?re de pilotage automatique, dans d'autres domaines que l'automobile. Le
cahier des charges Apr\u232?s avoir \u233?tudi\u233? l'existant, nous allons passer
\u224? la partie la plus longue et la plus difficile de notre travail, l'\u233?
laboration du cahier des charges. Comme indiqu\u233?, le cahier des charges est un
document que tous les acteurs en pr\u233?sence doivent \u234?tre capables de
comprendre facilement, et qui servira de contrat entre plusieurs parties prenantes.
Pour ce faire, il devra donc \u234?tre \u233?crit dans un langage clair et concis.
Pour l'essentiel, il sera constitu\u233? d'un ensemble de phrases telles que. par
exemple : En mode automatique, le v\u233?hicule doit se conformer au Code de la
route. Il s'agit l\u224? de ce que l'on appelle une exigence de haut niveau. \u201?
nonc\u233?e ainsi, elle para\u238?t \u233?vidente, mais doit n\u233?anmoins \u234?
tre sp\u233?cifi\u233?e de mani\u232?re pr\u233?cise, non ambigu\u235?, dans un
langage que tous les acteurs comprennent.\par\pard\plain\hyphpar} {
Chapitre 1 - La m\u233?thode en action Les r\u232?gles de gestion Plus loin dans le
cahier des charges, cette exigence de haut niveau sera exprim\u233?e en exigences
de plus bas niveau, comme : En mode automatique, le syst\u232?me fera en sorte que
le v\u233?hicule respecte les limitations de vitesse impos\u233?es par la
signalisation. En mode automatique, le syst\u232?me fera en sorte que le v\u233?
hicule n'acc\u233?l\u232?re pas lorsqu'un v\u233?hicule plac\u233? derri\u232?re
lui tente de le d\u233?passer. Dans ces phrases, qui constituent un \u233?
chantillon parmi des centaines d'autres, le marketing (ma\u238?tre d'ouvrage)
demande au bureau d'\u233?tudes (le ma\u238?tre d'ceuvre) que le syst\u232?me fasse
en sorte qu'\u224? tout moment, lorsque le v\u233?hicule est sous contr\u244?le du
pilote automatique, le Code de la route soit respect\u233?. Ces phrases sont des
exigences d'un type particulier. Dans cet ouvrage, et dans le vocabulaire consacr\
u233? de l'ing\u233?nierie des exigences, on les appelle r\u232?gles de gestion (en
anglais, business ruks). Si les r\u232?gte cfe o^stwn r\u233? extraits te textes r\
u233?gienwmta^ feutfl n\u233?cessai- - itemerrtlesrepen^ fatier\u234?f\u233?
ieftce ? la question est loin d'\u234?tre triviale, elleitepas d\u233? r\u233?
poiised\u233?fimth^dfe d\u233?pend 4t plusieurs farteurs : o^ suffisamment daire^\
u234?^^^ qui se (^\u249?iedisementre eux? Les contraintes Il ne suffit pas de
recopier le Code de la route, ou de le paraphraser, ou d'y faire r\u233?f\u233?
rence, pour \u233?laborer le cahier des charges d'un pilote automatique pour
automobile. Dans le cahier des charges, on trouvera des exigences telles que :
Lorsque le r\u233?gime du moteur d\u233?passe un seuil maximum not\u233? Rs. le
syst\u232?me devra faire en sorte que le v\u233?hicule change de r\u233?gime en
passant \u224? la vitesse sup\u233?rieure. Lorsque le r\u233?gime du moteur passe
sous un seuil minimum not\u233? Rm. le syst\u232?me devra faire en sorte que le v\
u233?hicule change de r\u233?gime et r\u233?trograde. Notons en passant que ces
exigences permettent de percevoir une fronti\u232?re entre deux mondes : le syst\
u232?me, que nous sommes en train d'\u233?tudier\par\pard\plain\hyphpar} {
ie 1 - M\u233?thodologie (parfois appel\u233? SAE. syst\u232?me \u224? l'\u233?
tude) et le contexte, qui est l'ensemble des syst\u232?mes ext\u233?rieurs au syst\
u232?me \u224? l'\u233?tude, et avec lesquelles il r\u233?agit. Le contexte peut \
u234?tre constitu\u233? de logiciels, de mat\u233?riels, et d'humains (comme le
conducteur du v\u233?hicule). La d\u233?termination du contexte est une activit\
u233? indispensable que nous allons d\u233?tailler dans un prochain chapitre. Les
exigences fonctionnelles Exigences r\u233?glementaires et contraintes techniques
sont des exigences ext\u233?rieures \u224? l'organisation qui exprime les besoins.
La majorit\u233? des besoins internes \u224? l'organisation vont se traduire par
des exigences fonctionnelles. Par exemple : En l'absence d'exigences r\u233?
glementaires et de contraintes m\u233?caniques, la vitesse du v\u233?hicule sera
celle d\u233?termin\u233?e par 1'utilisateur. Si la vitesse n'a pas \u233?t\u233?
d\u233?termin\u233?e par l'utilisateur, et en l'absence d'exigences plus
prioritaires, le v\u233?hicule acc\u233?l\u233?rera jusqu'\u224? atteindre la
vitesse maximale autoris\u233?e par la signalisation ou la r\u233?glementation. Les
exigences m\u233?tier Ni le Code de la route, ni une quelconque contrainte m\u233?
canique n'obligent un v\u233?hicule \u224? circuler \u224? la vitesse maximale
autoris\u233?e. L'exigence que nous venons de citer est une exigence m\u233?tier
(en anglais, business requirement). Dans notre exemple, la \u171? direction m\
u233?tier \u187? est le marketing. Cette derni\u232?re exigence, d\u233?terminant
la vitesse maximale, peut se rapporter \u224? une exigence de plus haut niveau
telle que : En l'absence de contraintes m\u233?caniques ou r\u233?glementaires, le
v\u233?hicule circulera \u224? la vitesse maximale possible. Cette exigence peut
elle-m\u234?me se rapporter \u224? une exigence de niveau sup\u233?rieur, c'est-\
u224?-dire \u224? un objectif : Les performances du v\u233?hicule devront d\u233?
passer celles des v\u233?hicules de la concurrence de la m\u234?me cat\u233?gorie.
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
op\u233?rationnel. Une des difficult\u233?s de l'ing\u233?nierie des exigences
consiste \u224? maintenir la tra\u231?abilit\u233? entre les exigences de diff\
u233?rents niveaux.\par\pard\plain\hyphpar} {
Chapitre 1 - La m\u233?thode en action T<xBlesm\u233?tiefv\u224?fiitstardu^ Itf
direction du d^veloppemem durabte vou^ tk>n en \u233?nerêraj\u244?fs qu'une autre
exigence: les besoins sont ceuxdespe^ Les autres exigences Les syst\u232?mes
informatiques manipulent des donn\u233?es. Les exigences sur les donn\u233?es,
comme les formats de donn\u233?es, les seuils de d\u233?clenchement, les relations
entre donn\u233?es, constituent une cat\u233?gorie \u224? part. Les exigences
fonctionnelles d\u233?crivent ce que le syst\u232?me doit faire, en d'autres termes
son comportement. Une autre cat\u233?gorie d'exigences, ais\u233?es \u224?
comprendre, mais difficiles \u224? d\u233?crire, concerne la qualit\u233? du syst\
u232?me. On les appelle exigences non fonctionnelles. a plusieura rriam\u232?r\
u235?^te ilkistr\u233? la stnjduratwa d W\u238?\u234?gerl Elle dasse les exigen<^ d
o^rtsfune des neuf cat\u233?gorks suivantes: mies, gains). \u8226? Sc\u233?narios
et cas d'utilisation : ib amesporolent \u224? o^ te \u8226? R\u232?gles de gestion
(r\u232?^ m\u233?êr) : fe logjdel dor^ une loi, un ;f^g^nM^n^;' tite;ducs^tiKf^4\
u224?ffii- uhe:|\u238?iiri\u251?\u202?duKL.-, \u8226? Exigent fbndiorin^
comportement du syst\u232?me. \u8226? Attributs de \u251?ît\u233?, \u233?galement
appela te taract\u233?ristia^ ex\u224?^ rK^'ie)tmpsouvert n\u233?glig\u233?e \
u8226? Exigenttdlirtertaces externes: in^^ ouun\u224?utrelbgidel \u8226?
Contraintes : ete contraintes l\u201?&a\u249? n^^ trop de \u339?rrtraintes
apparaissent k\u171? du reaid \u224? la recherche de la sdiition ad\u233?quate ;U
est ir\u244?te \u8226? P\u233?firtitiîte^ \u171?fuit num\u233?ro de S\u233?ajrit\
u233?sodale ou d'un rujme^ de s\u233?rie).\par\pard\plain\hyphpar} {
ie 1 - M\u233?thodologie \u8226? Suggestions de Mutions, fwmrf\u233?es comme des
e^^ un utilisa- teurauneki\u233?ep\u239?fejrt\u231?uedete l'ana^ des exigenc^JI est
important de les ftotit\u224?tiote^ D'autres exigences peuvemv\u234?Tr\u235? fbnwl\
u233?es et a d\u233?lais, mais elles sont distim\u238?es des exigences pro^
Nousieyi\u232?nd^^ a\u233?> au d\u233?velopperrîtto^ exigence Le m\u233?tier : g\
u233?rer une combinaison d'exigences Une combinaison d'exigences (r\u232?gles m\
u233?tier, exigences m\u233?tier, contraintes techniques) peut donner naissance \
u224? de nouvelles exigences, bien r\u233?elles, mais jamais formul\u233?es comme
telles. C'est l\u224? une des grandes difficult\u233?s de l'analyse des exigences.
Reprenons notre exemple fictif du cahier des charges d'un pilote automatique pour
automobile. Le Code de la route, ou du moins son sous- ensemble concernant la
conduite automobile, constitue un ensemble de r\u232?gles m\u233?tier. En voici une
(pas toujours respect\u233?e des automobilistes !) : Article R412-31 du Code Tout
conducteur doit de la route marquer signalisation jaune fixe. l'allumage dudit son
v\u233?hicule dans feu. le sauf Tarr\u234?t dans le conducteur ne des conditions
devant cas peut un o\u249?. plus feu lors de de arr\u234?ter de s\u233?curit\u233?
suffisantes. Le \u171? feu de signalisation jaune fixe \u187? est ce que l'on
appelle commun\u233?ment un feu orange. Pourquoi cette r\u232?gle de gestion ne
peut-elle pas \u234?tre reprise telle quelle dans le cahier des charges ? Il y a \
u224? cela plusieurs raisons : \u8226? Le vocabulaire du Code de la route n'est pas
le m\u234?me que celui du cahier des charges. Bien s\u251?r, on pourrait s'aligner
sur ce vocabulaire juridique, puisque c'est la loi. Mais pourquoi pas sur celui de
l'industrie automobile, qui est plus pr\u233?cis sur le plan de la m\u233?canique ?
\u8226? La r\u232?gle n'est centr\u233?e ni sur le syst\u232?me \u224? l'\u233?tude
(le pilote automatique), ni sur le v\u233?hicule, ni sur l'utilisateur du syst\
u232?me. Elle est centr\u233?e sur le couple conducteur-v\u233?hicule, repr\u233?
sent\u233? par c le conducteur \u187?, seul responsable, devant la loi. du
comportement de son v\u233?hicule (en cas de d\u233?faillance du v\u233?hicule, il
pourra par la suite se retourner contre le constructeur automobile, comme cela peut
\u234?tre le cas lors de toute d\u233?faillance d'un syst\u232?me automatis\u233?).
\u8226? Surtout, l'article fait r\u233?f\u233?rence \u224? une autre r\u232?gle ou
contrainte, qui est d\u233?crite ailleurs ou est cens\u233?e \u234?tre compr\u233?
hensible par tous. Cette contrainte\par\pard\plain\hyphpar} {
Chapitre 1 - La m\u233?thode en action concerne les conditions de s\u233?curit\
u233? \u171? suffisantes >. Elle est sans doute facile \u224? interpr\u233?ter
(quoique...) par les automobilistes, qui doivent respecter la loi. et par les
autorit\u233?s, qui doivent la faire respecter. Mais elle est beaucoup trop floue
pour d\u233?crire le comportement attendu d'un syst\u232?me. En r\u233?alit\u233?,
l'article cit\u233? fait appel \u224? d'autres articles, ainsi qu'\u224? la
jurisprudence, qui permet \u233?galement de d\u233?terminer ce que sont des
conditions de s\u233?curit\u233? suffisante, dans quelles circonstances le v\u233?
hicule pouvait ou non \u234?tre arr\u234?t\u233? sans danger, etc. Tentons de
traduire cette r\u232?gle m\u233?tier en exigence syst\u232?me. Cela donne : Si le
feu de signalisation dont d\u233?pend le v\u233?hicule passe \u224? 1'orange. et si
le syst\u232?me dispose du temps n\u233?cessaire pour arr\u234?ter le v\u233?hicule
\u224? 1'aplonb du signal et si en s'arr\u234?tant, le v\u233?hicule ne met pas en
danger le conducteur, les passagers et l'environnement du v\u233?hicule et si les
conditions de s\u233?curit\u233? telles que d\u233?finies par [un ensemble de r\
u232?gles de gestion pr\u233?alablement d\u233?finies] sont respect\u233?es alors
le syst\u232?me fait en sorte que le v\u233?hicule ralentisse progressivement
jusqu'\u224? s'arr\u234?ter \u224? l'aplomb du signal. Il s'agit l\u224? d'une
traduction encore tr\u232?s approximative de la r\u232?gle, qu'il faudra
certainement retravailler. Le but de l'exercice est de montrer \u224? quel point
une r\u232?gle de gestion qui nous para\u238?t simple, par ce que nous vivons tous
les jours avec, se traduit en une exigence syst\u232?me qui peut \u234?tre extr\
u234?mement complexe. En particulier, une analyse rapide de la r\u232?gle de
gestion, en interaction avec les contraintes m\u233?caniques, fait \u233?merger de
nouvelles conditions qui \u233?taient cach\u233?es ou sous-entendues jusque-l\
u224?. Dans notre exemple, c'est le facteur temps qui \u233?merge. D'autres
contraintes peuvent \u233?merger, comme la notion de risque. La r\u232?gle de
gestion peut tr\u232?s bien s'\u233?crire : Si. en arr\u234?tant le v\u233?hicule \
u224? l'aplomb du signal, le syst\u232?me cause moins de d\u233?g\u226?ts qu'il
n'en aurait caus\u233?s en ne s'arr\u234?tant pas. alors le syst\u232?me doit arr\
u234?ter le v\u233?hicule \u224? l'aplomb du signal.\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie Cette derni\u232?re formulation de l'exigence est sans
doute moins \u171? politiquement correcte \u187?, mais beaucoup plus proche de la
r\u233?alit\u233? que l'article de loi. En effet, un conducteur automobile fait en
permanence un calcul de risques. Il ne se contente pas de s'assurer que les
conditions de s\u233?curit\u233? sont v\u233?rifi\u233?es (elles ne le sont
jamais \u224? 100 %). il estime les risques \u224? passer \u224? l'orange et \u224?
ne pas passer, puis compare les deux en temps r\u233?el (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 \u233?loigne du strict respect de la loi). Selon le
niveau de cahier des charges \u224? \u233?laborer, l'article R412-31 du Code de la
route se traduira par quelques dizaines, centaines, voire milliers d'exigences
logicielles, qui tiendront compte d'exigences aussi diff\u233?rentes que le Code de
la route, la psychologie du comportement des pi\u233?tons, ou les contraintes m\
u233?caniques. La notion de partie prenante Cet exemple fait ressortir la notion de
partie prenante, extr\u234?mement importante et trop souvent n\u233?glig\u233?e. Un
ing\u233?nieur m\u233?canicien, un juriste et le repr\u233?sentant d'une
association d'automobilistes sont tous trois des parties prenantes au projet.
Consid\u233?rons chacun de ces acteurs comme une personne d'exp\u233?rience, de
bonne foi, dou\u233?e de bon sens. Cela ne les emp\u234?chera pas d'exprimer des
besoins contradictoires, car le bon sens est une question de point de vue.
L'analyste devra trouver et faire approuver un consensus entre des expressions de
besoins conflictuels, en g\u233?rant des priorit\u233?s entre exigences. Sa t\u226?
che sera grandement facilit\u233?e si, au lieu de devoir g\u233?rer des
contradictions, voire des conflits tout au long du recueil des besoins, il anticipe
sur ces \u233?ventuels conflits en analysant les int\u233?r\u234?ts et les rapports
de force des diff\u233?rents acteurs. Cette t\u226?che s'appelle analyse des
parties prenantes. Le point sur les concepts Besoin, demande, exigence et sp\u233?
cification On a vu, gr\u226?ce \u224? l'exemple pr\u233?c\u233?dent, les diff\u233?
rences entre besoin, demande et exigence. Le besoin est interne \u224? une
organisation ou une personne. Dans le cas d'une personne physique, il peut \u234?
tre ressenti, intellectuellement ou physiquement. Il peut \u234?tre exprim\u233?
plus ou moins clairement, sous-entendu, pass\u233? sous silence, ignor\u233? ou ni\
u233? par son auteur. La demande est l'expression d'un besoin. Elle peut \u234?tre
sup\u233?rieure au besoin, en termes de co\u251?t, de qualit\u233?, de fonctions,
ou lui \u234?tre inf\u233?rieure. O\par\pard\plain\hyphpar} {
Chapitre 1 - La m\u233?thode en action Par rapport \u224? la demande, une exigence
tient compte des contraintes, et introduit une notion de consensus, de cible \u224?
atteindre. Elle est demand\u233?e par le client et doit \u234?tre accept\u233?e par
le fournisseur. Elle doit \u234?tre mesurable, ou du moins v\u233?ritable. Enfin,
la sp\u233?cification est la traduction des exigences dans un langage convenu entre
le client et le fournisseur. Elle permet d'\u233?viter les effets pervers qui
perturbent leurs relations, y compris dans le cas o\u249? les deux parties, client
et fournisseur, sont de bonne foi. La sp\u233?cification des exigences est une d\
u233?marche industrielle. Ing\u233?nierie des exigences L'ing\u233?nierie des
besoins, ou ing\u233?nierie des exigences, est donc la discipline, vue comme un
ensemble de techniques, consistant \u224? recueillir les besoins, \u224? les
transformer en exigences, et \u224? les sp\u233?cifier dans un cahier des charges.
Quand on parle d'ing\u233?nierie, on pense souvent \u224? des techniques complexes.
Cependant, sur le plan conceptuel, les diff\u233?rentes techniques d\u233?crites
dans cet ouvrage sont simples. Comme nous le verrons, les vraies difficult\u233?s
proviennent essentiellement : \u8226? du choix entre plusieurs techniques ; \u8226?
de la n\u233?cessit\u233? d'un suivi rigoureux des exigences ; \u8226? des aspects
humains. Cahier des charges Un cahier des charges peut donc \u234?tre d\u233?fini
de trois fa\u231?ons : \u8226? C'est l'expression des besoins, apr\u232?s qu'ils
aient \u233?t\u233? recueillis, analys\u233?s, n\u233?goci\u233?s, prioris\u233?s.
sp\u233?cifi\u233?s, class\u233?s. \u8226? C'est un ensemble de demandes, apr\u232?
s traitement et arbitrage. \u8226? C'est un ensemble structur\u233? d'exigences,
qu'un client pr\u233?sente \u224? un fournisseur.\par\pard\plain\hyphpar} {
Chapitre 2 Les enjeux d'une bonne d\u233?finition des besoins Le cahier des charges
est un document constitu\u233? d'un ensemble structur\u233? d'exigences, transmis
d'un client \u224? un fournisseur, et qui a un caract\u232?re contractuel. Comme
nous le verrons tout au long de cet ouvrage, son \u233?laboration est un travail
collectif n\u233?cessitant la collaboration de nombreux acteurs. Le processus de
cette \u233?laboration est aussi important que le document qui en r\u233?sulte.
L'utilit\u233? d'un cahier des charges Un bon cahier des charges est un document
clair, facile \u224? lire et \u224? comprendre par les diff\u233?rents acteurs, qui
a \u233?t\u233? \u233?tabli sur la base d'un consensus. \u201?tant donn\u233?e la
complexit\u233? de certaines situations que ce document repr\u233?sente, il peut \
u234?tre tr\u232?s complexe, mais il n'est jamais \u171? compliqu\u233? \u187? :
c'est un document relativement facile \u224? maintenir et \u224? modifier. Ce
document, \u233?labor\u233? de mani\u232?re participative, d\u233?finissant
clairement les exigences d'un client vis-\u224?-vis d'un fournisseur, sera utile au
choix, \u224? la conception, \u224? la r\u233?alisation, au param\u233?trage d'une
application ou d'un syst\u232?me informatique, ainsi qu'\u224? sa mise en \u339?
uvre op\u233?rationnelle, sa maintenance et son exploitation. Un investissement tr\
u232?s rentable L'ensemble des activit\u233?s d'\u233?laboration qui part du
recueil des besoins et aboutit \u224? un cahier des charges est appel\u233? d\u233?
veloppement des exigences. Les enjeux li\u233?s au d\u233?veloppement des exigences
sont tr\u232?s importants. Les personnes qui \u233?laborent un cahier des charges
pour la premi\u232?re\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie 1. Ces chiffres \u233?ma- nent de plusieurs \u233?
tudes, en particulier celles de Boehm et de Crady. fois, ou demandent de
l'assistance pour son \u233?laboration, sont rarement conscientes de l'importance
de cette phase, et en sous-estiment les cons\u233?quences. Plut\u244?t qu'un long
discours, voici quelques faits1 : Environ les trois quarts des erreurs dans le
choix, la mise en \u339?uvre et la construction d'un logiciel sont dues \u224? des
exigences mal formul\u233?es ou \u224? un cahier des charges mal construit (nous
verrons plus loin ce que cela signifie). Le co\u251?t de la correction d'une erreur
produite lors de la phase d'exigences est beaucoup plus important (jusqu'\u224?
cent fois) lorsque cette erreur est d\u233?couverte en phase d'exploitation que
pendant la phase d'exigences elle-m\u234?me (voir figure 2-1 ). Ce constat,
statistiquement d\u233?montr\u233?, est apparemment contre-intuitif, puisque nombre
de donneurs d'ordres n'investissent pas suffisamment de temps et d'argent dans
cette phase, pensant sans doute que c'est du temps et de l'argent perdus, et qu'on
pourra toujours corriger le tir et rattraper les petites erreurs par la suite. Or.
corriger le tir co\u251?te largement plus cher que de viser juste du premier coup.
100 c Exigences Concept Real. Tests Phases de d\u233?veloppement Figure 2-1 :
Augmentation exponentielle des erreurs Exploit Si le cahier des charges est utilis\
u233? pour le choix d'un logiciel sur \u233?tag\u232?re (progiciel), le co\u251?t
d'un mauvais choix est nettement sup\u233?rieur au co\u251?t d'un bon cahier des
charges. Enfin, la r\u233?\u233?criture de sp\u233?cifications ou de programmes (le
rework) suite \u224? des sp\u233?cifications erron\u233?es ou insuffisamment pr\
u233?cises peut co\u251?ter jusqu'\u224? la moiti\u233? du co\u251?t total du d\
u233?veloppement. Sp\u233?cifier les besoins de mani\u232?re scrupuleuse est donc
un investissement extr\u234?mement rentable. Il peut rapporter plus de cent fois ce
qu'il aura co\u251?t\u233?.\par\pard\plain\hyphpar} {
Chapitre 2 - Les enjeux d'une bonne d\u233?finition des besoins Sans \u234?tre
ambitwtix, on petit tabler sur imretow la drteefttt eritre un <ahier d\u171? m\
u171?k)cm\'5ca rapporter au rtw df\u233?l\u226?bbii\u238?t\u224?tiMn^dM; c^^' d\
u232?s- \u171?\u226?hia^p\u226?s-iul4^n^Vf\u235?:-\u235?b4Qt.4*9J\u171? retravail \
u187? \'5c'7bfcwtoty des exig^rices en phase ofer\u233?îsatkM^ Les gains \u171?
cach\u233?s \u187? Les gains que nous venons de mentionner sont les plus visibles.
Mais obtenir de bonnes sp\u233?cifications d\u232?s le d\u233?but apporte de
nombreux b\u233?n\u233?fices secondaires, et pas seulement sur le plan financier.
R\u233?ussir du premier coup est beaucoup plus motivant et encourageant pour les
utilisateurs que de revenir sur des sp\u233?cifications. De plus, le processus m\
u234?me d'\u233?laboration d'un cahier d'exigences permet aux diff\u233?rentes
parties prenantes, \u224? commencer par les utilisateurs, de participer \u224? une
d\u233?marche collaborative de recueil, de sp\u233?cification, de validation des
besoins, et de r\u233?fl\u233?chir \u224? l'impact de la mise en \u339?uvre d'un
nouveau syst\u232?me sur les processus actuels. D'autres gains sont induits par le
processus m\u234?me de l'\u233?laboration. \u201?laborer un cahier des charges est
un travail d'\u233?quipe qui. bien men\u233?, va souder cette derni\u232?re autour
d'un projet commun. L'effort ult\u233?rieur de mise en \u339?uvre du produit, de
formation, de conduite du changement en sera grandement facilit\u233?. Enfin, last
but mi least, un cahier des charges bien construit co\u251?te beaucoup moins cher
qu'un cahier des charges \u233?labor\u233? de mani\u232?re empirique, avec des
allers-retours incessants entre les diff\u233?rentes parties prenantes. \u201?
laborer un cahier des charges n'est jamais chose ais\u233?e, suivre une m\u233?
thode rigoureuse et des techniques \u233?prouv\u233?es va grandement faciliter les
choses. Les difficult\u233?s Inutile de se voiler la face. Le travail d'\u233?
laboration est long et difficile. M\u234?me avec une bonne m\u233?thode et des t\
u234?tes bien faites, c'est une \u233?preuve, et on passe toujours par des moments
de d\u233?couragement. Il est important de conna\u238?tre par avance certaines
difficult\u233?s pour mieux pouvoir s'en pr\u233?munir. La premi\u232?re difficult\
u233? vient du donneur d'ordres. Ce peut \u234?tre la direction g\u233?n\u233?rale
d'une entreprise, ou une administration centrale dans le secteur 0\par\pard\plain\
hyphpar} {
Partie 1 - M\u233?thodologie public. Le donneur d'ordres doit s'impliquer, d\u233?
finir les objectifs, donner une lettre de mission claire \u224? l'\u233?quipe qui
va d\u233?finir les besoins. Ce n'est pas toujours le cas. Si la direction ne
s'implique pas. il faudra tout faire pour qu'elle s'engage dans ce projet, car sa
r\u233?ussite en d\u233?pend. La deuxi\u232?me difficult\u233? provient du rythme
de travail, qu'il convient de c\u226?dencer pour conserver la motivation des
acteurs jusqu'au bout et \u233?viter l'essoufflement. En effet, l'enthousiasme de
d\u233?part ne dure pas \u233?ternellement, surtout lorsque la d\u233?finition des
besoins devient un exercice routinier, avec ses lectures crois\u233?es et ses
revues formelles. L'inspiration peut aussi manquer au d\u233?marrage du projet,
pendant les phases cr\u233?atives de recueil des besoins, lorsque les futurs
utilisateurs manquent d'id\u233?es. Dans les deux cas, c'est le talent de
l'analyste des besoins qui est requis. Une autre difficult\u233? concerne les
pressions ext\u233?rieures aux groupes de travail. Le donneur d'ordres peut \u234?
tre press\u233? d'avoir des r\u233?sultats rapides, et pr\u233?f\u233?rer un
travail vite fait, mal fait, \u224? un document conclusif. \u192? d'autres moments,
le donneur d'ordres peut au contraire l\u226?cher la tension, pris par d'autres
priorit\u233?s. Or, la d\u233?finition des besoins est un exercice qui doit \u234?
tre rythm\u233?. Enfin, une difficult\u233? importante vient du fait que les gains
engendr\u233?s par une bonne d\u233?finition des besoins ne seront visibles qu'\
u224? tr\u232?s long terme, c'est-\u224?-dire lorsque le logiciel sera en
production. Pourquoi un dirigeant investirait-il dans une activit\u233? qui n'est
visible que lorsqu'elle est d\u233?faillante ? Les risques Quels que soient la
rigueur m\u233?thodologique et le talent de l'analyste, les risques existent et
sont nombreux. En voici quelques-uns, parmi les plus importants. Les sp\u233?
cifications rampantes Il est normal que les exigences \u233?voluent. Dans un tel
cas, les sp\u233?cifications du produit changent en cons\u233?quence, et le produit
lui-m\u234?me \u233?voluera par la suite. Les sp\u233?cifications rampantes
adviennent lorsque l'\u233?volution des exigences n'est pas contr\u244?l\u233?e. Le
produit ainsi couvert de < rustines \u187? risque de perdre en robustesse et en
coh\u233?rence. Souvent, les phases d'exigences et de conception sont bien s\u233?
par\u233?es. C'est en particulier le cas des appels d'offres publics, o\u249? le
cahier des clauses techniques particuli\u232?res (le CCTP) doit \u234?tre finalis\
u233? et approuv\u233? et o\u249? toute modification doit en principe faire l'objet
d'un avenant au o\par\pard\plain\hyphpar} {
Chapitre 2 - Les enjeux d'une bonne d\u233?finition des besoins contrat initial. M\
u234?me dans ce cas. les sp\u233?cifications peuvent \u233?voluer de mani\u232?re
incontr\u244?l\u233?e. Le cahier des charges devient alors un patchwork, avec tous
les risques d'incoh\u233?rences que cela peut entra\u238?ner. Pour \u233?viter
cette d\u233?rive, il faut d'une part que les objectifs du logiciel aient \u233?t\
u233? clairement d\u233?finis, et d'autre part que les modifications du cahier des
charges fassent partie d'un processus contr\u244?l\u233?. Le perfectionnisme
(sursp\u233?cification) Donner trop de d\u233?tails ne sert \u224? rien, et peut \
u234?tre nuisible. C'est en particulier le cas lorsque les utilisateurs ou leurs
repr\u233?sentants donnent des d\u233?tails sur la mani\u232?re dont une fonction
sera mise en \u339?uvre, en particulier en sp\u233?cifiant l'interface utilisateur
(comme \u171? cliquer avec le bouton droit de la souris \u187?). De tels d\u233?
tails n'ont rien \u224? faire dans un cahier des charges. S'il faut absolument sp\
u233?cifier des contraintes techniques, ce sera dans une annexe, et non dans la
description fonctionnelle des exigences. Une autre forme de sursp\u233?cification
consiste \u224? exiger des fonctions superflues. Cela augmentera inutilement le co\
u251?t du logiciel et les d\u233?lais de livraison. G\u233?n\u233?ralement, un
utilisateur ne conna\u238?t pas le co\u251?t de ses exigences. Pour \u233?viter
cette d\u233?rive, il est indispensable d'avoir cadr\u233? le projet, en temps, en
co\u251?t et en qualit\u233?. Le travail de l'assistant \u224? la ma\u238?trise
d'ouvrage consiste alors \u224? rappeler \u224? son client les objectifs que ce
client a lui-m\u234?me fix\u233?s. Les sp\u233?cifications insuffisamment d\u233?
taill\u233?es Le risque est ici de d\u233?crire les exigences de mani\u232?re tr\
u232?s globale (sous- sp\u233?cification), en esp\u233?rant que les concepteurs et
r\u233?alisateurs vont avoir suffisamment de < bon sens \u187? pour faire un
produit conforme \u224? ces besoins sous-entendus. C'est une utopie. Si un besoin
est insuffisamment explicit\u233?, un d\u233?veloppeur fera appel \u224? sa cr\
u233?ativit\u233?, essaiera de deviner ce que veut le client, avec de fortes
chances de se tromper. N\u233?gliger certains profils utilisateurs Un m\u234?me
logiciel s'adresse g\u233?n\u233?ralement \u224? des types d'utilisateurs diff\
u233?rents2, avec des besoins parfois tr\u232?s distincts. Bien que pouvant acc\
u233?der aux m\u234?mes informations, un comptable et un conseiller de client\u232?
le ne travaillent pas du tout de la m\u234?me fa\u231?on. Pour construire un
logiciel qui soit au service de plusieurs cat\u233?gories d'utilisateurs, il est
indispensable de tenir compte de leurs besoins particuliers, et pour cela de les
faire participer \u224? l'expression des exigences. 2. Voir le Chapitre 6, \u9632?
Analyser des parties prenantes \u187?.\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie Am\u233?liorer les pratiques d'\u233?laboration Des
bonnes pratiques d'expression et de gestion des exigences am\u233?lioreront consid\
u233?rablement la qualit\u233? du cahier des charges, et partant de l'application
finale. Cela est vrai dans tous les cas, qu'il s'agisse de d\u233?velopper une
application sur mesure ou de choisir, param\u233?trer et installer un progiciel.
Cet ouvrage n'a d'autre ambition que d'\u234?tre un manuel de bonnes pratiques qui
permettront : \u8226? de donner aux personnes en charge de l'\u233?laboration des
sp\u233?cifications d'exigences (cahier des charges) une approche et des outils qui
faciliteront leur travail ; \u8226? d'am\u233?liorer la communication entre client
(ma\u238?trise d'ouvrage), fournisseur (ma\u238?trise d'\u339?uvre) et analyste
(assistant \u224? la ma\u238?trise d'ouvrage) -, \u8226? d'\u233?viter le ph\u233?
nom\u232?ne des sp\u233?cifications rampantes ; \u8226? d'am\u233?liorer
l'efficacit\u233? en choisissant la technique ad\u233?quate de recueil, d'analyse,
de sp\u233?cification des exigences : \u8226? de minimiser l'effort en \u233?vitant
d'effectuer certaines t\u226?ches trop t\u244?t. ou de descendre trop vite dans les
d\u233?tails, ce qui obligera de revenir dessus une deuxi\u232?me fois ; \u8226? de
s\u233?curiser ce processus, gr\u226?ce \u224? des check-lists de fin d'\u233?
tape ; \u8226? de conserver la motivation des participants tout au long de l'\u233?
laboration ; \u8226? de pr\u233?parer le terrain \u224? l'\u233?laboration de cas
de test. o\par\pard\plain\hyphpar} {
Chapitre 3 Comp\u233?tences et savoir-Faire \u201?laborer un cahier des charges
exige de solides connaissances techniques et m\u233?thodologiques, ainsi que des
qualit\u233?s humaines. Pour cette raison, il n'y a pas un parcours type pour
devenir analyste des exigences. On trouve dans ce m\u233?tier des anciens
utilisateurs de produit, des ex-d\u233?veloppeurs, des experts du domaine
d'application. L'analyste doit apprendre, puis ma\u238?triser, les techniques de
l'ing\u233?nierie des besoins. C'est un animateur, un n\u233?gociateur, un interpr\
u232?te qui va \u233?couter les besoins des futurs utilisateurs et les reformuler
dans un langage clair (figure 3-1 ). mod\u233?Hse conceptualise MOA observe
reformule \u233?coute sp\u233?cifie cr\u233?e MOE analyse Q ^ synth\u233?tise anime
Analyste Figure 3-1 : Les comp\u233?tences de l'analyste Le savoir La connaissance
du m\u233?tier du client Sans \u234?tre un expert, l'analyste doit \u234?tre
familiaris\u233? avec le m\u233?tier de son client. En fonction des domaines
d'activit\u233?, du niveau de d\u233?tails attendu\par\pard\plain\hyphpar} {
ie 1 - M\u233?thodologie et du type d'application, cette connaissance se doit d'\
u234?tre plus ou moins approfondie. Tr\u232?s souvent, l'expertise est chez le
client. Sans \u234?tre expert, l'analyste doit \u234?tre capable de faire appel aux
experts, de comprendre leur langage, de se plonger dans leurs proc\u233?dures,
d'analyser leurs processus ; en d'autres termes, de conna\u238?tre leur m\u233?tier
sans pour autant le pratiquer. La connaissance des techniques de mod\u233?lisation
La repr\u233?sentation graphique des processus, des proc\u233?dures, des donn\u233?
es, des traitements sont souvent n\u233?cessaires, lorsque le langage \u233?crit ne
suffit pas ou manque de pr\u233?cision. Dans un tel cas. un bon sch\u233?ma vaut
mieux qu'un long discours. Cependant, il ne suffit pas de savoir dessiner un sch\
u233?ma ou un diagramme pour savoir mod\u233?liser. Encore faut-il comprendre la s\
u233?mantique, et les cons\u233?quences profondes de certains choix. Ainsi, sans
empi\u233?ter sur ie travail des techniciens, \u233?laborer un mod\u232?le
graphique demande quelques connaissances techniques. Par exemple, pour \u233?
laborer un mod\u232?le de donn\u233?es, il est utile de conna\u238?tre les
principes des bases de donn\u233?es relationnelles. Les sch\u233?mas seront lus par
les futurs utilisateurs qui ont besoin de clart\u233? et de simplicit\u233?, mais
aussi par les futurs d\u233?veloppeurs qui ont besoin de coh\u233?rence et de pr\
u233?cision. La connaissance des m\u233?tiers du d\u233?veloppement L'analyste des
exigences ne \u171? d\u233?veloppe \u187? pas de logiciel au sens courant du terme
(on a vu que l'analyse des exigences fait partie du cycle de d\u233?veloppement).
Avoir pratiqu\u233? le d\u233?veloppement est cependant un avantage qui permet de
savoir si un besoin exprim\u233? est r\u233?aliste, et \u224? quel prix il peut \
u234?tre r\u233?alis\u233?. Cela permet aussi, chaque fois que n\u233?cessaire, de
dialoguer avec les d\u233?veloppeurs et de se faire comprendre. Enfin, cela permet
de comprendre certaines contraintes et des compromis \u224? faire : plus de s\u233?
curit\u233? au d\u233?triment de la facilit\u233? d'utilisation, plus de richesse
fonctionnelle au d\u233?triment de la fiabilit\u233?... La connaissance des
technologies Il n'est pas indispensable d'\u234?tre un bon technicien pour sp\u233?
cifier des exigences et \u233?laborer un cahier des charges. C'est souvent
l'inverse qui est vrai, car un bon technicien a tendance \u224? rechercher des
solutions techniques plut\u244?t que de chercher \u224? comprendre le besoin de son
client. De bonnes connaissances techniques constituent n\u233?anmoins un s\u233?
rieux atout. Cela \u233?vite de chercher l'impossible l\u224? o\u249? des solutions
toutes pr\u234?tes sont sur le march\u233?. Cela permet aussi de conna\u238?tre les
limites impos\u233?es par certaines techniques. o\par\pard\plain\hyphpar} {
Chapitre 3 - Comp\u233?tences et savoir-faire Le savoir-Faire L'art de poser les
bonnes questions La question est \u224? l'analyste ce que le bistouri est au
chirurgien : un outil de travail quotidien, tr\u232?s simple, mais difficile \u224?
manier. Comme le bistouri, la question doit \u234?tre tranchante, bien aff\u251?t\
u233?e, et faire le moins de d\u233?g\u226?ts possible. Poser la bonne question au
bon moment est une affaire de talent, d'entra\u238?nement, mais aussi, et surtout,
de logique et de m\u233?thode. On peut avoir un r\u233?pertoire de questions g\
u233?n\u233?riques \u171? pr\u234?tes-\u224?-poser \u187?' pour \u233?viter d'\
u234?tre pris au d\u233?pourvu. Mais un bon analyste parcourt mentalement un arbre
de d\u233?cision et sait lier les questions entre elles dans un ordre logique, en
coh\u233?rence avec le point qu'il examine et les objectifs \u224? atteindre. Une
aptitude \u224? n\u233?gocier La personne charg\u233?e du recueil des besoins et de
l'\u233?laboration du cahier des charges joue un r\u244?le d'interm\u233?diaire
entre ma\u238?trise d'ouvrage et ma\u238?trise d'ceuvre. Elle doit \u234?tre <
bilingue \u187? ; non seulement conna\u238?tre le vocabulaire, comprendre le m\
u233?tier, mais \u233?galement pouvoir se mettre dans la peau des diff\u233?rents
acteurs pour comprendre leur point de vue. les contraintes de chacun, la mani\u232?
re de s'exprimer. Sp\u233?cifier des exigences, c'est avant tout < traduire \u187?
le langage du m\u233?decin, du juriste ou du banquier en un langage interm\u233?
diaire compris de tous les acteurs. Les qualit\u233?s d'animateur Le talent
d'animateur est indispensable, car le recueil des exigences est souvent une
activit\u233? d'\u233?quipe. Savoir animer un groupe de travail est une qualit\
u233? essentielle. Diff\u233?rents moyens vont permettre aux participants de
s'exprimer : brainstorming, maquettage sur papier, narration de situations v\u233?
cues, discussions, jeux de r\u244?le. Certaines techniques sont tr\u232?s
efficaces. Il faut aussi savoir cr\u233?er la motivation, puis la maintenir,
souvent pendant de longs mois, au fil des r\u233?unions. La qualit\u233?
d'organisateur et de chef de projet D\u233?finir les exigences demande une
planification soign\u233?e, une pr\u233?paration minutieuse, une organisation de
son propre travail et de celui de son \u233?quipe, en tenant compte des contraintes
du client et des autres parties prenantes. Une fois que le projet est lanc\u233?,
on doit faire face \u224? l'impr\u233?vu. \u192? l'image de tout chef de projet,
l'analyste des exigences doit \u234?tre capable de mener \u224? bien ces deux
activit\u233?s. Plus la planification sera rigoureuse, et plus il sera facile de
parer l'impr\u233?vu. 1. Voir en annexe la liste de questions g\u233?n\u233?rales.
Q\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie L'expression \u233?crite La capacit\u233? \u224? \
u233?crire avec aisance et pr\u233?cision est fondamentale. Parmi les nombreuses
mani\u232?res de repr\u233?senter les exigences, diagrammes, tableaux ou sch\u233?
mas, la plus usit\u233?e, et g\u233?n\u233?ralement la plus efficace, demeure la
langue fran\u231?aise. C'est en effet la seule repr\u233?sentation facilement
compr\u233?hensible par les gens de tous les m\u233?tiers. La langue fran\u231?aise
(et toute autre langue \u171? naturelle \u187?. en fonction du pays o\u249? l'on se
trouve et du milieu professionnel) est un outil extr\u234?mement complexe et
puissant, qui demande un long apprentissage et une longue pratique. Nous la ma\
u238?trisons tous, avec plus ou moins de talent, mais \u233?laborer un cahier des
charges exige l'utilisation d'un langage pr\u233?cis et non ambigu. Le savoir-\
u234?tre Une attitude de chef de projet Trois dangers menacent l'analyste des
exigences : \u8226? En manquant de rigueur, vouloir toujours faire plaisir \u224?
tout le monde ; cela conduit \u224? l'enlisement du projet. \u8226? En manquant de
souplesse, se faire un ennemi parmi les parties prenantes ; il risque de se faire <
griller \u187?. \u8226? Face \u224? des besoins mal d\u233?finis, laisser le flou
s'installer, voire l'amplifier ; or, sa mission exige de la pr\u233?cision. Face \
u224? ces trois menaces, la bonne attitude consiste \u224? \u234?tre rigoureux sur
le processus et souple avec les personnes. Cest cette neutralit\u233? bienveillante
qui lui permettra de s'en sortir indemne. La curiosit\u233? Le don d'observation et
la cr\u233?ativit\u233? vont de pair avec la curiosit\u233?. Faire de la veille
technologique est indispensable, et il faut la faire activement. La curiosit\u233?
m\u234?l\u233?e de cr\u233?ativit\u233? donne envie de < piquer des id\u233?es \
u187? et de les formaliser ensuite. Rappelons que les id\u233?es n'appartiennent \
u224? personne. Copier les id\u233?es en y ajoutant les siennes propres est l\u233?
gitime (surtout si, par respect du travail des autres, on cite ses sources). L'\
u233?coute Pour recueillir les besoins, il est plus important de savoir \u233?
couter que de savoir bien parler. Une bonne \u233?coute est pourtant une qualit\
u233? rare, et tr\u232?s appr\u233?ci\u233?e des utilisateurs. Un analyste doit \
u234?tre capable de mettre son interlocuteur en confiance ; de l'encourager \u224?
parler de son m\u233?tier ; de formuler une question en Q\par\pard\plain\hyphpar} {
Chapitre 3 - Comp\u233?tences et savoir-faire tenant compte du contexte et du m\
u233?tier de son interlocuteur ; de le relancer pour avoir des pr\u233?cisions ; de
stimuler son imagination et de le mettre en situation pour d\u233?crire une
situation r\u233?elle ou imaginer une situation \u224? venir ; de l'encourager \
u224? descendre dans les d\u233?tails ou, \u224? l'inverse, de prendre de la
hauteur par rapport \u224? sa situation. Une bonne \u233?coute est li\u233?e au
talent, \u224? l'exp\u233?rience et \u224? la personnalit\u233? de l'analyste. Mais
des interviews bien pr\u233?par\u233?es et bien structur\u233?es aident le talent \
u224? s'exprimer et les moins talentueux \u224? s'en sortir honn\u234?tement. Nous
donnerons quelques r\u232?gles simples de pr\u233?paration des interviews dans le
chapitre consacr\u233? au recueil des besoins. Un excellent relationnel Cette
qualit\u233? est principalement utile lors de l'animation de groupes de travail.
Lors d'une telle r\u233?union, un analyste doit \u234?tre capable de maintenir la
motivation, de laisser chacun s'exprimer, de cadrer et de recadrer pour rester
align\u233? sur les objectifs, de r\u233?soudre les conflits, de maintenir la bonne
humeur, de permettre aux plus timides de s'exprimer, et de canaliser les plus
bavards. Comme les qualit\u233?s d'\u233?coute, les qualit\u233?s relationnelles
sont grandement d\u233?pendantes du talent et de la personnalit\u233? de
l'analyste. Et comme pour l'\u233?coute, une bonne pr\u233?paration et des
techniques d'animation peuvent pallier le manque d'exp\u233?rience. L'observation
Une des nombreuses mani\u232?res de recueillir les besoins consiste \u224? observer
les personnes en train de travailler, dans leur milieu professionnel. Mais le don
d'observation est utile \u224? tout moment. Lors d'une interview, il est utile
d'observer comment l'interlocuteur r\u233?agit, et comment les participants \u224?
une r\u233?union interagissent et communiquent entre eux ; tout noter, sur le
papier ou dans sa t\u234?te, sous forme \u233?crite ou sous forme de croquis.
Parfois, deux yeux et deux oreilles ne suffisent pas, et lors de certaines r\u233?
unions un coanimateur peut \u234?tre utile. La cr\u233?ativit\u233? L'analyste des
exigences n'est pas toujours un \u234?tre neutre et incolore. Il est l\u224? pour
aider le client et l'utilisateur \u224? d\u233?finir, pr\u233?ciser et formaliser
le besoin. Mais le futur produit peut aussi contenir des caract\u233?ristiques
nouvelles auxquelles le client seul ne pensera jamais. L'analyste ou le consultant,
qui est en contact avec des clients parfois tr\u232?s diff\u233?rents, peut, et
doit, apporter des id\u233?es nouvelles. Il peut adaptera un domaine des id\u233?es
tir\u233?es d'un autre domaine. Par exemple, l'exigence fonctionnelle < relancer p\
u233?riodiquement les prospects \u187? d'un\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie logiciel commercial peut \u234?tre adapt\u233?e \u224?
un logiciel de cabinet dentaire pour relancer les patients. Ce sera ensuite aux
futurs utilisateurs (en l'occurrence, les dentistes) de dire si cette id\u233?e est
\u224? conserver. Encore faut-il que cette id\u233?e soit propos\u233?e. Si tous
les concepteurs se contentaient d'\u233?couter < la voix du client \u187?, il n'y
aurait que tr\u232?s peu d'innovations. Cela est particuli\u232?rement le cas des
clients qui sont des utilisateurs exp\u233?riment\u233?s d'un produit existant.
Souvent, ils demandent \u224? ce que le nouveau produit fasse < la m\u234?me
chose \u187? que le pr\u233?c\u233?dent, mais en mieux. Il faut \u234?tre capable
de leur proposer le < mieux \u187?, qui peut aller du simple lifting de l'interface
graphique \u224? des am\u233?liorations fonctionnelles cons\u233?quentes. L'esprit
d'analyse et de synth\u232?se Un cahier des charges est une arborescence
d'exigences. Il faut \u234?tre capable de travailler sur les branches de haut
niveau pour d\u233?finir les grandes fonctions, puis descendre dans le d\u233?tail
de chacune jusqu'aux branches les plus fines, sans se perdre, puis remonter \u224?
nouveau pour donner une vision globale au donneur d'ordres. Tout cela doit \u234?
tre fait avec un \u171? scalpel mental \u187? \u224? la main, qui va permettre de
s\u233?parer ce qui appartient \u224? l'univers des exigences (\u224? conserver
dans un cahier des charges) de ce qui est de l'ordre de la solution (\u224? manier
avec pr\u233?caution). L'analyste des exigences doit \u233?galement poss\u233?der
une sorte d'alarme int\u233?rieure qui le pr\u233?vient de toutes les
contradictions entre exigences (son bon relationnel doit l'aider \u224? \u233?viter
que ces contradictions se transforment en conflits de personnes) et un \u171? d\
u233?tecteur de flou \u187?, ou plut\u244?t une aversion caract\u233?ris\u233?e
pour les formulations floues, ambigu\u235?s, aux interpr\u233?tations multiples. La
clart\u233? Le m\u233?tier d'expression des exigences est un m\u233?tier de
communication. Pour faire passer des messages entre client et fournisseur, et aussi
entre utilisateurs de m\u233?tiers diff\u233?rents, il est donc primordial de
s'exprimer avec aisance et clart\u233?, oralement et par \u233?crit. L'ing\u233?
nieur des exigences utilise toute une palette d'outils : la parole dans un premier
temps, puis le langage \u233?crit ou graphique. Dans tous les cas, il doit utiliser
le moins de jargon possible. Ouand un mot nouveau ou \u171? barbare \u187?2
(c'est-\u224?-dire, appartenant au m\u233?tier de \u171? l'autre \u187?, et qui n'a
pas la m\u234?me signification pour toutes les parties prenantes) doit appara\u238?
tre dans le discours, il doit devenir p\u233?dagogue et clarifier le concept.
L'analyste des exigences doit manier plusieurs langages. Le langage parl\u233? et \
u233?crit en est un et occupe une place pr\u233?pond\u233?rante. Mais il existe 0
2. \u9632? Chacun appelle barbarie ce qui n'est pas de son usage \u9632?,
Montaigne.\par\pard\plain\hyphpar} {
Chapitre 3 - Comp\u233?tences et savoir-faire de nombreux langages graphiques, plus
ou moins adapt\u233?s aux interlocuteurs des diff\u233?rentes parties prenantes. Il
doit savoir les manier avec discernement. Certaines personnes, de par leur
profession, sont tr\u232?s familiaris\u233?es avec le langage graphique. C'est le
cas des ing\u233?nieurs. D'autres professions, comme les juristes, pr\u233?f\u232?
rent l'\u233?crit. Un sch\u233?ma qui para\u238?tra limpide \u224? l'un pourra \
u234?tre abscons pour l'autre. Il en est de m\u234?me des tableaux. Repr\u233?
senter les informations sous forme tabulaire va souvent de soi pour un ing\u233?
nieur ou un comptable, moins pour un juriste. Inversement, d\u233?aire un processus
op\u233?rationnel au moyen d'un long discours \u233?crit peut couler de source pour
un homme de loi et rebuter un ing\u233?nieur qui a besoin de s'appuyer sur des sch\
u233?mas pour faciliter sa compr\u233?hension. Ces diff\u233?rences culturelles
doivent \u234?tre imp\u233?rativement respect\u233?es si l'on veut \u233?viter les
incompr\u233?hensions, voire les conflits.\par\pard\plain\hyphpar} {
Chapitre 4 Exigences et cycle de vie du logicie Dans ce chapitre, nous allons
situer les activit\u233?s de l'ing\u233?nierie des exigences dans le cycle de vie
du logiciel. Cela va nous permettre de prendre la mesure de l'importance de ces
activit\u233?s, et de mieux comprendre les r\u244?les et responsabilit\u233?s des
diff\u233?rents acteurs, ainsi que ceux du ma\u238?tre d'oeuvre, du ma\u238?tre
d'ouvrage, et de l'analyste et de leurs engagements r\u233?ciproques. Le cycle de
vie du logiciel Il existe plusieurs fa\u231?ons de repr\u233?senter le cycle de vie
du logiciel. Le terme de cycle est d'ailleurs souvent utilis\u233? abusivement.
Voici (source : IEEE Std 982.2-1988) un mod\u232?le de cycle de vie en huit
phases : \u8226? Objectifs et concepts : d\u233?finition des objectifs du produit \
u224? construire, et premi\u232?re vision du logiciel. \u8226? Exigences : recueil,
analyse et formalisation des besoins, \u233?laboration du cahier des charges. \
u8226? Conception : sp\u233?cifications d\u233?taill\u233?es fonctionnelles et
techniques, en fonction des objectifs et des exigences pr\u233?c\u233?demment d\
u233?finis. \u8226? R\u233?alisation : programmation et tests unitaires. \u8226?
Tests et validation : tests fonctionnels, d'int\u233?gration et validation. \u8226?
Installation : mise en \u339?uvre op\u233?rationnelle et d\u233?ploiement. \u8226?
Exploitation et maintenance : mise \u224? disposition aupr\u232?s des utilisateurs.
\u8226? Retrait : arr\u234?t de l'exploitation, \u233?ventuellement migration vers
un autre logiciel ou nouvelle version du m\u234?me logiciel. Ce cycle en huit
phases est v\u233?ritablement circulaire, ce qui permet de prendre conscience que.
dans la vraie vie. un logiciel arrive rarement sur\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie un terrain vide, et ne laisse pas souvent un vide en
partant (figure 4-1). Bien avant de mettre un logiciel hors service, on se pr\u233?
occupe de son successeur. C'est en g\u233?n\u233?ral l'occasion de red\u233?finir
le concept et les objectifs, ainsi que les exigences qui en d\u233?coulent. Retrait
_^ Objectifeet .concepts Exploitation et maintenance / \'5c \'5c ExlQenoes
Installation et \'5c * / conception d\u233?ploiement . ^.^ ., R\u233?alisation et
validation Figure 4-1 : Le cycle de vie, mod\u232?le IEEE 982.2 Ce cycle en huit
phases donne, bien s\u251?r, une vision sch\u233?matique de la r\u233?alit\u233?
(c'est pr\u233?cis\u233?ment ce qui est demand\u233? \u224? un mod\u232?le). Dans
la pratique, les phases ne sont \u233?gales ni en temps ni en co\u251?ts, et elles
ne sont pas s\u233?par\u233?es par des cloisons \u233?tanches. Entre deux versions
d'un m\u234?me logiciel, ou entre un logiciel et son successeur, on peut constater
un retard de plusieurs phases. Il n'est pas rare que. pendant qu'un logiciel est
encore en validation, on d\u233?finisse d\u233?j\u224? les besoins de son
successeur. Ma\u238?tres d'ouvrage et ma\u238?tres d'oeuvre Le cycle de vie ainsi
repr\u233?sent\u233? nous permet de visualiser les relations et le partage des
responsabilit\u233?s entre parties prenantes. Le ma\u238?tre d'ouvrage est celui
qui demande, sp\u233?cifie, paie ou utilise le syst\u232?me, ou plus g\u233?n\u233?
ralement en tire un b\u233?n\u233?fice. Le ma\u238?tre d'oeuvre est celui qui le
con\u231?oit, le r\u233?alise, le met en \u339?uvre. Si on examine le cycle de vie
du logiciel au regard de cette distribution des r\u244?les (figure 4-2), on s'aper\
u231?oit que le ma\u238?tre d'ouvrage (ou client) est responsable de < l'h\u233?
misph\u232?re nord \u187? du cycle et que le ma\u238?tre d'ceuvre\par\pard\plain\
hyphpar} {
Chapitre 4 - Exigences et cycle de vie du logiciel occupe < l'h\u233?misph\u232?re
sud \u187?. On a donc, dans la partie haute du cycle, ceux qui d\u233?finissent et
utilisent le quoi. Et dans la partie basse, ceux qui sont responsables du comment.
Les strat\u232?ges, ceux qui d\u233?cident de ce que sera, dans ses tr\u232?s
grandes lignes, un nouveau produit, sont au p\u244?le nord du cycle. Les experts,
qui ma\u238?trisent dans le d\u233?tail les techniques pointues, sont au sud.
Retrait I\u8212? Les strat\u232?ges Objectifs et concepts Exploitation et
maintenance Installation et d\u233?ploiement Conception Tests et validation R\u233?
alisation 1\u8212? Les experts Figure 4-2 : Cycle de vie et partage des r\u244?les
Bien entendu, une m\u234?me personne peut, au cours de sa carri\u232?re, se trouver
alternativement client ou fournisseur. Mais au cours d'un m\u234?me projet, les r\
u244?les sont en principe s\u233?par\u233?s, ainsi que les mani\u232?res de
travailler. \u192? la fronti\u232?re de ces deux mondes se trouve le cahier des
charges, qui devient ainsi un contrat entre deux parties. De la qualit\u233? de ce
document d\u233?pendra grandement la bonne coop\u233?ration entre client (ma\u238?
trise d'ouvrage, donneur d'ordres) et fournisseur (\u233?diteur, int\u233?grateur,
vendeur). Entre ma\u238?trise d'ouvrage et ma\u238?trise d'oeuvre, il y a souvent
des difficult\u233?s de compr\u233?hension, dues \u224? des diff\u233?rences de m\
u233?tier et de langage. De ce fait, la tentation est grande de livrer un cahier
des charges qui contient du flou, des zones d'ombre, destin\u233?es \u224? pallier
les difficult\u233?s de compr\u233?hension. C'est ce qui arrive souvent, et ne fait
que repousser le probl\u232?me : les difficult\u233?s reviennent \u224? la surface
au moment de la livraison, g\u233?n\u233?rant des tensions, voire des conflits.\
Partie 1 - M\u233?thodologie B\u226?tisseurs et exploitants Le cycle de vie du
logiciel peut \u234?tre d\u233?coup\u233? verticalement. La partie droite est celle
des b\u226?tisseurs, qui imaginent, con\u231?oivent, r\u233?alisent. La partie
gauche est celle des exploitants, qui installent, exploitent, maintiennent. Entre
ces deux populations, c'est surtout la motivation qui est diff\u233?rente. Les b\
u226?tisseurs sont attir\u233?s vers le nouveau, imaginent toutes les possibilit\
u233?s, veulent cr\u233?er. La motivation des exploitants est la continuit\u233? et
la r\u233?gularit\u233? du fonctionnement, et la correction des erreurs et
anomalies. Pour cela, ils s'appuient sur des proc\u233?dures rigoureuses. Ici
aussi, il faut trouver un langage commun entre les diff\u233?rentes populations.
Retrait Objectifs et concepts Exploitation et maintenance Installation et d\u233?
ploiement Exigences Conception Tests et validation Figure 4-3 : Cycle de vie et r\
u233?partition des m\u233?tiers R\u233?alisation La phase cf exigences La phase
d'exigences sera d\u233?crite tr\u232?s en d\u233?tail dans les chapitres qui
suivent. Elle comporte les activit\u233?s et t\u226?ches suivantes : \u8226?
identifier les diff\u233?rents profils utilisateurs de l'application ; \u8226?
recueillir les besoins de chaque profil utilisateur ; \u8226? analyser les besoins
des utilisateurs, en \u233?liminer les incoh\u233?rences et les redondances ; \
u8226? traduire les besoins exprim\u233?s oralement en sp\u233?cifications ; \
u8226? aligner la sp\u233?cification des exigences (le cahier des charges) aux
objectifs d\u233?finis par le ma\u238?tre d'ouvrage ; \u8226? assurer la compl\
u233?tude du cahier des charges ;\par\pard\plain\hyphpar} {
Chapitre 4 - Exigences et cycle de vie du logiciel \u8226? d\u233?terminer, avec le
ma\u238?tre d'ouvrage et les utilisateurs, la priorit\u233? relative de chaque
exigence et son niveau de flexibilit\u233? (obligatoire, facultatif) ; \u8226?
faire valider par le ma\u238?tre d'ouvrage les exigences sp\u233?cifi\u233?es.
Comme on le voit sur la figure 4-4, la phase d'exigences fait partie de la
construction du logiciel ou du syst\u232?me, et elle est sous la responsabilit\
u233? du ma\u238?tre d'ouvrage. Retrait , ?^t\u171? Objectifs formalis\u233?s
Exploitation et j^mm^^\'5c maintenance / ^JBaMHBk Ex*9ences Cahier des charges
valid\u233? Installation et \'5c /Conception d\u233?ploiement ^ JUS? ' R\u233?
alisation et validation Figure 4-4 : La phase d'exigences dans le cycle de vie Dans
la pratique, le travail de l'analyste va au-del\u224? de la phase d'exigences
proprement dite. Il est fr\u233?quent que les concepts et les objectifs du logiciel
ne soient pas clairement d\u233?finis et ce sera \u224? l'analyste des exigences de
les formaliser et de les faire valider. Et, bien que cela d\u233?passe le strict
cadre du cahier des charges, l'analyste s'aventure souvent dans la zone floue entre
les exigences et la conception. Les engagements r\u233?ciproques L'\u233?laboration
du cahier des charges est sous la responsabilit\u233? d'une personne, l'analyste
des exigences, souvent appel\u233? assistant \u224? la ma\u238?trise d'ouvrage. \
u201?tant donn\u233? l'importance du cahier des charges, son r\u244?le est crucial,
et devrait \u233?galement \u234?tre r\u233?gi par un contrat, entre son client et
lui. C'est souvent un contrat moral, mais il gagne \u224? \u234?tre mis par \u233?
crit. Un consultant pourra int\u233?grer ces engagements r\u233?ciproques \u224?
une proposition commerciale d'\u233?laboration d'un cahier des charges. Cependant,
m\u234?me sans aucun \u233?crit de part et d'autre, l'analyste des exigences a
tout\par\pard\plain\hyphpar} {
ie 1 - M\u233?thodologie int\u233?r\u234?t \u224? conna\u238?tre la liste de ces
engagements, et de s'y tenir. Il devra \u233?galement mettre son client face \u224?
ses responsabilit\u233?s. Voici un mod\u232?le d'engagements r\u233?ciproques : j\
u239?m\u202?S\u202?Bj\u224?r seftNmi^ pratiques, s'exprimer en iitilte informer son
cfientde ra>\u171?rH\u187?merrt Ai (ahier des charges, tenk son dieirt Inform\u233?
des r^ sp\u233?dfto les besoiiK en termes ais\u233?mert cboisir les tedira\u251?^
animer tirted\u233?iiardie collabos an\u239?merW apporter des id\u233?es nouvelles,
dans le respect de cette neutralit\u233?, estimertecriai^ dans les r\u232?gles d\
u233?fait un losi\u201?iel d\u233? qualit\u233?. respecter la d\u233?marche
d'expression des besoins mise en place, irn\u226?ter les parties pienarrtes \u224?
pan^per^ inforrr^leednsurtart^ exprimer les besoins avec ^^ . lever les ambigu\
u239?t\u233?s sur texpression d'un besoin, indiquer les priorit\u233?s sur les
exigences exprim\u233?es, respecterles estimatwns faites par le consultant ou
l'expert varies documents intemi^ vaKtoie cahier des charges. Les engagements de
l'analyste peuvent faire fonction de charte de d\u233?ontologie. Les engagements du
ma\u238?tre d'ouvrage, m\u234?me s'ils ne sont pas formalis\u233?s, peuvent servir
de check-list au ma\u238?tre d'ouvrage. Pour l'analyste, c'est la check-list de ce
qu'il peut l\u233?gitimement demander \u224? son client. O\par\pard\plain\hyphpar}
{
Chapitre 5 La d\u233?marche Pour \u234?tre efficace, la d\u233?finition des
exigences doit devenir une activit\u233? syst\u233?matique et organis\u233?e,
faisant appel \u224? des acteurs dont les relations sont formalis\u233?es ; en
d'autres termes, une activit\u233? d'ing\u233?nierie. Dans le chapitre pr\u233?c\
u233?dent, nous avons vu comment cette activit\u233? s'ins\u232?re dans le cycle de
vie du logiciel. Nous allons maintenant rentrer un peu plus dans le d\u233?tail et
d\u233?crire globalement le processus de d\u233?veloppement des exigences. D\u233?
crire, documenter, communiquer Tout au long de cet ouvrage, nous d\u233?crivons des
techniques qui. regroup\u233?es, s'appellent ing\u233?nierie des besoins ou ing\
u233?nierie des exigences. Voil\u224? une belle expression, mais dans quelle mesure
le terme d'ing\u233?nierie est-il justifi\u233? ? Recueillir, analyser, sp\u233?
cifier les besoins sont en grande partie des actions de description. Il s'agit de
d\u233?crire un besoin en le formulant pour la premi\u232?re fois, en le
reformulant diff\u233?remment, de mani\u232?re plus claire, plus constructive, plus
coh\u233?rente ; en le montrant sous diff\u233?rents angles, comme un dessin
d'architecte montre un b\u226?timent selon des vues diff\u233?rentes ; en le
formulant dans un langage que tous (en tout cas tous ceux qui ont besoin de cette
description), comprennent et interpr\u232?tent de la m\u234?me fa\u231?on. D\u233?
composer un ensemble de besoins en sous-ensembles plus petits, de mani\u232?re
arborescente, le d\u233?crire sous diff\u233?rents aspects va immanquablement g\
u233?n\u233?rer beaucoup de documentation. Il s'agit l\u224? d'un aspect
fondamental de ce m\u233?tier. Nous devons g\u233?rer des masses d'informations et
les pr\u233?senter de mani\u232?re coh\u233?rente. Il faudra \u233?galement
maintenir cette coh\u233?rence dans le temps, g\u233?rer cette \u233?volution. La
gestion des versions et des changements fait partie du m\u233?tier.\par\pard\plain\
hyphpar} {
Partie 1 - M\u233?thodologie Toutes ces informations devront \u234?tre partag\u233?
es par tous ces acteurs. La d\u233?finition des besoins est donc aussi une activit\
u233? de communicalion. Cette communication se fait bien s\u251?r dans les deux
sens : \u233?coute et sp\u233?cification. Nous avons dans ce triptyque l'essence du
m\u233?tier d'analyste : d\u233?crire, documenter, communiquer (figure 5-1 ).
Communiquer Documenter \'5c / D\u233?crire Figure 5-1 : L'essence de notre m\u233?
tier Les diff\u233?rents niveaux d'exigences Les activit\u233?s de recueil,
d'analyse, de sp\u233?cification et de validation des exigences peuvent se faire \
u224? plusieurs niveaux : . : \u8226? Les objectifs strat\u233?giques1 fix\u233?s
par la direction g\u233?n\u233?rale ou par le don- '. i, ,. ,r neur d'ordres, et
dont le recueil et la formalisation demandent un soin chapitre o. ,. particulier. \
u8226? Les exigences de haut niveau, li\u233?es \u224? l'organisation (en anglais
business requirements). d\u233?coulant directement des objectifs ou de contraintes
organis\u226?t ion nel les ou r\u233?glementaires. \u8226? Les exigences de niveau
interm\u233?diaire correspondent au point de vue d'un utilisateur (en anglais user
requirements) : exigences comportementales, cas d'utilisation, exigences de qualit\
u233?. \u8226? Les exigences \u233?l\u233?mentaires (en anglais atomic
requirements), qui d\u233?crivent sous forme de phrases simples (du type \u171? le
syst\u232?me doit... \u187?) des exigences fonctionnelles ou non fonctionnelles,
des contraintes, d'ordre technique ou autre, ou des exigences d'interface. Cette
classification (qui peut varier selon les mod\u232?les de cahiers des charges)
permet de structurer la sp\u233?cification en \u171? couches \u187? d'exigences de
plus en plus d\u233?taill\u233?es (figure 5-2). Les exigences \u224? un niveau
doivent \u234?tre align\u233?es aux exigences de niveau sup\u233?rieur. 0\par\pard\
plain\hyphpar} {
Chapitre 5 - La d\u233?marche Les exigences de haut niveau (les objectifs) feront
l'objet d'un document particulier, qui pourra \u234?tre repris dans le cahier des
charges. En fonction de sa destination, le c\u339?ur du cahier des charges
descendra plus ou moins dans les d\u233?tails. Par exemple, un cahier des charges
destin\u233? \u224? d\u233?velopper un logiciel contiendra plus d'exigences d\u233?
taill\u233?es qu'un cahier des charges pour le choix d'un progiciel sur \u233?tag\
u232?re. /ObjectlfsX / Exigences \'5c / d'entreprise ou \'5c /
organisationnelies \'5c / Cas d'utilisation, exigences \'5c normatives et r\u233?
glementaires, r\u232?gles d'interop\u233?rabilit\u233?, de s\u233?curit\u233?....
Exigences \u233?l\u233?mentaires fonctionnelles et non fonctionneHes. contraintes,
exigences d'interface Figure 5-2 : Niveaux d'exigences Les \u233?tapes de l'\u233?
laboration \u201?laborer un cahier des charges consiste donc avant tout \u224?
traduire des besoins flous, impr\u233?cis, et parfois inconnus, en exigences
structur\u233?es et organis\u233?es : \u224? les traduire donc, depuis le langage
du client en un langage compr\u233?hensible de tous (client, fournisseur et
observateurs ext\u233?rieurs). Pr\u233?sentons les diff\u233?rentes t\u226?ches qui
vont du recueil des besoins au cahier des charges. La premi\u232?re t\u226?che
consiste \u224? d\u233?couvrir les enjeux, les objectifs, et les contraintes du
projet. Les enjeux constituent la raison profonde du lancement d'un projet, les
intentions derri\u232?re les objectifs. Certains enjeux seront clairs et pourront \
u234?tre exprim\u233?s dans le pr\u233?ambule du cahier des charges. D'autres
enjeux pourront \u234?tre cach\u233?s (ambitions personnelles, projet inavou\u233?
de d\u233?passer un concurrent). Ou'ils soient publics ou tenus secrets, ils
devront \u234?tre analys\u233?s, pris en compte. Les objectifs, eux. devront \u234?
tre formalis\u233?s. Ils constituent les exigences de plus haut niveau. Les
contraintes ne sont qu'une forme particuli\u232?re d'exigences, pr\u233?sent\u233?
es \u171? en creux \u187?. Une t\u226?che importante consiste \u224? identifier les
diff\u233?rents acteurs du projet (les parties prenantes, en particulier les repr\
u233?sentants des futurs utilisateurs), \u224? conna\u238?tre les enjeux les plus
importants pour chacun d'eux, \u224? \u233?tablir un dialogue, \u224? les faire
participer au projet d'\u233?laboration. \u8364?D\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie Recueillir les besoins est une t\u226?che beaucoup
plus complexe qu'il n'y para\u238?t. Les besoins sont rarement \u224? la surface du
sol2. Ils sont en g\u233?n\u233?ral cach\u233?s, et diverses techniques permettent
de les \u171? d\u233?terrer \u187? : les r\u233?unions de travail, les interviews
des utilisateurs, l'observation directe, la lecture de documents (y compris
d'autres cahiers des charges). Il n'y a pas de technique plus efficace qu'une
autre, tout d\u233?pend du contexte, et c'est une combinaison de techniques qui
permettra un recueil complet. Ainsi recueillies, les exigences seront analys\u233?
es. Analyser les exigences, c'est les faire passer par des < filtres \u187?, les
examiner pour d\u233?tecter les exigences manquantes, contradictoires, les incoh\
u233?rences \u224? divers niveaux. Une analyse efficace des exigences permet de
toujours rester au meilleur niveau de d\u233?tail. Le niveau de d\u233?tail n\u233?
cessaire d\u233?pend des intentions du projet. Par exemple, on n'exprimera pas le
m\u234?me niveau de d\u233?tails pour un projet de d\u233?veloppement sp\u233?
cifique et un choix de logiciel sur \u233?tag\u232?re. De plus, il faudra \u233?
tablir des priorit\u233?s entre exigences. Il va falloir ensuite r\u233?diger les
exigences, g\u233?n\u233?ralement sous forme de cahier des charges. La forme peut \
u234?tre textuelle ou graphique. Il n'y a pas de forme a priori meilleure qu'une
autre. Tout d\u233?pend de celui qui va lire le cahier des charges, l'important \
u233?tant de donner une vision et une compr\u233?hension partag\u233?es des
exigences. La repr\u233?sentation graphique fait appel \u224? des techniques de
mod\u233?lisation des donn\u233?es ou des traitements informatiques. Vu du r\u233?
dacteur, le cahier des charges n'est qu'un lieu de stockage des exigences. Mais les
exigences \u233?voluent. G\u233?rer les \u233?volutions fait \u233?galement partie
de ce qu'il est convenu d'appeler l'ing\u233?nierie des exigences. \u192? un
instant donn\u233?, une version du cahier des charges peut \u234?tre en cours
d'utilisation (par les \u233?quipes de concepteurs, par exemple), une autre en
cours d'\u233?laboration. Ce sont alors des techniques de gestion des versions et
de la configuration qui seront utilis\u233?es. Enfin, les exigences devront \u234?
tre valid\u233?es par les diff\u233?rentes parties prenantes. Cette validation se
fait \u224? plusieurs niveaux. Les futurs utilisateurs valideront souvent au fur et
\u224? mesure de la r\u233?daction, le donneur d'ordre validera g\u233?n\u233?
ralement l'ensemble du document. Le suivi de la validation des exigences n'est donc
pas une t\u226?che facile. Description formelle du processus global Formellement,
l'ing\u233?nierie des exigences comporte deux types d'activit\u233?s : \u8226? le
d\u233?veloppement des exigences, qui consiste \u224? d\u233?finir les besoins et \
u224? \u233?laborer un cahier des charges ; CD 2. En anglais, le terme utilis\u233?
pour le recueil est eli\u224?tation. Il peut se traduire par \u171?extraction*\par\
Chapitre 5 - La d\u233?marche \u8226? la gestion des exigences, qui consiste \u224?
g\u233?rer les changements et les \u233?volutions des exigences dans le temps. Le
d\u233?veloppement des exigences comporte quatre \u233?tapes tr\u232?s fortement
imbriqu\u233?es selon un processus cyclique : \u8226? le recueil, qui consiste \
u224? faire exprimer les besoins et \u224? rechercher les besoins d\u233?j\u224?
exprim\u233?s ; \u8226? l'analyse, qui consiste \u224? examiner les exigences sous
diff\u233?rentes facettes, et \u224? maintenir la coh\u233?rence entre les
exigences ; \u8226? la sp\u233?cification, qui consiste \u224? d\u233?crire et
documenter les exigences de mani\u232?re \u224? la fois formelle et compr\u233?
hensible par toutes les parties prenantes -. \u8226? la validation, qui consiste \
u224? obtenir, de la part de toutes les parties prenantes, un accord formel sur les
exigences sp\u233?cifi\u233?es. Comme on peut le voir, il y a des boucles de r\
u233?troaction entre les quatre activit\u233?s. Recueil f \u9830? ! Analyse 1 Sp\
u233?cification \u9830? Validation \u8226?CdC Figure 5-3 : Le processus global Le
d\u233?coupage en quatre \u233?tapes permet de mieux comprendre le m\u233?tier de
d\u233?finition des exigences. En pratique, ces \u233?tapes sont imbriqu\u233?es
dans le temps, chaque \u233?tape contenant une partie des autres. Par exemple, lors
d'une m\u234?me entrevue avec un utilisateur du futur produit (activit\u233? de l'\
u233?tape de recueil), on peut \u233?couter les besoins (recueil), tenter de
comprendre comment ce besoin se rattache aux objectifs de la direction (analyse),
essayer de reformuler le besoin de mani\u232?re claire (sp\u233?cification) et
demandera l'utilisateur son opinion sur cette formulation (validation). Le
processus en pratique Nous avons vu qu'en pratique les quatre activit\u233?s de
recueil, d'analyse, de sp\u233?cification et de validation, ne sont ni lin\u233?
aires ni bien distinctes. \u192? ces quatre activit\u233?s s'ajoute la gestion
des \u233?volutions des exigences, qui en r\u233?alit\u233? commence d\u232?s le d\
u233?but du recueil. S'y ajoute une activit\u233? en amont de d\u233?finition des
objectifs (en toute rigueur, c'est une phase O\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie 3. Voir au chapitre 16 un mod\u232?le de pro- pr\u233?
c\u233?dente du cycle de vie, mais dans tous les cas, elle devra \u234?tre d\u233?
clin\u233?e pendant la phase d'exigences). Et, cela va sans dire, une activit\u233?
transverse de gestion de projet. Il n'existe cependant pas un mod\u232?le unique de
processus3, autrement dit aucune < recette de cuisine \u187? qui nous indiquerait
les t\u226?ches \u224? mener \u224? \u244?mqît\u249?t\u232?tie cnaclue \u233?laPe-
et dans ûel ordre- adapt\u233?. Chaque projet est diff\u233?rent, et la premi\
u232?re t\u226?che de l'\u233?quipe charg\u233?e de d\u233?finir les besoins
consiste \u224? ajuster le processus de d\u233?finition aux contraintes propres au
projet. Ce qui est cependant certain, et v\u233?rifi\u233? dans la pratique, c'est
que les \u233?tapes en amont (la pr\u233?paration), si elles sont bien men\u233?es,
facilitent grandement la d\u233?finition des besoins proprement dite (la production
du cahier des charges). En d'autres termes, d\u233?finir les besoins devrait \u234?
tre une activit\u233? < descendante \u187? [lop-down) dont les \u233?tapes sont les
suivantes : \u8226? \u201?tapes en amont (pr\u233?paration de l'\u233?laboration du
cahier des charges) : - d\u233?finir le concept et pr\u233?ciser les objectifs, -
analyser les parties prenantes : r\u244?les, responsabilit\u233?s. - d\u233?finir
les cat\u233?gories (classes) d'utilisateur. - s\u233?lectionner, dans chaque cat\
u233?gorie, les repr\u233?sentants des utilisateurs. - choisir, en fonction du
contexte et des contraintes, les techniques de recueil \u224? mettre en place, - d\
u233?finir les contours du futur produit (p\u233?rim\u232?tre). - d\u233?finir
les \u233?changes entre le futur produit (vu comme une bo\u238?te noire) et le \
u171? monde ext\u233?rieur \u187?, - identifier les cas d'utilisation m\u233?tier
[business use cases), - \u233?tablir des priorit\u233?s entre cas d'utilisation, -
s\u233?lectionner les cas d'utilisation qui seront informatis\u233?s. \u8226? \
u201?tapes de d\u233?finition des besoins (production du cahier des charges) : - d\
u233?crire les cas d'utilisation. - d\u233?crire les exigences non fonctionnelles,
- d\u233?crire les contraintes. - mod\u233?liser les donn\u233?es. - d\u233?finir
les exigences fonctionnelles, - passer en revue les sp\u233?cifications
d'exigences. - d\u233?velopper, si n\u233?cessaire, des maquettes. - d\u233?
velopper, si n\u233?cessaire, des prototypes d'une partie du futur syst\u232?me. O\
Chapitre 5 - La d\u233?marche - sp\u233?cifier pr\u233?cis\u233?ment les exigences
fonctionnelles dans le cahier des charges, - faire valider le cahier des charges. \
u8226? \u201?tapes transverses : - g\u233?rer les demandes de changement des
exigences, - g\u233?rer l'\u233?quipe de d\u233?finition des exigences, - planifier
et g\u233?rer les groupes de travail de recueil, d'analyse ou de validation des
exigences. - g\u233?rer le projet (co\u251?ts, d\u233?lais, relation avec le
donneur d'ordres). Check-list La liste des t\u226?ches \u224? effectuer vue au
paragraphe pr\u233?c\u233?dent peut servir de check-list Iorsde l'\u233?
tablissement d'un plan-projet pour l'\u233?laboration d'un cahier des charges.\par\
Chapitre 6 D\u233?finir le concept et les objectiFs Cette \u233?tape pr\u233?alable
de d\u233?finition du concept et des objectifs est cruciale pour la suite. C'est un
miniprocessus de d\u233?finition des exigences, en plus dense, plus rapide, et au
plus haut niveau. Son livrable est une sorte de cahier des charges en concentr\
u233?. Il conditionne la r\u233?ussite du projet. Elle doit donc \u234?tre men\
u233?e avec le plus grand soin. Une activit\u233? pr\u233?alable indispensable La
premi\u232?re activit\u233? \u224? laquelle doit s'attaquer l'\u233?quipe en charge
de d\u233?finir les besoins consiste \u224? d\u233?finir le concept et ses
objectifs du produit, les objectifs du cahier des charges lui-m\u234?me, ainsi que
les exigences au plus haut niveau. Ces t\u226?ches seront men\u233?es en parall\
u232?le, car elles sont pratiquement indissociables. En effet, elles permettent de
r\u233?pondre aux quatre questions suivantes : \u8226? Concept du produit : en quoi
consistera le produit ? De quoi sera-t-il fait ? En quoi se distinguera-t-il des
produits existants, qu'ils soient concurrents ou compl\u233?mentaires ? \u8226?
Objectifs du produit : quelle utilisation sera faite du produit ? Dans quel but ?
Pour servir qui ? Pour servir \u224? quoi ? Pour gagner quoi ? \u8226? Objectifs du
cahier des charges : que veut-on faire du cahier des charges ? Choisir un produit
sur \u233?tag\u232?re, d\u233?velopper une application sp\u233?cifique, acqu\u233?
rir un progiciel, le param\u233?trer et le d\u233?ployer ? \u8226? 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\
u233?, performance) auxquelles le produit doit r\u233?pondre en priorit\u233? ?
Quelles seront \u233?ventuellement les contraintes techniques incontournables ?\
Partie 1 - M\u233?thodologie Cette \u233?tape fait d\u233?j\u224? appel aux
techniques classiques de recueil, d'analyse, de sp\u233?cification et de validation
des exigences, mais \u233?tant donn\u233? son caract\u232?re strat\u233?gique, nous
d\u233?crivons ces techniques sp\u233?cifiquement adapt\u233?es \u224? cette \u233?
tape pr\u233?paratoire plus en d\u233?tail dans les paragraphes qui suivent.
Objectifs, p\u233?rim\u232?tre et parties prenantes 1. Cadrage La litt\u233?rature
anglophone parle de document de \u171? vision et port\u233?e \u187? (vision and
scope). Lors de cette \u233?tape pr\u233?alable1, il s'agit de d\u233?finir : \
u8226? l'objectif; \u8226? le p\u233?rim\u232?tre, ou champ de l'\u233?tude ; \
u8226? les parties prenantes. Par parties prenantes nous entendons toutes les
personnes ou organisations impact\u233?es (positivement ou n\u233?gativement) par
l'introduction du syst\u232?me ou susceptibles d'influencer son choix, son d\u233?
veloppement ou son d\u233?ploiement. Ces trois activit\u233?s sont fortement
interd\u233?pendantes (figure 6-1). Toutes les exigences formalis\u233?es devront \
u234?tre align\u233?es sur l'objectif pr\u233?c\u233?demment d\u233?fini. Mais qui
va exprimer l'objectif ? En grande partie, le donneur d'ordres. Cependant, en tant
que personne physique, il va rarement exprimer un objectif de mani\u232?re
formelle. Il s'appuiera sur des experts, il devra tenir compte d'autres parties
prenantes (actionnaires, associations, syndicats, soci\u233?t\u233?s savantes...).
Or, l'influence de ces parties prenantes sur l'objectif d\u233?pend du p\u233?rim\
u232?tre. Figure 6-1 : Trois activit\u233?s pr\u233?alables indissociables Ces
trois activit\u233?s sont pr\u233?sent\u233?es dans les paragraphes qui suivent. Le
document r\u233?sultant de ces activit\u233?s est un document de cadrage. in\par\
Chapitre 6 - D\u233?pnir le concept et les objectifs Recueillir les objectiFs Les
objectifs : des exigences au plus haut niveau Les objectifs du syst\u232?me (\u224?
choisir, \u224? d\u233?velopper ou \u224? mettre en \u339?uvre) ne sont rien de
plus que des exigences de haut niveau. Voici un exemple d'objectif, pour un
logiciel de prescription de m\u233?dicaments : Assurer la s\u233?curit\u233?, la
tra\u231?abilit\u233? et la qualit\u233? des prescriptions conform\u233?ment \u224?
l'arr\u234?t\u233? du 31 mars 1999. Cet objectif contient en r\u233?alit\u233?
trois exigences de tr\u232?s haut niveau (s\u233?curit\u233?, tra\u231?abilit\u233?
et qualit\u233? des prescriptions de m\u233?dicaments). Chacune d'elles sera d\
u233?clin\u233?e en une multitude d'exigences fonctionnelles (quel sc\u233?nario
suit le m\u233?decin qui prescrit, quelles informations doivent \u234?tre saisies,
comment le logiciel v\u233?rifie les interactions m\u233?dicamenteuses) et non
fonctionnelles (le temps d'affichage du nom du m\u233?dicament, la pr\u233?cision
des informations affich\u233?es) ainsi que des contraintes techniques. Comme on se
l'imagine ais\u233?ment, les objectifs d'aussi haut niveau doivent \u234?tre
formul\u233?s avec le plus grand soin, puis valid\u233?s au plus haut niveau hi\
u233?rarchique possible, car ils conditionnent des pans entiers du syst\u232?me \
u224? venir. Pr\u233?ciser et formaliser l'objectif Quelle sera la finalit\u233? du
syst\u232?me ? S'agit-il de choisir un logiciel sur \u233?tag\u232?re, ou bien de
d\u233?velopper un logiciel sp\u233?cifique ? La forme, le contenu et la structure
du futur cahier des charges en d\u233?pendent, et donc la fa\u231?on dont il sera \
u233?labor\u233?. Le co\u251?t de son \u233?laboration peut varier dans un rapport
de un \u224? dix, le co\u251?t du logiciel install\u233? de un \u224? cent. Il est
donc de premi\u232?re importance de pr\u233?ciser, en collaboration avec le donneur
d'ordre, l'objectif \u224? atteindre. Cet objectif sera formul\u233? sur une page
maximum, et approuv\u233? par le donneur d'ordre. On peut formaliser l'objectif
sous une forme finalit\u233?-avantage-mesure. Par exemple : \u8226? finalit\u233? :
assurer la s\u233?curit\u233? des prescriptions de m\u233?dicaments ; \u8226?
avantage : diminution du nombre d'erreurs m\u233?dicamenteuses ; \u8226? mesure :
diminution de 20 % du nombre d'erreurs. En fonction du contexte, on pourra
conserver cette forme de pr\u233?sentation dans le document, ou se servir de cette
formulation uniquement pour recueillir l'objectif aupr\u232?s du donneur d'ordres
et pr\u233?f\u233?rer une pr\u233?sentation plus litt\u233?raire pour le document.\
Partie 1 - M\u233?thodologie Techniques de recueil : r\u233?unions et interviews
Les techniques pour recueillir ces objectifs et besoins \u224? haut niveau sont les
r\u233?unions et les interviews. Il peut s'agir d'une r\u233?union de lancement \
u224? l'initiative du donneur d'ordre, de r\u233?unions avec les repr\u233?sentants
des utilisateurs, ou d'interviews individuelles. Quand on est dans le flou, que les
r\u244?les et responsabilit\u233?s sont mal d\u233?finis, que les objectifs ne sont
pas clairs, l'interview est la technique la plus efficace. \u192? la fin de
l'interview, on demandera \u224? la personne interview\u233?e quelles autres
personnes sont susceptibles de nous fournir des informations compl\u233?mentaires.
Cette technique permet de d\u233?finir de proche en proche les objectifs et le
concept, en croisant les informations obtenues au cours des diff\u233?rentes
entrevues. D\u233?terminer le p\u233?rim\u232?tre Le domaine d'application :
l'utilit\u233? du produit \u192? qui et \u224? quoi servira le futur syst\u232?me,
et pour quoi faire ? Ces questions vont d\u233?terminer le domaine d'application.
Il est important de le conna\u238?tre, car il nous permettra de d\u233?terminer
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\u233?, industrie automobile) est simple \u224? d\u233?
terminer. Mais il s'agit d'aller un peu plus dans le d\u233?tail, en partant de
l'objectif. Prenons un exemple : si l'objectif est de \u171? g\u233?rer de mani\
u232?re centralis\u233?e les demandes de subventions des jeunes cin\u233?astes
expatri\u233?s \u187?. on s'aper\u231?oit que l'on aura affaire, non \u224? un,
mais \u224? plusieurs experts de domaines d'expertise tr\u232?s diff\u233?rents. Si
l'on ne veut pas tomber dans le pi\u232?ge de la d\u233?composition fonctionnelle
(description des diff\u233?rentes fonctions du produit), il est essentiel de se
concentrer sur la question \u8364? \u224? quoi sert le produit, \u224? qui, pour
quoi faire ? \u187?. On a obtenu, lors de la d\u233?termination des objectifs, des
r\u233?ponses comme : g\u233?rer au quotidien les demandes de subvention. Savoir o\
u249? et par qui sont g\u233?r\u233?es des demandes de subvention de ce type
permettra de d\u233?limiter le domaine d'application. Le p\u233?rim\u232?tre : les
limites du produit \u192? ce stade, il n'est pas question de d\u233?crire le syst\
u232?me \u224? l'\u233?tude lui-m\u234?me. Ce qu'il est possible de d\u233?
terminer, c'est son p\u233?rim\u232?tre : quelles sont les limites du produit, et
quelles sont les interfaces qui permettent de communiquer avec l'ext\u233?rieur. Ce
monde ext\u233?rieur est fait de logiciels, de\par\pard\plain\hyphpar} {
Chapitre 6 - D\u233?pnir le concept et les objectifs mat\u233?riels et
d'utilisateurs avec lesquels le syst\u232?me \u224? l'\u233?tude va communiquer. Il
est essentiel de d\u233?crire le p\u233?rim\u232?tre avec le plus grand soin, sous
forme textuelle. Ce texte, qui devra faire l'objet d'un consensus entre toutes les
parties prenantes, sera soumis \u224? l'approbation du donneur d'ordre et des
principales parties prenantes. D\u233?crire le p\u233?rim\u232?tre est un exercice
difficile et un investissement tr\u232?s rentable. L'\u233?laboration de ce texte
va permettre, non seulement de clarifier les concepts, mais \u233?galement de d\
u233?couvrir des contraintes, de d\u233?terminer par la suite les parties
prenantes, et de pr\u233?ciser l'objectif. Le diagramme de contexte Le diagramme de
contexte est un outil de communication int\u233?ressant, et il peut \u234?tre \
u233?labor\u233? d\u232?s cette premi\u232?re \u233?tape, quitte \u224? \u234?tre
affin\u233? par la suite. Un diagramme de contexte n'est ni plus ni moins qu'un
diagramme de flux \u224? un niveau tr\u232?s macroscopique, o\u249? le syst\u232?me
\u224? l'\u233?tude est au centre. Ce diagramme peut \u234?tre utilis\u233? pour d\
u233?crire l'existant (diagramme de contexte m\u233?tier) ou pour situer le futur
syst\u232?me dans ses interactions avec le monde ext\u233?rieur (diagramme de
contexte produit). Outre sa valeur p\u233?dagogique comme outil de communication,
il sera tr\u232?s utile lors de l'\u233?tape de recueil des exigences pour d\u233?
terminer les cas d'utilisation \'5c'7busecases). La figure 6-2 repr\u233?sente le
diagramme de contexte (ici simplifi\u233?) pour un syst\u232?me de prise en charge
m\u233?dicamenteuse pour un centre hospitalier. M\u233?decin -Prescription
rProscription Avis pharmaceutique ^ Pharmacien Avis pharmaceutique /l \u201?l\u233?
ments de prescription Informations patient Validation de l'administration
Informations m\u233?dicament Informations^ patient Informations patient \u201?l\
u233?ments de prescription" Dossier patient Figure &2 : Diagramme de contexte\par\
Partie 1 - M\u233?thodologie Analyser les parties prenantes Savoir qui a int\u233?
r\u234?t \u224? quoi et quand ~~ On appelle partie prenante2 toute personne, groupe
de personnes ou orga- . . . ' nisation qui a un int\u233?r\u234?t (positif ou n\
u233?gatif) dans le projet ou le produit. holder. Oui paye pour le d\u233?
veloppement, la mise en service, l'exploitation du futur logiciel ? Oui va le r\
u233?aliser ? Qui va l'utiliser ? Qui va conduire le projet de r\u233?alisation ?
Et... qui va essayer de torpiller le projet \u224? tout prix ? Il est important de
le savoir d'avance. On identifiera les personnes ou les profils (par exemple,
assistante administrative) ayant un int\u233?r\u234?t dans l'\u233?laboration du
cahier des charges ou dans les applications qui en font l'objet, le r\u244?le que
ces personnes pourront jouer pour l'\u233?laboration des cahiers des charges (par
exemple, expert, conseiller, relecteur, futur utilisateur), leurs r\u244?les, int\
u233?r\u234?ts et objectifs. Cette \u233?tape d'analyse a une faible visibilit\
u233? \u224? court terme et un fort impact \u224? long terme, ce qui fait qu'il est
facile de la rater. \u192? d\u233?faut de cette analyse, on court le risque de se
focaliser sur quelques partenaires, de passer \u224? c\u244?t\u233? de besoins
importants, et d'occulter des pans entiers du cahier des charges. L'analyse des
parties prenantes va permettre, en temps voulu, de fixer les priorit\u233?s entre
des besoins tr\u232?s divers et parfois contradictoires, d'arbitrer, de g\u233?rer
les conflits, et surtout, de conna\u238?tre le v\u233?ritable objectif, de savoir
si (et quand) on s'en \u233?loigne, de mani\u232?re \u224? corriger les \u233?
carts. Liste des parties prenantes Une premi\u232?re liste des parties prenantes
a \u233?t\u233? \u233?tablie lors de la planification du projet de d\u233?finition
des besoins. Il s'agit maintenant de dresser une liste compl\u232?te et d\u233?
taill\u233?e et de n'oublier personne. La liste peut \u234?tre tr\u232?s diff\u233?
rente d'un projet \u224? l'autre. Voici \u224? titre indicatif une liste, \u224?
affiner pour chaque projet : \u8226? le donneur d'ordres, ou ma\u238?trise
d'ouvrage strat\u233?gique, propri\u233?taire du produit, c'est-\u224?-dire celui
qui paye pour le produit ; \u8226? la ma\u238?trise d'ouvrage op\u233?rationnelle,
qui repr\u233?sente les utilisateurs ; \u8226? les utilisateurs, qui vont
travailler avec le produit, directement ou indirectement (il faudra d\u233?tailler
les diff\u233?rents profils) ; \u8226? l'assistant \u224? ma\u238?trise d'ouvrage,
analyste ou consultant, qui va recueillir, analyser et sp\u233?cifier les besoins,
et interagir avec l'\u233?quipe de d\u233?veloppement ; \u8226? les concepteurs,
architectes, r\u233?alisateurs, qui vont recevoir le cahier des charges et devront
l'interpr\u233?ter et le r\u233?aliser ; \u8226? l'\u233?quipe de test et de
validation, qui va v\u233?rifier que le produit d\u233?velopp\u233? respecte le
cahier des charges ;\par\pard\plain\hyphpar} {
Chapitre 6 - D\u233?pnir le concept et les objectifs \u8226? les personnes charg\
u233?es de r\u233?diger la documentation du produit, conform\u233?ment aux sp\u233?
cifications ; \u8226? les concepteurs et r\u233?alisateurs d'autres produits, qui
vont interagir avec le syst\u232?me \u224? l'\u233?tude ; \u8226? les personnes
charg\u233?es du support technique ou fonctionnel du produit \u224? choisir ou \
u224? d\u233?velopper ; \u8226? le marketing du produit ; \u8226? les juristes; \
u8226? les organismes de normalisation (leurs repr\u233?sentants) ; \u8226? les
experts m\u233?tier ; \u8226? les experts techniques. Cette liste n'est pas
exhaustive. Elle sera nominative, du moins en ce qui concerne les parties prenantes
\u224? fort pouvoir de d\u233?cision. La grille impact-pouvoir-influence Apr\u232?s
avoir dress\u233? la liste des parties prenantes, on doit \u233?valuer le pouvoir,
l'int\u233?r\u234?t et l'influence de chacun d'eux, de mani\u232?re \u224? mieux
orienter les efforts de recueil des exigences. Il y a plusieurs mani\u232?res de
repr\u233?senter l'influence des parties prenantes sur le projet (grilles pouvoir-
influence, pouvoir-impact, pouvoir-int\u233?r\u234?t, etc.) dont chacune a ses
avantages. La mani\u232?re la plus utile semble \u234?tre la grille impact-pouvoir-
influence : \u8226? Impact : dans quelle mesure la personne, le groupe ou le profil
utilisateur sera-t-il impact\u233? (dans son travail, dans son pouvoir) par
l'introduction du syst\u232?me ? \u8226? Pouvoir : quel est son pouvoir d'influence
? \u8226? Influence : cette influence sera-t-elle positive, n\u233?gative ou neutre
? Par exemple, le donneur d'ordres a beaucoup de pouvoir, une influence positive
sur le projet et sera g\u233?n\u233?ralement fortement impact\u233?. Une
association professionnelle ou un syndicat peuvent avoir beaucoup de pouvoir
(positif ou de nuisance) sans \u234?tre directement impact\u233?s. A contrario, un
utilisateur final a g\u233?n\u233?ralement beaucoup d'int\u233?r\u234?t et peu de
pouvoir (figure 6-3). L'utilit\u233? d'une telle grille est multiple : \u8226?
conna\u238?tre les int\u233?r\u234?ts de chaque partie prenante, ce qui permet d\
u233?j\u224? de d\u233?tecter des exigences : \u8226? en fonction de l'impact et du
pouvoir, avoir une premi\u232?re id\u233?e des priorit\u233?s entre exigences ; \
u8226? d\u233?tecter les risques potentiels, de mani\u232?re \u224? les limiter ; \
u8226? savoir qui informer, quand, et de quelle mani\u232?re ; \u8226? d\u233?
tecter les freins \u224? l'avancement du projet.\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie Fort voir =3 o IJ- ible u. Q Actionnaires Q
Psychologue \u169?DG 0 M\u233?decins 0 Comptables ^ Infirmiers A Support ^
technique FaWe Impact Figure 6-3 : Grille impoct-pouvoir-influence Fort Grille de
questionnement La grille de questionnement suivante peut servir de trame (par
exemple, lors d'une interview) pour la d\u233?termination des objectifs, du
contexte, et des parties prenantes, et pour anticiper les techniques \u224?
utiliser : \u8226? Demandeur. Oui est \u224? l'origine de la demande ? \u8226?
Motivation. Qu'est-ce qui. d'apr\u232?s vous, a motiv\u233? la demande ? \u8226?
Objectif. \u219?uel est l'objectif de l'application ? Quel est l'objectif du cahier
des charges ? Que veut-on obtenir ? Quel probl\u232?me veut-on r\u233?soudre ? \
u8226? Crit\u232?res. Comment saurons-nous que l'objectif est atteint ? \u8226? B\
u233?n\u233?fices attendus. Qu'esp\u232?re-ton gagner avec ce projet ? \u8226?
Acteurs. Qui va utiliser le produit ? Qui va payer ? Qui va d\u233?velopper,
maintenir, exploiter ? Quels sont les d\u233?cideurs ? \u8226? Contenu. Que va-t-on
mettre dans le cahier des charges ? Que va-t-on exclure : les fonctions ? les
exigences non fonctionnelles (qualit\u233?, performances) ? les contraintes
techniques ? les contraintes de projet ? les contraintes d'exploitation ? \u8226?
Port\u233?e. Quelles fonctions va-t-on d\u233?crire dans le cahier des charges
(port\u233?e fonctionnelle) ? Qu'est-ce qui sera englob\u233? par le cahier des
charges : l'entreprise enti\u232?re, le syst\u232?me, un composant du syst\u232?me
(port\u233?e de conception) ?\par\pard\plain\hyphpar} {
Chapitre 6 - D\u233?pnir le concept et les objectifs \u8226? Niveau. \u192? quel
niveau d'observation va-t-on se placer : un niveau strat\u233?gique, au niveau
utilisateur, ou au niveau tr\u232?s d\u233?taill\u233? ? Quel niveau de d\u233?tail
ou d'abstraction veut-on obtenir ? \u8226? Usage. Que veut-on en faire du cahier
des charges : choix de progiciel, d\u233?veloppent sp\u233?cifique... ? \u8226?
Parties prenantes. Oui sera le correspondant de la personne charg\u233?e de r\u233?
diger 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 \u224? chaque interlocuteur, de mani\u232?re \u224? se faire une id\
u233?e des demandes, mais il est \u233?vident que le poids des r\u233?ponses sera
diff\u233?rent en fonction des interlocuteurs. Les utilisateurs ne sont pas les
payeurs. Plus que jamais, la difficult\u233? de cet exercice de questionnement est
de ne pas trop descendre dans les d\u233?tails. Il ne s'agit pas. dans cette \u233?
tape pr\u233?liminaire, de faire le cahier des charges par anticipation, mais
d'apporter une < vision \u187?, une conceptualisation de ce que sera le futur syst\
u232?me. Tableau des parties prenantes Gr\u226?ce \u224? la grille impact-pouvoir-
influence et suite aux informations recueillies au moyen de la grille de
questionnement, on peut \u233?tablir le tableau des parties prenantes. La grille du
tableau 6-1 est donn\u233?e en exemple. Notons que les rubriques des diff\u233?
rentes colonnes peuvent varier selon le contenu, la port\u233?e, le niveau et
l'usage du cahier des charges (voir paragraphe pr\u233?c\u233?dent). Tableau 6-1 -
GriHe des parties prenantes Partie prenante Actionnaire DG M\u233?decins Infirmiers
R\u244?le Finance le projet MOA strat\u233?gique Utilisateurs directs Prescripteurs
Utilisateurs directs Administrent les m\u233?dicaments Objectifs Efficience
Prescrire sans perte de temps Aide \u224? la prescription Probl\u233?matique Co\
u251?t du d\u233?veloppement Respect de la r\u233?glementation Erreurs m\u233?
dicamenteuses Besoins particuliers Facilit\u233? d'utilisation Disponibilit\u233?
de l'application Apport d'expertise Non Non Oui Oui\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie Le document de cadrage Il est important de formaliser
l'objectif, le champ de l'\u233?tude et le tableau des parties prenantes dans un
document unique, et faire valider ce document par les parties prenantes les plus
importantes (les d\u233?cideurs). Une fois valid\u233?, un tel document a plusieurs
vertus : \u8226? C'est un cahier des charges en condens\u233?. \u8226? C'est une
aide \u224? la gestion de projet : il permet de chiffrer l'effort n\u233?cessaire
pour \u233?laborer le reste du cahier des charges, \u224? trouver les experts, \
u224? planifier. \u8226? Il peut faire fonction de lettre de mission pour
l'analyste. Le document de cadrage est le livrable de la phase de pr\u233?paration
du processus. Il contiendra donc les \u233?l\u233?ments suivants : \u8226? le
concept ; \u8226? les objectifs ; \u8226? les parties prenantes : r\u244?les,
responsabilit\u233?s ; \u8226? les cat\u233?gories (classes) d'utilisateur ; \
u8226? les contours du futur produit et \u233?changes avec l'ext\u233?rieur :
diagramme de contexte ; \u8226? les cas d'utilisation m\u233?tier \'5c'7bbusiness
use cases) dans leurs grandes lignes, par priorit\u233? ; \u8226? les cas
d'utilisation qu'on a d\u233?cid\u233? d'informatiser. Check-list La check-list
suivante permet de s'assurer que les conditions sont r\u233?unies pour r\u233?ussir
le projet, qu'il s'agisse de choisir et mettre en \u339?uvre un progiciel ou de d\
u233?velopper une application. Si toutes les conditions ne sont pas r\u233?unies, \
u233?laborer un cahier des charges sera de peu d'utilit\u233?. \u8226? Les
objectifs sont-ils clairement sp\u233?cifi\u233?s ? \u8226? A-t-on identifi\u233?,
analys\u233? et formalis\u233? la liste des parties prenantes ? \u8226? Les
objectifs sp\u233?cifi\u233?s sont-ils approuv\u233?s par les parties prenantes ? \
u8226? Les objectifs sont-ils r\u233?alistes, en termes de d\u233?lais, de charge,
de budget et aussi de risques ? \u8226? A-t-on analys\u233? les risques ? \u8226?
Y-a-t-il consensus entre parties prenantes sur le p\u233?rim\u232?tre ? \u8226? Le
p\u233?rim\u232?tre a-t-il \u233?t\u233? formellement approuv\u233? par le donneur
d'ordres ? \u8226? Les parties prenantes se sont-elles engag\u233?es \u224?
participer ?\par\pard\plain\hyphpar} {
Chapitre 7 Planifier le projet d'\u233?laboration \u201?laborer un cahier des
charges est un projet en soi. Dans ce cadre, il n\u233?cessite une v\u233?ritable
planification. Apr\u232?s avoir d\u233?fini les parties prenantes, le champ et
l'objectif, nous avons en main tous les \u233?l\u233?ments pour \u233?laborer le
plan projet. Celui-ci consiste \u224? d\u233?terminer les techniques, m\u233?thodes
et outils \u224? mettre en \u339?uvre pour mener \u224? bien le projet d'\u233?
laboration du cahier des charges, avec un maximum d'efficacit\u233? pour un minimum
d'effort. Le livrable de cette \u233?tape pr\u233?alable est un plan projet. Le
plan projet Ce document vient en compl\u233?ment du document de cadrage et sert de
feuille de route \u224? l'\u233?quipe d'\u233?laboration du cahier des charges.
L'ensemble forme le \u171? cahier des charges du projet de cahiers des charges \
u187?. Le plan projet contient un devis estimatif des co\u251?ts et d\u233?lais,
ainsi qu'une description br\u232?ve (une ou deux pages) de l'organisation et de la
m\u233?thode de travail : taille de l'\u233?quipe, moyens \u224? mettre en \u339?
uvre, formations \u224? pr\u233?voir, circuit de l'information, fr\u233?quence des
r\u233?unions, validation des documents, en fonction d'un certain nombre de param\
u232?tres (taille fonctionnelle, maille du cahier des charges... ). Cette mani\
u232?re descendante [top-down) de proc\u233?der pr\u233?sente plusieurs avantages :
\u8226? \u192? la fin de cette \u233?tape, vous disposez de tous les outils n\u233?
cessaires \u224? l'\u233?laboration du cahier des charges. \u8226? Vous avez une
id\u233?e pr\u233?cise des param\u232?tres du projet : co\u251?t, d\u233?lais,
qualit\u233?, ressources n\u233?cessaires. \u8226? Vous pouvez ainsi n\u233?gocier
avec le donneur d'ordres sur des bases solides.\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie Les paragraphes qui suivent d\u233?taillent les
activit\u233?s de cette \u233?tude pr\u233?liminaire : cadrer la m\u233?thodologie
et \u233?laborer le plan projet. Cadrer la m\u233?thodologie D\u233?finir le
processus global Le processus de recueil des besoins et d'\u233?laboration du
cahier des charges peut varier d'un cas \u224? l'autre. Une bonne pratique consiste
\u224? d\u233?crire ce processus et l'encha\u238?nement de chacune de ses activit\
u233?s (recueil, analyse, sp\u233?cification, validation, gestion) selon un sch\
u233?ma de processus d\u233?taill\u233?. Cette \u233?tape est utile, voire
indispensable, lorsque l'\u233?laboration du cahier des charges est faite par un
consultant externe. Dans ce cas. il doit d\u233?crire sch\u233?matiquement sa m\
u233?thode de travail dans sa proposition technique et commerciale. 1. Diagrammes:
voir au chapitre 10. 2. Ces techniques sont d\u233?crites dans les chapitres 7 \
u224? 14. 3. Outils : voir au chapitre 19. Choisir les mod\u232?les de repr\u233?
sentation \u224? utiliser On choisira les mod\u232?les1 de repr\u233?sentation des
exigences qui seront utilis\u233?s pour l'\u233?laboration des cahiers des charges
(par exemple, cas d'utilisation, diagrammes de s\u233?quence...). Le choix se fera
en fonction du domaine (technique,administration, banque...), des normes et
standards dans l'entreprise, mais aussi en fonction de la sociologie des parties
prenantes. En effet, en fonction des milieux professionnels, les personnes sont
plus ou moins sensibles \u224? une repr\u233?sentation plut\u244?t qu'\u224? une
autre. D\u233?terminer et adapter les techniques Il n'y a pas une m\u233?thode
unique de gestion des exigences. Les techniques2 classiques d'acquisition,
d'analyse, de sp\u233?cification, de validation et de gestion des exigences devront
\u234?tre adapt\u233?es au contexte, aux interlocuteurs, au type de syst\u232?me \
u224? l'\u233?tude. \u201?tudier les outils On fera une analyse
comparatived'outils3 d'aide \u224? l'\u233?laboration de cahiers des charges et de
gestion des exigences. Il s'agira, dans cette \u233?tude de d\u233?finition, de
faire un choix d'outils, ou simplement de mieux conna\u238?tre l'offre du march\
u233?, de mani\u232?re \u224? mieux adapter les techniques, d\u233?terminer les
profils des intervenants, anticiper sur les co\u251?ts de formation, les charges
d'\u233?laboration. o\par\pard\plain\hyphpar} {
Chapitre 7 - Planifier le projet d'\u233?laboration \u201?laborer les documents
types Pour chaque mod\u232?le de repr\u233?sentation des exigences choisi, on \
u233?laborera le mod\u232?le de document appropri\u233? (mod\u232?le g\u233?n\u233?
rique) ; par exemple, mod\u232?le de cas d'usage ( use case). Cet ouvrage donne
plusieurs mod\u232?les de documents types, ainsi que des adresses Internet utiles
permettant d'en t\u233?l\u233?charger. Identifier et adapter les mod\u232?les Il
s'agit de d\u233?terminer, avec la collaboration des parties prenantes les plus
impact\u233?es, la structure4 du document final, son niveau (par exemple, niveau
strat\u233?gique, niveau de l'utilisateur, ou niveau des sous-fonctions), sa port\
u233?e (organisation, syst\u232?me, sous-syst\u232?me, composant), son contenu dans
les grandes lignes (en dehors des exigences fonctionnelles, les autres exigences
abord\u233?es). On \u233?laborera le mod\u232?le de document (le template) de
cahier des charges. 4. Mod\u232?les de cahiers des charges : voir au chapitre 14. \
u201?laborer le plan projet Identifier les profils utilisateurs Cette activit\u233?
fait suite \u224? l'analyse des parties prenantes en la d\u233?taillant en ce qui
concerne les profils utilisateurs. On identifiera et analysera les profils
utilisateurs types pour le logiciel qui fera l'objet de cahiers des charges, leurs
attentes, leurs besoins g\u233?n\u233?riques, les conflits potentiels entre types
d'utilisateurs, leur niveau de ma\u238?trise des technologies, etc. Cette activit\
u233? sera affin\u233?e lors de l'\u233?tape de recueil des besoins. \u201?tablir
la liste des sources d'exigences Les exigences qui seront formul\u233?es dans les
cahiers des charges proviendront de sources diverses : \u233?tudes en amont, \u233?
tudes th\u233?oriques, \u233?tude de la concurrence, ... et. bien s\u251?r. les
besoins des diff\u233?rentes parties prenantes, en particulier les utilisateurs. On
\u233?tablira dans un premier temps la liste des sources possibles d'exigences :
tableau comprenant les sources d'exigences, leur utilit\u233?, les techniques de
recueil d'exigences, les ressources n\u233?cessaires, la charge de travail
relative. Cette liste sera affin\u233?e et d\u233?taill\u233?e lors de l'\u233?tape
de recueil.\par\pard\plain\hyphpar} {
ie 1 - M\u233?thodologie Estimer les charges et les d\u233?lais Comme pour tout
projet, l'estimation des charges et des d\u233?lais est un exercice difficile, \
u224? l'issue incertaine, mais n\u233?anmoins indispensable. La charge d'\u233?
laboration d\u233?pend de plusieurs param\u232?tres : \u8226? la facilit\u233? de
recueil des besoins : les sources d'exigences et les techniques \u224? utiliser en
fonction des sources et de l'objectif \u224? atteindre ; \u8226? la taille
fonctionnelle du logiciel \u224? d\u233?finir : nombre de fonctions et leur
importance ; \u8226? la destination du cahier des charges : choix d'un progiciel ou
d\u233?veloppement d'un logiciel sp\u233?cifique ; \u8226? le niveau de d\u233?tail
avec lequel on veut d\u233?crire le produit ; \u8226? la maturit\u233? de l'\u233?
quipe de d\u233?veloppement ; \u8226? l'habitude de collaborer entre ma\u238?trise
d'ouvrage et ma\u238?trise d'oeuvre ; \u8226? l'exp\u233?rience et l'habilet\u233?
de l'assistant \u224? ma\u238?trise d'ouvrage. Toute la suite de cet ouvrage
s'attache \u224? optimiser le temps et l'effort d'\u233?laboration du cahier des
charges, en minimisant les risques et en am\u233?liorant la qualit\u233?.
Identifier les ressources Un projet d'\u233?laboration d'un cahier des charges fait
appel \u224? plusieurs comp\u233?tences. Ces diverses comp\u233?tences peuvent \
u234?tre r\u233?unies chez une seule personne et. dans de nombreux cas. un
consultant seul peut animer le projet d'\u233?laboration du cahier des charges, en
r\u233?alisant plusieurs t\u226?ches : recueil des besoins, animation des groupes
de travail, r\u233?daction des sp\u233?cifications, etc. Cependant, pour les
projets d'envergure, il sera peut-\u234?tre utile de faire appel, m\u234?me
ponctuellement, \u224? des personnes diff\u233?rentes. Le directeur de la mission,
ou directeur de projet, d'assistance \u224? la ma\u238?trise d'ouvrage pour l'\
u233?laboration du cahier des charges. C'est le correspondant unique du client. Il
d\u233?finit et g\u232?re le projet et anime les interactions entre acteurs. Sans \
u234?tre n\u233?cessairement un expert du domaine d'application. Il suit de bout en
bout les op\u233?rations d'\u233?laboration du cahier des charges et y participe en
grande partie. L'expert m\u233?tier. C'est un consultant exp\u233?riment\u233? ou
senior connaissant le domaine d'application, l'organisation du client. Souvent un
ancien utilisateur, il conna\u238?t de pr\u233?f\u233?rence les applications
concurrentes de celle \u224? d\u233?velopper. Sans \u234?tre informaticien, il
conna\u238?t les \u233?diteurs de logiciels du domaine d'application. O\par\pard\
plain\hyphpar} {
Chapitre 7 - Planifier le projet d'\u233?laboration Un consultant expert en gestion
des exigences. Il apporte \u224? l'\u233?quipe expertise et conseil m\u233?
thodologique. Il conna\u238?t les techniques de recueil des besoins, de mod\u233?
lisation, de repr\u233?sentation de l'information. Un expert technique, qui pourra
se prononcer sur les contraintes techniques. Identifier et analyser les risques Une
bonne pratique consiste \u224? identifier les risques associ\u233?s \u224? l'\u233?
laboration de tous les cahiers des charges et de mettre au point des strat\u233?
gies d'att\u233?nuation. Il ne s'agit pas ici d'aborder les risques inh\u233?
rents \u224? un projet de d\u233?veloppement ou \u224? l'exploitation d'un
logiciel, mais aux risques sp\u233?cifiques \u224? l'\u233?laboration du cahier des
charges. Parmi les risques les plus fr\u233?quents, citons l'indisponibilit\u233?
de certains profils utilisateurs pour participer \u224? des groupes de travail
d'expression des besoins. Un autre risque est li\u233? \u224? la non-implication,
ou \u224? l'implication insuffisante, de la ma\u238?trise d'ouvrage strat\u233?
gique. Contenu du plan projet Le plan projet contiendra au minimum les \u233?l\
u233?ments suivants : \u8226? description simple du processus global d'\u233?
laboration ; \u8226? techniques de recueil \u224? mettre en place : interviews, r\
u233?unions, groupes de travail, maquettes ou prototypes, etc. ; \u8226? mod\u232?
les de repr\u233?sentation de l'information \u224? utiliser ; \u8226? outils \u224?
utiliser ; \u8226? liste des documents types \u224? utiliser ; \u8226? liste des
sources d'exigences ; \u8226? repr\u233?sentants des utilisateurs retenus pour
participer aux diff\u233?rents groupes de travail ; \u8226? formations \u233?
ventuellement pr\u233?vues aux techniques et outils ; \u8226? ressources n\u233?
cessaires ; \u8226? charges; \u8226? d\u233?lais; \u8226? risques. Enregistrement
des charges et des d\u233?lais Une organisation qui souhaite industrialiser le
processus de d\u233?veloppement et de gestion des exigences aura tout int\u233?r\
u234?t \u224? \u233?tablir et faire appliquer un suivi du temps pass\u233? aux
diff\u233?rentes activit\u233?s. Par exemple. CEI\par\pard\plain\hyphpar} {
Partie 1 - M\u233?thodologie recueil, analyse, sp\u233?cification, validation. Ou
mieux (car plus proche de la pratique) : \u8226? temps pass\u233? en r\u233?unions
avec le ma\u238?tre d'ouvrage ; \u8226? temps pass\u233? en groupe de travail ; \
u8226? r\u233?daction et modifications du cahier des charges ; \u8226? revues de
documents. Check-list L'objectif du projet est-il clair, sans ambigu\u239?t\u233?,
sans langue de bois ? L'atteinte de l'objectif est-elle v\u233?rifiable et
mesurable ? L'atteinte de l'objectif se traduira-t-elle par un b\u233?n\u233?fice
pour l'entreprise ou l'organisation ? Est-on assur\u233? que l'objectif pourra \
u234?tre atteint avec les moyens allou\u233?s ? Y a-t-il un accord \u233?crit sur
le p\u233?rim\u232?tre du projet ? A-t-on \u233?tudi\u233? les risques, en termes
d'impact et de probabilit\u233?, et s'est- on assur\u233? qu'ils sont
raisonnables ? A-t-on estim\u233? les co\u251?ts et s'est-on assur\u233? qu'ils
sont raisonnables ? Les parties prenantes sont-elles impliqu\u233?es ?
L'investissement pr\u233?vu est-il justifi\u233? ? S'est-on assur\u233? qu'il ne
subsiste aucune zone d'ombre sur le processus d'\u233?laboration du cahier des
charges ? e>\par\pard\plain\hyphpar} {
\u199?p\u226?rtTe D\u233?veloppement des exigences Le projet d'\u233?laboration du
cahier des charges \u233?tant pr\u233?par\u233? et planifi\u233?, nous abordons
maintenant le c\u339?ur de notre m\u233?tier : le d\u233?veloppement des exigences
proprement dit. Nous d\u233?crivons les techniques et m\u233?thodes qui vont nous
permettre, en partant des objectifs, de valider un cahier des charges, en
optimisant les co\u251?ts, les d\u233?lais et la qualit\u233?. Souvenons-nous
cependant que le processus est it\u233?ratif, et que les r\u233?sultats des \u233?
tapes pr\u233?paratoires ne sont jamais grav\u233?s dans le marbre. La
planification initiale peut \u234?tre remise en cause, comme pour tout projet.
L'objectif et le p\u233?rim\u232?tre peuvent varier. Des parties prenantes rest\
u233?es dans l'ombre peuvent toujours se manifester. Aussi est-il important, tout
en gardant l'objectif en t\u234?te, de rester toujours \u224? l'\u233?coute des
diff\u233?rents acteurs.\par\pard\plain\hyphpar} {
Chapitre 8 L'\u233?tape de recueil De toutes les activit\u233?s de l'ing\u233?
nierie des exigences, l'activit\u233? de recueil est celle qui demande le plus de
qualit\u233?s humaines. Il faut trouver la personne qui d\u233?tient l'information,
l'encourager \u224? exprimer, puis \u233?couter ce qu'elle a \u224? dire, avec
neutralit\u233? et bienveillance. Il faut animer des groupes de travail o\u249? des
tensions entre individus peuvent appara\u238?tre. Raison de plus pour bien pr\u233?
parer cette \u233?tape, en laisser le moins de choses possibles au hasard. L'enjeu
Capturer les besoins est a priori chose simple et facile. Il suffit de se r\u233?
unir avec les futurs utilisateurs, interviewer le client, ou compulser normes et
standards pour recueillir les besoins \u224? la source. La r\u233?alit\u233? est
bien loin d'\u234?tre aussi si simple. \u192? moins de vouloir faire d\u233?
velopper une petite application simple pour une demi-douzaine d'utilisateurs (et
encore...), on se trouve vite confront\u233? \u224? des difficult\u233?s diverses :
r\u233?sistances, contradictions, guerres des clans, dissensions. Mais plus concr\
u232?tement, demandez \u224? un futur utilisateur du syst\u232?me d'exprimer ses
besoins. Posez-lui la question \u171? quel est le besoin ? \u187?. Spontan\u233?
ment, il exprimera, selon le cas : \u8226? un probl\u232?me ou une difficult\
u233? \u224? laquelle il est confront\u233? -. \u8226? une solution (plus pr\u233?
cis\u233?ment sa solution) \u224? ce probl\u232?me ; \u8226? la mani\u232?re dont
cette solution sera mise en \u339?uvre ; \u8226? un vrai besoin, c'est-\u224?-dire
une fonction attendue du futur syst\u232?me. Autrement dit, dans la majorit\u233?
des cas. l'utilisateur interview\u233? n'exprimera pas spontan\u233?ment un besoin.
Quelle est donc la \u171? bonne technique \u187? \u224? employer pour recueillir
les besoins ? Comment aider le futur utilisateur\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences \u224? s'exprimer ? Comment \u233?viter
que les r\u233?unions de travail ne s'\u233?ternisent, ou ne se transforment en
pugilat verbal ? Il n'y a pas de recette miracle, mais des outils et des
techniques. Le reste est affaire d'exp\u233?rience et d'habilet\u233?, pour choisir
le bon outil et l'utiliser \u224? bon escient. Voici donc quelques techniques et
outils, ainsi que des conseils d'utilisation. Le processus de recueil Il n'y a pas
de plan type de l'\u233?tape de recueil, avec un encha\u238?nement immuable de t\
u226?ches pr\u233?d\u233?finies. Les techniques pour recueillir les exigences sont
nombreuses et tr\u232?s vari\u233?es, et le choix de telle ou telle technique d\
u233?pend du contexte, de l'existant et des contraintes : la disponibilit\u233? des
personnes et leur niveau d'expertise, les documents pouvant \u234?tre consult\u233?
s, la possibilit\u233? d'observer sur le terrain les pratiques existantes ou des
syst\u232?mes analogues \u224? celui \u224? l'\u233?tude. Mais comme avec les
autres \u233?tapes, la planification et la v\u233?rification jouent un r\u244?le
important. Planifier le recueil Pr\u233?parer grilles et outite S\u233?lectionner
les techniques 1 ' RecueBfirles besoins ' ' V\u233?rifier .,./i n Documenter ah/ff>
Figure 8-1 : Le processus de recueil Planifier le recueil des besoins C'est \u224?
partir de la liste des sources d'exigences et du tableau des parties prenantes que
l'on va planifier dans le temps le recueil des besoins, et pr\u233?voir les
ressources (humaines et mat\u233?rielles) et la logistique. Cette planification
doit \u234?tre souple, car le volume et la qualit\u233? des informations que l'on
va recueillir ne sont pas pr\u233?cis\u233?ment connus \u224? l'avance. Rappelons
que l'\u233?tape de recueil, en pratique, n'est pas isol\u233?e des autres.
L'analyse, la sp\u233?cification, et une grande partie de la validation des besoins
se d\u233?roulent en parall\u232?le avec le recueil. C'est une raison suppl\u233?
mentaire pour planifier soigneusement les interviews des diff\u233?rentes parties
prenantes, et surtout les r\u233?unions des groupes de travail. Il faut souvent une
semaine pour obtenir un rendez-vous, et plus d'un mois pour o\par\pard\plain\
hyphpar} {
Chapitre 8 - L'\u233?tape de recueil r\u233?unir un groupe de travail. La lecture
des documents est \u233?videmment plus simple \u224? planifier, mais peut \u234?tre
longue. Et surtout, ne pas oublier de \u171? pr\u233?voir l'impr\u233?vu \u187?.
Des r\u233?unions suppl\u233?mentaires sont souvent n\u233?cessaires pour \u233?
daircir des points obscurs. Pr\u233?parer les grilles et les outils En fonction des
buts vis\u233?s (d\u233?veloppement de logiciel, ou choix d'un progiciel, par
exemple), de la granularit\u233? \u224? atteindre, des personnes \u224?
interviewer, on pr\u233?parera des guides d'entretien ou de r\u233?union. Une
partie des grilles d'interview ou des th\u232?mes des groupes de travail devra \
u234?tre formalis\u233?e et envoy\u233?e par avance aux participants. Pour
recueillir des besoins \u224? partir de documents \u233?crits, il est \u233?
galement int\u233?ressant de se munir de grilles de lecture pour \u233?viter d'\
u234?tre submerg\u233? par la masse de documents. La quantit\u233? d'informations \
u224? traiter peut rendre l'op\u233?ration de recueil complexe, en particulier si
l'on veut garder la tra\u231?abilit\u233? des exigences aux \u233?tapes suivantes.
Le principe de la construction d'une grille est simple. Il consiste \u224? partir
de l'objectif pour d\u233?couvrir les exigences qui en d\u233?coulent, et des
exigences d\u233?j\u224? exprim\u233?es pour d\u233?couvrir les exigences plus d\
u233?taill\u233?es. 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 d\u233?crites dans la suite de ce chapitre. Quelle que soit
la technique choisie, l'information recueillie doit \u234?tre soigneusement r\u233?
pertori\u233?e et stock\u233?e en vue d'une analyse et d'une sp\u233?cification
ult\u233?rieures. Cela est vrai m\u234?me si recueil, analyse et sp\u233?cification
ont lieu au cours d'une m\u234?me r\u233?union d'un groupe de travail. Une des
difficult\u233?s d\u233?coule de la surabondance des informations recueillies, et
ce, quelle que soit la technique de recueil. Pour \u233?viter de se noyer sous un
flot de paroles ou sous des milliers de pages, il n'y a pas de recette miracle,
mais un principe : travailler \u224? partir de grilles en gardant en t\u234?te
l'objectif. V\u233?rifier les informations recueillies On v\u233?rifiera
l'exactitude des informations recueillies au moyen d'un compte-rendu de r\u233?
union ou d'interview. Il ne s'agit pas ici de valider les exigences, mais d'obtenir
un feedback sur les informations recueillies. Cela permettra de corriger les
informations au plus pr\u232?s de la source. Q\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Si le recueil des besoins est fait par
une \u233?quipe (c'est souvent le cas), il faut pr\u233?voir de faire le point pour
\u233?changer sur les informations recueillies. Le plan de recueil Le plan de
recueil servira de guide tout au long de l'\u233?tape de recueil des besoins. Il
contient : \u8226? Les objectifs du recueil : en particulier, il est important de
savoir s'il s'agit de recueillir des exigences \u224? haut niveau, ou de descendre
dans les d\u233?tails, ou de consolider des exigences d\u233?j\u224? formalis\u233?
es. \u8226? Les livrables et leur forme, ainsi que leur niveau de formalisme ; cela
peut aller d'une simple note sous forme textuelle, jusqu'\u224? des mod\u232?les de
donn\u233?es strictement formalis\u233?s. \u8226? Les m\u233?thodes et techniques
de recueil, qui peuvent varier selon les objectifs, les livrables et les
interlocuteurs. \u8226? Les risques induits, et les m\u233?thodes de contournement
et d'att\u233?nuation des risques. \u8226? La planification du recueil : co\u251?
ts, dates, d\u233?lais et ressources. Risques li\u233?s au recueil et att\u233?
nuation Les risques li\u233?s au recueil proviennent des sources de besoins, plus
ou moins disponibles et fiables, ainsi que de la mani\u232?re dont ses besoins sont
exprim\u233?s. Le premier facteur de risque est l'indisponibilit\u233? des sources,
qu'il s'agisse de documents auxquels on ne peut acc\u233?der (d\u233?truits,
perdus, corrompus, confidentiels) ou de personnes qui ne sont pas ou trop peu
disponibles. Les informations erron\u233?es, intentionnellement ou non. sont un
deuxi\u232?me facteur de risque. Les interlocuteurs se servent souvent d'une \u233?
tude des besoins pour servir leurs int\u233?r\u234?ts propres, et non les objectifs
vis\u233?s par le syst\u232?me \u224? construire. Pour \u233?viter ce pi\u232?ge,
il faut, d'une part, s'appuyer sur les objectifs pr\u233?alablement formalis\u233?s
et, d'autre part, croiser les sources. En troisi\u232?me lieu viennent les besoins
non exprim\u233?s, ou exprim\u233?s de mani\u232?re floue. C'est pour cette raison
qu'il est utile d'utiliser les comp\u233?tences d'un expert m\u233?tier, qui ma\
u238?trise le vocabulaire de ses interlocuteurs. De plus, il est indispensable,
pour recueillir des besoins op\u233?rationnels, de descendre au plus bas niveau hi\
u233?rarchique possible, de consulter de vrais utilisateurs, et ne pas se contenter
des seuls < repr\u233?sentants \u187? des utilisateurs. O\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil Un autre facteur de risque provient de la
difficult\u233? de se faire une id\u233?e d'ensemble d'un besoin. Interroger un
seul utilisateur apportera une image d\u233?form\u233?e du besoin, et trop peu
d'informations sur les pratiques quotidiennes. Inversement, avec trop de sources,
trop d'interlocuteurs, il est difficile de g\u233?rer les contradictions sur le
fond et sur la forme. Chercher \u224? savoir \u171? qui a raison \u187? pousse \
u224? descendre dans les d\u233?tails, et c'est l\u224? un risque suppl\u233?
mentaire. Recueillir des besoins trop ou insuffisamment d\u233?taill\u233?s, par
rapport aux objectifs du cahier des charges, est encore un risque. C'est pour cela
qu'il est indispensable de conna\u238?tre par avance les objectifs et le niveau de
d\u233?tail recherch\u233?. Des techniques de recueil, que nous verrons plus loin,
permettent d'\u233?lever le niveau, ou au contraire, de descendre plus dans le d\
u233?tail. D\u233?termination des profils utilisateurs Apr\u232?s le donneur
d'ordres, qui a exprim\u233? l'objectif, les parties prenantes qui seront les plus
impliqu\u233?es sur le plan op\u233?rationnel dans le recueil des exigences sont
les futurs utilisateurs du syst\u232?me. La typologie des profils Pour mener \u224?
bien le recueil, il est n\u233?cessaire de d\u233?terminer les profils des
utilisateurs, et de les classer en cat\u233?gories, de mani\u232?re \u224? pouvoir,
par la suite, d\u233?terminer les besoins par cat\u233?gorie d'utilisateurs. Il y a
plusieurs fa\u231?ons d'\u233?tablir les profils utilisateurs, en fonction de leur
m\u233?tier, de leur position hi\u233?rarchique ou de leur emplacement g\u233?
ographique. Cependant, le plus efficace est de les grouper en fonction de leur
interaction avec le syst\u232?me. Ce qui nous int\u233?resse ici n'est pas
l'individu, mais son r\u244?le vis- \u224?-vis du syst\u232?me, sachant qu'un
individu peut jouer plusieurs r\u244?les (par exemple, dans un restaurant, prendre
les commandes et s'occuper de la comptabilit\u233?) et donc avoir plusieurs
profils. Les profils utilisateurs seront constitu\u233?s en fonction : \u8226? des
fonctions du syst\u232?me auxquelles ils font appel ; \u8226? du niveau de s\u233?
curit\u233? requis pour acc\u233?der \u224? certaines fonctions ; \u8226? de leurs
propres exigences de s\u233?curit\u233?, de fiabilit\u233? ou d'ergonomie ; \u8226?
de leur fr\u233?quence d'utilisation du syst\u232?me ; \u8226? de leur pratique de
syst\u232?mes analogues ; \u8226? de leur connaissance du domaine.\par\pard\plain\
hyphpar} {
Partie 2 - D\u233?veloppement des exigences Un exemple Un centre hospitalier a
besoin de choisir et de mettre en \u339?uvre un syst\u232?me de gestion du m\u233?
dicament. Les profils utilisateurs suivants ont \u233?t\u233? d\u233?finis : \
u8226? prescripteur : m\u233?decin, sage-femme, ou toute autre personne amen\u233?e
\u224? prescrire des m\u233?dicaments ; \u8226? pharmacien ; \u8226? pr\u233?
parateur en pharmacie ; \u8226? infirmier ; \u8226? gestionnaire du syst\u232?me.
Il n'y a \u233?videmment pas une correspondance biunivoque entre un groupe de
personnes et un profil utilisateur. Le profil \u171? presaipteur > peut \u234?tre
attribu\u233? \u224? deux personnes de m\u233?tiers tr\u232?s diff\u233?rents (par
exemple, un m\u233?decin et une sage-femme). Inversement, le pharmacien d'un h\
u244?pital peut, dans certains cas, tenir le r\u244?le de gestionnaire du syst\
u232?me. Le tableau 8-1 des profils reprend, de mani\u232?re plus d\u233?taill\
u233?e, le tableau des parties prenantes qui a \u233?t\u233? \u233?labor\u233? lors
de l'\u233?tape pr\u233?paratoire. Il pourra \u234?tre encore enrichi au fil de
l'eau lors de l'\u233?tape de recueil. Tableau 8-1 - Grilla das utiBsataars M\u233?
decin Pharmacien Pr\u233?parateur Infirmier gestionnaire Fonctions utilis\u233?es
Prescription Validation pharmaceutique Saisie de la dispensation du m\u233?dicament
Saisie de l'administration du m\u233?dicament Param\u233?trage Exigences particuli\
u232?res Facilit\u233? d'apprentissage Tablette mobile Fr\u233?quence Quotidienne
Quotidienne Quotidienne Quotidienne Mensuelle Pratique Assez importante Tr\u232?s
importante Faible Faible Recherche des sources d'exigences Les parties prenantes,
et en particulier les futurs utilisateurs, sont la premi\u232?re source d'exigence.
Tous n'ont pas le m\u234?me domaine de\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil comp\u233?tences, ni le m\u234?me niveau
d'expertise. Le tableau des parties prenantes va \u224? nouveau nous permettre de
trouver les personnes-ressources, mais cette fois il devra \u234?tre utilis\u233?
pour \u233?laborer un tableau nominatif. Toutes les personnes d'un m\u234?me profil
n'ont pas le m\u234?me niveau d'expertise, ni la m\u234?me facilit\u233?
d'expression. Attention cependant : les opposants au projet ont parfois autant
d'informations utiles \u224? nous apporter que les plus moteurs. Il faudra les
invitera s'exprimer, en r\u233?union ou en interview, et les \u233?couter avec
bienveillance. Les articles, \u233?tudes comparatives, \u233?tudes de march\u233?,
forums sur Internet constituent \u233?galement une bonne source. Ces informations
ne sont pas toujours fiables, ni toujours \u224? jour. Il faudra donc croiser les
informations entre elles, et avec des sources plus s\u251?res. Les cahiers des
charges existants contiennent souvent des exigences qui peuvent \u234?tre reprises,
apr\u232?s \u233?ventuelle mise \u224? niveau. Si le cahier des charges est bien
fait, la reprise peut \u234?tre tr\u232?s simple. On peut remonter au cahier des
charges \u224? partir de sp\u233?cifications fonctionnelles g\u233?n\u233?rales ou
d\u233?taill\u233?es d'un logiciel existant (voire d'un logiciel qui n'a jamais vu
le jour), ou directement en observant le comportement du produit. Les < sous-
produits \u187? sont \u233?galement une mine d'informations pouvant \u234?tre r\
u233?utilis\u233?es, apr\u232?s analyse, pour \u233?laborer les exigences : fiches
d'anomalie, rapports d'essais, rapports au fieip-desk... en particulier, les fiches
d'anomalie sont tr\u232?s utiles pour recueillir des exigences \u171? n\u233?
gatives \u187? ou. pour formuler les choses plus positivement, des exigences d'am\
u233?lioration de l'existant. Il en est de m\u234?me des rapports d'audit, des
fiches de r\u233?clamations, et des demandes de modification, pour examiner ce qui
peut \u234?tre am\u233?lior\u233? et ce qui manque. Les normes, qui constituent \
u224? elles seules un recueil d'exigences, sont \u233?videmment une source fiable.
Il est n\u233?cessaire de faire attention \u224? la date de publication, de
s'assurer pour chaque norme qu'elle s'applique au contexte du syst\u232?me \u224?
l'\u233?tude. Il est \u224? noter que les normes ne sont pas toujours compatibles
entre elles, ni coh\u233?rentes sur le vocabulaire. Enfin, la documentation d'un
logiciel existant (\u224? remplacer), ou celle des concurrents sont des sources \
u224? ne pas n\u233?gliger. Techniques de recueil La capture des exigences n\u233?
cessite une bonne dose de cr\u233?ativit\u233?. On entend par l\u224? la cr\u233?
ativit\u233? op\u233?rationnelle, et non artistique. Celle d'un commandant d'unit\
u233? sur le th\u233?\u226?tre des op\u233?rations. \u192? condition d'\u234?tre\
Partie 2 - D\u233?veloppement des exigences orient\u233? vers l'objectif et de
respecter la doctrine, vous avez le droit, et m\u234?me le devoir, d'\u234?tre
inventif et d'improviser. Il en est de m\u234?me pour la capture des exigences.
Tant que vous avez l'objectif en vue. que vous respectez les bonnes pratiques, que
vous vous en tenez \u224? votre lettre de mission, vous avez la libert\u233?
d'utiliser toutes les techniques connues de recueil des besoins, et d'en inventer
d'autres si n\u233?cessaire. Les techniques doivent \u234?tre adapt\u233?es aux
personnes et aux circonstances. Ainsi, rien ne vous emp\u234?che d'organiser un
brainstorming avec certains utilisateurs et des interviews individuelles avec
d'autres. Lorsqu'il s'agit de choisir outils et techniques, c'est l'exp\u233?rience
et l'intuition qui doivent servir de guides, et non les proc\u233?dures. Il n'y a
pas en la mati\u232?re de recette miracle. Mais il y a des techniques. Le reste est
une affaire d'exp\u233?rience, pour choisir la bonne technique et l'utiliser au bon
moment. On trouvera dans les paragraphes qui suivent quelques techniques qui ont
fait leurs preuves, \u224? commencer par les plus classiques, ainsi que leur mode
d'utilisation. L'analyse de documents Utilit\u233? de la technique L'analyse de
documents est un des moyens les plus directs de recueillir des exigences. Les
documents existants constituent une des principales sources disponibles
d'exigences, dont certaines sont pour ainsi dire < pr\u234?tes \u224? l'emploi \
u187?. La difficult\u233? provient en g\u233?n\u233?ral de l'abondance des
documents, qu'il faut soigneusement trier, et dont il faudra filtrer l'information
utile. Utiliser des informations pr\u233?existantes permettra de r\u233?duire le
nombre et la dur\u233?e des interviews et r\u233?unions, mais pas de les supprimer.
Elle permettra \u233?galement d'acqu\u233?rir des connaissances sur le domaine
d'application, les interviews ult\u233?rieures \u233?tant un moyen d'affiner et de
consolider ces connaissances. Cela \u233?vitera aussi de perdre la face en posant
des questions dont on peut trouver la r\u233?ponse dans des documents disponibles.
Les sources Les sources sont en g\u233?n\u233?ral abondantes (voire
surabondantes) : \u8226? cahiers des charges et sp\u233?cifications de produits
similaires ou concurrents, de versions ant\u233?rieures du syst\u232?me \u224? l'\
u233?tude ; \u8226? normes : sources de r\u232?gles de gestion et de contraintes
techniques ; G>\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil \u8226? proc\u233?dures, descriptions
partielles de processus m\u233?tier ; \u8226? documents de travail, comptes-rendus
de r\u233?unions : sources de besoins, contraintes, frustrations des utilisateurs,
priorit\u233?s ; \u8226? documentation technique : source de contraintes ; \u8226?
documentation conceptuelle ou th\u233?orique, source de sp\u233?cifications
innovantes ; \u8226? formulaires papier : tr\u232?s utiles pour conna\u238?tre les
informations \u224? saisir, celles devant appara\u238?tre dans un document de
sortie ; \u8226? fiches d'anomalie, demandes de modifications. Mode op\u233?ratoire
Le mode op\u233?ratoire est le suivant : 1. Commencer par lister les documents
existants relatifs au domaine et/ou au syst\u232?me \u224? l'\u233?tude. 2. Passer
les documents rapidement en revue, de pr\u233?f\u233?rence en \u233?quipe, et noter
leur contenu et leur utilit\u233?. 3. Faire examiner les documents par un ou
plusieurs experts, en fonction de leur contenu et de l'app\u233?tence des experts
pour la question. 4. Trier les documents : d\u233?cider des documents \u224?
reprendre en l'\u233?tat, ceux \u224? retravailler, des parties de documents \u224?
extraire et conserver. 5. D\u232?s que possible, valider la pertinence, la coh\
u233?rence, la \u8364? fra\u238?cheur \u187? des informations fournies. 6.
Maintenir un tableau de la documentation existante. La r\u233?union d'un groupe de
travail Utilit\u233? et difficult\u233? La m\u233?thode < naturelle \u187?. qui
consiste \u224? r\u233?unir des volontaires des diff\u233?rentes parties prenantes
et \u224? leur demander d'exprimer les besoins, est aussi la moins efficace. Ainsi,
en r\u233?unissant vingt personnes de m\u233?tiers tr\u232?s diff\u233?rents, en m\
u233?langeant utilisateurs, donneurs d'ordres, ma\u238?tres d'ouvrage, et autres
parties int\u233?ress\u233?es, on risque de ne recueillir que peu d'informations,
et tr\u232?s peu d'exigences exploitables. D'une part, par ce qu'au-del\u224? de
dix ou douze participants, une grande partie d'entre eux sera inactive et risquera
m\u234?me de perturber les autres, et d'autre part, par ce qu'il est difficile de
d\u233?fricher le terrain, d'\u233?couter tous les besoins, et d'obtenir un
consensus dans un milieu trop h\u233?t\u233?rog\u232?ne.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences 1. Dar&Requirements by collaboration,
Ellen Cottesdiener donne de nombreuses techniques et m\u233?thodes de recueil par
ateliers de travail. Les groupes de travail organis\u233?s Une m\u233?thode des
plus efficaces consiste \u224? r\u233?unir les parties prenantes par profil : une
premi\u232?re r\u233?union avec le ma\u238?tre d'ouvrage strat\u233?gique, puis une
r\u233?union avec des repr\u233?sentants des utilisateurs d'un m\u233?tier, puis
d'un autre m\u233?tier. Une fois que les besoins des diff\u233?rents contributeurs
seront recueillis, on programmera une r\u233?union \u171? mixte \u187? avec le
repr\u233?sentant de chaque m\u233?tier ou profil utilisateur. De tels ateliers1
peuvent \u233?galement r\u233?unir ma\u238?trise d'ouvrage et ma\u238?trise
d'ceuvre, ou utilisateurs et d\u233?veloppeurs, dans un m\u234?me lieu. L'animation
de ces ateliers de travail, qui peuvent durer plusieurs jours, n'est pas chose ais\
u233?e. Au moins deux animateurs sont n\u233?cessaires : l'analyste ou assistant \
u224? la ma\u238?trise d'ouvrage, et une personne charg\u233?e 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 pr\u233?
paration, de la part de tous les participants, mais surtout de la part de
l'animateur. De plus, certaines r\u232?gles doivent imp\u233?rativement \u234?tre
respect\u233?es : \u8226? choisir avec soin un nombre limit\u233? de participants
(quatre \u224? cinq, plus les animateurs) ; \u8226? faire respecter une bonne
discipline de travail \u224? tous les participants : arrivera l'heure, \u233?
teindre son t\u233?l\u233?phone mobile, \u233?viter toute conversation en apart\
u233?, respecter les divers avis ; \u8226? rester align\u233? avec les objectifs
tels qu'ils ont \u233?t\u233? formalis\u233?s ; \u8226? maintenir la discussion au
bon niveau de d\u233?tail : \u233?viter de descendre trop dans les d\u233?tails, ou
au contraire de remettre en cause les objectifs ; \u8226? si de nouvelles id\u233?
es apparaissent et semblent int\u233?ressantes, \u233?viter de d\u233?vier, mais
conserver ces id\u233?es \u224? part, de mani\u232?re \u224? y revenir plus tard,
lors d'un autre atelier par exemple ; \u8226? fixer un ordre du jour pr\u233?cis,
avec une dur\u233?e pr\u233?cise pour chaque point, et s'y tenir ; \u8226?
maintenir jusqu'au bout l'enthousiasme du d\u233?but. L'interview structur\u233?e
individuelle Utilit\u233? et technique d'interview Cette technique est utile, voire
indispensable, pour conna\u238?tre les besoins individuels des utilisateurs. Elle
se focalise sur une partie du processus, en particulier celle dont l'utilisateur
est expert ou praticien (mais pas Q\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil seulement). La difficult\u233? est de trouver
le bon \u233?chantillon d'utilisateurs, et de poser les questions ad\u233?quates en
fonction des objectifs \u224? atteindre. L'interview structur\u233?e permet g\u233?
n\u233?ralement de recueillir ou de pr\u233?ciser des besoins dont les utilisateurs
sont conscients. Ce point est \u224? noter, car d'autres techniques, comme le
brainstorming, l'observation directe, et dans une large mesure les ateliers de
travail, permettent de faire \u233?merger des besoins bien r\u233?els dont les
utilisateurs n'ont pas conscience. D\u233?roulement de l'interview Les \u233?tapes
d'une interview sont les suivantes : 1. Pr\u233?paration. La pr\u233?paration est
indispensable \u224? une interview efficace. Elle sera d'autant plus longue et
importante que l'intervieweur sera novice dans cette technique et son expertise \
u233?loign\u233?e du domaine d'application. - Collecte et lecture de documents,
relecture des interviews pr\u233?c\u233?dentes, de l'existant, du contexte. - Pr\
u233?paration des questions : questions g\u233?n\u233?riques, questions g\u233?n\
u233?rales de contexte, questions pr\u233?cises \u224? l'interview\u233?, questions
de compl\u233?ment d'autres interviews. - Planification de l'interview et
ordonnancement des questions. Une interview dure environ une heure, maximum une
heure et demie. Les questions doivent appara\u238?tre comme une suite logique,
allant du g\u233?n\u233?ral au particulier. 2. Interview sur le terrain, de pr\
u233?f\u233?rence pr\u232?s du lieu de travail de l'interview\u233? (il sera plus \
u224? l'aise), mais pas directement sur son lieu de travail (il risque d'\u234?tre
interrompu). - Ouverture de l'interview : l'intervieweur se pr\u233?sente, rappelle
l'objectif et du temps dont on dispose. - Questionnement : l'intervieweur pose la
question de la grille et note la r\u233?ponse. Il reformule si n\u233?cessaire et
fait pr\u233?ciser les points qui ne lui paraissent pas clairs. L'op\u233?ration
est r\u233?p\u233?t\u233?e jusqu'\u224? ce que l'interview\u233? accepte la
reformulation de l'intervieweur. - Cl\u244?ture : l'interviewer rappelle les points
principaux, relit les besoins tels que formul\u233?s par \u233?crit et indique s'il
y aura un compte-rendu et si ce compte-rendu devra \u234?tre formellement valid\
u233?. 3. Finalisation. L'intervieweur relit ses notes, structure les informations
et r\u233?dige le compte-rendu. Il envoie le compte-rendu \u224? l'interview\u233?
pour validation. Ce dernier peut faire ses remarques. L'intervieweur peut compl\
u233?ter l'interview en posant des questions suppl\u233?mentaires, souvent par t\
u233?l\u233?phone.\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences Poser des questions efficacement
L'interview contient en \u171? mod\u232?le r\u233?duit \u187? les quatre \u233?
tapes du d\u233?veloppement des exigences. Et dans le cadre d'une interview, chaque
question pos\u233?e est elle-m\u234?me un microprocessus recueil-analyse-sp\u233?
cification- validation : \u8226? Recueil : l'intervieweur pose une question et
recueille de l'information. \u8226? Analyse : en s\u233?ance ou \u171? \u224? froid
\u187?. l'intervieweur cherche \u224? prioriser les r\u233?ponses et cherche les
incoh\u233?rences. Il peut, en s\u233?ance, dessiner des diagrammes pour s'assurer
que lui et son interlocuteur ont compris la m\u234?me chose. \u8226? Sp\u233?
cification : en s\u233?ance, l'intervieweur reformule la r\u233?ponse ou pose des
questions suppl\u233?mentaires pour obtenir une exigence bien formul\u233?e le plus
en amont possible. \u192? froid, il r\u233?dige le compte-rendu d'interview avec
pr\u233?cision. \u8226? Validation : en s\u233?ance, l'intervieweur cherche \u224?
associer \u224? chaque exigence des crit\u232?res d'\u233?valuation. Par la suite,
il demandera \u224? l'interview\u233? de valider le compte-rendu. Cette approche
consistant \u224? consid\u233?rer chaque activit\u233? et chaque t\u226?che comme
un cycle contenant toutes les autres \u233?tapes est tr\u232?s efficace. L'id\u233?
e est de d\u233?couvrir le plus t\u244?t possible les incoh\u233?rences, incompl\
u233?- tudes et insuffisances des exigences, tant dans leur formulation que dans
leur structure. Les types de questions Une grille d'interview, pr\u233?par\u233?e \
u224? l'avance, est utile. Elle contient des questions types \u224? poser. Les
questions ouvertes permettent de comprendre le contexte de travail, et les besoins
imm\u233?diats. Ce sont des questions en < comment \u187?. Par exemple, \u171?
comment faites-vous actuellement pour enregistrer une demande de pr\u234?t ? \
u187?. Les questions en \u171? quoi \u187? permettent de d\u233?rouler un processus
: < une fois que vous avez fini cette action, que faites-vous ? \u187?. Et ainsi de
suite. Cette mani\u232?re de proc\u233?der permet de recueillir les exigences du m\
u234?me niveau appartenant \u224? une s\u233?quence. Les questions en \u171?
comment \u187? permettent d'apporter plus de d\u233?tails : \u171? concr\u232?
tement, comment faites-vous ? \u187?. Ce type de question permet donc de descendre
des exigences de haut niveau aux exigences op\u233?rationnelles. Inversement, la
question \u171? pourquoi \u187? est utile pour prendre de la hauteur (figure 8-2).
O\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil Figure 8-2 : Navigation entre niveaux
d'exigences Il est possible d'encha\u238?ner les < pourquoi \u187? pour remonter au
niveau de besoin ad\u233?quat par rapport \u224? l'objectif fix\u233?. Voici une s\
u233?quence d'interview en pourquoi : < Il nous faut une case \u224? cocher "membre
du conseil" (expression d'une solution en termes d'interface utilisateur, beaucoup
trop bas). Question Pourquoi une case \u224? cocher ? R\u233?ponse On doit pouvoir
indiquer au syst\u232?me qu'un de nos adh\u233?rents est membre du conseil
d'orientation (il s'agit l\u224? d'une exigence fonctionnelle, correctement formul\
u233?e, mais sans doute encore de trop bas niveau). Question Pourquoi doit-on
pouvoir indiquer cela au syst\u232?me ? R\u233?ponse \u192? tout moment, un
utilisateur qui interroge le dossier d'un adh\u233?rent doit savoir s'il s'agit
d'un membre du conseil d'orientation. \u187? En posant deux questions \u171?
pourquoi ? \u187?2, on a ainsi trouv\u233? une exigence globale, qui est un
invariant du syst\u232?me \u224? construire. Cela va sans dire, une exigence
formul\u233?e de cette mani\u232?re pose les bases d'un logiciel mieux construit et
plus maintenable. L'exigence peut \u234?tre sp\u233?cifi\u233?e dans le cahier des
charges : \u192? tout moment, au cours d'une consultation, le syst\u232?me doit
donner \u224? l'utilisateur la possibilit\u233? de savoir si un adh\u233?rent est
membre du conseil d'administration. 2. Exercice : poser encore deux questions en
pourquoi pour remonter jusqu'\u224? un objectif.\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences En revanche, la question \u171? pourquoi \
u187? pos\u233?e \u224? titre personnel est \u224? proscrire, car elle peut \u234?
tre ressentie comme une agression. La premi\u232?re question de l'exemple pr\u233?
c\u233?dent devient, en caricaturant \u171? mais pourquoi voulez-vous \u224? tout
prix cliquer sur cette case ? \u187?. M\u234?me sans aller jusque-l\u224?, une
question \u171? pourquoi \u187? impliquant la personne interview\u233?e doit \u234?
tre \u233?vit\u233?e. ferfo^ au d\u226?our tfurte Urt\u202?rview, on a la surprise
rfertendre n\u244?tf\u244? intefteaiteur \u233?iKmcerti\u232?s&\u238?\u238?iieme^
plus nen \u224? faire qu'\u224? fr leîerdesdiaBget C'est l\u224? une stirprte
magique. Qties'estfl pass\u233??Si notre interta^ d\u235?pt\u226?\u239?^ min\u233?
som toutes les coutures, fe hiHti\u234?me jou\u233? le rte de Fanalysifit^ un bon
esprit de synth\u232?se. Existe*^ ura technkpie po^^ spVmtante \u187? de la ^
simpfissinie sur le pri avec beaucoup tfatt\u232?n^ estenconfiaiK\
u233?,dansunew'tf^^ l\u233?^leiKft\u233?ttta\u224?ieMjfe Lorso^ votre
intert\'5c5cuteur a fmi rnoiits, avant de repreiKlre la parde. Sept s^ secret d\
u232?s jn\u232?jfleurs in\u339?^ feire un analyste. Et surtout, un des rnonieimles
pfeisp^ m\u233?tier. De l'ouverture \u224? la pr\u233?cision Un des secrets de
l'efficacit\u233? du processus de d\u233?veloppement des exigences r\u233?side dans
la capacit\u233? \u224? faire passer les besoins par un \u171? entonnoir \u187?,
c'est-\u224?-dire un tuyau tr\u232?s large \u224? une extr\u233?mit\u233? et tr\
u232?s \u233?troit \u224? l'autre. Cela se voit au niveau du macroprocessus : l'\
u233?tape de recueil est ouverte, et autorise l'expression des besoins sous une
forme large, peu pr\u233?cise. \u192? l'autre bout du tuyau, la validation ne
laisse passer que des exigences extr\u234?mement pr\u233?cises. Entre les deux, les
phases d'analyse, puis de validation, resserrent progressivement la pr\u233?cision.
Mais l'entonnoir peut aussi \u234?tre appliqu\u233? au niveau du microprocessus.
Une question peut \u234?tre pos\u233?e de mani\u232?re tr\u232?s ouverte, puis
resserr\u233?e par reformulations progressives. Et un des moyens pour y arriver
consiste \u224? filtrer les g\u233?n\u233?ralisations, les distorsions et les
omissions. o\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil Les g\u233?n\u233?ralisations On les d\u233?
tecte de deux fa\u231?ons. \u8226? Par l'emploi de quantificateurs universels
(tous, toujours, jamais, personne, chaque fois. etc.). Le travail de l'analyste
consiste \u224? reformuler en encourageant la pr\u233?cision. Par exemple :
Interview\u233? (utilisateur) < Dans cet \u233?tablissement, tout le personnel a
acc\u232?s \u224? l'application par un identifiant et un mot de passe. Analyste
Tout le personnel ? Interview\u233? (utilisateur) Enfin, non, pas tous. Le
personnel de l'entretien des locaux et les int\u233?rimaires n'y ont pas acc\u232?
s. \u187? \u8226? Une autre cat\u233?gorie de g\u233?n\u233?ralisations se
manifeste par les op\u233?rateurs modaux (il faut, on doit, etc.) L\u224? aussi,
c'est l'occasion de pr\u233?ciser les besoins, ou de d\u233?tecter une faille dans
le processus : Interview\u233? (utilisateur) < \u192? son embauche, un employ\u233?
doit s'inscrire aupr\u232?s du service informatique pour obtenir un code d'acc\
u232?s. Analyste Que se passe-t-il s'il ne le fait pas ? Interview\u233?
(utilisateur) Eh bien, dans ce cas. il ne pourra pas acc\u233?der au syst\u232?
me. \u187? La d\u233?tection et le traitement des g\u233?n\u233?ralisations sont un
bon moyen de trouver ce qui. dans un cas d'utilisation, s'appelle le sc\u233?nario
alternatif, ou les exceptions. Les omissions Les omissions passent sous silence une
partie de l'information. On trouve dans cette cat\u233?gorie : \u8226? Les
omissions simples Interview\u233? (utilisateur) < )e traite le dossier. Analyste
Quel dossier ? (ou : en quoi consiste le traitement du dossier ?) \u187? \u8226?
Les omissions par comparaison Interview\u233? (utilisateur) \u171? Cette
application est plus rapide. Analyste Plus rapide que quoi ?\par\pard\plain\
hyphpar} {
ie 2 - D\u233?veloppement des exigences Interview\u233? (utilisateur) Plus rapide
que l'application X du service Y. \u187? \u8226? Les omissions par manque d'index
de r\u233?f\u233?rence qui omettent l'acteur Interview\u233? (utilisateur) \u171?
On acc\u232?de au syst\u232?me par un code d'acc\u232?s temporaire. Analyste Oui
acc\u232?de par un code temporaire ? Interview\u233? (utilisateur) Les int\u233?
rimaires et les sous-traitants. \u187? Le traitement des omissions permet de
recueillir plus d'informations qu'une reformulation simple. Il am\u233?liore la pr\
u233?cision et la compl\u233?tude des informations recueillies sans attendre la
phase d'analyse ou de sp\u233?cifications. Les distorsions Enfin les
distorsions : \u8226? La divination Interview\u233? (utilisateur) \u171? Les secr\
u233?taires ne sont pas satisfaites de cette application. Analyste Comment cela se
manifeste-t-il ? \u187? La r\u233?ponse \u224? cette question va peut-\u234?tre
permettre de comprendre si les secr\u233?taires sont v\u233?ritablement
insatisfaites de l'application ou si le probl\u232?me est ailleurs. \u8226? Le lien
de cause \u224? effet Interview\u233? (utilisateur) \u8364? Le logiciel n'est pas
utilis\u233?, il manque d'ergonomie. Analyste Est-ce vraiment le manque d'ergonomie
qui freine l'adoption du logiciel ? \u187? Une mani\u232?re moins abrupte de
reformuler la question est de rebondir : \u171? En dehors de l'ergonomie, que
manque-t-il \u224? ce logiciel ? \u187? D\u233?tecter les distorsions permet g\
u233?n\u233?ralement d'augmenter la pr\u233?cision de la formulation du besoin.
Attention aux effets inattendus Demander un peu plus de pr\u233?cision de la part
de son interlocuteur est un bon moyen d'anticiper, lorsque cela est possible, sur
les phases d'analyse O\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil et de sp\u233?cification3. Plus on anticipe au
moment de l'interview, plus on capte d'informations pr\u233?cises, et plus on \
u233?limine rapidement les ambigu\u239?t\u233?s, impr\u233?cisions, et incompl\
u233?tudes. La recherche de la pr\u233?cision est un investissement rentable, car
une accumulation d'impr\u233?cisions et d'incoh\u233?rences co\u251?te beaucoup
plus cher \u224? d\u233?tecter et \u224? \u233?liminer apr\u232?s coup. Cependant,
une interview n'est pas un interrogatoire de police. Il faut faire attention \u224?
ne pas \u171? forcer \u187? l'interlocuteur. Il a le droit d'\u234?tre impr\u233?
cis, et m\u234?me incoh\u233?rent. Et surtout, il a le droit d'avoir son jargon.
C'est \u224? l'analyste de s'adapter. Il faut donc \u234?tre prudent, surtout au d\
u233?but de l'\u233?laboration du cahier des charges, surtout au d\u233?but d'une
interview. En tout \u233?tat de cause, il est inutile de rechercher la pr\u233?
cision si cela va jusqu'\u224? \u233?nerver notre interlocuteur. Mieux vaut
patienter, rechercher les informations \u224? une autre source, que de risquer de
bloquer le processus. 3. Lors de la phase de sp\u233?cification et de validation,
les impr\u233?cisions et incoh\u233?rences seront d\u233?tect\u233?es au moyen de
checMists. Le brainstorming Technique cr\u233?ative, le brainstorming est surtout
utile pour le d\u233?veloppement d'un nouveau produit, lorsqu'il s'agit de faire
jaillir de nouvelles id\u233?es. Une s\u233?ance brainstorming bien men\u233?e
permet de recueillir des exigences dont les utilisateurs ne sont pas conscients.
Cette technique permet aussi de s'attaquer4 \u224? un probl\u232?me qui sort des
cat\u233?gories habituelles. C'est le cas d'un projet qui fait l'objet de tr\u232?s
nombreuses contraintes. Dans un tel cas, une nouvelle id\u233?e originale permet de
r\u233?soudre ces contraintes en sortant du cadre habituel de r\u233?flexion. Le
brainstorming peut \u233?galement s'av\u233?rer utile lorsque ma\u238?trise
d'ouvrage et ma\u238?trise d'\u339?uvre sont en conflit (larv\u233? ou ouvert) et
que les diff\u233?rents intervenants de la ma\u238?trise d'ouvrage n'ont pas une
id\u233?e tr\u232?s claire de ce qu'ils souhaitent. Recueillir les diff\u233?rentes
fonctions ou contraintes sur des Post-lt* et les \u233?taler sur un mur ou un
tableau peut permettre de clarifier la situation. Une telle s\u233?ance de
brainstorming peut \u234?tre suivie d'un diagramme des affinit\u233?s ou d'une
maquette papier. 4. Brainstorming. Terme invent\u233? par Alex Osbome de brain,
(cerveau), et to stonn, (attaquer, assaillir). Il ne s'agit donc pas d'une \u9632?
temp\u234?te dans un cerveau \u187?, mais de s'attaquer mentale* ment,
collectivement, \u224? une difficult\u233?. Le diagramme des affinit\u233?s La m\
u233?thode du diagramme des affinit\u233?s est utile lorsqu'il s'agit de < faire le
tour de la question \u187?, d'en voir les diff\u233?rents aspects, et de les
classer par cat\u233?gories. Les \u233?tapes de la m\u233?thode sont les
suivantes : \u8226? L'animateur expose le probl\u232?me aussi clairement que
possible.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences \u8226? Chaque participant \u233?crit
une ou plusieurs r\u233?ponses au probl\u232?me, chacune d'elle sur une fiche (par
exemple, une fiche adh\u233?sive de type Post-lt*). \u8226? L'animateur ramasse les
r\u233?ponses et les expose \u224? l'ensemble des participants. Il \u233?tale les
fiches sur une table ou les colle sur un mur. \u8226? Les participants regroupent
les fiches par cat\u233?gories, sans avoir \u224? se justifier ; un participant
peut d\u233?placer une fiche d'une cat\u233?gorie \u224? une autre. \u8226? Le
regroupement en cat\u233?gories conti nue. jusqu'\u224? obtention d'un consensus. \
u8226? On peut cr\u233?er des sous-cat\u233?gories. \u8226? Les participants
donnent un nom \u224? chaque cat\u233?gorie et sous-cat\u233?gorie. Plusieurs
variantes \u224? cette technique existent, en fonction du type de probl\u232?me \
u224? traiter. Elle est surtout utile lors des premi\u232?res \u233?tapes de
recueil et d'analyse des besoins, par exemple, pour conna\u238?tre les parties
prenantes ou pour d\u233?terminer les grandes fonctions attendues du syst\u232?me
(figure 8-3). Prescrire des m\u233?dicaments R\u233?diger la prescription Signer la
prescription Consulter le dossier du patient R\u233?pondre \u224? l'avis
pharmaceutique Administrer des m\u233?dicaments Lire la prescription Valider 1'
administration Analyser la prescription Donner un avis pharmaceutique Pr\u233?parer
les doses G\u233?rer les stocks de m\u233?dicaments Figure 8-3 : Diagramme des
affinit\u233?s L'observation directe Observer un utilisateur sur le lieu de son
travail est souvent le moyen le plus simple de conna\u238?tre ses besoins. C'est
aussi un moyen de conna\u238?tre ses difficult\u233?s et les probl\u232?mes qu'il
rencontre (avec le logiciel actuel ou en l'absence de logiciel) de mani\u232?re \
u224? formuler des exigences qui aboutiront \u224? un produit bien adapt\u233? \
u224? leurs besoins. O\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil Certains utilisateurs (ou futurs utilisateurs)
sont capables de mod\u233?liser eux-m\u234?mes leur travail, c'est-\u224?-dire d\
u233?crire la succession des t\u226?ches qui le constituent. D'autres sont beaucoup
plus \u224? l'aise lorsqu'ils sont dans l'action. L'observation peut \u234?tre
neutre, \u224? distance, l'observateur se faisant le plus discret possible. Elle
peut \u234?tre plus intrusive, l'observateur posant \u224? l'utilisateur des
questions sur la mani\u232?re dont il s'y prend. Cette technique a ses limites.
Elle permet de recueillir les besoins op\u233?rationnels pour des op\u233?rations
visibles, les op\u233?rations intellectuelles \u233?tant difficilement observables
et analysables de l'ext\u233?rieur. Avec cette technique, on ne pourra d\u233?crire
les besoins g\u233?n\u233?riques ou de haut niveau qu'apr\u232?s analyse de
nombreuses observations. Les questionnaires Le questionnaire est un moyen facile de
recueillir des opinions ou des donn\u233?es de la part d'un grand nombre de
personnes. Cependant, cette technique n'encourage pas la cr\u233?ativit\u233? et
l'\u233?mergence de nouvelles id\u233?es. La technique la plus courante consiste \
u224? utiliser une \u233?chelle de Likert. Les cat\u233?gories de r\u233?ponses,
sur une \u233?chelle comportant quatre \u224? sept niveaux, sont formul\u233?es de
mani\u232?re \u224? ce que leur signification soit claire pour tout le groupe de
personnes interrog\u233?es. Les questions ferm\u233?es (cases \u224? cocher)
facilitent l'analyse. Mais l'\u233?laboration de telles questions est loin d'\u234?
tre un exercice facile. Les questions doivent \u234?tre tr\u232?s claires, sp\u233?
cifiques, neutres (ne pas induire la r\u233?ponse) et formul\u233?es avec le
vocabulaire de celui qui r\u233?pond. Il est possible d'ajouter quelques questions
ouvertes lorsque le questionnaire s'adresse \u224? un petit nombre de personnes.
Pour \u233?laborer le questionnaire, les questions \u224? se poser sont : \u8226?
Quel est l'objectif du questionnaire ? Que veut-on savoir pr\u233?cis\u233?ment ? \
u8226? Comment cette information peut-elle \u234?tre fournie ? \u8226? Quel est le
degr\u233? de pr\u233?cision recherch\u233? ? \u8226? Quel est le nombre de
questions \u224? poser pour avoir les informations recherch\u233?es ? \u8226?
Combien de questions est-il r\u233?aliste de poser ? \u8226? Qui va exploiter les
r\u233?ponses et comment ?\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences La r\u233?utilisation d'exigences Un
cahier des charges d'un autre logiciel, ou d'une version pr\u233?c\u233?dente du m\
u234?me logiciel, peut contenir des exigences r\u233?utilisables. Souvent, le
recueil consiste alors \u224? simplement reprendre les exigences, \u233?
ventuellement en mettant \u224? jour le vocabulaire. On v\u233?rifiera sa
compatibilit\u233? avec les autres exigences, pour \u233?viter redondances et
incoh\u233?rences. L'analyse de produits existants \u192? d\u233?faut de cahier des
charges existant, on peut examiner un logiciel d\u233?j\u224? en production. Il
sera tr\u232?s riche en enseignements. Il est bien entendu possible d'examiner un
produit d\u233?j\u224? en production, qui arrive en fin de vie. que l'on souhaite
remplacer ou red\u233?velopper. L'analyse d'un produit existant permet dans ce cas
de d\u233?couvrir des exigences implicites, des fonctions utilis\u233?es au
quotidien, mais dont les utilisateurs n'ont pas conscience. On peut \u233?galement
analyser un produit concurrent de celui que l'on souhaite d\u233?velopper ou faire
d\u233?velopper. Si la loi interdit de < d\u233?compiler \u187? un logiciel, rien
n'interdit en revanche de l'analyser sur le plan comportemental. \u192? ce propos,
un \u233?diteur d'un logiciel pourtant \u171? pointu \u187? \u224? qui on disait
que son produit \u233?tait le meilleur du march\u233? a r\u233?pondu qu'il avait \
u8364? achet\u233?, install\u233? et test\u233? tous les produits de la concurrence
\u187?. Cela ne l'emp\u234?chait pas de proposer des fonctions innovantes
introuvables ailleurs. Rechercher l'inFormation l\u224? o\u249? elle se trouve Nous
avons vu qu'il y a diff\u233?rents niveaux d'exigences. \u192? chaque niveau, les
exigences seront recueillies aupr\u232?s d'un interlocuteur diff\u233?rent, avec
des techniques diff\u233?rentes. Le donneur d'ordres va apporter les exigences du
plus haut niveau, c'est- \u224?-dire les objectifs. On utilisera l'interview
structur\u233?e, ou les r\u233?unions en petit comit\u233?. Les techniques comme le
brainstorming ou le diagramme des affinit\u233?s peuvent \u234?tre tr\u232?s
utiles, mais rarement possibles dans la pratique. Les objectifs doivent \u234?tre
recueillis le plus souvent chez des dirigeants ou les cadres sup\u233?rieurs, et il
est difficile de r\u233?unir tous ces d\u233?cideurs pendant une heure trente sur
le th\u232?me \u171? brainstorming \u187?. L'interview face \u224? face est la
technique la plus indiqu\u233?e dans ce cas. G\u239?\par\pard\plain\hyphpar} {
Chapitre 8 - L'\u233?tape de recueil Pour recueillir les besoins des utilisateurs,
les groupes de travail d'une journ\u233?e \u224? intervalles de deux ou trois
semaines, programm\u233?s longtemps \u224? l'avance, sont les plus efficaces.
L'observation directe, sur site, est consommatrice de temps pour l'analyste. Si
celui-ci est habile et discret, un grand nombre d'observations peuvent \u234?tre
faites avec un minimum de perturbation des utilisateurs au travail. L'observation
directe altern\u233?e avec les groupes de travail est tr\u232?s utile, l'une
permettant de valider l'autre. Objectifs Interview Individuelle Exigences
d'entreprise. ttt Ma\u238?trise d'ouvrage R\u233?unions R\u232?gles de gestion,
Contraintes techniques tt Experts techniques ttt Interviews. r\u233?unions Experts
m\u233?tier Exigences S . . . . . . . . . . . \'5cQuestionnalres. uateW- ffff\
u239?\u239?ff f|| ffffffV \'5c ,ntwvk)ws. Groupes de travail utilisateurs r\u233?
unions. Figure 84 : Recueillir l'exigence au bon niveau Les bonnes pratiques Que ce
soit au cours d'une interview ou lors d'une r\u233?union de travail, un certain
nombre de bonnes pratiques doit \u234?tre respect\u233? si l'on veut travailler
efficacement. Recueillir les besoins au bon niveau Comme nous l'avons vu, les
exigences devront \u234?tre recueillies aupr\u232?s des interlocuteurs idoines. On
recueille les objectifs (exigences du niveau le plus \u233?lev\u233?) aupr\u232?s
de la direction g\u233?n\u233?rale, les exigences les plus d\u233?taill\u233?es
aupr\u232?s des utilisateurs sur le terrain. Ce principe g\u233?n\u233?ral pose la
question de l'ordre dans lequel seront men\u233?es les interviews. A priori,
l'ordre id\u233?al est celui qui consiste \u224? partir des objectifs (donc du ma\
u238?tre d'ouvrage strat\u233?gique), puis \u224? descendre progressivement vers
plus de d\u233?tails jusqu'aux utilisateurs les plus op\u233?rationnels. Outre le
fait que cela n'est pas toujours possible, cela pose d'autres difficult\u233?s : si
l'on veut \u233?viter de poser au directeur g\u233?n\u233?ral des questions dont la
r\u233?ponse est facile \u224? trouver aupr\u232?s des op\u233?rationnels O\par\
Partie 2 - D\u233?veloppement des exigences 5. Une astuce : util\u187?* ser le mode
r\u233?vision d'un traitement de texte (si on ma\u238?trise cette technique), ou
utiliser des para* graphes de couleurs diff\u233?rentes pour visualiser les
modifications nouvellement int\u233?gr\u233?es. (mais a priori inconnue de
l'intervieweur), il faudrait les avoir interview\u233?s avant. Apporter un retour
rapide aux interlocuteurs Suite \u224? un entretien ou \u224? une r\u233?union de
recueil, il est utile de r\u233?diger un compte-rendu. C'est une bonne pratique
bien connue, et \u233?galement une marque de courtoisie \u224? l'\u233?gard de ses
interlocuteurs. R\u233?diger un compte- rendu d\u233?taill\u233? et pr\u233?cis pr\
u233?sente aussi quelques inconv\u233?nients car cela prend du temps qui pourrait
souvent mieux \u234?tre utilis\u233? ; on se retrouve avec un grand nombre d\u233?
comptes-rendus, qui constituent une documentation lourde \u224? g\u233?rer. Une
mani\u232?re plus efficace de proc\u233?der consiste \u224? : \u8226? lors d'une
interview ou r\u233?union, donner aux interlocuteurs un feedback imm\u233?diatement
apr\u232?s l'expression d'un besoin : \u8226? suite \u224? une interview ou une r\
u233?union, utiliser le cahier des charges lui- m\u234?me comme compte-rendu. Tr\
u232?s concr\u232?tement, au cours du recueil, il est utile de donner un retour
direct (un feedback) \u224? ses interlocuteurs, sous forme de reformulation de ce
qui vient d'\u234?tre dit, \u233?ventuellement en utilisant un moyen de
communication diff\u233?rent, par exemple un sch\u233?ma. Cela rassure les
interlocuteurs et \u233?vite de partir dans une fausse direction. Puis, suite \
u224? l'entrevue ou la r\u233?union, on int\u233?grera ce qui a \u233?t\u233?
formul\u233? dans le cahier des charges, et on le soumettra \u224? la validation5
des participants. Attention : il ne s'agit en aucun cas de court-circuiter les \
u233?tapes d'analyse et de sp\u233?cification, mais de faire une analyse partielle
et une sp\u233?cification des besoins qui ont \u233?t\u233? formul\u233?s lors de
la r\u233?union. Parler le langage du client De mani\u232?re g\u233?n\u233?rale, si
on veut faciliter la communication, il faut apprendre et utiliser le langage du ma\
u238?tre d'ouvrage plut\u244?t que de forcer ce dernier \u224? utiliser notre
jargon technique. Par langage, on entend bien s\u251?r le vocabulaire, mais \u233?
galement la mani\u232?re de repr\u233?senter l'information. Un juriste a l'habitude
de travailler sur du texte. Si un sch\u233?ma simple peut \u233?ventuellement
l'aider, un sch\u233?ma complexe (ceux dont raffolent justement les informaticiens)
est \u224? \u233?viter. Inversement, si les utilisateurs sont des informaticiens ou
des ing\u233?nieurs, un sch\u233?ma sera souvent plus parlant qu'un texte. Lever
toute ambigu\u239?t\u233? au fil de l'eau Les mots ont souvent un sens diff\u233?
rent d'un m\u233?tier \u224? l'autre, m\u234?me au sein d'une m\u234?me
organisation. Rappelons \u224? ce sujet que tout terme un 0\par\pard\plain\hyphpar}
{
Chapitre 8 - L'\u233?tape de recueil tant soit peu ambigu devra \u234?tre inclus
dans un glossaire. Ce glossaire, qui fait partie du cahier des charges, devra \
u234?tre enrichi tout au long du processus de son \u233?laboration. Maintenir la
coh\u233?rence le plus en amont possible Les \u233?tapes d'analyse, de sp\u233?
cification et de validation sont pr\u233?sent\u233?es dans les chapitres suivants
de cet ouvrage. Mais certaines des op\u233?rations de ces \u233?tapes peuvent \
u234?tre effectu\u233?es en amont, en phase de recueil : \u8226? suite \u224? une
interview, r\u233?aliser un examen rapide de la coh\u233?rence avec les notes
d'autres interviews, afin de d\u233?tecter des incoh\u233?rences ou des manques ; \
u8226? lors d'une r\u233?union de recueil, repr\u233?senter l'information sous
forme de sch\u233?ma ; \u8226? \u224? la suite d'une interview, et si n\u233?
cessaire, envoyer un bref compte-rendu \u224? la personne interview\u233?e pour
validation. En cas de conflit entre exigences, il est important qu'il soit r\u233?
solu avant de poursuivre. L'analyse des parties prenantes qui a \u233?t\u233? faite
pendant l'\u233?tape pr\u233?paratoire permet de savoir qui a plus de poids.
Trouver le d\u233?cideur qui tranchera le conflit est important, mais cela demande
de l'habilit\u233?. Le d\u233?cideur n'est pas toujours le futur utilisateur, il
n'est pas au-dessus des lois et des r\u232?glements, mais il joue un r\u244?le cl\
u233?. Cette activit\u233? rel\u232?ve de la n\u233?gociation des exigences (que
certains auteurs consid\u232?rent comme une \u233?tape \u224? part enti\u232?re
dans le processus de d\u233?veloppement et de gestion des exigences). Si les
conflits entre exigences ne sont pas r\u233?gl\u233?s pendant la phase d'exigences
(et de pr\u233?f\u233?rence pendant le recueil, ou juste apr\u232?s), qui se
chargera de le faire ? Les \u233?quipes de la phase suivante, c'est-\u224?-dire les
concepteurs-d\u233?veloppeurs. Ce n'est pas leur r\u244?le. Recueillir les besoins
et non les solutions D\u232?s l'\u233?tape de recueil, il est important de ne
retenir que les besoins, et non les solutions. M\u234?me chez les assistants \u224?
ma\u238?trise d'ouvrage exp\u233?riment\u233?s, exprimer des solutions en lieu et
place des besoins est une erreur fr\u233?quente. En effet, il existe une \u171?
zone floue \u187? entre les exigences et la conception, et il n'est jamais facile
de savoir quand s'arr\u234?ter. Recueillir les besoins alternatifs et exceptionnels
On a naturellement tendance \u224? recueillir le \u171? flux normal \u187? d'un
processus, et \u224? exprimer les besoins correspondant \u224? des conditions
normales. Or, un syst\u232?me doit traiter les situations d'exception, par d\u233?
finition rares et improbables. Tr\u232?s souvent, pour un seul cas normal
d'utilisation du syst\u232?me, il peut exister de nombreux cas exceptionnels. o\
Partie 2 - D\u233?veloppement des exigences Les cas exceptkmr^ sont par d^ Mais
leur l\u233?\u231?\u249?eil p\u232?trt \u232?ta difft\u224?te et leur eux qui
posent proW\u232?me.\u224? toutes les phases du ê tion. Raison de plus pour les
i^^ :Kt\u233?sîiM&^^ un distributeur automatique de biHeter par exerrHrfe en cas
d'err\u233? rrialies\u224?tiaitersuite\u224?urf\u226? En plus des cas exceptionnels
(par exemple, d\u233?passement d'une limite autoris\u233?e ou erreur de la part de
l'utilisateur), il faut penser au comportement que le syst\u232?me devra adopter en
cas d'anomalie du syst\u232?me lui-m\u234?me. Recueillir les besoins positifs, mais
aussi n\u233?gatifs Les besoins n\u233?gatifs, ou exprim\u233?s n\u233?gativement,
sont fort utiles \u224? l'analyste. Le \u171? questionnement n\u233?gatif \u187?
permet de mettre en lumi\u232?re des besoins qui n'auraient pu \u234?tre exprim\
u233?s que difficilement de mani\u232?re positive. C'est aussi un bon moyen de
recueillir les besoins des personnes r\u233?sistantes au changement. La n\u233?
gation est souvent la porte de l'am\u233?lioration, et les personnes r\u233?
sistantes au changement peuvent \u234?tre tr\u232?s cr\u233?atives. Cornitte pour
les besx^ \u234?^ recueilfis par des quest\u187?rfc ouvert^ seniwuve^ le syst\u232?
me a\u233?toel^SJ quelque diose vous d\u233?rangeait avec te syst\u232?me adueL ce
serait quoi ? Que voudr\u238?etvous que le syst\u232?me \u224? t\u224?ift'i\u224?
ssei. que le syst\u232?nie actuel ne fait pas? Faisons tafts^te \u201?couter le
silence Il y a des besoins que l'on recueille plus facilement en creux, dans le
non-dit ou dans le \u171? presque rien \u187?. En posant des questions ouvertes, g\
u233?n\u233?rales, voire impr\u233?cises, vagues, ambigu\u235?s... la r\u233?ponse
vient souvent spontan\u233?ment. Le client compl\u232?te la question impr\u233?cise
par une phrase pr\u233?cise, en employant ses propres mots. L'impr\u233?cision d\
u233?clenche la pr\u233?cision. Une question impr\u233?cise est souvent un moyen
d'aboutir \u224? une formulation pr\u233?cise. Le langage flou permet de formuler
un discours o\u249? chacun entend ce qu'il veut bien. Proscrit de l'\u233?tape de
sp\u233?cifications (c'est de la langue de bois), il est ici utilis\u233? pour
provoquer de la pr\u233?cision de la part de l'interview\u233?. Q\par\pard\plain\
hyphpar} {
Chapitre 8 - L'\u233?tape de recueil Enc\u233?quicwKerr^lafohctkM Tester la
validit\u233? des exigences au plus t\u244?t Il ne s'agit pas de valider les
exigences, mais de les tester au plus t\u244?t. Sont-elles utiles ? Refl\u232?tent-
elles les vrais besoins ? Sont-elles r\u233?alisables \u224? un co\u251?t
raisonnable ? Il s'agit de parcourir, avec l'interview\u233?, le cheminement mental
qui a conduit \u224? l'expression de ce besoin. Parfois, les besoins exprim\u233?s
n'ont aucune utilit\u233?. C'est en particulier le cas lorsqu'un utilisateur a pris
ses habitudes avec un syst\u232?me ancien et veut retrouver les m\u234?mes
fonctionnalit\u233?s dans le nouveau syst\u232?me, alors qu'elles n'ont pas lieu
d'\u234?tre. Un autre moyen consiste, apr\u232?s avoir interview\u233? un
utilisateur et lui avoir fait pr\u233?ciser un besoin, de l'exprimer \u224? 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 \u171?
obsol\u232?te \u187? a \u233?t\u233? exprim\u233? par un sup\u233?rieur hi\u233?
rarchique : le subordonn\u233? ne s'exprimera que s'il a confiance en
l'intervieweur. Check-list de fin d'\u233?tape de recueil La \u171? fin d'\u233?
tape \u187? est hypoth\u233?tique, car les besoins \u233?voluent en permanence,
qu'on ne peut jamais \u234?tre certain d'avoir \u233?puis\u233? la liste
potentielle d'exigences, et que les \u233?tapes sont imbriqu\u233?es : on aura
commenc\u233? \u224? analyser, sp\u233?cifier et valider bien avant d'avoir coch\
u233? tous les points de la check-list. Cette check-list peut \u234?tre utilis\
u233?e \u224? tout moment pour conna\u238?tre l'avancement du recueil des exigences
et \u233?viter de passer \u224? c\u244?t\u233? de points importants. \u8226? On a
soigneusement \u233?tabli la liste des parties prenantes. \u8226? On a formalis\
u233? les attentes de chaque partie prenante. \u8226? Toutes les parties prenantes
sont repr\u233?sent\u233?es et actives. \u8226? On a soigneusement \u233?tabli la
liste des sources d'exigences. \u8226? Les exigences ont \u233?t\u233? recueillies
chez les vrais utilisateurs. \u8226? Toutes les cat\u233?gories d'utilisateurs sont
repr\u233?sent\u233?es. \u8226? Toutes les cat\u233?gories d'utilisateur se sont
exprim\u233?es.\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences \u8226? On a recueilli les exigences
positives, et aussi n\u233?gatives. \u8226? On a donn\u233? un feedback \u224? tous
les participants. \u8226? Les participants ont relu ou revu les besoins exprim\
u233?s. \u8226? Les exigences d\u233?rivent des objectifs. \u8226? On n'a retenu
que les besoins, non des \u233?l\u233?ments de solution.\par\pard\plain\hyphpar} {
Chapitre 9 Les cas d'utilisation Les cas d'utilisation (use cases en anglais) sont
devenus c\u233?l\u232?bres gr\u226?ce, en particulier, \u224? UML (Unt/fed Modeiing
Language). Cependant, les adeptes d'UML utilisent le plus souvent les diagrammes de
cas d'utilisation, ce qui est un peu r\u233?ducteur. Les cas d'utilisation sous
forme textuelle offrent, eux, une grande richesse d'expression. Qu'est-ce qu'un cas
d'utilisation ? Un cas d'utilisation est un contrat de comportement, entre un syst\
u232?me (par exemple, un logiciel) ou un sous-syst\u232?me et des acleurs qui
interagissent avec lui. Ces acteurs peuvent \u234?tre des utilisateurs (humains) du
syst\u232?me ou des syst\u232?mes voisins. Un cas d'utilisation regroupe un
ensemble de sc\u233?narios (figure 9-1 ) qui peuvent, soit aboutir, soit \u233?
chouer. Pour formuler un cas d'utilisation, on doit respecter les contraintes
suivantes : \u8226? Un cas d'utilisation se rapporte \u224? un objectif et un seul.
\u8226? Il d\u233?crit un comportement utile \u224? l'atteinte de cet objectif. \
u8226? La description prend le point de vue d'une (ou plusieurs) partie(s)
prenante(s). \u8226? Il comporte un acteur principal et un seul. \u8226? Il d\u233?
bute avec un \u233?v\u233?nement d\u233?clencheur. \u8226? Il se poursuit jusqu'\
u224? ce que l'objectif soit atteint ou abandonn\u233?.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences M\u233?decin prescripteur S\u233?
lectionner un patient \'5c'7d Saisir la prescription Modifier la prescription 1
<ôM\u232?me)> Non \u9660? Signer la prescription Syst\u232?me v Interroger basem\
u233?d. \'5c'7b Contr\u244?ler les posotogies 1 Contr\u244?ler les interactions
Alimenter le plan de soin Figure 9-1 : Sc\u233?nario de cas d'utilisation 1. Le
plus connu est Alistair Cockbum. Voit R\u233?diger des cas d'utilisation efficaces
publi\u233? aux \u233?ditions Eyrolles. Le contenu d'un cas d'utilisation Un cas
d'utilisation s'exprime essentiellement sous forme textuelle. Les diff\u233?rents
items qui le composent varient selon les auteurs1, le type d'application, le degr\
u233? de pr\u233?cision que l'on veut atteindre gr\u226?ce aux sp\u233?cifications.
Voici une structuration assez classique : \u8226? Acteur principal : c'est la
personne qui. dans le pr\u233?sent cas d'utilisation, interagit avec le syst\u232?
me. \u192? eux deux, ils \u171? ex\u233?cutent \u187? le cas d'utilisation. \u8226?
Autres acteurs : toutes les personnes impact\u233?es par la mise en \u339?uvre du
cas d'utilisation. \u8226? D\u233?clencheur : il s'agit de l'\u233?v\u233?nement
qui d\u233?clenche le cas d'utilisation. En principe, c'est un \u233?v\u233?nement
m\u233?tier (voir le diagramme de contexte). \u8226? Description : description
courte du d\u233?roulement du cas d'utilisation. en\par\pard\plain\hyphpar} {
Chapitre 9 - Les cas d'utilisation \u8226? Pr\u233?conditions : conditions qui
doivent \u234?tre v\u233?rifi\u233?es, pour que le cas d'utilisation d\u233?
marre. \u8226? Postconditions : \u233?galement appel\u233?es garanties en cas de
succ\u232?s. \u201?tat du syst\u232?me \u224? la fin de l'ex\u233?cution du cas
d'utilisation. \u8226? Garanties minimales : \u233?tat du syst\u232?me lors de
l'ex\u233?cution du cas. quelle qu'en soit l'issue. \u8226? Sc\u233?nario nominal :
c'est un sc\u233?nario formul\u233? comme une alternance d'actions de l'utilisateur
et de r\u233?ponses du syst\u232?me. Il d\u233?crit l'ex\u233?cution du cas
d'utilisation dans des conditions attendues. L'ex\u233?cution du sc\u233?nario
permettra d'atteindre l'objectif \u233?nonc\u233? dans le titre du cas
d'utilisation. G\u233?n\u233?ralement, les actions sont num\u233?rot\u233?es. \
u8226? Sc\u233?nario alternatif2 : s\u233?quence alternative du sc\u233?nario. La
num\u233?rotation permet de se raccrocher au flux normal. Par exemple, si on d\
u233?crit une alternative \u224? la s\u233?quence 2-5. on notera les actions 2-5.a.
2-5.b. etc. \u8226? Exceptions : s\u233?quence d\u233?clench\u233?e par une
anomalie ou une erreur lors de l'ex\u233?cution du flux normal ou d'un flux
alternatif. \u8226? Cas indus : liste des cas d'utilisation inclus dans le cas
d'utilisation pr\u233?sent. Les cas inclus sont en quelque sorte des \u171? sous-
cas \u187? (analogues \u224? des sous-programmes). Ils permettent de d\u233?crire
des s\u233?quences qui se retrouvent dans plusieurs cas d'utilisation, ou d'am\
u233?liorer la lisibilit\u233?. \u8226? Fr\u233?quence d'utilisation : nombre
estim\u233? de fois o\u249? ce cas d'utilisation sera ex\u233?cut\u233? par les
acteurs, dans l'unit\u233? de temps appropri\u233?e (jours, heures...). \u8226? R\
u232?gles m\u233?tier : r\u232?gles m\u233?tier auxquelles ce cas est subordonn\
u233?. \u8226? Exigences particuli\u232?res : exigences suppl\u233?mentaires
(exigences non fonctionnelles, contraintes...) qui s'appliquent \u224? ce cas
d'utilisation. \u8226? Notes et questions : remarques particuli\u232?res. Cockbum
et ses adeptes ajoutent les points suivants : \u8226? Port\u233?e de conception :
c'est la largeur du champ de la description ; par exemple l'entreprise, le syst\
u232?me, ou un sous-syst\u232?me. \u8226? Niveau d'objectif : d\u233?signe le
niveau de l'objectif que l'on veut atteindre : niveau strat\u233?gique, niveau
utilisateur (int\u233?resse l'acteur principal), ou niveau d'une sous-fonction. Ces
deux derniers points sont int\u233?ressants, et pour Cockbum, ils devraient \u234?
tre obligatoires pour d\u233?crire un cas d'utilisation. C'est ainsi dans les
projets importants o\u249? l'on d\u233?veloppe un grand nombre de cas
d'utilisation. Ces notions, bien que tr\u232?s utiles, ne sont pas toujours faciles
\u224? manier. 2. Cockbum utilise le terme extensions qui regroupe sc\u233?narios
alternatifs et exceptions.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Avantages des cas d'utilisation Les cas
d'utilisation ont un \u233?norme avantage : ils concilient les litt\u233?raires (au
sens large du terme : c'est-\u224?-dire les personnes port\u233?es sur le langage \
u233?crit plut\u244?t que sur les sch\u233?mas) et les informaticiens. Pour qui a
pratiqu\u233? la programmation, un cas d'utilisation rappelle un algorithme \u233?
crit en pseudo-code. Il pr\u233?sente n\u233?anmoins les exigences sous une forme
ais\u233?ment compr\u233?hensible par tous, ce qui permet d'obtenir facilement une
vision commune, et donc d'aboutir \u224? un consensus entre parties prenantes
(c'est le but du cahier des charges). L'autre avantage est celui du point de vue.
Les cas d'utilisation sont \u233?crits dans la langue de l'utilisateur, et centr\
u233?s sur ses actions. Cela augmente les chances d'obtenir un produit lui-m\u234?
me centr\u233? sur l'utilisateur. Enfin, les exigences r\u233?dig\u233?es de cette
mani\u232?re mod\u233?lisent une activit\u233? r\u233?elle, et donc de vrais
besoins ; avec ce proc\u233?d\u233?, il y a peu de chances qu'un utilisateur
exprime des besoins \u171? gadgets \u187? pour se faire plaisir (ce qui arrive
souvent quand on commence par d\u233?crire l'interface utilisateur). Les cas
d'utilisation offrent plus de chances \u224? l'\u233?quipe de d\u233?veloppement de
r\u233?aliser un logiciel robuste. Ils \u233?vitent les zones floues qui pourraient
\u234?tre mal interpr\u233?t\u233?es pendant le d\u233?veloppement. En d\u233?
crivant tous les sc\u233?narios possibles (combinaisons du sc\u233?nario nominal,
des sc\u233?narios alternatifs et des sc\u233?narios en cas d'\u233?chec), on a
plus de chances de donner aux concepteurs un document coh\u233?rent qu'en leur
fournissant une liste de fonctions. Enfin, \u224? partir des cas d'utilisation, il
est relativement facile de d\u233?duire les cas de test. Les cas d'utilisation sont
donc le \u171? couteau suisse \u187? de la mod\u233?lisation des exigences. Ils
peuvent \u234?tre utilis\u233?s \u224? tous les niveaux, depuis les objectifs
strat\u233?giques jusqu'\u224? la description d'un comportement tr\u232?s d\u233?
taill\u233?. Ils permettent de d\u233?crire des processus, de n\u233?gocier entre
parties prenantes, de faire ressortir (et donc d'anticiper) les probl\u232?mes. \
u192? partir de l\u224?. il sera possible de faire une premi\u232?re estimation des
co\u251?ts de d\u233?veloppement, de reboucler sur les objectifs d\u233?finis plus
en amont, puis de passer \u224? la phase de conception. Les concepteurs pourront
par la suite se servir de cas d'utilisation pour d\u233?crire, non plus les
besoins, mais la solution, et la ma\u238?trise d'ouvrage reprendre la main pour pr\
u233?ciser les sc\u233?narios de recette. Elaboration des cas d'utilisation Les cas
d'utilisation sont un excellent outil d'analyse, mais aussi de recueil et de sp\
u233?cification. Ils s'av\u232?rent utiles pour assembler les besoins \u8364?3\par\
Chapitre 9 - Les cas d'utilisation recueillis aupr\u232?s de plusieurs acteurs,
travailler avec les diff\u233?rents acteurs, interagir avec eux, et faire valider
les exigences correspondantes. En d'autres termes, c'est un bon moyen de
transformer un besoin en exigence. Une s\u233?quence d'\u233?laboration d'un cas
d'utilisation peut \u234?tre la suivante : \u8226? recueillir les besoins de haut
niveau aupr\u232?s de la ma\u238?trise d'ouvrage ; \u8226? en d\u233?duire les cas
d'utilisation ; \u8226? recueillir les besoins aupr\u232?s de diff\u233?rentes
sources (documentation client, produits existants, etc.) ; \u8226? compl\u233?ter
le recueil aupr\u232?s de plusieurs utilisateurs ; \u8226? consolider l'ensemble et
d\u233?gager un ou plusieurs sc\u233?narios ; \u8226? d\u233?crire ces sc\u233?
narios au moyen d'un cas d'utilisation relativement simple ; \u8226? distribuer le
cas d'utilisation aux participants d'un groupe de travail -, \u8226? travailler en
groupe sur le cas d'utilisation pour l'affiner ; \u8226? si n\u233?cessaire, it\
u233?rer sur les \u233?tapes pr\u233?c\u233?dentes. Un autre moyen efficace de d\
u233?terminer les cas d'utilisation consiste \u224? partir du diagramme de contexte
: \u8226? Chaque fl\u232?che (entrante ou sortante) du diagramme de contexte est un
\u233?v\u233?nement m\u233?tier \'5c'7bbusiness event). \u8226? L'\u233?v\u233?
nement m\u233?tier est formul\u233? sous forme de phrase \u224? l'infinitif (par
exemple, pr\u233?sume un m\u233?dicament). \u8226? L'\u233?v\u233?nement m\u233?
tier devient la description du cas d'utilisation. \u8226? Une extr\u233?mit\u233?
de la fl\u232?che pointe vers le syst\u232?me ; l'autre extr\u233?mit\u233? est
l'acteur principal (par exemple, m\u233?decin prescripteur). \u8226? On travaille
avec les parties prenantes, en particulier un repr\u233?sentant des utilisateurs
(correspondant \u224? l'acteur principal et aux acteurs secondaires, par exemple un
m\u233?decin et un pharmacien) pour d\u233?aire les sc\u233?narios (nominal et
alternatif). Dans la pratique, comme toujours dans la d\u233?finition des besoins,
on peut combiner ces deux approches, par raffinements successifs et allers et
retours entre un diagramme de contexte et des cas d'utilisation. CttNWMT<df>
SBWafnMT<MS (UEMMttGSS'mfMrtVflf\u201?S CflS CPViHHMlflQB ' te cas d'ir\u244?
lisatkm c La m\u233?ttoxte consiste \u224? se p^tesquestfcMKsuiwrrttt \u8226?
QueBes sort les dom^ \u8226? Queksort les traitements (<ato^\par\pard\plain\
hyphpar} {
Partie 2 - D\u233?veloppement des exigences Un exemple Voici un exemple extrait
d'un cahier des charges du domaine des syst\u232?mes d'information hospitaliers.
L'acteur principal est le prescripteur (m\u233?decin ou sage-femme). Les acteurs
secondaires, pharmacien et infirmier, traitent la prescription. Nom du CU. Acteur
principal Autres parties prenantes Description Pr\u233?conditions Garanties
minimales Garanties en cas de succ\u232?s Flux normal Prescrire Prescripteur
Pharmacien, infirmier Le prescripteur prescrit des m\u233?dicaments \u224? un
patient hospitalis\u233?. Le prescripteur est identifi\u233?. Le syst\u232?me
dispose des informations utiles sur le patient Le patient est admis dans l'unit\
u233?. Le prescripteur a effectu\u233? son observation m\u233?dicale. Le
prescripteur a consult\u233? le dossier patient Le livret th\u233?rapeutique est
accessible au prescripteur. Le syst\u232?me tient \u224? jour un journal de toutes
les op\u233?rations. Les informations saisies par le prescripteur ne seront
accessibles aux autres acteurs qu'une fois la prescription sign\u233?e. La
prescription est une op\u233?ration atomique. Elle ne peut r\u233?ussir enti\u232?
rement ou \u233?chouer. La prescription peut \u234?tre valid\u233?e par la
pharmacie. Mise \u224? jour du plan de soins avec le plan d'administration pr\u233?
visionnel. Int\u233?gration de l'ordonnance dans le dossier m\u233?dical du patient
1. Le prescripteur s\u233?lectionne dans la liste des patients de l'unit\u233? de
responsabilit\u233? m\u233?dicale le patient pour lequel une prescription doit \
u234?tre faite. 2. Le prescripteur saisit un \u233?l\u233?ment de prescription
autant de fois que n\u233?cessaire. [saisir un \u233?l\u233?ment de prescription
est un cas inclus]. 3. Le syst\u232?me contr\u244?le les nosologies et les
interactions m\u233?dicamenteuses en interrogeant la base m\u233?dicamenteuse. 4.
Le syst\u232?me contr\u244?le les interactions physiopathologiques. 5. Le syst\
u232?me signale les \u233?ventuelles interactions et anomalies. en\par\pard\plain\
hyphpar} {
Chapitre 9 - Les cas d'utilisation Nom du CU. Flux normal (suite) Flux alternatif
Cas inclus Fr\u233?quence d'utilisation Prescrire 6. En cas d'anomalie, le
prescripteur peut modifier la prescription ou la maintenir et en indiquer les
raisons. 7. Le syst\u232?me inscrit la prescription dans le plan de soins de
l'infirmi\u232?re avec un statut \u171? en attente d'analyse par la pharmacie \
u187?. 8. Le prescripteur signe la prescription. 9. Le prescripteur peut imprimer
l'ordonnance. [On traite ici d'une alternative \u224? l'\u233?tape 1 ] : 1 a - Si
le prescripteur d\u233?cide une hospitalisation imm\u233?diate en consultation : 1
al - La prescription est faite sur une unit\u233? de consultation. Ia2 - Le
prescripteur indique l'unit\u233? d'hospitalisation. 1a3 - Le syst\u232?me affecte
la prescription \u224? l'unit\u233? d'hospitalisation. [Autre alternative \u224?
l'\u233?tape 1 ] : 1 b - Si la m\u234?me \u233?quipe m\u233?dicale et soignante
travaille sur deux unit\u233?s: 1 bl \u8226? Le prescripteur consulte une liste de
patients comportant les patients des deux unit\u233?s. Saisir un \u233?l\u233?ment
de prescription \u192? chaque consultation Les cas d'utilisation peuvent \u234?tre
plus ou moins d\u233?taill\u233?s, selon le niveau de pr\u233?cision du cahier des
charges. Difficult\u233?s et risques des cas d'utilisation Le premier risque est
li\u233? \u224? l'apparente facilit\u233? d'\u233?criture. On peut faire l'analogie
avec un ouvrage litt\u233?raire : un cas d'utilisation bien \u233?crit est tr\u232?
s facile \u224? lire par tous les intervenants d'un projet. Son \u233?criture est
en revanche beaucoup plus difficile, et demande de savoir ma\u238?triser les trois
concepts de port\u233?e, d'acteur principal et de niveau, ce qui demande un certain
entra\u238?nement. Les cas d'utilisation sont \u233?galement difficiles \u224?
comprendre (et a fortiori \u224? \u233?laborer) lorsqu'ils d\u233?crivent un
processus qui n'existe pas et qui devra \u234?tre informatis\u233?. Par exemple, un
m\u233?decin comprendra tr\u232?s facilement le CTfr\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences cas d'utilisation appel\u233? prescrire
un m\u233?dicament, mais aura du mal \u224? r\u233?agir face \u224? un cas
d'utilisation d\u233?crivant une pratique professionnelle qu'il ne ma\u238?trise
pas encore. D'autre part, les cas d'utilisation ne sont pas adapt\u233?s \u224?
toutes les situations. Ils sont de peu d'utilit\u233? pour des syst\u232?mes o\
u249? les interactions et transactions sont peu fr\u233?quentes, comme les
programmes de calcul scientifique ; et \u233?galement dans des cas o\u249? les
interactions sont tr\u232?s complexes, comme les syst\u232?mes temps r\u233?el. Il
en est de m\u234?me pour les syst\u232?mes s'appuyant sur des r\u232?gles de
gestion nombreuses et complexes. Enfin, ils ne sont pas du tout adapt\u233?s \u224?
la description des exigences non fonctionnelles. Dans tous ces cas. il est pr\u233?
f\u233?rable d'utiliser d'autres mod\u232?les de description. Vouloir sp\u233?
cifier la totalit\u233? des exigences sous forme de cas d'utilisation est donc
inefficace. Et certaines exigences, m\u234?me parmi celles pouvant \u234?tre d\
u233?crites de cette fa\u231?on, gagent \u224? l'\u234?tre au moyen de formalismes
diff\u233?rents. D'une mani\u232?re g\u233?n\u233?rale, lors de l'\u233?laboration
d'un cas d'utilisation, il faut rester simple et utiliser cet outil pour ce \u224?
quoi il est destin\u233? : d\u233?crire un ensemble de sc\u233?narios permettant
d'atteindre un objectif dans l'int\u233?r\u234?t des acteurs. Les cas suivants
doivent \u234?tre consid\u233?r\u233?s comme des signaux de danger : \u8226? des
cas d'utilisation trop nombreux, dans lesquels on se perd ; \u8226? des cascades de
cas inclus -, \u8226? des cas d'utilisation complexes, trop longs, incompr\u233?
hensibles par certains acteurs ; \u8226? des cas d'utilisation qui d\u233?crivent
l'interface utilisateur, ou les donn\u233?es : ils ne sont pas faits pour \u231?a.
Les diagrammes de cas d'utilisation Que penser des diagrammes de cas
d'utilisation ? Les adeptes d'UML en font un usage abondant, alors qu'Alistair
Cockbum ne les utilise qu'avec grande parcimonie, en mettant le lecteur en garde
contre les risques que pr\u233?sente leur utilisation. En r\u233?alit\u233?, dans
les cas simples, les diagrammes de cas d'utilisation sont faciles \u224? dessiner
et \u224? comprendre, mais sont de peu d'utilit\u233?. Dans les cas complexes, ils
sont peu maniables et ont tendance \u224? devenir incoh\u233?rents et ambigus.
Finalement, ils ne sont utiles qu'\u224? petites doses, \u224? titre illustratif.
CE)\par\pard\plain\hyphpar} {
Chapitre 9 - Les cas d'utilisation * Si vous passez beaucoup detemps\u224?\u233?tu^
prendre en compte, tfe* que vofe\u233?nei^ rWacnw de textt^M entre cas <f
utilisation sontdirectes. Apr\u232?s cela, vous aure^ rKBuds\u226?u cerveau \u224?
leur sujet [^ Ceux qui \u233?crivent de bons <as d'utilisation textuels ne sont
tout simplement pas confront\u233?s aux probl\u232?mes que renccmtient \u339?ux o^
bricoiert des personnages stylis\u233?^ des eiTrpses et des fl\u232?ches pr&\u224?
ms\u233?s par UML les relations se d\u233?gagent naturellement de P\u233?cm^re du
r\u233?^ ; dles ne deviennert pro^ en fait un abc\u232?s de fixation. \u8364?ette
id\u233?e fait son chemin \u224? mesure qtfun n^^ sant d\u233? consultants
accumulent uiieexp\u233?rieiK\u187? doublet ATistairCockbum,
kriredescasd'utilisathneffkaees,^^^^ (H)\par\pard\plain\hyphpar} {
Chapitre 10 L'\u233?tape d'analyse Le ma\u238?tre d'ouvrage, les utilisateurs et
autres parties prenantes expriment g\u233?n\u233?ralement leurs besoins en langue
naturelle. Dans le cahier des charges, ces besoins seront reformul\u233?s sous
forme d'exigences, dans la m\u234?me langue naturelle, mais sous une forme diff\
u233?rente, plus formelle. L'expression des exigences est donc une traduction entre
le langage (et souvent le jargon) des utilisateurs et un langage tr\u232?s pr\u233?
cis, compr\u233?hensible par tous les acteurs. Entre les deux, une repr\u233?
sentation sous forme graphique, sous forme de sc\u233?nario, ou sous forme de
prototype, permet d'obtenir une compr\u233?hension commune, de lever toute ambigu\
u239?t\u233? et incoh\u233?rence. Utilit\u233? de l'\u233?tape d'analyse Il est
illusoire de penser que l'utilisateur ou son repr\u233?sentant va nous pr\u233?
senter une liste bien ordonn\u233?e de besoins bien formul\u233?s. Les besoins sont
en g\u233?n\u233?ral exprim\u233?s sous forme de grappes, dont il faudra trier les
grains. Plusieurs besoins tr\u232?s diff\u233?rents peuvent \u234?tre formul\u233?s
dans une m\u234?me phrase, comme \u171? on a besoin d'avoir toutes les informations
d'un client sous les yeux, et de pouvoir choisir dans un menu les diff\u233?rents
produits \u224? lui proposer, et le syst\u232?me doit r\u233?agir tr\u232?s vite
sans jamais se bloquer \u187?. Dans cet exemple, le client : \u8226? N'indique pas
l'acteur (qui est < on \u187? ?). \u8226? Exprime plusieurs besoins dans une m\
u234?me phrase. \u8226? M\u233?lange des besoins fonctionnels et non
fonctionnels. \u8226? M\u233?lange des besoins g\u233?n\u233?raux (vision globale)
et de d\u233?tail (choix).\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences \u8226? Formule une solution (choix
dans un menu) \u224? la place d'un besoin. \u8226? Formule des besoins non
mesurables (\u171? tr\u232?s vite \u187?). \u8226? Formule une exigence
probablement irr\u233?aliste (< jamais >). Au cours d'une r\u233?union d'un groupe
de travail, on peut recueillir une vingtaine de formulations de ce type. Et l'\
u233?laboration d'un cahier des charges peut n\u233?cessiter une quinzaine de r\
u233?unions de travail. On admettra facilement que trois cents phrases de ce type
mises bout \u224? bout ne constituent pas un cahier des charges, mais une liste qui
deviendra vite incoh\u233?rente. Pour travailler efficacement, il sera donc n\u233?
cessaire d'analyser, de reformuler, de trier et de classer les besoins au fur et \
u224? mesure qu'ils se pr\u233?sentent, ou en tout cas le plus t\u244?t possible.
Le processus d'analyse Les objectifs de l'\u233?tape d'analyse sont les
suivants : \u8226? classer et structurer les exigences ; \u8226? d\u233?velopper
une compr\u233?hension partag\u233?e des besoins qui ont \u233?t\u233? recueillis ;
\u8226? d\u233?tecter les incoh\u233?rences, redondances et incompl\u233?tudes et
faire le n\u233?cessaire pour les r\u233?duire, voire les \u233?liminer. Ces deux
objectifs sont indissociables. Pour les atteindre, l'\u233?tape d'analyse fait
largement appel \u224? l'exp\u233?rience et \u224? la cr\u233?ativit\u233?, car il
n'y a pas de m\u233?thode miracle pour d\u233?tecter toutes les incoh\u233?rences
et incompl\u233?tudes. La m\u233?thode empirique, qui consiste \u224? relire les
exigences et \u224? en discuter en groupe de travail, a son utilit\u233?, mais on
en voit vite les limites. Ce chapitre va d\u233?tailler des techniques sp\u233?
cifiques qui seront mises en \u339?uvre, et en particulier : \u8226? structurer et
organiser les exigences par types ; \u8226? \u233?tablir un dictionnaire de donn\
u233?es ; \u8226? analyser les r\u232?gles m\u233?tier ; \u8226? classer les
exigences par priorit\u233?s ; \u8226? mod\u233?liser les exigences sous forme
graphique ; \u8226? r\u233?aliser une \u171? maquette papier \u187? ou un prototype
: \u8226? \u233?laborer des cas de test-. \u8226? tester la faisabilit\u233? et le
co\u251?t des exigences. La figure 10-1 pr\u233?sente le processus g\u233?n\u233?
ral de l'\u233?tape d'analyse. CD\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse -Recueil Structurer Mod\u233?iser Prioriser it
\u201?tudier co\u251?t et faisabftt\u233? sp\u233?cification^ Figure 101 : Le
processus d'analyse Si l'analyste a une formation d'ing\u233?nieur, il sera tent\
u233?, du moins dans un premier temps, de concevoir l'\u233?tape d'analyse comme
une activit\u233? purement technique. En r\u233?alit\u233?, il ne sortira rien de
bon si les diff\u233?rentes parties prenantes, et en particulier les repr\u233?
sentants des utilisateurs, ne sont pas impliqu\u233?es. L'analyste doit ma\u238?
triser UML (ou un autre langage graphique), mais il doit \u234?tre suffisamment p\
u233?dagogue pour rendre les diagrammes compr\u233?hensibles par tout lecteur
potentiel. Structurer et organiser les exigences Les exigences doivent \u234?tre
class\u233?es en cat\u233?gories, soit au fil de l'eau lors du recueil, soit au
plus tard pendant l'\u233?laboration du document d'exigences (cahier des charges).
La classification qui suit est inspir\u233?e de Karl Wiegers (voir bibliographie),
mais la plupart des classifications s'en approchent. Les objectifs sont des
exigences de haut niveau. Un objectif est formul\u233? sous forme de phrase avec un
verbe \u224? l'infinitif, par exemple \u171? diminuer de 20 % le temps d'attente au
guichet \u187?. Les objectifs sont exprim\u233?s, dans la majorit\u233? des cas.
par le donneur d'ordre. Le verbe sous-entendu est le verbe vouloir (ou devoir, dans
le sens d'une volont\u233?) : nous (l'entreprise) voulons diminuer le temps
d'attente (il s'agit l\u224? de la volont\u233? du ma\u238?tre d'ceuvre). Les cas
d'utilisation ou sc\u233?narios correspondent \u224? des besoins des utilisateurs
et s'expriment \u233?galement comme une phrase \u224? l'infinitif, par exemple \
u171? enregistrer un nouveau client \u187?. La phrase sous-entendue est avoir
besoin de, exprim\u233?e \u224? la premi\u232?re personne : \u171? j'ai besoin
d'enregistrer tout nouveau client \u187?. Les r\u232?gles sont des exigences r\
u233?glementaires ou des r\u232?gles m\u233?tier (\u233?galement appel\u233?es r\
u232?gles de gestion). Le verbe sous-entendu ou explicite est devoir : le logiciel
doit se conformer \u224? telle r\u233?glementation, dans des conditions bien d\
u233?finies. Par exemple : < un retrait d'esp\u232?ces ne peut \u234?tre effectu\
u233? que si le compte est positif \u187? (formul\u233? autrement, le compte doit \
u234?tre positif pour qu'un retrait puisse \u234?tre effectu\u233?). GJD\par\pard\
plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences Les exigences fonctionnelles constituent le
c\u339?ur et souvent la partie la plus importante d'un cahier des charges. Elles
expriment un comportement requis de la part du syst\u232?me. Elles d\u233?rivent
des cat\u233?gories pr\u233?c\u233?dentes. Par exemple \u171? si le retrait d'esp\
u232?ces n'est pas autoris\u233?, le syst\u232?me envoie un message au client \
u187?. Les exigences de qualit\u233?, \u233?galement appel\u233?es exigences non
fonctionnelles, bien qu'elles n'en constituent qu'une partie. Elles s'expriment
sous forme d'adjectif (rapide, facile...) ou de la propri\u233?t\u233?
correspondante (rapidit\u233?, facilit\u233?...). Les exigences d'interface qui
expriment le besoin d'une communication entre le syst\u232?me \u224? l'\u233?tude
et le monde ext\u233?rieur : mat\u233?riel, logiciel et personnes. Les contraintes
techniques, comme l'utilisation d'un syst\u232?me ou d'un langage particulier, ou
de technologies sp\u233?cifiques, comme un protocole de communication ou de s\u233?
curit\u233?. Il est important d'analyser l'origine de ces contraintes et leur
utilit\u233? r\u233?elle, car elles peuvent avoir des r\u233?percussions n\u233?
gatives sur la fonctionnalit\u233? ou la qualit\u233?. Les exigences sur les
formats de donn\u233?es, comme un code postal en cinq chiffres, un code pays. etc.
Les suggestions de solutions qui n'ont pas lieu de se retrouver en tant que telles
dans un cahier des charges, et qu'il faudra analyser pour remonter \u224? une
exigence d'un des types pr\u233?c\u233?demment d\u233?finis. Par exemple, si
l'exigence est \u171? la somme doit s'afficher en rouge \u187?. il est important de
savoir pourquoi. Cela peut correspondre \u224? une r\u232?gle m\u233?tier (certains
chiffres doivent s'afficher en rouge dans telle condition), d'une r\u232?gle
d'ergonomie (homog\u233?n\u233?it\u233? : l'affichage doit \u234?tre le m\u234?me
d'une application \u224? l'autre) ou d'un souhait personnel. D'autres informations
ou exigences peuvent \u234?tre formul\u233?es. Elles pourront ou non se retrouver
dans le cahier des charges, ou en pr\u233?ambule, ou en annexe de celui-ci :
description de l'existant, contraintes sur les d\u233?lais, sur les co\u251?ts, sur
la formation des utilisateurs, le d\u233?coupage en lots lors d'un appel d'offres,
et toutes informations utiles \u224? ceux qui vont r\u233?pondre au cahier des
charges. Il s'agit l\u224? d'une premi\u232?re classification qui. avec l'habitude,
se fait mentalement au cours du recueil des exigences. Une classification plus pr\
u233?cise se fait lors de la r\u233?daction du cahier des charges, et d\u233?pend
donc pr\u233?cis\u233?ment du mod\u232?le de cahier des charges utilis\u233?.
D'ailleurs, disposer d'un squelette (ou mod\u232?le) de cahier des charges sert pr\
u233?cis\u233?ment \u224? cela : c'est une armoire de rangement pour les exigences.
GJD\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse \u201?tablir un dictionnaire de donn\u233?es
Comme les exigences fonctionnelles, la description des donn\u233?es constitue une
passerelle de communication entre ma\u238?trise d'ouvrage (le vocabulaire des
utilisateurs) et ma\u238?trise d'ceuvre (la compr\u233?hension des concepteurs et
d\u233?veloppeurs). Les m\u234?mes donn\u233?es apparaissant d'une exigence \u224?
l'autre, il est utile de les sp\u233?cifier une fois pour toutes. Par exemple :
Client \u187? id_client [9 chiffres] + nom [15 lettres] + pr\u233?nom [15 lettres]
La syntaxe peut \u234?tre plus ou moins complexe, en fonction de l'usage qui sera
fait des sp\u233?cifications d'exigences (d\u233?veloppement sp\u233?cifique ou
choix de progiciel). Certaines interfaces (normes d'interop\u233?rabilit\u233?)
peuvent n\u233?cessiter une description extr\u234?mement pr\u233?cise des formats
de donn\u233?es \u233?chang\u233?es, mais c'est rarement le cas pour un cahier des
charges fonctionnel \u233?labor\u233? dans le cadre d'un appel d'offres, par
exemple. L'important est que toutes les personnes int\u233?ress\u233?es soient
d'accord sur le contenu de telle ou telle donn\u233?e, afin d'\u233?viter toute
ambigu\u239?t\u233?. Analyser les r\u232?gles m\u233?tier Qu'est-ce qu'une r\u232?
gle m\u233?tier ? Les r\u232?gles m\u233?tier, \u233?galement appel\u233?es r\u232?
gles de gestion (en anglais business rutes) d\u233?rivent des lois, r\u232?
glements, proc\u233?dures, codes de bonnes pratiques en vigueur pour un m\u233?tier
donn\u233?, r\u232?gles de calcul, etc. Ce sont l\u224? des exigences en puissance,
mais elles sont g\u233?n\u233?ralement \u233?nonc\u233?es sous une forme
inappropri\u233?e pour appara\u238?tre dans un cahier des charges. Autrement dit.
ce sont des interm\u233?diaires entre un texte ou une pratique (texte r\u233?
glementaire, pratique professionnelle) et une exigence. Plus pr\u233?cis\u233?ment,
une r\u232?gle de gestion peut \u234?tre : \u8226? un fait ; \u8226? une contrainte
(seul un acteur X peut accomplir l'action Y) ; \u8226? une r\u232?gle d'action (un
acteur X doit accomplir l'action Y) ; \u8226? une inf\u233?rence (si... alors...) ;
\u8226? une r\u232?gle de calcul (par exemple, calcul de la TVA). Les r\u232?gles
m\u233?tier ne sont pas des besoins utilisateurs et ne sont pas consid\u233?r\u233?
es comme des exigences \u224? proprement parler. En g\u233?n\u233?ral, elles
n'apparaissent pas en tant que telles dans un cahier des charges, mais y sont d\
u233?clin\u233?es sous forme d'exigences. C!7\u224?\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences 1. De fortes contraintes de tracabilit\
u233? et de maintenabilit\u233? peuvent rendre indispensable le recours \u224? un
outil de gestion des exigences (voir au chapitre 19). Plut\u244?t qu'un long
discours, donnons quelques exemples de r\u232?gle m\u233?tier : \u8226? Tout m\
u233?dicament est livr\u233? \u224? la pharmacie dans un emballage avec un code-
barres (fait). \u8226? Le directeur d'un \u233?tablissement de sant\u233? \u233?
tablit la liste des personnes habilit\u233?es \u224? prescrire des m\u233?dicaments
(r\u232?gle d'action). \u8226? Le pharmacien doit analyser la prescription avant de
livrer un m\u233?dicament (r\u232?gle d'action). \u8226? Le pharmacien doit
s'assurer qu'il n'y a pas interaction m\u233?dicamenteuse entre plusieurs m\u233?
dicaments prescrits (r\u232?gle d'action). \u8226? Si la date de p\u233?remption
inscrite sur l'emballage est sup\u233?rieure \u224? la date du jour, alors le
produit est p\u233?rim\u233? (inf\u233?rence). Il est clair que toutes ces r\u232?
gles n'ont pas \u224? se retrouver dans une sp\u233?cification d'exigences. Il
serait inutile de les indure dans le cahier des charges lui-m\u234?me, du moins
sous cette forme, car elles n'ont pas d'impact direct sur le produit. Mais, d'une
part, elles participent \u224? l'analyse des exigences et. d'autre part, il est n\
u233?cessaire, pour des raisons de tracabilit\u233? et de maintenabilit\u233?, de
pouvoir conna\u238?tre en permanence le lien entre une r\u232?gle m\u233?tier et
une exigence du cahier des charges1. De la r\u232?gle m\u233?tier \u224? l'exigence
\u192? l'origine, les r\u232?gles m\u233?tier n'ont pas \u233?t\u233? \u233?crites
pour figurer dans un cahier des charges. M\u234?me si cela peut en choquer
certains, on peut dire que. vis-\u224?-vis du cahier des charges, ce sont des \
u171? exigences brutes \u187?. Pour en faire des exigences aptes \u224? entrer dans
un cahier des charges, le travail de recueil, d'analyse et de sp\u233?cification
est analogue \u224? celui de l'analyse des besoins. Il consiste \u224? : \u8226?
recueillir les r\u232?gles de gestion - rechercher les sources des r\u232?gles de
gestion potentielles (l\u233?gislation, normes, recueils de pratiques
professionnelles, protocoles...) qui sont en rapport avec l'objectif et dans le
champ de l'\u233?tude, - recueillir l'ensemble des r\u232?gles, proc\u233?dures,
pratiques, susceptibles d'avoir un impact sur les exigences ; \u8226? analyser
ces \u233?l\u233?ments - filtrer en fonction des objectifs. - rechercher les incoh\
u233?rences, redondances et incompl\u233?tudes, - si n\u233?cessaire, repr\u233?
senter ces \u233?l\u233?ments en diagrammes, sous la forme appropri\u233?e ; \
u8226? traiter les r\u232?gles de gestion - formuler les \u233?l\u233?ments pr\
u233?c\u233?dents sous forme de r\u232?gles m\u233?tier. GjD\par\pard\plain\
hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse - stocker ces r\u232?gles dans le r\u233?f\
u233?rentiel appropri\u233?, - d\u233?cider lesquelles de ces r\u232?gles m\u233?
tier seront automatis\u233?es : \u8226? sp\u233?cifier - formuler ces r\u232?gles
sous forme d'exigences, - inclure ces exigences dans le cahier des charges ; \
u8226? g\u233?rer - maintenir la tra\u231?abilit\u233? entre les r\u232?gles de
gestion et les exigences fonctionnelles en aval, - analyser l'impact d'une r\u232?
gle de gestion sur l'ensemble des exigences m\u233?tier. La diff\u233?rence avec le
traitement des besoins r\u233?side donc dans le stockage des r\u232?gles m\u233?
tier dans une zone particuli\u232?re, en vue de les inclure, si n\u233?cessaire,
dans le cahier des charges. Cette zone de stockage peut \u234?tre un simple
tableau, une base de donn\u233?es, ou mieux, un outil de gestion des exigences. Les
r\u232?gles m\u233?tier vont g\u233?n\u233?ralement donner lieu \u224? des
exigences fonctionnelles de haut niveau, parfois appel\u233?es exigences m\u233?
tier \'5c'7bbusiness requiremenls). Elles seront d\u233?clin\u233?es sous forme
d'exigences plus fines, en fonction du niveau de d\u233?tail requis. D\u233?finir
les priorit\u233?s d'un projet Pourquoi et quand d\u233?finir les priorit\u233?s ?
Tout projet est limit\u233? par le budget allou\u233?, les d\u233?lais exig\u233?s,
le risque admissible et les ressources disponibles. Il est donc indispensable de d\
u233?finir les priorit\u233?s entre exigences. La priorisation des exigences est
utile : \u8226? lors de la d\u233?finition des objectifs, (dans toute la mesure du
possible) ; \u8226? lors du d\u233?veloppement des exigences (\u233?laboration du
cahier des charges) ; \u8226? lors du choix d'une solution. La gestion des priorit\
u233?s permettra de r\u233?soudre les conflits au plus t\u244?t, de faire des
compromis, et \u233?ventuellement de planifier la mise en \u339?uvre de certaines
exigences pour une version ult\u233?rieure du syst\u232?me. Il est important de d\
u233?finir les priorit\u233?s entre fonctions (ou exigences non fonctionnelles) le
plus t\u244?t possible, quitte \u224? revoir la liste des priorit\u233?s par la
suite, avec le recul. Cela minimise le risque de voir des conflits s'envenimer ou
de devoir remettre en cause l'existant au dernier moment. CE)\par\pard\plain\
hyphpar} {
Partie 2 - D\u233?veloppement des exigences Comment d\u233?finir les priorit\u233?s
? G\u233?rer les priorit\u233?s est loin d'\u234?tre une t\u226?che facile. Tout
utilisateur a tendance \u224? penser que a) toutes ses exigences sont prioritaires
sans exception et que b) ses exigences sont prioritaires sur celles des autres. Les
priorit\u233?s ne peuvent \u234?tre d\u233?finies par les seuls utilisateurs (ou
leurs repr\u233?sentants). Elles doivent \u234?tre confront\u233?es au r\u233?el,
c'est-\u224?-dire \u224? ce qui est faisable ou pas. et \u224? quel co\u251?t. Il
est donc n\u233?cessaire d'organiser des r\u233?unions entre experts m\u233?tier
(utilisateurs ou repr\u233?sentants) et experts techniques (d\u233?veloppeurs,
chefs de projet ou leurs repr\u233?sentants) et de confronter les points de vue. Il
n'y a pas de m\u233?thode miracle, la gestion des priorit\u233?s reposant sur des
principes de n\u233?gociation. En cas de conflit entre priorit\u233?s, il faut se
poser les questions suivantes : \u8226? Qui serait insatisfait si cette exigence
n'\u233?tait pas mise en \u339?uvre ? \u8226? Peut-on satisfaire cette exigence par
d'autres moyens ? \u8226? Comment se comporterait le syst\u232?me sans cette
fonction ? \u8226? Le syst\u232?me dans son ensemble serait-il mis en cause ? \
u8226? Quelle est la limite acceptable en termes de d\u233?lais ? de co\u251?ts ? \
u8226? Est-on pr\u234?t \u224? assumer le risque de supprimer cette fonction ? La
priorit\u233? d'une exigence est fonction de son urgence et de son importance
(principe d'Eisenhower) : \u8226? les exigences urgentes et importantes seront en
haute priorit\u233? ; \u8226? les exigences importantes, mais non urgentes,
viendront ensuite ; \u8226? les exigences urgentes et non importantes sont de
priorit\u233? faible ; \u8226? les exigences ni urgentes ni importantes seront
mises de c\u244?t\u233?. Outre l'urgence et l'importance, doivent entrer en ligne
de compte le risque \u224? faire et \u224? ne pas faire (ce que l'on gagne en
faisant, ce que l'on perd en ne faisant pas), le co\u251?t de r\u233?alisation,
ainsi que le risque li\u233? \u224? la r\u233?alisation (li\u233? au manque de
savoir-faire de l'\u233?quipe de d\u233?veloppement, \u224? l'immaturit\u233? des
technologies mises en \u339?uvre, etc.). Il est facile de construire (ou de trouver
sur Internet) une matrice de priorisation des exigences, permettant de faire une
somme pond\u233?r\u233?e des diff\u233?rents param\u232?tres. La m\u233?thode des
cent points : mode op\u233?ratoire La m\u233?thode des cent points est un grand
classique. Elle est tr\u232?s utilis\u233?e par les consultants pour animer un
groupe de travail de s\u233?lection de progiciel. Dans ce dernier cas. les
exigences s'appellent crit\u232?res de\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse choix, mais l'id\u233?e est la m\u234?me. Sous
sa forme simplifi\u233?e, les \u233?tapes de la m\u233?thode sont les suivantes :
1. Les participants dressent la liste des exigences \u224? prioriser. On utilisera
de pr\u233?f\u233?rence un tableur et la liste ne doit \u234?tre ni trop longue, ni
trop courte (r\u232?gle du pouce : imprim\u233?e, la liste doit tenir sur une page
A4). 2. On se fixe la r\u232?gle suivante : chaque exigence aura un poids compris
entre 1 (peu prioritaire) et 4 (tr\u232?s prioritaire), et la somme des poids des
exigences devra \u234?tre \u233?gale \u224? 100. On peut jouer sur ces chiffres,
mais on \u233?vitera de les modifier en cours de route. 3. Les participants
attribuent \u224? chaque exigence un poids. Ce poids doit \u234?tre attribu\u233?
par consensus entre participants. Si un consensus ne peut \u234?tre trouv\u233?, on
vote (c'est un pis-aller) ou quelqu'un doit trancher (c'est un pis-aller de plus).
C'est l\u224? que les talents d'animateur de l'analyste seront utiles. 4. Lorsque
chaque exigence aura re\u231?u un poids, si la somme des poids est inf\u233?rieure
ou sup\u233?rieure \u224? 100, on cherchera \u224? augmenter ou r\u233?duire le
poids de certaines exigences jusqu'\u224? atteindre 100. Ici aussi, on cherche le
consensus. Si on utilise un tableur, il est facile de jeter de temps en temps un
coup d'ceil sur la somme des poids. Avec un peu d'exp\u233?rience, l'animateur sait
qu'il doit forcer sur les pond\u233?rations ou au contraire les mod\u233?rer, bien
avant d'arriver au bout de la liste. 5. Lorsque toutes les exigences sont pond\
u233?r\u233?es et que la somme des poids est \u233?gale \u224? 100, les exigences
sont prioris\u233?es. Il est clair que cette m\u233?thode demande du doigt\u233? de
la part de l'animateur (analyste ou consultant) et une atmosph\u232?re
consensuelle, sinon la s\u233?ance tournera vite au pugilat. \u192? certains
moments, l'animateur peut assouplir les r\u232?gles : ajouter quelques exigences
suppl\u233?mentaires, autoriser les d\u233?passements, ou modifier la liste en
cours de route. Ces entorses sont somme toute normales, la \u171? r\u232?gle du 100
\u187? \u233?tant plut\u244?t arbitraire. Il arrive d'ailleurs souvent qu'en
discutant, les participants remettent en question les exigences elles-m\u234?mes,
ou fassent \u233?merger de nouvelles exigences. Ce ph\u233?nom\u232?ne est normal,
voire souhaitable, mais doit \u234?tre contr\u244?l\u233? pour \u233?viter les d\
u233?rives : augmentation exponentielle du nombre d'exigences, sp\u233?cifications
rampantes, ou retours incessants en arri\u232?re. Une variante de la m\u233?thode
consiste \u224? donner \u224? chaque participant cent points, qu'il pourra utiliser
\u224? sa guise. S'il y a cinq participants, la somme pond\u233?r\u233?e des
priorit\u233?s sera \u233?gale \u224? 500. Le consultant ou analyste qui anime le
groupe n'a pas de points. Cette variante permet d'aller plus vite, mais en \u233?
vitant la recherche d'un consensus, elle n'encourage pas la r\u233?flexion sur les
exigences elles-m\u234?mes.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences 2. En France, la soci\u233?t\u233?
Adexys commercialise une gamme d'outils d'\u233?valuation bas\u233?s sur la m\u233?
thode AHP. La m\u233?thode peut \u234?tre enrichie, en donnant des poids li\u233?s
non seulement au besoin des utilisateurs, mais aussi au co\u251?t, au risque, au
temps de d\u233?veloppement, etc. Autres m\u233?thodes M\u234?me avec une matrice
simple (somme pond\u233?r\u233?e des b\u233?n\u233?fices, co\u251?ts, risques) on
obtient le plus souvent des r\u233?sultats satisfaisants. Le plus important est
d'amener les diff\u233?rents acteurs \u224? se mettre d'accord sur un processus de
priorisation et \u224? travailler ensemble pour d\u233?finir les priorit\u233?s.
Pour les projets importants, des m\u233?thodes plus complexes de priorisation,
comme AHP (Analytical Hierarchical Pncess) ou \u219?FD (QualUy Function Deploy-
ment) peuvent \u234?tre mises en \u339?uvre. La m\u233?thode AHP est une m\u233?
thode d'aide \u224? la d\u233?cision qui consiste \u224? comparer deux \u224? deux
des crit\u232?res (et dans le cas des exigences) class\u233?s hi\u233?
rarchiquement. Le nombre total de comparaisons est n x (w-l)/2 o\u249? n est le
nombre d'exigences \u224? prioriser \u224? chaque niveau hi\u233?rarchique, ce
qui augmente tr\u232?s vite le nombre de comparaisons \u224? faire. Cette m\u233?
thode est puissante, mais en pratique demande \u224? \u234?tre outill\u233?e2.
Modeliser sous forme graphique La mod\u233?lisation graphique est \u224? la fois un
outil d'analyse, de communication entre acteurs, et de validation. Certains
traitements ou processus sont plus simples \u224? comprendre lorsqu'ils sont repr\
u233?sent\u233?s graphiquement, et les \u233?ventuelles incoh\u233?rences < sautent
aux yeux \u187?. Un bon sch\u233?ma, c'est bien connu, vaut bien cent pages de
texte. Cependant, ne nous faisons pas d'illusions. Contrairement \u224? ce que l'on
\u233?crit parfois, la mod\u233?lisation sous forme graphique n'est pas un outil
universel et ne remplace pas le texte \u233?crit. Il y a \u224? cela plusieurs
raisons : \u8226? Contrairement \u224? ce que l'on pense souvent, des sch\u233?mas
qui paraissent tr\u232?s simples \u224? certains seront difficiles \u224?
comprendre pour d'autres. \u8226? Un sch\u233?ma peut \u234?tre facile \u224? lire,
mais beaucoup plus difficile \u224? \u233?laborer qu'un texte. \u8226? \u201?
laborer un sch\u233?ma para\u238?t facile, mais c'est l\u224? une simplicit\u233?
trompeuse, car il faut utiliser un formalisme pr\u233?cis et conna\u238?tre la s\
u233?mantique sous- jacente. \u8226? \u192? moins d'un formalisme extr\u234?me, une
m\u234?me repr\u233?sentation peut avoir des interpr\u233?tations diff\u233?rentes
selon les auteurs et lecteurs, et induire en erreur. QD\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse \u8226? Il n'existe pas de notation graphique
universelle qui permettrait de repr\u233?senter tous les besoins. Les diagrammes
peuvent \u234?tre ins\u233?r\u233?s dans un cahier des charges, en compl\u233?ment
du texte \u233?crit. Ils peuvent \u233?galement \u234?tre tr\u232?s utiles en tant
que repr\u233?sentations interm\u233?diaires, uniquement dans un but d'analyse,
sans n\u233?cessairement appara\u238?tre dans le cahier des charges. Un diagramme
ne sert p\u187? seu^ tout, \u224? \u233?riger de point de vue. En effet, analyser
un probl\u232?me, c'est ted\u233?composer en ses diff\u233?rents constituants, dam
te butde mietix te compre^ dTfr&errtei Et surtout ^ diffi\u233?reiTHnent le texte
et les im lit\u233? de d\u233?tecter \u249?n\u235?incot\u224?taftfe^ On donne ici
quelques diagrammes parmi les plus utilis\u233?s. Les paragraphes qui suivent n'ont
pas pour objectif de remplacer un ouvrage sur l'analyse des syst\u232?mes
d'information, mais de montrer leur utilit\u233? pratique dans la d\u233?finition
des besoins. Le diagramme d'activit\u233?s ou carte de processus C'est le plus
classique des diagrammes. On le trouve dans diverses m\u233?thodologies, sous des
noms diff\u233?rents, avec des symbolismes vari\u233?s. Il s'appelle process map en
anglais, et son \u233?quivalent UML est le diagramme d'activit\u233?. Il permet de
repr\u233?senter les \u233?tapes d'un processus m\u233?tier, leur s\u233?quence,
leurs entr\u233?es et sorties, les acteurs responsables de chaque \u233?tape. Ces
diagrammes peuvent \u234?tre utilis\u233?s pour repr\u233?senter un processus
existant ou \u224? venir, automatis\u233? ou manuel. C'est donc un outil assez g\
u233?n\u233?raliste. Les \u233?tapes peuvent \u234?tre r\u233?parties sur des <
bandes \u187? (en anglais svrim lanes. par analogie avec les couloirs d'une
piscine), chaque bande \u233?tant sous la responsabilit\u233? d'un acteur. Certains
analystes r\u233?servent une bande aux \u233?tapes automatis\u233?es ou \u224?
automatiser. En plus d'\u234?tre le < couteau suisse \u187? de l'analyste, un
diagramme de processus est un excellent outil de dialogue avec les utilisateurs, et
de n\u233?gociation avec la ma\u238?trise d'ouvrage, \u224? condition : \u8226? de
tenir sur une page A4 ; \u8226? d'\u234?tre \u171? autoexplicatif \u187? ; \u8226?
de ne pas comporter trop d'\u233?tapes (une douzaine au plus). GD\par\pard\plain\
hyphpar} {
ie 2 - D\u233?veloppement des exigences Les grands sch\u233?mas synoptiques sur une
grande feuille A3 ou A2 peuvent \u234?tre utiles aux analystes et concepteurs,
rompus aux sch\u233?mas complexes. Mais ils ne devraient pas sortir de leurs
tiroirs. Une \u171? usine \u224? gaz \u187? risque d'effrayer un interlocuteur et
d'avoir l'effet exactement inverse de celui escompt\u233?. Patient M\u233?decin
Infirmi\u232?re Pharmacie c \u9830?, , Communique les H informations Interroger le
patient Prescrire les m\u233?dicaments Modifier la prescription 1 Oui f Administrer
les m\u233?dicaments * Analyser la prescription i ^^^mter^sw "^\'5cactions^^ Non \
u9660? D\u233?livrer les doses Figure 10-2 : Carte des processus Le diagramme de
flux de donn\u233?es (DFD) Un diagramme de flux de donn\u233?es (ou plus
simplement, diagramme de flux) permet de repr\u233?senter la mani\u232?re dont les
donn\u233?es sont trait\u233?es (transf\u233?r\u233?es, modifi\u233?es) par le
syst\u232?me d'information (personnes et applications). Plusieurs mod\u232?les de
repr\u233?sentation existent. Dans le mod\u232?le le plus couramment utilis\u233?
(figure 10-3) : \u8226? Les processus sont repr\u233?sent\u233?s par des cercles.
CD\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse Les entit\u233?s externes au syst\u232?me
(personnes physiques ou morales, groupes de personnes ou autres syst\u232?mes) sont
repr\u233?sent\u233?es par des rectangles3. Les flux de donn\u233?es sont repr\
u233?sent\u233?s par des fl\u232?ches. Les zones de stockage (bases de donn\u233?
es, fichiers...) sont repr\u233?sent\u233?es par deux segments parall\u232?les. 3.
Remarquons que les rectangles ne font pas partie du syst\u232?me. Base m\u233?
dicamenteuse Informations patient Figure 10-3 : Un diagramme de flux de donn\u233?
es GD\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences Chaque processus d'un diagramme peut \u234?
tre \u233?clat\u233? en processus plus d\u233?taill\u233?s dans de nouveaux
diagrammes de flux. \u192? ce propos, remarquons que le diagramme de contexte, dont
il a d\u233?j\u224? \u233?t\u233? question dans cet ouvrage, est le plus simple des
diagrammes de flux. Il repr\u233?sente le processus global correspondant au syst\
u232?me \u224? l'\u233?tude, entour\u233? des personnes ou logiciels avec lesquels
il r\u233?agit. Le diagramme de flux met en \u233?vidence le partage du travail
entre le syst\u232?me \u224? l'\u233?tude et son environnement. C'est donc un bon
moyen de donner une vision globale des diff\u233?rents processus et de leurs
relations entre eux. et il est g\u233?n\u233?ralement bien compris des
utilisateurs. Il peut donc \u234?tre utilis\u233? lors du recueil des besoins dans
le but d'\u233?claircir ou de valider ce qui a \u233?t\u233? formul\u233?
oralement. Bien entendu, il peut appara\u238?tre dans un cahier des charges.
Quelques r\u232?gles d'\u233?laboration du diagramme : \u8226? Tout processus doit
comporter une fl\u232?che en entr\u233?e et une fl\u232?che en sortie. \u8226? Une
fl\u232?che ne peut pas relier directement deux processus. Quelques r\u232?gles
pratiques : \u8226? Num\u233?roter les processus facilite grandement la lecture. \
u8226? Ne pas mettre trop d'entit\u233?s dans un diagramme. Suivre la r\u232?gle du
\u171? sept plus ou moins deux \u187?. Au-del\u224? de neuf, le diagramme est
illisible. \u8226? Si un processus est complexe, on peut le mod\u233?liser dans un
autre diagramme. Dans ce cas, on utilisera une num\u233?rotation point\u233?e pour
num\u233?roter les sous-processus (par exemple, le processus num\u233?ro 4 se d\
u233?composera en 4.1,4.2, etc.). Le diagramme de s\u233?quence Le diagramme de s\
u233?quence (figure 10-4) permet de mod\u233?liser les flux d'informations entre
acteurs, en faisant ressortir l'encha\u238?nement chronologique des activit\u233?s
d'un processus. Horizontalement, de gauche \u224? droite, on repr\u233?sente les \
u171? lignes de vie \u187? des diff\u233?rents acteurs. Des messages, synchrones ou
asynchrones, transitent d'un acteur \u224? l'autre. Verticalement, on peut lire
l'encha\u238?nement des actions dans le temps. Le diagramme de s\u233?quence est un
outil d'analyse plus que de recueil ou de sp\u233?cification. En dehors des
domaines techniques o\u249? la synchronisation des t\u226?ches est complexe (t\
u233?l\u233?coms), il est rare de le rencontrer dans un cahier des charges. Il est
en revanche tr\u232?s utile pour alimenter la r\u233?flexion permettant de d\u233?
cider des op\u233?rations \u224? automatiser et sur les processus \u224?
optimiser \u224? la suite d'une informatisation. Le diagramme de 00\par\pard\plain\
hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse la figure 10-4 repr\u233?sente un processus
manuel. L'automatisation de ce processus permettra de supprimer environ la moiti\
u233? des t\u226?ches (mises \u224? jour, transmission manuelle d'informations et
archivage). M\u233?decin Gestionnaire dossier patient Prescription Infirmier
Pharmacien Pr\u233?parateur + Mise \u224? jour *D Prescription Notification de non
validation Ordre de d\u233?livrance I Compte-rendu d'administration I Mise \u224?
jour du dossier I I Compte-rendu de d\u233?livrance **\u171? 1 I I Relev\u233?
d'administration r i i 1 i Figure 10-4 : Un diagramme de s\u233?quence *& Archivage
*D-^ Le diagramme entit\u233?-association ou diagramme de classes Ce diagramme, tr\
u232?s technique, peut \u234?tre utile dans certains cas, mais n'a pas toujours sa
place dans un cahier des charges (figure 10-5). Il permet de repr\u233?senter les
attributs des donn\u233?es et les relations entre les donn\u233?es du syst\u232?me.
Dans le cadre de la phase de d\u233?finition des besoins, \u233?laborer ce mod\
u232?le permet d'avoir une vision exhaustive des donn\u233?es manipul\u233?es par
le syst\u232?me. C'est donc un mod\u232?le conceptuel des donn\u233?es, ind\u233?
pendant des aspects techniques, que l'on utilise. Apr\u232?s transformation, il
aboutira \u224? un mod\u232?le physique, qui lui, d\u233?pend de l'impl\u233?
mentation physique (base de donn\u233?es). L'exp\u233?rience montre que la lecture
(sans parler de l'\u233?laboration m\u234?me) d'un tel mod\u232?le n'est pas
toujours ais\u233?e pour les utilisateurs non informaticiens. Il est utile
d'accompagner le diagramme de texte explicatif. CD\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences Lors du recueil, les questions \u224? se
poser, et \u224? poser aux repr\u233?sentants des utilisateurs, sont : \u8226?
Quelles sont les donn\u233?es manipul\u233?es par le syst\u232?me ? \u8226? Quelles
donn\u233?es le syst\u232?me devra-t-il stocker ? Les entit\u233?s sont des donn\
u233?es, ou plus g\u233?n\u233?ralement, des ensembles de donn\u233?es : un client,
un compte, une facture... Elles comportent des attributs (par exemple, le nom du
client). Les entit\u233?s sont g\u233?n\u233?ralement repr\u233?sent\u233?es par
des rectangles. Les relations comportent, pour chaque entit\u233? reli\u233?e, une
cardinalit\u233?. Par exemple, la relation entre un client et ses comptes en banque
est l-N. signifiant que chaque client peut avoir un ou plusieurs comptes, et chaque
compte appartenant \u224? un client et un seul. Les relations sont g\u233?n\u233?
ralement repr\u233?sent\u233?es par des lignes dont la terminaison indique la
cardinalit\u233?. Les relations peuvent elles-m\u234?mes comporter des propri\u233?
t\u233?s (des ovales avec Merise, des rectangles avec UML). Les questions suppl\
u233?mentaires \u224? poser sont donc : \u8226? Quelles sont les donn\u233?es
contenues dans cette entit\u233? ? \u8226? Quelles sont les relations entre ces
deux donn\u233?es ? Il y a des dizaines de fa\u231?ons de repr\u233?senter les
entit\u233?s et les relations (\u224? la Merise, \u224? la UML, rectangles, ovales,
losanges...). Le plus important est que tous les acteurs utilisent le m\u234?me
langage graphique. On s'adaptera \u224? la culture ou aux standards du client ou de
l'entreprise pour laquelle on travaille. La figure 10-5 utilise un formalisme
proche d'UML pour repr\u233?senter les entit\u233?s et relations dans le domaine de
la prescription m\u233?dicale. 1 S\u233?jour \u163? Bon de livraison \u239?- \u201?
l\u233?ment de livraison 0. \u8226? Compte-rendu d'analyse pharmaceutique 1
Prescription \u231? 0..* 1 1 Composant livre o..- | Composant prescrit 0..* Compte-
rendu d'administration 1 \u201?l\u233?ment de prescription \u206?1 \u201?l\u233?
ment de posologie \u201?l\u233?ment d'administration 1 Composant administr\u233?
Figure 10-5 : Un diagramme entit\u233?asso\u224?ation CD\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse Les adeptes d'UML utilisent des diagrammes de
classe. Une classe d'objets contient \u224? la fois des attributs et des
traitements (ou op\u233?rations). En principe, un mod\u232?le de classes devrait \
u234?tre diff\u233?rent d'un mod\u232?le entit\u233?s-relations. Dans la pratique,
on s'aper\u231?oit que les mod\u232?les UML sont souvent r\u233?duits \u224? des
entit\u233?s et des relations (m\u234?me dans les ouvrages consacr\u233?s \u224?
UML). L'id\u233?e ici n'est pas d'entrer dans les d\u233?tails de la conception
d'un mod\u232?le de donn\u233?es (il y a d'excellents ouvrages pour cela), mais de
montrer comment un tel mod\u232?le peut \u234?tre utilis\u233? comme outil
d'analyse et de sp\u233?cification dans le cadre d'un cahier des charges. Les six
t\u226?ches (imbriqu\u233?es et cycliques, bien s\u251?r) sont les suivantes : \
u8226? Identifier les entit\u233?s. Les entit\u233?s sont des objets ou des agr\
u233?gations de donn\u233?es. On les repr\u233?sente par des rectangles. \u8226?
Identifier les attributs (propri\u233?t\u233?s). On indiquera celles utiles au
syst\u232?me \u224? l'\u233?tude (rappelons qu'il ne s'agit pas, au stade du cahier
des charges, de mod\u233?liser une base de donn\u233?es). L'un de ces attributs est
l'identifiant (\u233?quivalent \u224? la cl\u233? primaire sur un mod\u232?le
physique). \u8226? D\u233?crire les entit\u233?s et attributs, de pr\u233?f\u233?
rence dans le dictionnaire de donn\u233?es. \u8226? Identifier les relations entre
donn\u233?es. On peut commencer ce travail \u224? t\u234?te repos\u233?e, mais le
mod\u232?le ainsi construit (ou plut\u244?t, en cours de construction) sera d\u232?
s que possible soumis \u224? l'avis des repr\u233?sentants des utilisateurs. \
u8226? D\u233?finir les cardinalit\u233?s des relations. \u8226? V\u233?rifier la
coh\u233?rence de l'ensemble et remonter \u224? la premi\u232?re \u233?tape si n\
u233?cessaire. Au risque de nous r\u233?p\u233?ter, rappelons-le : il s'agit ici de
mod\u233?liser les besoins, et non la solution. Au fur et \u224? mesure que l'on d\
u233?crira de nouvelles exigences fonctionnelles, on les confrontera au mod\u232?le
de donn\u233?es, en cherchant \u224? \u233?liminer les incoh\u233?rences. Le
processus de construction est donc it\u233?ratif et imbriqu\u233? aux autres
processus. Le principe de simplicit\u233? a \u233?t\u233? \u233?nonc\u233? par
plusktirs phfldsopbes. Uto:^ foimi* l\u224?tkms les plus <^ rt\u232? doiverrt pas \
u233?lie nwt\u244?pT^ \u224? utiliser \u339? priw^ sur tous les types de diagramme/
et par\u244?culi\u232?r^^ at\u224?\u226?&s^ mkroentit\u233?s si cela n'aide pas \
u224? la r\u233?flexwn sur les besoms^ Parfois pouss\u233? jusqu'\u224? sa fimite:
ne pas raim de diagramme ^t\u224?^ n\u233?cessaire. -'\u9632? CE)\par\pard\plain\
hyphpar} {
ie 2 - D\u233?veloppement des exigences Le diagramme \u233?tats-transitions
Rappelons qu'un diagramme \u233?tats-transitions repr\u233?sente, sur le plan
informatique, un automate d'\u233?tats finis. De ce fait, il permet de repr\u233?
senter des processus de mani\u232?re concise, pr\u233?cise et non ambigu\u235?,
facilement compr\u233?hensible par les concepteurs et r\u233?alisateurs du syst\
u232?me. On retrouvera ce type de sch\u233?ma dans des cahiers des charges pour des
logiciels temps r\u233?el, mais pas seulement. Il peut \u234?tre tr\u232?s efficace
pour d\u233?crire un processus administratif, par exemple. La figure 10-6 pr\u233?
sente un diagramme d'\u233?tats-transitions pour un logiciel de gestion de dossier.
Il a \u233?t\u233? \u233?labor\u233? par un groupe de travail compos\u233? de
fonctionnaires de l'administration publique, anim\u233? par un assistant \u224? la
ma\u238?trise d'ouvrage. Dossier" complet ==Q \u238? Encours instruction T En
attente de la commission technique -Avis OK- Sursis \u224? statuer V\u233?rifi\
u233? pour commission pl\u233?nl\u233?re Inscription Figure 106 : Un diagramme \
u233?tats-transitions Inscription directe Compl\u233?ment d'instruction
ainsirucoon^- Inscription-M < 1 Inscrit en commission technique J < Inscrit en
commission pl\u233?nl\u233?re * OK J_ En attente de r\u233?alsation R\u233?
alisation 4- \u8226? d\u233?cision Rejet (QD\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse Voici une s\u233?quence classique d'\u233?
laboration de ce type de diagramme : 1. Lors d'une premi\u232?re r\u233?union du
groupe de travail avec le donneur d'ordre (direction, administration centrale),
l'analyste recueille des informations sur les \u233?tapes du cheminement du
dossier. Il ne pr\u233?sente pas de diagramme (risque de confusion). 2. En
interviews individuelles d'utilisateurs sur le terrain, l'analyste recueille les
pratiques (qui peuvent diff\u233?rer sensiblement de la proc\u233?dure officielle).
3. Seul, le consultant \u233?labore le diagramme \u233?tats-transitions, en notant
les incoh\u233?rences, en tentant de les r\u233?soudre si possible. 4. L'analyste
parcourt les textes r\u233?glementaires. \u192? nouveau, il note les \u233?carts et
les incoh\u233?rences. Il compl\u232?te ou modifie le diagramme. 5. Lors d'une
deuxi\u232?me r\u233?union du groupe de travail, l'analyste pr\u233?sente le
diagramme \u233?tats-transitions au donneur d'ordres et lui demande son avis. Si
aucun consensus n'est trouv\u233?, on peut remonter aux \u233?tapes 2 \u224? 4. 6.
L'analyste met le diagramme au propre. Il demande au groupe de travail de le
valider. 7. Si cela est possible, le diagramme est envoy\u233? \u224? la ma\u238?
trise d'oeuvre pour avoir son avis. Les questions \u224? poser aux diff\u233?rents
acteurs sont : \u8226? Ouel est le cheminement (du dossier, d'un objet) ? \u8226?
Dans quels \u233?tats peut se trouver (le dossier, l'objet) ? \u8226? Ouel \u233?v\
u233?nement va modifier (le dossier, l'objet) ? \u8226? Oue se passe-t-il suite \
u224? cet \u233?v\u233?nement ? \u8226? Oue se passe-t-il si cet \u233?v\u233?
nement n'a pas lieu ? (exception) Comme pour les autres types de diagramme, le
diagramme \u233?tats-transitions peut servir \u224? mod\u233?liser un processus
existant ou un processus \u224? informatiser. Il est souvent long \u224?
constituer, surtout lorsque les interlocuteurs sont plus familiaris\u233?s avec des
proc\u233?dures \u233?crites (proc\u233?dures administratives) qu'avec des sch\
u233?mas. Les organigrammes, arbres et tables de d\u233?cision Des r\u232?gles de
gestion fort complexes, par exemple sur le plan juridique, peuvent parfois
s'exprimer tr\u232?s facilement, et devenir tr\u232?s claires pour la ma\u238?trise
d'ceuvre, si elles sont exprim\u233?es sous forme de tables ou d'arbres de d\u233?
cision, ou sous forme d'organigramme. Lors de l'\u233?laboration d'un cahier des
charges pour une application de port\u233?e nationale, nous avions d\u233?termin\
u233? 24 r\u233?ponses \u224? la question de savoir qui, parmi le p\u232?re, la m\
u232?re ou autre repr\u233?sentant l\u233?gal \u224? droit CED\par\pard\plain\
hyphpar} {
Partie 2 - D\u233?veloppement des exigences \u224? l'information sur un enfant, en
fonction de la situation. Un tableau \u224? 24 lignes et 10 colonnes a rendu la
situation beaucoup plus facile \u224? comprendre. Quant aux informaticiens, selon
leurs propres termes, \u171? ils n'avaient plus qu'\u224? coder \u187?. La bo\u238?
te \u224? outils La mod\u233?lisation sous forme graphique est une bo\u238?te \
u224? outils. Pour repr\u233?senter la m\u234?me information, on a parfois le choix
entre plusieurs outils. Inversement, un outil peut avoir plusieurs usages. Il ne
s'agit pas de \u171? tout > repr\u233?senter avec le m\u234?me outil, ni d'utiliser
tous les outils \u224? tout prix. Rappelons que l'objectif premier est ici de se
faire comprendre de tous les acteurs et d'ajouter de la pr\u233?cision au texte.
Par exemple, dans un cahier des charges pour une application de gestion, on pourra
utiliser un diagramme \u233?tats-transitions pour montrer le circuit d'une demande,
suivi d'un diagramme de s\u233?quence, ou un seul diagramme de flux. La question \
u224? se poser est : comment repr\u233?senter l'information de mani\u232?re \u224?
ce qu'elle soit compr\u233?hensible de tous, sans ambigu\u239?t\u233? ? Il y a un
travers dans lequel nous avons tous tendance \u224? tomber : nous n'utilisons que
les outils que nous ma\u238?trisons. Et comme nous ma\u238?trisons mieux les outils
que nous utilisons souvent, nous finissons par n'utiliser qu'un outil ou deux. Pour
ne pas tomber dans ce travers, il ne faut pas h\u233?siter \u224? exp\u233?
rimenter. Maquettes et prototypes La maquette papier Une maquette est un mod\u232?
le qui pr\u233?figure un produit futur. Rappelons qu'\u224? la diff\u233?rence d'un
prototype, la maquette est toujours un produit jetable. Le but ici n'est pas de
commencer \u224? d\u233?velopper le produit, ni m\u234?me \u224? le sp\u233?cifier,
mais de visualiser son aspect ou son comportement. Il ne s'agit pas de sp\u233?
cifier le produit, et encore moins de d\u233?velopper un prototype. Plus le support
sera temporaire4 (tableau blanc, notes auto- adh\u233?sives). et moins on sera
tent\u233? de faire des sp\u233?cifications d\u233?taill\u233?es 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.
Concr\u232?tement, cela consiste \u224? sch\u233?matiser sur le papier, ou sur un
tableau blanc, un dessin d'\u233?cran, par exemple. Plusieurs dessins d'\u233?crans
sur feuilles de papier A4 dispos\u233?s sur une grande feuille de papier blanc
permettent de simuler des encha\u238?nements d'\u233?crans et des interactions avec
les utilisateurs. On peut utiliser des moyens d'expression plus 4. Maquette \u8226?
faible fid\u233?lit\u233? \u8226? (low\u226?) corn* par\u233?e \u224? un prototype.
CD\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse riches, comme des outils de pr\u233?sentation,
HTML, voire un dessin anim\u233?. Mais l'id\u233?e est toujours la m\u234?me. Une
maquette papier est utile pour faire visualiser les fonctions attendues \u224? des
personnes peu habitu\u233?es \u224? travailler sur des mod\u232?les abstraits, de
les aider \u224? imaginer eux-m\u234?mes une pr\u233?figuration du futur produit.
Une fois que les participants se sont mis d'accord, il est plus facile de
formaliser ces exigences, sous forme de cas d'utilisation par exemple. Le
prototypage Contrairement \u224? la maquette papier, un prototype est \u171? vivant
\u187?. C'est du logiciel. Il peut \u234?tre jetable ou au contraire r\u233?
utilisable, si on a l'intention de l'int\u233?grer dans le produit fini.
Prototyper, c'est donc entrer provisoirement (et par exception) dans la phase de r\
u233?alisation pour exp\u233?rimenter un fragment du produit \u224? venir.
Plusieurs formes de prototypes sont envisageables, en particulier : \u8226? Le
prototype \u171? horizontal \u187? : il simule l'application visuellement (encha\
u238?nement d'\u233?crans), sans que toutes les fonctions soient pr\u233?sentes. Il
est utilis\u233? en particulier pour montrer et tester les encha\u238?nements d'\
u233?crans. Il est visuellement proche de l'application \u224? venir, mais les \
u233?crans sont \u171? creux \u187? ou \u171? muets \u187? : les fonctions ne sont
pas d\u233?velopp\u233?es et ne seront pas ex\u233?cut\u233?es. \u8226? Le
prototype \u171? vertical \u187? : une seule fonction est compl\u232?tement d\u233?
velopp\u233?e. Ce type de prototype est utilis\u233? pour tester une fonction ou
une propri\u233?t\u233? du logiciel, comme la fiabilit\u233?, la s\u233?curit\
u233?, ou le temps de r\u233?ponse. En pratique, le prototypage est faisable si une
\u233?quipe de d\u233?veloppement est pr\u233?sente et interagit avec la ma\u238?
trise d'ouvrage. C'est le cas dans une grande entreprise ou une administration qui
d\u233?veloppe une application en interne. Immanquablement, il y aura un moment o\
u249? les repr\u233?sentants des utilisateurs vont se trouver face \u224? face avec
les d\u233?veloppeurs. C'est l'assistant \u224? la ma\u238?trise d'ouvrage qui doit
g\u233?rer le choc des cultures. Un talent d'animateur et de mod\u233?rateur est
requis, car il peut y avoir des tensions. Quel que soit le type de prototype d\
u233?velopp\u233?, il risque de d\u233?river vers un d\u233?but de d\u233?
veloppement. Cela peut \u234?tre intentionnel (m\u233?thodes agiles), mais cela
doit \u234?tre contr\u244?l\u233?. Avant de faire d\u233?velopper un prototype, il
faut estimer les risques que comporte cette \u171? incursion \u187? dans la phase
de r\u233?alisation : sp\u233?cifications informelles et rampantes, court-drcuitage
in\u233?vitable entre ma\u238?trise d'ouvrage et ma\u238?trise d'oeuvre, et
illusion, de la part de la ma\u238?trise d'ouvrage, que le d\u233?veloppement du
produit est presque fini (alors qu'il n'a pas encore commenc\u233?). QD\par\pard\
plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Matrices CRUD et RACI Un des moyens de
d\u233?tecter les incoh\u233?rences et incompl\u233?tudes est la matrice CRUD (de
l'anglais Create, Read, Update. Ddele). Une entit\u233? doit pouvoir \u234?tre cr\
u233?\u233?e, lue, mise \u224? jour et supprim\u233?e du syst\u232?me. Si l'une de
ces op\u233?rations ne peut \u234?tre effectu\u233?e par le syst\u232?me pour une
entit\u233? donn\u233?e, il faut pousser l'analyse et comprendre pourquoi. Ce n'est
pas n\u233?cessairement une incompl\u233?tude (par exemple, on peut vouloir que
certaines entit\u233?s ne soient jamais supprim\u233?es), mais il faut s'en
assurer. Une autre matrice que l'on peut utiliser est celle des responsabilit\u233?
s, ou matrice RACI [Responsable, Aaountable. Consulted, inform\u233?e) d\u233?
finissant le r\u244?le des acteurs par rapport aux fonctions. Comme pour la matrice
CRUD. il ne s'agit pas de d\u233?tecter 100 % des incoh\u233?rences, mais d'affiner
l'analyse. Evaluer la Faisabilit\u233? et le co\u251?t Il est rare que le demandeur
(ma\u238?trise d'ouvrage ou utilisateur) connaisse le co\u251?t de ses exigences.
D'une part, par ce que ce qui est simple \u224? l'ex\u233?cution peut \u234?tre tr\
u232?s complexe \u224? impl\u233?menter sous forme de logiciel (l'inverse est \
u233?galement vrai : certains utilisateurs n'osent pas demander une fonction en
pensant que leur demande est irr\u233?aliste, alors qu'elle est tr\u232?s simple \
u224? r\u233?aliser). D'autre part, par ce que le co\u251?t d'une fonction d\u233?
pend du contexte, de ce qui a \u233?t\u233? r\u233?alis\u233? par ailleurs. Il est
donc important de conseiller le demandeur sur le co\u251?t estim\u233? de sa
demande. Ce co\u251?t n'est pas seulement financier. La r\u233?alisation d'une
exigence peut n\u233?cessiter des d\u233?lais suppl\u233?mentaires, une formation
des utilisateurs, une nouvelle organisation, ou avoir des r\u233?percussions dans
d'autres domaines. Par faisabilit\u233?, on entend aussi l'estimation des risques.
Une nouvelle fonction peut avoir des cons\u233?quences sur le d\u233?lai de
livraison de l'ensemble de l'application, ou sur ses performances, ou sa s\u233?
curit\u233?. C'est au ma\u238?tre d'ouvrage de d\u233?cider de l'opportunit\u233?
de r\u233?aliser une exigence, apr\u232?s avoir \u233?t\u233? inform\u233? des
cons\u233?quences. Le diagramme de Kano (figure 10-7) permet de chercher le rapport
entre le degr\u233? de r\u233?alisation d'une caract\u233?ristique et le degr\u233?
de satisfaction du client. Le principe est de ranger chaque caract\u233?ristique du
produit (fonction ou caract\u233?ristique non fonctionnelle) dans une des trois
cat\u233?gories : (E>\par\pard\plain\hyphpar} {
Chapitre 10 - L'\u233?tape d'analyse \u8226? Fonction obligatoire (indispensable) :
son absence cr\u233?e de l'insatisfaction chez le client, mais sa pr\u233?sence
n'apporte pas de satisfaction particuli\u232?re (souvent consid\u233?r\u233?e comme
\u233?vidente, donc pass\u233?e sous silence lors d'une interview). \u8226?
Fonction \u224? satisfaction proportionnelle : le niveau de satisfaction est
proportionnel \u224? la pr\u233?sence de la fonction ou \u224? la performance de la
caract\u233?ristique (g\u233?n\u233?ralement, elles \u233?mergent les premi\u232?
res lors d'une interview ou d'une enqu\u234?te). \u8226? Fonction attractive : son
absence ne cr\u233?e pas de frustration, mais sa pr\u233?sence apporte une
satisfaction suppl\u233?mentaire (rarement exprim\u233?es lors d'interviews, mais
surtout avec des techniques de cr\u233?ativit\u233?). Pour savoir dans quelle cat\
u233?gorie cette fonction doit \u234?tre rang\u233?e (du point de vue de
l'utilisateur, bien s\u251?r) il faut lui demander comment il r\u233?agirait si ce
besoin \u233?tait combl\u233? et s'il ne l'\u233?tait pas. puis de lui proposer,
pour chaque question, quatre r\u233?ponses possibles : \u171? j'aime \u187?. \u171?
c'est normal de l'avoir \u187?. \u171? je suis indiff\u233?rent \u187? et \u171? je
n'aime pas \u187?. On consigne ensuite les r\u233?sultats dans une matrice
(tableau) \u224? quatre lignes et quatre colonnes, correspondant \u224? ces quatre
r\u233?ponses aux deux questions. Ils permettent de d\u233?terminer, pour chaque
besoin exprim\u233?, s'il est indispensable, de base, ou constitue un \u171? plus \
u187?. Satisfaction cfierrt Insatisfaction client Figure 107 : Diagramme de Kano
CED\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Check-list d'analyse Il n'y a pas v\
u233?ritablement de \u171? fin d'\u233?tape \u187? d'analyse, il ne s'agit donc pas
ici de v\u233?rifier qu'un objectif a \u233?t\u233? atteint. Cette check-list est \
u224? utiliser p\u233?riodiquement pour v\u233?rifier que l'on avance dans la bonne
direction et que les moyens n\u233?cessaires et suffisants sont mis en \u339?uvre
pour am\u233?liorer la coh\u233?rence, la compl\u233?tude des exigences. Il s'agit
aussi d'\u233?viter le ph\u233?nom\u232?ne de l'analyse interminable (en anglais
anaiysis paralysis). Cette liste peut donc donner l'impression qu'elle fait double
emploi avec les check-lists du recueil et des sp\u233?cifications. \u8226? On a
examin\u233?, revu, affin\u233? et si n\u233?cessaire modifi\u233? le diagramme de
contexte. \u8226? Le dictionnaire de donn\u233?es a \u233?t\u233? cr\u233?\u233?,
et il est r\u233?guli\u232?rement enrichi. \u8226? Les exigences ont \u233?t\u233?
d\u233?compos\u233?es de mani\u232?re suffisamment fine pour refl\u233?ter les
besoins les plus proches du terrain (utilisateurs). \u8226? Les exigences ont \
u233?t\u233? d\u233?compos\u233?es de mani\u232?re suffisamment fine pour \u234?tre
compr\u233?hensibles sans ambigu\u239?t\u233? par le ma\u238?tre d'ceuvre. \u8226?
On n'a pas d\u233?compos\u233? les exigences au-del\u224? du strict n\u233?
cessaire. \u8226? Les diff\u233?rents acteurs ont activement particip\u233? \u224?
l'analyse. \u8226? Chaque cas d'utilisation a un acteur d\u233?fini. \u8226? Chaque
fonction a un utilisateur d\u233?fini. \u8226? Il y a une tra\u231?abilit\u233?
entre les exigences de diff\u233?rents niveaux. \u8226? On a d\u233?fini des
priorit\u233?s entre exigences. \u8226? On a utilis\u233? des mod\u232?les
graphiques lorsque cela \u233?tait n\u233?cessaire. \u8226? On a utilis\u233? une
matrice CRUD. \u8226? On a utilis\u233? une matrice RACI. (E\u163?)\par\pard\plain\
hyphpar} {
Chapitre 11 Les exigences non Fonctionnelles Difficiles \u224? recueillir, \u224?
analyser et \u224? sp\u233?cifier, li\u233?es \u224? la fois au mat\u233?riel, au
logiciel et \u224? l'usage qui en est fait, les exigences non fonctionnelles sont
souvent n\u233?glig\u233?es. Pourtant, c'est la satisfaction de ces exigences qui
fait la qualit\u233?, et donc dans une large mesure, la valeur d'un logiciel. Les
caract\u233?ristiques de qualit\u233? Un logiciel ne peut \u234?tre d\u233?crit ni
par ses seules fonctions (point de vue du ma\u238?tre d'ouvrage), ni par ses seules
caract\u233?ristiques techniques (contraintes de la ma\u238?trise d'ceuvre). Le
cahier des charges doit n\u233?cessairement comporter des caract\u233?ristiques
relatives \u224? la qualit\u233? du logiciel, appel\u233?es exigences non
fonctionnelles. Comme les exigences fonctionnelles, celles-ci doivent \u234?tre
structur\u233?es selon leur typologie. Plusieurs typologies existent pour d\u233?
crire la qualit\u233? du logiciel. La plus ancienne est celle de McCall, qui permet
de caract\u233?riser la qualit\u233? du logiciel selon un certain nombre de
facteurs et de crit\u232?res. Dans les paragraphes qui suivent, nous d\u233?crivons
les exigences non fonctionnelles en utilisant la structuration par caract\u233?
ristiques et sous- caract\u233?ristiques de qualit\u233? selon la norme ISO/CEI
25000. Cette norme a l'avantage de d\u233?crire la qualit\u233? du logiciel de la
mani\u232?re la plus compl\u232?te et la moins redondante possible. Dans la
pratique, pour \u233?laborer un cahier des charges, on ne suivra pas n\u233?
cessairement ce m\u234?me sch\u233?ma. Chaque mod\u232?le de cahier des charges
structure les exigences non fonctionnelles selon un sch\u233?ma qui lui est propre.
ISO 25000 pourra servir de trame et de liste de contr\u244?le lors de l'\u233?
laboration d'un cahier des charges ou de l'utilisation d'un mod\u232?le de cahier
des charges.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Qualit\u233? du logiciel ~r~ Capacit\
u233? fonctionnelle l Aptitude Exactitude Conformit\u233? r\u233?glementaire
Interop\u233?rabilit\u233? S\u233?curit\u233? FlabiHt\u233? 1 Maturit\u233? Tol\
u233?rance aux fautes Possibilt\u233?de r\u233?cup\u233?ration Conformit\u233?
Facilit\u233? d'utilisation i Facilit\u233? de compr\u233?hension Facilit\u233? d'
apprentissage Facilit\u233? d'exploitation Attractlvit\u233? Conformit\u233?
Rendement l Comportement vis-a-vis du temps Comportement vis-\u224?-vis des
ressources Conformit\u233? Maintenabilit\u233? l Fadlit\u233? d'analyse Facilit\
u233? de modification Stabilit\u233? TestablHt\u233? Conformit\u233? PortabBIt\
u233? l Fadlit\u233? d'adaptation Fadrt\u233?\u224? l'installation
Interchangeabilit\u233? Conformit\u233? Figure 1 h 1 : Caract\u233?ristiques et
sous<aract\u233?risnques ISO 25000 norme ISO/CEI 25000 La norme ISO 25000',
relative \u224? la qualit\u233? du produit logiciel, donne des outils pour, d'une
part \u233?valuer la qualit\u233? du logiciel, et d'autre part pour construire la
qualit\u233?. Selon cette norme, la qualit\u233? du logiciel peut \u234?tre per\
u231?ue sur trois niveaux : \u8226? La qualit\u233? interne \'5c'7binternai
qualily) correspond au niveau structurel d'analyse, et peut \u234?tre \u233?valu\
u233?e par examen du code source, de l'architecture, des sp\u233?cifications ;
c'est la perspective de l'architecte de l'application, du concepteur, du d\u233?
veloppeur. \u8226? La qualit\u233? externe \'5c'7bexternal qualily) correspond au
niveau comportemental, visible et mesurable en particulier lors de tests ; c'est la
qualit\u233? vue avec la perspective du chef de projet et des \u233?quipes de
validation. \u8226? La qualit\u233? de fonctionnement (quality in use) correspond
au point de vue de l'utilisateur. Elle se d\u233?compose en quatre caract\u233?
ristiques : l'efficacit\u233? (relative \u224? l'atteinte des objectifs de
l'utilisateur), la productivit\u233? (\u233?conomie de temps, d'efforts) la s\u233?
curit\u233? (risques sur l'utilisateur, le logiciel, l'environnement), et la
satisfaction de l'utilisateur. La norme se r\u233?f\u232?re \u233?galement \u224?
la qualit\u233? du processus de d\u233?veloppement, sans d\u233?finir ce processus
(il y a d'autres normes pour cela). Ces diff\u233?rents niveaux de qualit\u233? du
produit et du processus sont interd\u233?pendants : la qualit\u233? de
fonctionnement d\u233?pend de la qualit\u233? externe, qui d\u233?pend de la
qualit\u233? interne, qui elle-m\u234?me d\u233?pend de la qualit\u233? du
processus de d\u233?veloppement. 1. La s\u233?rie normative ISO/CEI 25000 r\u233?
sulte de la fusion entre plusieurs normes dont ISO/ ai 9126 et ISO/ CE114598. U (E\
u163?)\par\pard\plain\hyphpar} {
Chapitre 11 - Les exigences non Fonctionnelles Cette repr\u233?sentation \u233?tag\
u233?e de la qualit\u233? pourra \u234?tre mise \u224? profit pour structurer les
exigences dans un cahier des charges2, par exemple, selon le sch\u233?ma : \u8226?
qualit\u233? en utilisation -*\u9632? exigences utilisateur ; \u8226? qualit\u233?
externe \u9632?*\u8226? exigences produit ; \u8226? qualit\u233? interne -*\u8226?
contraintes techniques : \u8226? qualit\u233? du processus \u9632?*\u8226?
contraintes projet. Les contraintes li\u233?es au projet et les contraintes
techniques seront abord\u233?es plus loin. Examinons ici les exigences de qualit\
u233? interne et externe telles que d\u233?finies par la norme, c'est-\u224?-dire
sous forme de caract\u233?ristiques et sous-caract\u233?ristiques. Capacit\u233?
fonctionnelle La capacit\u233? fonctionnelle (ou fonctionnalit\u233?)
est \'5c'7bensemble d'attributs portant sur \'5c'7bexistence d'un ensemble de
fonctions et leurs propri\u233?t\u233?s donn\u233?es. Les propri\u233?t\u233?s sont
celles qui satisfont aux besoins exprim\u233?s ou implicites (norme ISO/CEI 25000).
Elle se d\u233?compose en cinq sous-caract\u233?ristiques : \u8226? Aptitude :
attributs du logiciel portant sur la pr\u233?sence et l'ad\u233?quation d'une s\
u233?rie de fonctions pour des t\u226?ches donn\u233?es. \u8226? Exactitude :
ensemble des attributs de logiciel portant sur la fourniture de r\u233?sultats
justes ou convenus. \u8226? Conformit\u233? r\u233?glementaire : respect des
normes, conventions et r\u233?glementations de droit. \u8226? Interop\u233?rabilit\
u233? : capacit\u233? \u224? interagir avec des syst\u232?mes donn\u233?s. \u8226?
S\u233?curit\u233? : aptitude \u224? emp\u234?cher tout acc\u232?s non autoris\
u233? (accidentel ou d\u233?lib\u233?r\u233?) au programme ou aux donn\u233?es. En
pratique, dans un cahier des charges, la section exigences fonctionnelles d\u233?
crira l'aptitude, et rien de plus. La conformit\u233? r\u233?glementaire sera d\
u233?finie dans la section r\u232?gles de gestion. Les trois autres sous-caract\
u233?ristiques (exactitude, conformit\u233? r\u233?glementaire, s\u233?curit\u233?)
seront d\u233?crites dans des paragraphes correspondants, dans la section exigences
non fonctionnelles. Pour sp\u233?cifier les exigences d'interop\u233?rabilit\u233?
et de s\u233?curit\u233?, un moyen pratique et efficace consiste \u224? faire r\
u233?f\u233?rence \u224? des normes relatives \u224? ces sous-caract\u233?
ristiques. Fiabilit\u233? La fiabilit\u233? est \'5c'7bensemble d'attributs portant
sur taptitude du logiciel \u224? maintenir son niveau de service dans des
conditions pr\u233?cises et pendant une p\u233?riode d\u233?termin\u233?e. 2. Voir
au chapitre 13 comment formuler les exigences non fonctionnelles, et au chapitre 14
leur place dans les diff\u233?rents mod\u232?les de cahiers des charges. \'5c'7bEJ\
ie 2 - D\u233?veloppement des exigences Ce crit\u232?re se d\u233?cline en : \
u8226? Maturit\u233? : fr\u233?quence de d\u233?faillances dues \u224? des d\u233?
fauts du logiciel. \u8226? Tol\u233?rance aux fautes : aptitude du logiciel \u224?
maintenir un niveau de service acceptable en cas de d\u233?faut du logiciel ou de
violation de son interface. \u8226? Possibilit\u233? de r\u233?cup\u233?ration :
capacit\u233? \u224? r\u233?tablir son niveau de service et de restaurer les
informations directement affect\u233?es en cas de d\u233?faillance, et sur le temps
et l'effort n\u233?cessaires pour le faire. Parmi les mesures utilis\u233?es pour
la Habilit\u233?, citons le temps moyen entre deux d\u233?faillances (MTBF, mean
lime between failures), la dur\u233?e moyenne de d\u233?faillance \'5c'7bmean down
time). ou le temps mis par le syst\u232?me pour red\u233?marrer. Nous sommes l\
u224? \u224? la limite entre les exigences produit (tr\u232?s d\u233?pendantes du
mat\u233?riel) et les exigences de service. Formuler ces exigences dans un cahier
des charges est tout \u224? fait possible, mais la formulation est tr\u232?s d\
u233?pendante des fournitures attendues (logiciel seul, mat\u233?riel et logiciel,
services, etc.). Facilit\u233? d'utilisation (utilisabilit\u233?) La notion
d'utilisabilit\u233? est proche de celle d'ergonomie. L'ergonomie est l'\u233?tude
des situations de travail et des relations entre l'\u234?tre humain et un syst\
u232?me. Elle a pour objectif d'am\u233?liorer le confort, voire le plaisir, de
l'utilisateur et par voie de cons\u233?quence l'efficacit\u233? dans le travail et
dans l'utilisation d'un produit (en l'occurrence, un logiciel). Le terme
d'utilisabilit\u233? englobe un p\u233?rim\u232?tre plus large, qui comprend
l'efficacit\u233?. De plus, le mot ergonomie a \u233?t\u233? largement galvaud\
u233? par les informaticiens, qui le mettent un peu \u224? toutes les sauces, et
par les utilisateurs, qui ne sont pas suffisamment pr\u233?cis dans leurs
exigences. La norme ISO/CEI 25000 d\u233?finit la facilit\u233? d'utilisation (ou
utilisabilit\u233?) comme \u171? l'ensemble d'attributs portant sur l'effort n\
u233?cessaire pour l'utilisation et sur l'\u233?valuation individuelle de cette
utilisation par un ensemble d\u233?fini ou implicite d'utilisateurs \u187?. Elle se
d\u233?cline en : \u8226? Facilit\u233? de compr\u233?hension : attributs du
logiciel portant sur l'effort que doit faire l'utilisateur pour reconna\u238?tre la
logique et sa mise en \u339?uvre. \u8226? Facilit\u233? d'apprentissage : attributs
du logiciel portant sur l'effort que doit faire l'utilisateur pour apprendre son
application (par exemple, ma\u238?trise de l'exploitation des entr\u233?es, des
sorties). \u8226? Facilit\u233? d'exploitation : attributs du logiciel portant sur
l'effort que doit faire l'utilisateur pour exploiter et contr\u244?ler son
application. \u8226? Attractivit\u233? : capacit\u233? du produit logiciel \u224? \
u234?tre attrayant pour l'utilisateur. CD\par\pard\plain\hyphpar} {
Chapitre 11 - Les exigences non Fonctionnelles L'util is\u226?bilit\u233? est
difficile \u224? d\u233?finir. Une fa\u231?on de faire consiste \u224? exiger la
conformit\u233? \u224? des standards d'utilisabilit\u233? ou \u224? une charte
d'ergonomie. De tels documents imposent des r\u232?gles, comme par exemple sur le
nombre maximal de boutons par \u233?cran, le nombre d'objets sur une liste ou les
combinaisons de couleurs autoris\u233?es. Une autre mani\u232?re de faire
consiste \u224? formuler les exigences d'utilisabilit\u233? \u224? un plus haut
niveau, en l'occurrence au niveau de l'utilisateur. Voici par exemple comment
peuvent s'exprimer quatre exigences d'utilisabilit\u233?. correspondant aux quatre
sous-caract\u233?ristiques (facilit\u233? d'apprentissage, de compr\u233?hension,
d'exploitation et d'attractivit\u233?) : Pour 80 % des m\u233?decins, une formation
initiale de 2 heures sera suffisante \u224? l'appropriation des fonctions de
prescription. Apr\u232?s un mois d'utilisation quotidienne. 80 X des utilisateurs
form\u233?s \u224? l'outil pourront l'utiliser sans faire appel \u224? une aide
ext\u233?rieure. Le temps moyen mis par un m\u233?decin form\u233? au logiciel pour
prescrire un m\u233?dicament avec le module de prescription ne doit pas exc\u233?
der de 10 X le temps moyen mis par un m\u233?decin pour effectuer cette action
manuellement. Apr\u232?s un mois d'utilisation quotidienne. 80 X des utilisateurs
devront se d\u233?clarer satisfaits ou tr\u232?s satisfaits par 1e syst\u232?me.
Remarquons cette proportion de 80 %. On ne peut pas exiger qu'une fonction faisant
intervenir des \u234?tres humains soit r\u233?alis\u233?e \u224? 100 %. Ouatre
utilisateurs sur cinq efficients et satisfaits est beaucoup plus r\u233?aliste.
Rendement La norme ISO/CEI 25000 d\u233?finit le rendement comme l'ensemble
d'attributs portant sur le niveau de service d'un logiciel el la quantit\u233? de
ressources utilis\u233?es, dans des conditions d\u233?termin\u233?es. Celui-ci se
d\u233?cline en : \u8226? comportement vis-\u224?-vis du temps, portant sur les
temps de r\u233?ponse et de traitement, ainsi que sur les d\u233?bits lors de l'ex\
u233?cution de sa fonction ; \u8226? comportement vis-\u224?-vis des ressources,
portant sur la quantit\u233? de ressources utilis\u233?es et sur la dur\u233?e de
leur utilisation lorsqu'il ex\u233?cute sa fonction. Dans un cahier des charges, il
est rare que l'on sp\u233?cifie directement le comportement vis-\u224?-vis des
ressources (m\u233?moire ou espace disque). En g\u233?n\u233?ral, il est plus utile
de sp\u233?cifier l'exigence \u224? un plus haut niveau (nombre d'utilisateurs
simultan\u233?s). Le comportement vis-\u224?-vis du temps sera \u233?galement d\
u233?crit comme une exigence non fonctionnelle de niveau CD\par\pard\plain\hyphpar}
{
ie 2 - D\u233?veloppement des exigences utilisateur (temps de r\u233?ponse). Ces
deux exigences sont interd\u233?pendantes. Cela donne : Le syst\u232?me pourra \
u234?tre utilis\u233? simultan\u233?ment par 150 utilisateurs. \u192? pleine
charge, le temps d'affichage d'un \u233?cran complet sera inf\u233?rieur ou \u233?
gal \u224? 1.5 seconde. Remarquons que cette la premi\u232?re exigence de rendement
est la d\u233?clinaison d'une contrainte organisationnelle, voire d'un objectif
strat\u233?gique. La seconde exigence d\u233?rive d'une exigence d'utilisabilit\
u233?, et correspond \u224? un seuil psychologique. Ces deux exigences sont interd\
u233?pendantes : avec 150 utilisateurs simultan\u233?s, le syst\u232?me r\u233?
pondra en moins d'une seconde et demie. Maintenabilit\u233? La maintenabilit\u233?
est formellement d\u233?finie \u171? comme l'ensemble d'attributs portant sur
l'effort n\u233?cessaire pour faire des modifications donn\u233?es \u187? (ISO/IEC
25000). Elle se d\u233?compose en : \u8226? Facilit\u233? d'analyse : attributs du
logiciel portant sur l'effort n\u233?cessaire pour diagnostiquer les d\u233?
ficiences ou les causes de d\u233?faillance, ou pour identifier les parties \u224?
modifier. \u8226? Facilit\u233? de modification : attributs du logiciel portant sur
l'effort n\u233?cessaire pour modifier, rem\u233?dier aux d\u233?fauts, ou changer
d'environnement. \u8226? Stabilit\u233? : attributs du logiciel portant sur le
risque des effets inattendus des modifications. \u8226? Testabilit\u233? :
attributs du logiciel portant sur l'effort n\u233?cessaire pour valider le logiciel
modifi\u233?. La maintenabilit\u233? est une caract\u233?ristique essentiellement
interne, invisible de l'utilisateur. On peut cependant sp\u233?cifier des
contraintes de service \u224? l'utilisateur. Le mod\u232?le Volere (voir chapitre
14) regroupe dans un m\u234?me paragraphe les exigences de maintenabilit\u233? et
de support. Il s'agit en r\u233?alit\u233? d'exigences de maintenance plut\u244?t
que de maintenabilit\u233?. Portabilit\u233? La portabilit\u233? est \u8364?
l'ensemble d'attributs portant sur l'aptitude du logiciel \u224? \u234?tre transf\
u233?r\u233? d'un environnement \u224? l'autre \u187? (norme ISO/CEI 25000). Elle
se d\u233?compose en : \u8226? Facilit\u233? d'adaptation : elle concerne les
attributs du logiciel portant sur la possibilit\u233? de son adaptation \u224?
diff\u233?rents environnements donn\u233?s sans avoir recours \u224? d'autres
actions ou moyens que ceux pr\u233?vus \u224? cet effet pour le logiciel consid\
u233?r\u233?. CED\par\pard\plain\hyphpar} {
Chapitre 11 - Les exigences non Fonctionnelles \u8226? Facilit\u233? \u224?
l'installation : effort n\u233?cessaire pour installer le logiciel dans un
environnement donn\u233?. \u8226? Conformit\u233? relative aux r\u232?gles de
portabilit\u233? : attributs du logiciel permettant \u224? celui-ci de se conformer
aux normes ou conventions ayant trait \u224? la portabilit\u233?. \u8226?
Interchangeabilit\u233? : aptitude du logiciel \u224? \u234?tre utilis\u233? \u224?
la place d'un autre logiciel dans le m\u234?me environnement. La portabilit\u233?
stricto sensu (facilit\u233? d'adaptation) induit une contrainte tr\u232?s forte
sur le d\u233?veloppement et l'architecture du logiciel. Aussi, on ne l'exigera que
si cela s'av\u232?re n\u233?cessaire, apr\u232?s une \u233?ventuelle \u233?tude
d'opportunit\u233?. En revanche, la facilit\u233? d'installation est une exigence \
u224? forte valeur ajout\u233?e, surtout si le logiciel doit \u234?tre install\
u233? sur des postes individuels. Il faudra la sp\u233?cifier dans tous les cas.
Zoom sur l'utilisabilit\u233? Il y a au moins trois mani\u232?res de sp\u233?cifier
l'utilisabilit\u233? dans un cahier des charges. La premi\u232?re s'appuie sur les
quatre sous-caract\u233?ristiques d'utilisabilit\u233? de la norme ISO 25000 d\
u233?j\u224? mentionn\u233?e : facilit\u233? d'apprentissage, facilit\u233? de
compr\u233?hension, facilit\u233? d'exploitation (utilisation au quotidien) et
attractivit\u233?. La deuxi\u232?me fa\u231?on de structurer les exigences
d'utilisabilit\u233? s'appuie \u233?galement sur ISO 25000, cette fois sur la
qualit\u233? de fonctionnement (en anglais. qualily in use). Celle-ci se d\u233?
finit par quatre crit\u232?res : \u8226? L'efficacit\u233? : capacit\u233? du
logiciel \u224? permettre aux utilisateurs d'atteindre leurs objectifs avec
exactitude et exhaustivit\u233?. \u8226? La productivit\u233?.- capacit\u233? \
u224? optimiser le temps et l'effort de l'utilisateur. \u8226? La s\u233?curit\
u233? : capacit\u233? du produit logiciel \u224? limiter les risques sur la sant\
u233?, les activit\u233?s ou l'environnement des utilisateurs, en particulier suite
\u224? une d\u233?faillance (ici. le terme innocuit\u233?, traduction de l'anglais
safety. serait sans doute plus appropri\u233?). \u8226? La satisfaction .-
correspond \u224? une attitude positive de l'utilisateur lors de l'interaction avec
le produit. La troisi\u232?me mani\u232?re de structurer les exigences s'appuie sur
les crit\u232?res d'ergonomie d\u233?finis par la norme AFNOR Z-67-133-13. bas\
u233?e sur les travaux de Bastien et Scapin. Cette norme d\u233?finit l'ergonomie
du logiciel par sept crit\u232?res (figure 11-2) : \u8226? la compatibilit\
u233? ; \u8226? le guidage; \u8226? l'homog\u233?n\u233?it\u233?; 3.AFNORZ67-133-1.
D\u233?finition des cri* t\u232?res ergonomiques de conception et \u233?valuation
des interfaces utilisateurs, 1991. CD\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences \u8226? la souplesse; \u8226? le contr\
u244?le explicite ; \u8226? la gestion des erreurs ; \u8226? la concision. Figure
U-2 : Sept crit\u232?res d'ergonomie Examinons chacun de ces crit\u232?res et la
mani\u232?re de les d\u233?cliner sous forme d'exigences. Compatibilit\u233? La
compatibilit\u233? est la < capacit\u233? \u224? s'int\u233?grer dans l'activit\
u233? des utilisateurs \u187?. Elle concerne l'accord pouvant exister entre les
caract\u233?ristiques professionnelles et psychologiques de l'utilisateur (m\u233?
moire, perceptions, habitudes, etc.) et l'organisation du dialogue entre
l'utilisateur et l'application. Une bonne compatibilit\u233? r\u233?duit consid\
u233?rablement le temps d'apprentissage d'une application. On doit exiger que le
logiciel s'adapte au m\u233?tier de chaque profil utilisateur. Le syst\u232?me doit
non seulement int\u233?grer les proc\u233?dures, qui rel\u232?vent plut\u244?t
d'exigences fonctionnelles, mais s'adapter \u224? la psychologie et la physiologie
de l'utilisateur. Un exemple typique est celui de l'utilisation de la souris,
exclue pour les utilisateurs qui saisissent des donn\u233?es en masse, mais n\u233?
cessaire pour les d\u233?cideurs sur une application intranet. La segmentation des
profils utilisateurs et l'analyse de leurs t\u226?ches sont donc n\u233?cessaires
avant toute sp\u233?cification. CD\par\pard\plain\hyphpar} {
Chapitre 11 - Les exigences non Fonctionnelles Guidage Le guidage est \u171?
l'ensemble des moyens mis en \u339?uvre pour conseiller, orienter, informer et
conduire l'utilisateur lors de ses interactions avec l'ordinateur \u187?. On
distingue le guidage explicite, qui se traduit par l'aide en ligne, les messages
d'erreur, d'avertissement ou d'information, et le guidage implicite, qui concerne
les formats de saisie des informations, la disposition des informations sur l'\
u233?cran, etc. Le guidage est li\u233? \u224? la navigabilit\u233?. L'utilisateur
doit savoir \u224? tout moment \u224? quel point du processus il se trouve, et
comment passer \u224? une autre t\u226?che. Le syst\u232?me doit canaliser le
travail de l'utilisateur en lui laissant un maximum de libert\u233? tout en l'emp\
u234?chant d'entreprendre des actions qui nuisent \u224? sa s\u233?curit\u233?, \
u224? sa productivit\u233? ou \u224? son efficacit\u233?. Homog\u233?n\u233?it\
u233? L'homog\u233?n\u233?it\u233? est la \u171? capacit\u233? d'un syst\u232?me \
u224? conserver une logique d'usage constante \u187?. Elle se r\u233?f\u232?re \
u224? la fa\u231?on avec laquelle des choix d'objets de l'interface sont conserv\
u233?s pour des contextes identiques, et des objets diff\u233?rents pour des
contextes diff\u233?rents. Elle facilite l'apprentissage et r\u233?duit l'effort de
m\u233?morisation. L'homog\u233?n\u233?it\u233? concerne la localisation d'un objet
sur l'\u233?cran, son format et sa pr\u233?sentation, ainsi que la syntaxe et le
vocabulaire employ\u233?s. Les \u233?crans de saisie et la logique des actions
doivent \u234?tre analogues dans toute l'application, et m\u234?me, si possible,
d'une application \u224? l'autre. Un bon moyen d'exiger l'homog\u233?n\u233?it\
u233? consiste \u224? imposer une charte d'ergonomie, pr\u233?existante ou adapt\
u233?e au logiciel. Cependant, des exigences particuli\u232?res \u224? certaines t\
u226?ches doivent \u234?tre \u233?labor\u233?es. Souplesse La souplesse est la \
u171? capacit\u233? de l'interface \u224? s'adapter aux diff\u233?rentes exigences
de la t\u226?che, aux diverses strat\u233?gies, aux habitudes et niveaux de
connaissances des diff\u233?rents utilisateurs \u187?. Contrairement \u224? la
compatibilit\u233?, qui revient \u224? adapter d'avance le logiciel aux diff\u233?
rents profils utilisateurs, la souplesse permet \u224? un logiciel de s'adapter \
u224? ses habitudes, ainsi qu'\u224? son exp\u233?rience ou son niveau d'expertise.
Exemple de souplesse : les modes expert et d\u233?butant. Les utilisateurs d\u233?
butants auront les commandes pr\u233?sent\u233?es sous forme de menu, les exp\u233?
riment\u233?s auront des raccourcis clavier \u224? leur disposition. Autre exemple,
la facilit\u233? pour l'utilisateur \u224? param\u233?trer le logiciel pour
l'adapter \u224? son m\u233?tier... tout en respectant l'exigence d'homog\u233?n\
u233?it\u233?, ce qui montre \u224? quel point l'ergonomie n'est pas chose ais\
u233?e. GE)\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Contr\u244?le explicite Le contr\u244?
le explicite est < l'ensemble des moyens du dialogue qui permettent \u224?
l'utilisateur de ma\u238?triser le lancement et le d\u233?roulement des op\u233?
rations ex\u233?cut\u233?es par le syst\u232?me informatique \u187?. C'est ce qui
permet \u224? l'utilisateur de ma\u238?triser le syst\u232?me. Ce contr\u244?le se
manifeste en particulier par le feedback que fournit le syst\u232?me. En pratique,
les r\u233?actions du syst\u232?me doivent \u234?tre pr\u233?visibles. Cette
exigence apporte \u224? l'utilisateur l'autonomie qu'il est en droit d'attendre du
syst\u232?me, ainsi qu'un confort li\u233? \u224? une sensation de contr\u244?le
sur l'application. Cette agr\u233?able sensation de \u171? piloter \u187? le
produit (plut\u244?t que d'\u234?tre malmen\u233? par lui) facilite l'appropriation
de l'outil par l'utilisateur et minimise les erreurs. Gestion des erreurs La
gestion des erreurs rassemble < tous les moyens permettant d'une part d'\u233?viter
ou de r\u233?duire les erreurs, et d'autre part de les corriger lorsqu'elles
surviennent \u187?. Elle pr\u233?vient le stress et augmente la sensation de s\
u233?curit\u233? (et la s\u233?curit\u233? effective). Comme exemples d'exigences,
citions : \u8226? la possibilit\u233? d'annuler une action (touche \u171? undo >) ;
\u8226? la demande de confirmation des actions dont les effets sont irr\u233?
versibles ; \u8226? les messages d'avertissement. Concision La concision est \u171?
l'ensemble des moyens qui. pour l'utilisateur, contribuent \u224? la r\u233?duction
de ses activit\u233?s de perception et de m\u233?morisation et concourent \u224?
l'augmentation de l'efficacit\u233? du dialogue \u187?. Elle a des effets positifs
sur la productivit\u233? et contribue \u224? diminuer la charge mentale et donc la
fatigue et le stress. Exemple d'exigence : \u8226? minimiser le nombre de menus et
de clics pour ex\u233?cuter une t\u226?che ; \u8226? limiter le nombre de
possibilit\u233?s offertes (tout en respectant les exigences de souplesse et de
contr\u244?le explicite). GB\par\pard\plain\hyphpar} {
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 \u339?uvre.
Elles occupent un chapitre \u224? part dans le cahier des charges. La difficult\
u233? consiste \u224? les d\u233?crire sans tomber dans le pi\u232?ge classique de
la description d'une solution en lieu et place d'un besoin. Contraintes de projet
La formulation de ces contraintes d\u233?pend beaucoup du type de solution
(progiciel, d\u233?veloppement sp\u233?cifique) et du rapport entre client et
fournisseur (d\u233?veloppement par des \u233?quipes internes, ou au contraire
appel d'offres public). Charges, co\u251?ts et d\u233?lais Ces exigences impos\
u233?es \u224? la ma\u238?trise d'\u339?uvre d\u233?coulent des contraintes de
budget et d'urgence au niveau de la ma\u238?trise d'ouvrage. Il faut savoir qu'une
diminution du d\u233?lai a toujours une r\u233?percussion importante sur les co\
u251?ts, voire m\u234?me sur la faisabilit\u233?. (< neuf femmes ne font pas un
enfant en un mois \u187? dit-on parfois), et souvent sur la qualit\u233?.
L'expression de contraintes de co\u251?t peut \u234?tre utile dans le cadre d'un d\
u233?veloppement en interne, elle l'est beaucoup moins lorsqu'on s'adresse \u224?
un fournisseur externe, et en principe interdite dans le cadre d'un appel d'offres
public. Installation, mise en exploitation, recette Les exigences doivent indiquer
(ou demander au fournisseur d'indiquer) si le produit est autoinstallable. si
l'installation est \u224? la charge du fournisseur\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences ou du client, la charge d'installation
pour le fournisseur et/ou le client, les d\u233?lais \u224? pr\u233?voir, et la
disponibilit\u233? des diff\u233?rents acteurs par profil. Le cahier des charges
peut d\u233?tailler les modalit\u233?s de recette ou demander \u224? la ma\u238?
trise d'ouvrage de les proposer. Migration Comme pour l'int\u233?gration, la
migration peut \u234?tre plus ou moins complexe et co\u251?teuse, jusqu'\u224? n\
u233?cessiter une v\u233?ritable \u233?tude. Pour que le fournisseur puisse r\u233?
pondre \u224? cette contrainte, il faut lui indiquer aussi pr\u233?cis\u233?ment
que possible, au minimum le format et le contenu des donn\u233?es \u233?chang\u233?
es, le support physique et/ou logique (par exemple, base de donn\u233?es, disque
dur), la structure (fichiers plats, tables de base de donn\u233?es
relationnelle...) et le volume de donn\u233?es \u224? reprendre. Le cahier des
charges doit indiquer clairement les engagements mutuels du fournisseur et du
client, qui sont tr\u232?s interd\u233?pendants. Par exemple, on peut exiger du
fournisseur qu'il reprenne les donn\u233?es pr\u233?sent\u233?es sous forme de
fichier \u224? plat, le client s'engageant \u224? fournir ce fichier apr\u232?s
avoir \u171? attaqu\u233? \u187? lui-m\u234?me la base de donn\u233?es de
l'ancienne application. Les charges, d\u233?lais, disponibilit\u233?s des acteurs
sont \u233?galement des exigences \u224? indiquer. Environnement de d\u233?
veloppement Imposer l'environnement de d\u233?veloppement, en termes d'outils,
langages, m\u233?thodes, etc., est parfois n\u233?cessaire, mais induit des
contraintes tr\u232?s fortes sur le ma\u238?tre d'\u339?uvre. Il faudra donc bien
peser le pour et le contre avant de formuler cette exigence, \u233?ventuellement
apr\u232?s discussion ou n\u233?gociation, ou laisser dans le cahier des charges
l'ouverture \u224? la n\u233?gociation. Contraintes d'environnement Environnement
mat\u233?riel et logiciel Ces exigences ou contraintes concernent la plate-forme
mat\u233?rielle, le syst\u232?me d'exploitation, les bases de donn\u233?es, les
navigateurs sur (ou sous) lesquels la solution devra fonctionner. La premi\u232?re
contrainte concerne le type de fourniture. Trois cas peuvent se pr\u233?senter : \
u8226? Seul le produit logiciel est livr\u233?. Le client dispose de la plate-
forme. Dans ce cas. c'est au client de d\u233?crire l'environnement, qui devient de
facto une contrainte. Le fournisseur devra pr\u233?ciser dans sa r\u233?ponse ses
propres contraintes en termes de mat\u233?riels et logiciels de base. (ED\par\pard\
plain\hyphpar} {
Chapitre 12 - Exigences projet et contraintes techniques \u8226? Le client demande
la fourniture du produit logiciel seul, mais n'a pas encore acquis l'infrastructure
n\u233?cessaire pour l'h\u233?berger. L'exigence consiste \u224? demander au
fournisseur de sp\u233?cifier ses propres exigences en termes d'infrastructure. Le
client peut \u233?galement exiger du fournisseur qu'il maintienne son produit pour
tenir compte de l'\u233?volution du mat\u233?riel ou du logiciel de base. \u8226?
Le client demande une solution compl\u232?te, mat\u233?riel et logiciel. Il exige
du fournisseur de d\u233?tailler la liste des mat\u233?riels et logiciels fournis,
et de lister ses propres contraintes d'environnement (salle, etc.). Toutes les
nuances et variations sont possibles. Les autres contraintes d'environnement mat\
u233?riel et logiciel d\u233?pendent \u233?troitement de cette premi\u232?re
contrainte. Interfaces Ce paragraphe d\u233?taille les protocoles, formats d'\u233?
change de donn\u233?es, appels de proc\u233?dures entre applications, messages \
u233?chang\u233?s. Si l'on descend dans des d\u233?tails techniques, ce qui est
souvent n\u233?cessaire, il faudra faire appel \u224? des experts. En fonction du
niveau de d\u233?tail, il sera utile d'expliciter les exigences sous forme de
diagrammes de s\u233?quence ou de diagrammes d'\u233?tat. Chaque fois que cela sera
possible, on s'appuiera sur des normes et standards d'interop\u233?rabilit\u233?
existants. La r\u233?f\u233?rence \u224? des standards est infiniment plus s\u251?
re et \u233?conomique en efforts de sp\u233?cification que la description d\u233?
taill\u233?e d'interfaces. Elle a des cons\u233?quences tr\u232?s positives sur le
co\u251?t et la qualit\u233? de la solution. Services d'accompagnement Les services
d'accompagnement doivent \u234?tre sp\u233?cifi\u233?s avec beaucoup de soin,
clart\u233? et pr\u233?cision, car c'est souvent sur ces services que le
fournisseur \u8364? fait sa marge \u187?. Une sp\u233?cification impr\u233?cise
peut donner lieu \u224? des litiges, voire des conflits entre client et
fournisseur, avec des risques financiers. Il y a deux mani\u232?res de formuler les
exigences de service : imposer des contraintes ou demander au fournisseur de pr\
u233?ciser sa r\u233?ponse (proposition technique et commerciale). Lorsque le
fournisseur est une soci\u233?t\u233? externe et que le client doit passer par un
appel d'offres public (\u201?tat, collectivit\u233?), c'est souvent la deuxi\u232?
me option qui est choisie, voire n\u233?cessaire. GD\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Exigences d'int\u233?gration L'int\
u233?gration du produit \u224? l'environnement du client est un point tr\u232?s d\
u233?licat. Pour que le fournisseur puisse r\u233?pondre aux exigences d'int\u233?
gration, il doit bien conna\u238?tre l'environnement du client, en particulier les
applications \u171? partenaires \u187? avec lesquelles le produit fourni devra
communiquer. Souvent, une v\u233?ritable \u233?tude d'int\u233?grabilit\u233? doit
avoir lieu. Elle peut \u234?tre faite par le client, le fournisseur, et le plus
souvent par une collaboration des deux parties. L'exercice est d'autant plus
difficile que. lorsque le client \u233?tablit son cahier des charges, il ne conna\
u238?t pas encore la solution propos\u233?e par le fournisseur. C'est la situation
dans laquelle se trouve, en particulier, l'Administration lorsqu'elle \u233?tablit
un appel d'offres public pour choisir un progiciel du march\u233?. Support
utilisateurs, support technique La qualit\u233? du support aux utilisateurs est
souvent une des cl\u233?s de la r\u233?ussite d'un projet. De plus, le support est
un gros consommateur de ressources. Il est donc indispensable de sp\u233?cifier pr\
u233?cis\u233?ment les conditions de support ou de demander au fournisseur de les
sp\u233?cifier. Les diff\u233?rents niveaux de support doivent \u234?tre d\u233?
crits, ainsi que le profil des intervenants \u224? chaque niveau de support, et les
ressources d\u233?di\u233?es. Par exemple, le support premier niveau pourra \u234?
tre fait par le client, et le deuxi\u232?me niveau par le fournisseur. Maintenance
Les exigences de maintenance ne doivent pas \u234?tre confondues avec les exigences
de maintenabilit\u233?. La maintenabilit\u233? est une propri\u233?t\u233? du
logiciel, alors que la maintenance est un service rendu au client. En dehors de cas
tr\u232?s rares, un logiciel install\u233? devra \u234?tre maintenu. Le client ne
pourra pas se passer de ce service, qui lui sera factur\u233?, parfois tr\u232?s
cher. De plus en plus fr\u233?quemment, la maintenance co\u251?te plus cher que
l'achat du produit (cette tendance s'acc\u233?l\u232?re avec l'arriv\u233?e de
produits open source). De plus, les op\u233?rations de maintenance peuvent elles-m\
u234?mes induire des contraintes pour le client et l'utilisateur, avec des arr\
u234?ts d'exploitation pour mont\u233?e de version ou pour correction de bogues. Un
client a donc int\u233?r\u234?t \u224? bien sp\u233?cifier les conditions et les
modalit\u233?s de la maintenance. Les exigences d\u233?pendent bien s\u251?r du
domaine d'application, du type d'application, de l'environnement informatique et m\
u233?tier. Voici quelques exemples d'exigences de maintenance : \u8226? fr\u233?
quence des installations de versions majeures ; \u8226? modalit\u233?s
d'installation (par le client, par le fournisseur, etc.) : ITO\par\pard\plain\
hyphpar} {
Chapitre 12 - Exigences projet et contraintes techniques \u8226? processus de
maintenance, tout particuli\u232?rement pour la maintenance corrective ; \u8226?
obligations respectives du client et du fournisseur concernant la maintenance de
l'infrastructure sous-jacente (serveurs, base de donn\u233?es, etc.) ; \u8226?
compatibilit\u233? ascendante entre versions (peut aussi \u234?tre consid\u233?r\
u233?e comme une exigence de maintenabilit\u233?). Documentation Rappelons que la
documentation fait partie int\u233?grante du produit. Les contraintes g\u233?n\
u233?rales s'appliquant au produit s'appliquent donc ipso facto \u224? sa
documentation. C'est en particulier le cas de la livraison d'une documentation
suite \u224? un changement de version du produit. Cela va sans dire, mais cela va
mieux en le disant, et encore mieux en le stipulant par \u233?crit. Les exigences
de documentation peuvent \u234?tre extr\u234?mement vari\u233?es. Elles peuvent
concerner le volume de la documentation, sa forme physique (papier, m\u233?dia,
documentation en ligne...), la fr\u233?quence de sa mise \u224? jour, son contenu,
la facilit\u233? de lecture et d'apprentissage ou son mode de distribution.
Formation des utilisateurs La formation des utilisateurs est tr\u232?s importante
pour la r\u233?ussite du projet. La plupart des fournisseurs ont, parall\u232?
lement \u224? leur offre produit, des offres de formation standard. Le prix de ces
formations peut \u234?tre tr\u232?s \u233?lev\u233?. Il est tout \u224? fait
possible, m\u234?me dans le cadre d'appels d'offres publics, de \u171? n\u233?
gocier > ces prix au moyen du cahier des charges. En particulier, on sait que
certains utilisateurs n'utilisent qu'un tr\u232?s petit nombre de fonctions. La
formation standard \u171? g\u233?n\u233?raliste \u187? peut \u234?tre \u171? tron\
u231?onn\u233?e \u187? en fonction du profil utilisateur. Rien n'emp\u234?che de
stipuler que telle cat\u233?gorie d'utilisateurs doit pouvoir \u234?tre form\u233?e
en deux heures (en lieu et place d'une formation g\u233?n\u233?rale de trois jours,
par exemple). En fonction de la mani\u232?re dont elle est formul\u233?e, cette
exigence peut aussi trouver sa place dans la rubrique \u171? facilit\u233?
d'utilisation \u187? (chapitre des exigences non fonctionnelles). Environnement
physique d'utilisation Il ne s'agit pas ici d'environnement informatique, mais bien
de l'environnement physique au sens large. Par exemple, une solution (mat\u233?riel
et logiciel) peut n\u233?cessiter d'\u234?tre utilis\u233?e en milieu tropical, st\
u233?rile (bloc op\u233?ratoire), humide, bruyant, etc. D\u233?crire cet
environnement est important, car il induit des contraintes sur le mat\u233?riel
informatique, mais aussi \u338?>\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences sur l'ergonomie du produit. En indiquant,
par exemple, que le logiciel sera utilis\u233? au service des urgences d'un h\u244?
pital, on donne une information tr\u232?s importante au fournisseur, en lui
laissant la libert\u233? (et la responsabilit\u233?) d'imaginer la solution qui
convient le mieux (affichage tr\u232?s sobre) ou de faire une \u233?tude
d'ergonomie. Le fait de d\u233?crire l'environnement d'utilisation et d'exiger du
fournisseur que son produit respecte cette contrainte d'environnement reporte
l'effort de recherche et d'\u233?tude (en particulier d'ergonomie) sur le
fournisseur. Dans le cas d'un logiciel critique, cela risque d'\u234?tre plus co\
u251?teux pour le fournisseur, mais aussi plus stimulant. On devra donc \u233?
tudier l'opportunit\u233? de formuler les exigences, soit sous forme de contraintes
physiques d'utilisation, soit sous forme de r\u232?gles d'ergonomie, ou m\u234?me
d'exigences fonctionnelles. L'exercice n'est pas facile. CD\par\pard\plain\hyphpar}
{
Chapitre 13 L'\u233?tape de sp\u233?cification Le processus de sp\u233?cification
Le sch\u233?ma ci-dessous pr\u233?sente une vision simplifi\u233?e du travail de
sp\u233?cification. -Analyse- * Formuler Structurer V\u233?rifier -VaUdatlon-
Figure 13-1 : Le processus de sp\u233?\u224?fkation Les trois t\u226?ches
consistant \u224? formuler, structurer et v\u233?rifier les exigences sont tr\u232?
s interd\u233?pendantes et le processus est naturellement it\u233?ratif. Formuler
Le comportement (exigences fonctionnelles) et les propri\u233?t\u233?s (exigences
non fonctionnelles) doivent \u234?tre formul\u233?s avec beaucoup de soin et de pr\
u233?cision, de mani\u232?re \u224? \u234?tre compris par tous ceux qui liront le
cahier des charges. Une bonne ma\u238?trise de la langue \u233?crite est n\u233?
cessaire, mais non suffisante. Une bonne formulation sera facilit\u233?e si les \
u233?tapes pr\u233?c\u233?dentes ont \u233?t\u233? respect\u233?es. La sp\u233?
cification graphique est un cas particulier de formulation. Un graphique peut
faciliter la compr\u233?hension, mais si l'on veut qu'il soit compr\u233?hensible
de tous les acteurs, il est encore plus difficile \u224? < \u233?crire \u187? qu'un
texte.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Structurer Structurer le cahier des
charges consiste \u224? ranger les exigences sous forme arborescente, afin de
rendre la lecture, la compr\u233?hension et la maintenance du document la plus ais\
u233?e possible. Le mod\u232?le de cahier des charges nous donne un premier niveau
de structuration, mais certains sous-chapitres devront \u234?tre subdivis\u233?s,
parfois tr\u232?s finement. C'est en particulier le cas des exigences
fonctionnelles. Pour un logiciel d'une grande richesse fonctionnelle, la
structuration est loin d'\u234?tre \u233?vidente. Dans un tel cas, on pr\u233?sente
en g\u233?n\u233?ral les exigences de deux niveaux diff\u233?rents dans deux
chapitres diff\u233?rents : \u8226? exigences utilisateur (par exemple, sous forme
de cas d'utilisation) ; \u8226? exigences produit (sous forme d'exigences \u233?l\
u233?mentaires). V\u233?rifier Il s'agit ici de v\u233?rifier, en particulier au
moyen de check-iists, que les exigences qui viennent d'\u234?tre r\u233?dig\u233?es
r\u233?pondent \u224? un certain nombre de crit\u232?res. Elles doivent, en
particulier, \u234?tre align\u233?es sur les objectifs et les exigences de plus
haut niveau, correspondre au besoin des utilisateurs, \u234?tre r\u233?alistes et
bien formul\u233?es. Les activit\u233?s de structuration, de formulation et de v\
u233?rification sont it\u233?ratives. L'activit\u233? de v\u233?rification fait
partie int\u233?grante de la sp\u233?cification et est distincte de l'\u233?tape
ult\u233?rieure de validation, qui s'int\u233?resse autant au contenu qu'\u224? la
structure ou \u224? la formulation. La Formulation Appliquer des r\u232?gles de
bonne formulation peut appara\u238?tre contraignant, mais est tr\u232?s
avantageux \u224? terme. Un cahier des charges bien formul\u233? est beaucoup plus
maintenable. N'oublions pas que sa maintenance commence tr\u232?s t\u244?t, toute
exigence \u233?tant susceptible d'\u234?tre modifi\u233?e \u224? tout moment (mais
pas n'importe comment). Nous donnons dans les paragraphes qui suivent un ensemble
de principes et de r\u232?gles de bonne formulation. La liste peut para\u238?tre
longue, mais avec l'exp\u233?rience, la formulation correcte devient une seconde
nature. La structure grammaticale Une exigence \u233?l\u233?mentaire correctement
formul\u233?e r\u233?pond aux crit\u232?res suivants : \u8226? Elle est
grammaticalement correcte. CE)\par\pard\plain\hyphpar} {
Chapitre 13 - L'\u233?tape de sp\u233?cification \u8226? Elle est r\u233?dig\u233?e
\u224? la forme active : sujet, verbe, compl\u233?ment. \u8226? Le sujet est n\
u233?cessairement un utilisateur, un syst\u232?me ou un attribut du syst\u232?me. \
u8226? Un m\u234?me terme a la m\u234?me signification pour tout lecteur potentiel.
\u8226? Les termes ambigus ont \u233?t\u233? d\u233?finis dans un glossaire. Il est
n\u233?cessaire d'utiliser des phrases du type \u171? le logiciel doit... \u187?.
Par exemple : \u171? Le logiciel doit afficher le co\u251?t des m\u233?dicaments
prescrits > plut\u244?t que : \u171? Affichage du co\u251?t \u187?. Pour exprimer
une exigence, il est pr\u233?f\u233?rable d'utiliser une phrase courte et claire.
On \u233?vitera les phrases comportant des propositions relatives, ou des
conjonctions de coordination. L'id\u233?al (pas toujours r\u233?alisable) 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 \
u224? appliquer \u224? chaque exigence. Une exigence bien formul\u233?e doit \u234?
tre : \u8226? \u201?l\u233?mentaire (en anglais, atomic). Elle ne doit comporter
qu'un \u233?l\u233?ment ins\u233?cable. Pour v\u233?rifier si une exigence est \
u233?l\u233?mentaire, essayez de la couper en deux ( en g\u233?n\u233?ral au niveau
des conjonctions de coordination). \u8226? N\u233?cessaire. L'exigence doit servir
au moins \u224? un profil utilisateur ou une partie prenante. Un moyen de v\u233?
rifier cette r\u232?gle est de se poser la question : que se passera-t-il si cette
exigence est supprim\u233?e ? \u8226? Mesurable, ou du moins v\u233?riflable. Dans
le cas contraire, le ma\u238?tre d'ceuvre peut faire ce qu'il veut, c'est un v\
u339?u pieux. Les adjectifs et adverbes non mesurables (tels que rapide,
performant, fiable, nombreux) rendent l'exigence non mesurable. Il en est de m\
u234?me pour les phrases \u224? la voix passive, l'emploi du < etc. \u187? et des
points de suspension. \u8226? Concis. Plus la formulation est courte, plus
l'exigence sera robuste. M\u233?thode : \u233?liminer syst\u233?matiquement tous
les mots qui ne servent \u224? rien. \u8226? Tra\u231?able, vis-\u224?-vis
d'exigences de plus haut niveau ou de plus bas niveau. Au-del\u224? d'un certain
volume de sp\u233?cifications, l'utilisation d'outils sp\u233?cifiques est n\u233?
cessaire pour que ce crit\u232?re soit respect\u233?. \u8226? R\u233?alisable et
modifiable. Dans le cas contraire, c'est un v\u339?u pieux. C'est ici que la comp\
u233?tence technique de l'analyste peut \u234?tre utile. Il peut avertir son client
de la difficult\u233? ou de l'impossibilit\u233? de mettre en \u339?uvre une
exigence, et aider \u224? la n\u233?gociation. \u8226? Autosuffisante. Dans la
mesure du possible, elle doit \u234?tre lue et comprise ind\u233?pendamment des
autres. Dans une exigence, un pronom per- 09\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences sonnel comme \u171? il \u187? ou \u171?
elle \u187? se rapporte g\u233?n\u233?ralement \u224? une exigence pr\u233?c\u233?
dente. Il faut remplacer le pronom personnel par le sujet, quitte \u224? se r\u233?
p\u233?ter (un cahier des charges n'est pas une \u339?uvre litt\u233?raire). \
u8226? Ind\u233?pendante de la solution. Rappelons qu'une exigence doit d\u233?aire
un besoin ou une contrainte, et non une solution. De plus, certaines r\u232?gles r\
u233?gissent les relations entre exigences. Un ensemble d'exigences doit \u234?
tre : - Complet L'ensemble doit d\u233?crire tous les cas possibles. Par exemple,
si on d\u233?crit le comportement du syst\u232?me en cas d'acceptation, on doit
aussi d\u233?crire son comportement en cas de refus. - Coh\u233?rent Une exigence
ne doit pas entrer en conflit avec les autres. Une forme plus subtile d'incoh\u233?
rence advient lorsqu'un ensemble d'exigences entre en contradiction avec un autre
ensemble. - Non redondant Deux exigences ne doivent pas se recouvrir ou se r\u233?
p\u233?ter, m\u234?me partiellement. U\u171?rigfedtt5C\u187? la i^^ simple qui
permet de v\u233?rifier rapidement qu'une exigence est bien fbnnul\u233?e.Ce^
s'applique(\u233?ipl\u232?meiitw Toute exigence doit \u234?tre: \u171? Cone4te:elte
respecte les ^ pratiqijes de b profession. '""\u9632?*' \u8226? \u199?
^fififijKiiift; r elle d^ti\u238?t rd\u226?ia\u251?i; d\u233?\u231?\u226?ft: r^k\
u163?|^ et fM!\u226?c^ si. n\u233?\u231?\u233?as\u226?ii\u232? les corrigions de
faction. \u8226? Oafmidlenecofnp^ tirjJe ; tout lecteur la oDmpreiKi^ \u171?
Cdrtdserelteesttbfmu^ \u8226? Coh\u233?rente l\u233?fen'ettae pas m^ La langue de
bois : quand et comment l'\u233?liminer ? Qui n'a jamais us\u233? de la langue de
bois ? Quant aux sous-entendus, il est impossible de s'en passer dans la vie
courante, ne serait-ce que pour la bri\u232?vet\u233? du discours. Le flou est g\
u233?n\u233?ralement largement compens\u233? par la communication non verbale. Par
ailleurs, le langage flou a sa place lors de l'\u233?tape de recueil. Nous laissons
du flou dans nos questions pour permettre \u224? l'interlocuteur de s'exprimer.
C'est d'ailleurs une technique d'interview souvent utilis\u233?e, consciemment ou
non. Lors de la sp\u233?cification, la langue de bois, et de mani\u232?re g\u233?n\
u233?rale le langage flou, est \u224? proscrire. L'analyste l'\u233?liminera sans
piti\u233?, soit en faisant ITO\par\pard\plain\hyphpar} {
Chapitre 13 - L'\u233?tape de sp\u233?cification la correction lui-m\u234?me (\
u224? valider plus tard), soit en demandant des pr\u233?cisions compl\u233?
mentaires. Le flou peut arriver : Pendant le recueil des besoins (interview) :
c'est normal, la pr\u233?cision doit venir progressivement. Reformuler en douceur.
Pendant l'analyse : c'est le moment de chercher \u224? l'\u233?liminer. Un bon sch\
u233?ma peut mettre au jour une incoh\u233?rence du discours. Lors des sp\u233?
cifications (r\u233?daction du cahier des charges) : la t\u226?che sera plus
difficile ; il faudra chercher \u224? pr\u233?ciser l'exigence, la corriger, et v\
u233?rifier la coh\u233?rence d'ensemble. Lors de la validation (revue de sp\u233?
cifications) : c'est un indicateur de non-qualit\u233? lors des \u233?tapes pr\
u233?c\u233?dentes. Pr\u233?voir une charge de travail suppl\u233?mentaire, et
chercher \u224? s'am\u233?liorer. Am\u233?liorer la formulation : exemples Voici
quelques exigences mal formul\u233?es, suivies d'une explication et de la
reformulation am\u233?lior\u233?e. Elles proviennent d'un cahier des charges, en
cours d'\u233?laboration, pour un progiciel de gestion du circuit du m\u233?
dicament dans un \u233?tablissement de sant\u233?. Exemple 1 : \u224? la fois trop
et pas assez Voici comment une exigence \u233?tait initialement formul\u233?e dans
un cahier des charges pour l'informatisation du circuit du m\u233?dicament d'un h\
u244?pital : Les stocks seront g\u233?r\u233?s au niveau du code produit, du
produit et du num\u233?ro de lot. dans tous les lieux de stockage : la pharmacie et
l'armoire \u224? pharmacie des unit\u233?s de soins. Un analyste exp\u233?riment\
u233? d\u233?tecte tout de suite qu'il ne s'agit pas d'une exigence. N'importe quel
lecteur muni de la check-list de formulation correcte s'en apercevra \u233?galement
en essayant de faire passer la phrase de la voix passive \u224? la voix active : on
ne sait pas qui est l'acteur et que fait le syst\u232?me. D'autre part, le texte
apporte une surabondance d'informations concernant les lieux de stockage. Ils
doivent \u234?tre d\u233?crits, soit en intention : quel que soit le lieu de
stockage, soit en extension : \u224? la pharmacie et dans les unit\u233?s de soins.
L'exigence \u233?l\u233?mentaire devient alors : Le syst\u232?me doit permettre au
pharmacien de suivre les stocks d'un m\u233?dicament donn\u233?, par son code
produit et par son num\u233?ro de lot. Le syst\u232?me doit permettre le suivi de
m\u233?dicaments en pharmacie. Le syst\u232?me doit permettre le suivi des m\u233?
dicaments en unit\u233?s de soins. CD\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences On obtient donc, non pas une, mais trois
exigences \u233?l\u233?mentaires. Cela peut sembler lourd, mais c'est beaucoup plus
clair. Exemple 2 : am\u233?liorer la clart\u233? d'une exigence Voici une exigence
extraite d'un cahier des charges pour un logiciel hospitalier : Le progiciel doit
comporter un pr\u233?param\u233?trage de ces donn\u233?es (au niveau de l'h\u244?
pital ou d'une sp\u233?cialit\u233?), pr\u233?param\u233?trage modifiable par le
prescripteur. On comprend de quoi il s'agit, mais l'exigence peut \u234?tre
grandement am\u233?lior\u233?e. L'expression \u171? comporter un param\u233?
trage... \u187? ne pr\u233?cise pas l'acteur. L'expression \u171? au niveau de... \
u187? est ambigu\u235? : on ne sait pas qui. de l'h\u244?pital ou de la sp\u233?
cialit\u233?, est l'acteur de ce param\u233?trage, ou le b\u233?n\u233?ficiaire, ou
les deux. < Ces donn\u233?es \u187? fait allusion \u224? une exigence pr\u233?c\
u233?dente, sp\u233?cifiant les informations qu'un prescripteur peut saisir.
L'exigence am\u233?lior\u233?e devient : Le progiciel doit permettre \u224?
l'administrateur du progiciel de param\u233?trer, pour l'ensemble de l'h\u244?
pital, les informations qu'un prescripteur peut saisir, et le caract\u232?re
obligatoire de cette saisie. Le progiciel doit permettre \u224? l'administrateur du
progiciel de param\u233?trer, pour chaque sp\u233?cialit\u233?, les informations
qu'un prescripteur peut saisir, et le caract\u232?re obligatoire de cette saisie.
Le progiciel doit permettre \u224? un prescripteur de param\u233?trer, pour toutes
les prescriptions \u224? venir, les informations qu'il pourra saisir. Cette
formulation en trois exigences \u233?l\u233?mentaires est \u233?videmment plus
lourde, mais elle ne laisse plus aucune ambigu\u239?t\u233? quant aux actions
autoris\u233?es pour chaque acteur. Exemple 3 : beaucoup de mots pour rien L'\u233?
nonc\u233? de l'exigence est le suivant : Le progiciel doit pouvoir supporter les
diff\u233?rentes organisations existantes dans l'\u233?tablissement au niveau des
unit\u233?s de soin. Le verbe \u171? supporter \u187?. en l'occurrence un
anglicisme, est ici ambigu. Gr\u226?ce au contexte, le lecteur pourra comprendre
qu'il faut l'interpr\u233?ter dans le sens de \u171? r\u233?pondre aux besoins de \
u187?. L'expression < les diff\u233?rentes organisations... au niveau des unit\
u233?s de soins \u187? signifie ici les diff\u233?rents types d'organisation que
l'on peut rencontrer dans un \u233?tablissement. L'exigence devient donc : \u338?D\
Chapitre 13 - L'\u233?tape de sp\u233?cification Le progiciel doit r\u233?pondre
aux besoins des diff\u233?rents modes d'organisation d'une unit\u233? de soin. La
formulation est un peu plus claire, cependant. \u171? r\u233?pondre aux besoins \
u187? est impr\u233?cis : on ne sait pas \u224? quel besoin le progiciel doit r\
u233?pondre. Si le besoin est diff\u233?rent d'un mode d'organisation \u224?
l'autre, il faudra r\u233?diger une exigence pour chacun d'eux. Sinon, l'exigence
devient : Le progiciel doit \u234?tre utilisable dans toute unit\u233? de soins de
l'\u233?tablissement, quel que soit son mode d'organisation. On s'aper\u231?oit
maintenant que l'impr\u233?cision vient du mode d'organisation. Il faudrait donc
lister et expliciter les diff\u233?rents modes d'organisation de l'\u233?
tablissement, soit en intention (r\u233?f\u233?rence \u224? une description de tous
les modes d'organisation) soit en extension (faire la liste des modes
d'organisation). Or. ce qui est plus simple et plus efficace, c'est de d\u233?crire
les diff\u233?rents modes organisationnels dans un chapitre pr\u233?liminaire, d\
u233?crivant le contexte. L'exigence devient alors : Le progiciel doit \u234?tre
utilisable dans toute unit\u233? de soins. Mais c'est l\u224? une tautologie. Cette
exigence peut donc \u234?tre purement et simplement supprim\u233?e... \u224? moins
d'en d\u233?duire une exigence non fonctionnelle d'utilisabilit\u233? : le
progiciel doit \u234?tre adaptable (ou d\u233?j\u224? adapt\u233? ?) aux diff\u233?
rents modes d'organisation de l'\u233?tablissement. La structuration
Structuration : adopter et adapter les mod\u232?les Il existe plusieurs mod\u232?
les de cahiers des charges1, comme X50-I5I, ~~~~. ~~~~~ l%t .. , ^ ,N1 ^ ., ., 1.
Voir au chapitre IEEE 830, ou le mod\u232?le Volere. Ces mod\u232?les sont extr\
u234?mement utiles : ils ^mm les diff\u233?rents servent de check-lists et \u233?
vitent d'oublier certains points indispensables, mod\u232?les de cahiers Ils ont
une structure coh\u233?rente, descendante (lop-down) et compl\u232?te desdiarges.
(toutes les cat\u233?gories d'exigences et autres rubriques sont repr\u233?sent\
u233?es). Ils constituent donc un bon d\u233?part pour la sp\u233?cification des
exigences, et m\u234?me plus que la sp\u233?cification : ils servent de check-lists
pour le recueil. Une organisation pourrait choisir un de ces mod\u232?les et
l'adapter \u224? sa situation particuli\u232?re. Par exemple, une entreprise
soumise au code des march\u233?s publics peut y ajouter un chapitre sur les aspects
juridiques. Si ce nouveau mod\u232?le ne correspond pas \u224? toutes les
situations d'une organisation, il pourra \u234?tre raffin\u233? au niveau d'une
direction ou d'un service, et ainsi de suite. ira\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Rappelons que le mod\u232?le de d\u233?
veloppement et de gestion des exigences, tel que d\u233?crit dans cet ouvrage, peut
(et souvent doit) \u234?tre adapt\u233? au cas particulier de chaque entreprise. Il
n'y a pas de mod\u232?le parfait. R\u233?utiliser autant que possible Une exigence
bien formul\u233?e co\u251?te cher \u224? obtenir. Elle doit passer par le cycle
complet de recueil, analyse, sp\u233?cification et validation. \u192? long terme,
il est donc beaucoup plus efficace de r\u233?diger des exigences r\u233?utilisables
d'un projet \u224? l'autre que de les r\u233?inventer et de les reformuler. C'est
en particulier le cas des exigences non fonctionnelles, telle la s\u233?curit\
u233?. Rendre les exigences r\u233?utilisables ou. mieux encore, \u233?laborer du
premier coup des exigences r\u233?utilisables, exige un bon niveau d'organisation.
Il faut retrouver des exigences existantes, les adapter, et \u233?ventuellement les
r\u233?injecter dans un \u171? pot commun \u187? et. ce qui est plus difficile,
conserver la coh\u233?rence d'ensemble. Au-del\u224? d'une certaine complexit\
u233?, les outils de gestion des exigences deviennent quasiment indispensables. En
pratique, cela n\u233?cessite : \u8226? d'avoir une base d'exigences, bien tenue,
c'est-\u224?-dire contenant des exigences correctes (coh\u233?rentes, non ambigu\
u235?s, etc.) ; \u8226? d'avoir le moyen de les retrouver rapidement en fonction
d'un certain nombre de crit\u232?res ; \u8226? une fois l'exigence r\u233?utilis\
u233?e, c'est-\u224?-dire utilis\u233?e dans plus d'une sp\u233?cification, d'avoir
les moyens de suivre son \u233?volution et de r\u233?percuter les modifications sur
plusieurs occurrences ; \u8226? de pouvoir g\u233?rer la tra\u231?abilit\u233? sur
chaque occurrence. Choisir la forme de description Les exigences peuvent \u234?tre
d\u233?crites sous plusieurs formes : cas d'utilisation, mod\u232?les graphiques
(traitements, donn\u233?es, flux, processus...) et exigences \u233?l\u233?
mentaires. Le choix de la forme (textuelle ou graphique), du niveau de d\u233?tail
(la < granularit\u233? \u187? d'une exigence) en fonction des acteurs et du domaine
d'application est un art plut\u244?t qu'une science. Il n'y a pas de dogme en ce
qui concerne les modes de repr\u233?sentation. Par exemple, pour certains auteurs
(comme Alistair Cockburn). les cas d'utilisation se suffisent \u224? eux-m\u234?mes
dans 90 % des cas. Pour d'autres, ils ne sont qu'un moyen de d\u233?couvrir les
exigences fonctionnelles et n'ont pas \u224? appara\u238?tre dans un cahier des
charges. Pour d'autres enfin, cas d'utilisation et exigences fonctionnelles peuvent
coexister au sein d'un m\u234?me document. (HD\par\pard\plain\hyphpar} {
Chapitre 13 - L'\u233?tape de sp\u233?cification En tout \u233?tat de cause, le
type incontournable d'exigence est l'exigence \u233?l\u233?mentaire. Sp\u233?cifier
les exigences \u233?l\u233?mentaires Les exigences \u233?l\u233?mentaires
constituent le c\u339?ur de la plupart des cahiers des charges. Par exigence \u233?
l\u233?mentaire (en anglais, atomk requirement) on entend toute exigence formul\
u233?e en langue naturelle sous forme de phrase qui se suffit \u224? elle-m\u234?
me. Il peut s'agir l\u224? d'une exigence fonctionnelle ou non fonctionnelle, ou
d'une contrainte produit ou projet. Par exemple : \u8226? Le syst\u232?me pr\u233?
sentera la liste des couleurs disponibles. \u8226? Le temps maximum
d'indisponibilit\u233? du syst\u232?me sera de 20 minutes par jour. \u8226? Le
syst\u232?me sera accessible au moyen d'un navigateur HTML 4.0. Une exigence \u233?
l\u233?mentaire peut d\u233?couler directement d'un objectif, d'une r\u232?gle de
gestion, d'un cas d'utilisation, ou de toute exigence de plus haut niveau. Les
exigences \u233?l\u233?mentaires sont regroup\u233?es sous forme arborescente. Cas
des exigences non Fonctionnelles Les exigences non fonctionnelles sont particuli\
u232?rement difficiles \u224? formuler. En fait, chaque caract\u233?ristique non
fonctionnelle (fiabilit\u233?, maintenabilit\u233?. .. ) pr\u233?sente des
difficult\u233?s de description particuli\u232?res. En toute rigueur, il est n\
u233?cessaire de sp\u233?cifier (par exemple, ici, pour la fiabilit\u233?) : \
u8226? la d\u233?finition de la mesure (par exemple, la d\u233?finition du temps
d'indisponibilit\u233? ou du temps de r\u233?ponse) ; \u8226? l'unit\u233? de
mesure (par exemple, minutes) ; \u8226? la valeur minimale ou maximale (par exemple
: 20 minutes d'interruption maximum) ; \u8226? la m\u233?thode de mesure (par
exemple, chronom\u232?tre) ; \u8226? la valeur optimale; \u8226? la valeur nominale
et la tol\u233?rance : \u8226? les valeurs admises par exception (par exemple, le
dimanche, une interruption de 30 minutes est autoris\u233?e). Certains auteurs pr\
u233?conisent des mod\u232?les de structuration des exigences. Tom Gilb2 propose un
langage sp\u233?cial de sp\u233?cification des exigences 2. Tom Cilb, Compe\u187?
non fonctionnelles, appel\u233? planguage \'5c'7bplanning language) qui permet de
les 0\u219?^ Engineering, d\u233?crire avec pr\u233?cision. Elle peut cependant \
u234?tre vue comme trop com- Butterworth-Heine- plexe et trop formelle pour la
plupart des projets. Rien n'emp\u234?che de la "lann, 2005. simplifier, ou
d'utiliser une description moins formelle.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Dans de nombreux cas. on peut se
contenter d'une description beaucoup moins formelle, comme : L'application doit
pouvoir fonctionner 24 heures sur 24 et 7 jours sur 7 avec un taux
d'indisponibilit\u233? maximal de : - 15 minutes par jour dans la p\u233?riode
comprise entre 7 heures et 23 heures ; - 30 minutes par jour dans la p\u233?riode
comprise entre 23 heures et 7 heures : - 3 heures par an pour maintenance. Rien
n'emp\u234?che, d'ailleurs, de s'inspirer de la norme ISO 25000 (plus pr\u233?cis\
u233?ment, les normes ISO/CEI 25020 \u224? 25024, qui reprend les \u233?l\u233?
ments de la norme ISO/CEI 9126-4). Cette norme donne une d\u233?finition tr\u232?s
pr\u233?cise d'un grand nombre d'indicateurs de qualit\u233? et de leurs m\u233?
triques. Voici un exemple : \u8226? Nom : temps moyen d'indisponibilit\u233?. \
u8226? But : temps moyen pendant lequel le syst\u232?me demeure indisponible entre
une d\u233?faillance et la remise en ordre de marche graduelle. \u8226? Formule de
mesure : X = T/N. o\u249? T est le temps total d'indisponibilit\u233? et N le
nombre de d\u233?faillances observ\u233?es. \u8226? Interpr\u233?tation de la
valeur mesur\u233?e : 0 < X ; la plus petite valeur mesur\u233?e est la
meilleure. \u8226? Type d'\u233?chelle : ratio (rapport de valeurs). \u8226? Type
de mesure.- T = temps. N = nombre, X = temps/nombre. \u8226? Origine de la mesure :
rapport de test, rapport d'intervention. \u8226? R\u233?f\u233?rence \u224? une
description de processus (ISO/1EC 12207) : 5.3 int\u233?gration, 5.3 tests de
qualification, 5.4 op\u233?ration. 6.5 validation. La norme d\u233?crit ainsi des
centaines de m\u233?triques sur presque cent pages, pour chacune des vingt-sept
sous-caract\u233?ristiques ISO 25000. Elle pourra servir de check-list pour v\u233?
rifier que toutes les exigences non fonctionnelles ont \u233?t\u233? int\u233?gr\
u233?es. Elle apportera \u233?galement des id\u233?es sur la mani\u232?re de
formuler une exigence et d'en fixer les crit\u232?res de satisfaction. Check-list
de sp\u233?cification dune exigence La check-list qui suit concerne chaque exigence
individuellement. \u8226? L'exigence est align\u233?e sur un objectif \u233?nonc\
u233?, une exigence de plus haut niveau, ou un besoin d'un type d'utilisateur. \
u8226? L'exigence d\u233?crit un besoin ou une contrainte, et non un \u233?l\u233?
ment de solution. cm\par\pard\plain\hyphpar} {
Chapitre 13 - L'\u233?tape de sp\u233?cification \u8226? L'exigence doit satisfaire
au moins un besoin d'au moins un type d'utilisateur. \u8226? L'exigence est sp\
u233?cifi\u233?e au niveau ad\u233?quat, ni trop d\u233?taill\u233?, ni trop g\
u233?n\u233?ral, pour \u234?tre comprise par toutes les parties prenantes. \u8226?
L'exigence \u233?mane d'une source reconnue et l\u233?gitime, partie prenante ou
texte de r\u233?f\u233?rence. \u8226? L'exigence est sp\u233?cifi\u233?e avec le
formalisme (textuel, graphique) ad\u233?quat pour \u234?tre comprise par tous les
lecteurs. \u8226? Si l'exigence est sp\u233?cifi\u233?e textuellement, elle l'est
sous forme active : sujet (acteur) verbe (action) compl\u233?ment (pr\u233?
cisions). \u8226? Les termes ambigus sont d\u233?finis dans le glossaire. \u8226?
L'exigence est tra\u231?able. Il est possible, \u224? partir d'une exigence donn\
u233?e, de remonter \u224? une exigence de plus haut niveau ou de plus bas
niveau. \u8226? L'exigence est compl\u232?te. Elle repr\u233?sente une fonction \
u233?l\u233?mentaire. \u8226? L'exigence \u233?l\u233?mentaire est \u171?
atomique \u187? : elle repr\u233?sente une seule fonction \u233?l\u233?mentaire
ins\u233?cable. \u8226? L'exigence est grammaticalement correcte. \u8226?
L'exigence est formul\u233?e selon le mod\u232?le en vigueur. \u8226? L'exigence
n'entre pas en conflit avec une exigence de plus haut niveau. \u8226? L'exigence
est utile. Elle a \u233?t\u233? valid\u233?e par au moins un repr\u233?sentant des
utilisateurs. \u8226? L'exigence est r\u233?alisable. Elle a \u233?t\u233? valid\
u233?e par un expert technique, concepteur ou d\u233?veloppeur. \u8226? L'exigence
est non ambigu\u235?. Elle a une seule interpr\u233?tation possible, quel que soit
le lecteur. \u8226? L'exigence est concise. Elle est \u233?crite de la mani\u232?re
la plus simple possible, avec le moins de mots possibles. \u8226? L'exigence est v\
u233?riflable. Une fois le produit d\u233?velopp\u233?, il sera possible de v\u233?
rifier objectivement et sans \u233?quivoque qu'elle est satisfaite. Check-list d'\
u233?tape de sp\u233?cification Cette check-list est relative aux diff\u233?rentes
activit\u233?s de sp\u233?cification.- elle liste les conditions \u224? remplir
avant de passer \u224? la prochaine \u233?tape (validation). Pour la formulation
des exigences elles-m\u234?mes, voir la check-list pr\u233?c\u233?dente, ainsi que
la check-list relative au cahier des charges. \u8226? Le mod\u232?le de cahier des
charges a \u233?t\u233? accept\u233? par tous les acteurs. \u8226? Le mod\u232?le
de cahier des charges a \u233?t\u233? adapt\u233? \u224? l'organisation. cs>\par\
ie 2 - D\u233?veloppement des exigences \u8226? Le mod\u232?le de cahier des
charges a \u233?t\u233? adapt\u233? au projet. Les mod\u232?les graphiques utilis\
u233?s sont compr\u233?hensibles par tous. \u8226? Chaque rubrique du mod\u232?le
de cahier des charges a \u233?t\u233? remplie, ou laiss\u233?e vide avec
justification. \u8226? La formulation de chaque exigence a \u233?t\u233? v\u233?
rifi\u233?e \u224? l'aide de la check-list ad\u233?quate. \u8226? Telles que
formul\u233?es, les exigences seront utiles \u224? la r\u233?alisation. <E>\par\
Chapitre 14 Structure du cahier des charges Choisir, adapter et utiliser un mod\
u232?le de cahier des charges est une des cl\u233?s de l'efficacit\u233? de son \
u233?laboration et de la qualit\u233? du livrable. En effet, un mod\u232?le est \
u224? la fois un guide pour agir, une check-list pour valider et un support pour
communiquer sur les exigences. On trouve dans la litt\u233?rature et sur le Web des
mod\u232?les de cahier des charges pr\u234?ts \u224? utiliser, que l'on peut \u233?
ventuellement adapter. Visite comment\u233?e. Le mod\u232?le de cahier des charges
Les \u233?l\u233?ments du contenu Un bon mod\u232?le de cahier des charges contient
toutes les rubriques qui seront n\u233?cessaires \u224? la description et \u224? la
compr\u233?hension des exigences, et rien de plus. On peut adapter le mod\u232?le
aux contraintes particuli\u232?res du domaine d'application et des technologies
mises en \u339?uvre. Cette op\u233?ration n'est pas triviale. Malgr\u233? leur
apparente simplicit\u233?, les mod\u232?les de cahiers des charges pr\u233?sent\
u233?s dans ce chapitre r\u233?sultent d'une longue r\u233?flexion, d'un travail
collaboratif entre experts, et d'une exp\u233?rimentation sur le terrain, parfois
sur des centaines de projets. L'arborescence des paragraphes La plupart des mod\
u232?les de cahiers des charges (normes ou standards) comportent cinq \u224? dix
parties, d\u233?coup\u233?es en dix \u224? trente paragraphes.\par\pard\plain\
hyphpar} {
Partie 2 - D\u233?veloppement des exigences 1. IEEE Std 830- 1998. IEEE Re\u339?
mmended Practice for Software Requirements Sp\u233?cifications, Software
Engineering Standards Committee, of die IEEE Computer Society. L'ordre d'apparition
des paragraphes est important. Il doit correspondre id\u233?alement \u224? l'ordre
de lecture, et aussi, dans la mesure du possible, \u224? la s\u233?quence des \
u233?tapes du processus d'\u233?laboration du cahier des charges. Les diff\u233?
rents mod\u232?les existants Nous pr\u233?sentons dans les paragraphes qui suivent
diff\u233?rents mod\u232?les de cahiers des charges, et leurs domaines
d'application possibles. Pour chacun d'eux, nous exposons sa structure, son
contenu, ses avantages et inconv\u233?nients. La plupart sont t\u233?l\u233?
chargeables, souvent gratuitement ou moyennant une somme modeste. Il est important
d'investir du temps \u224? bien choisir, bien comprendre et si n\u233?cessaire
adapter un mod\u232?le. Cet investissement correspond \u224? une fraction minime de
l'effort qui sera par la suite consacr\u233? \u224? l'\u233?laboration du cahier
des charges. Le mod\u232?le IEEE 830 Orientation La norme de sp\u233?cification des
exigences IEEE 830 ( 1998)' donne un mod\u232?le g\u233?n\u233?raliste, plut\u244?t
orient\u233? vers le d\u233?veloppement sp\u233?cifique et assez technique. Le mod\
u232?le ne fournit pas une structure fig\u233?e de cahier des charges, mais propose
un ensemble de recommandations (emploi du verbe should) sur la mani\u232?re de
structurer le cahier des charges, et les diff\u233?rentes parties dont il doit se
composer. Il fournit un squelette de cahier des charges. Enfin, une annexe
informative donne huit mani\u232?res de structurer les exigences, en particulier
fonctionnelles. Structure du mod\u232?le Le tableau 14-1 donne les \u233?l\u233?
ments du document avec leur traduction en fran\u231?ais. (H3\par\pard\plain\
hyphpar} {
Chapitre 14 - Structure du cahier des charges Tabfeau 14-1 - Mod\u232?le IEEE 830
1. Introduction 1.1 Purpose 1.2 Scope 1.3 D\u233?finitions, acronyms, and
abbreviations 1.4 R\u233?f\u233?rences 1.5 Overview 2. Overall description 2.1
Product perspective 2.2 Product fonctions 2.3 User characteristics 2.4 Constraints
2.5 Assumptions and dependencies 3. Sp\u233?cifie requirements Appendixes Index 1.
Introduction 1.1 Objectif 1.2 P\u233?rim\u232?tre (port\u233?e) 1.3 D\u233?
finitions, acronymes, et abr\u233?viations 1.4 R\u233?f\u233?rences 1.5 Vue
d'ensemble 2. Description g\u233?n\u233?rale 2.1 Perspective du produit 2.2
Fonctions du produit 2.3 Caract\u233?ristiques utilisateurs 2.4 Contraintes 2.5
Suppositions et d\u233?pendances 3. Exigences sp\u233?cifiques Annexes Index
Contenu du document Le mod\u232?le IEEE est un grand classique et contient tous les
\u233?l\u233?ments que l'on s'attend \u224? trouver dans un cahier des charges, du
moins sur le plan technique. La norme pr\u233?cise que les exigences concernant la
solution peuvent exceptionnellement y figurer, sous forme restrictive
(contraintes). La norme pr\u233?cise que les exigences fonctionnelles (paragraphe
2.2) peuvent contenir des diagrammes, ainsi que le paragraphe de perspective (2.1 )
dans le cas o\u249? le produit serait connect\u233? \u224? d'autres (ce qui. de nos
jours, est presque toujours le cas). Un diagramme de contexte y trouverait sa
place. Le paragraphe 3 (exigences sp\u233?cifiques) constitue le corps du document.
La partie fonctionnelle doit contenir toutes les entr\u233?es et sorties du syst\
u232?me (stimulus et r\u233?ponses), et la description des fonctions en r\u233?
ponse \u224? une entr\u233?e ou sortie. Les exigences non fonctionnelles
(attributs) sont organis\u233?es en fiabilit\u233?, disponibilit\u233?, s\u233?
curit\u233?, maintenabilit\u233?, et portabilit\u233?. La norme donne de nombreuses
explications sur les diff\u233?rentes mani\u232?res de structurer les exigences
fonctionnelles : par mode, par classes ou o\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences entit\u233?s, par caract\u233?ristiques
utilisateur, par stimulus et r\u233?ponse, par hi\u233?rarchie fonctionnelle, ou
par une combinatoire de ces types de structuration. Avantages et inconv\u233?nients
de la norme Le mod\u232?le a une forte orientation < arborescence fonctionnelle \
u187?, les autres \u233?l\u233?ments (mod\u232?le de donn\u233?es, exigences non
fonctionnelles) \u233?tant trait\u233?s rapidement, voire pass\u233?s sous silence.
L'ensemble est donc assez technique, avec une coloration \u171? g\u233?nie logiciel
\u187?. Il fait d'ailleurs explicitement r\u233?f\u233?rence \u224? la norme IEEE
12207 (cycle de vie du logiciel) avec laquelle il est compatible. Le point fort de
la norme est plut\u244?t dans son annexe informative sur les diff\u233?rentes mani\
u232?res de structurer la d\u233?composition des fonctions, qui donne des pistes de
r\u233?flexion. Dans le cas d'un syst\u232?me de grande taille fonctionnelle
(nombre important de fonctions \u233?l\u233?mentaires) le probl\u232?me est loin
d'\u234?tre trivial, et les autres normes, plus r\u233?centes, le passent sous
silence. Le mod\u232?le AFNOR X50-151 Orientation de la norme La norme AFNOR X50-
I5I donne un mod\u232?le de cahier des charges tr\u232?s g\u233?n\u233?raliste, qui
n'est pas sp\u233?cifique \u224? l'informatique et aux syst\u232?mes d'information.
Il fait partie d'une s\u233?rie normative sur l'analyse de la valeur et l'analyse
fonctionnelle. Il donne donc une place importante \u224? l'ouverture sur le
dialogue entre client et fournisseur. Structure du mod\u232?le Le tableau 14-2
donne le plan d'un cahier des charges selon la norme AFNOR X50-15I. (HD\par\pard\
plain\hyphpar} {
Chapitre 14 - Structure du cahier des charges Tabfeau 14-2 - Mod\u232?to AFNOR X50-
151 1. Pr\u233?sentation du probl\u232?me 1.1 Le produit et son march\u233? 1.2.
Contexte du projet, les objectifs 2. \u201?nonc\u233? fonctionnel du besoin 2.1.
Cyde d'utilisation du produit et identification de son environnement 2.2 \u201?
nonc\u233? des fonctions de service et des contraintes Fonctions de service
attendues Contraintes Classement ou notation des fonctions 2.3. Caract\u233?
risation des fonctions de service et des contraintes Crit\u232?res d'appr\u233?
ciation Niveaux des crit\u232?res d'appr\u233?ciation Flexibilit\u233? des
niveaux : classe de flexibilit\u233?, limites d'acceptation Taux d'\u233?change 3.
Appel \u224? variantes 4. Cadre de r\u233?ponse Contenu du document de sp\u233?
cifications Les notions de niveau, de flexibilit\u233? et de taux d'\u233?change
sont des concepts d'analyse de la valeur. Le principe est que pour permettre au
fournisseur d'optimiser sa solution (apporter le maximum de satisfaction au co\
u251?t le plus faible), il est n\u233?cessaire d'indiquer la priorit\u233? entre
exigences, car les exigences formul\u233?es par le client dans le cahier des
charges n'ont pas toutes la m\u234?me importance ou la m\u234?me urgence. \u8226?
La classe de flexibilit\u233? (niveau de flexibilit\u233? de chaque exigence :
nulle, faible, bonne, forte), indique dans quelle limite une contrainte est n\u233?
gociable. \u8226? La limite d'acceptation d\u233?finit, pour chacune des caract\
u233?ristiques fondamentales du produit, une valeur minimale de la mesure du crit\
u232?re d'appr\u233?ciation. En de\u231?\u224? de cette valeur, le besoin sera d\
u233?clar\u233? insatisfait. \u8226? Le taux d'\u233?change indique les
compensations fix\u233?es a priori au cas o\u249? certains crit\u232?res
d'acceptation, jug\u233?s essentiels par le demandeur, ne seraient pas satisfaits
(par exemple, les p\u233?nalit\u233?s de retard, dans le cas o\u249? le fournisseur
ne respecterait pas ses d\u233?lais de livraison). fna\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Enfin, l'appel \u224? des variantes
permet de stimuler la cr\u233?ativit\u233? du fournisseur. Le client peut
solliciter des propositions d'am\u233?lioration qui. dans le cas d'un logiciel,
seront fonctionnelles (cr\u233?ation, modification ou suppression de fonctions) ou
non fonctionnelles (performances, ergonomie). Les variantes peuvent \u234?tre soit
des suppl\u233?ments, soit des alternatives au sc\u233?nario pr\u233?conis\u233?.
Enfin, la norme pr\u233?voit explicitement un cadre de r\u233?ponse, utile dans le
cadre des march\u233?s publics. Avantages et inconv\u233?nients Avec les notions de
niveau, de flexibilit\u233?, de limite d'acceptation et de taux d'\u233?change, la
norme X50-I51 nous donne des pistes de r\u233?flexion int\u233?ressantes. Ces
concepts sont assez difficiles \u224? utiliser en pratique dans le contexte des
syst\u232?mes d'information, mais on peut s'en inspirer pour construire un mod\
u232?le adapt\u233?. Le mod\u232?le n'est pas adapt\u233? aux sp\u233?cificit\u233?
s du logiciel et des syst\u232?mes d'information. La structure est incompl\u232?te
et le vocabulaire utilis\u233? n'est pas celui du g\u233?nie logiciel. Si on d\
u233?cide de l'utiliser, il faudra n\u233?cessairement le compl\u233?ter avec des \
u233?l\u233?ments d'autres mod\u232?les de cahiers des charges. 2. Le mod\u232?le
peut \u234?tre t\u233?l\u233?dtarg\u233? sur le site de Karl Wiegers http//www.pro-
\u339?ssimpactcon/ goodies.shtml. Le mod\u232?le de Wiegers Orientation Le mod\
u232?le pr\u233?conis\u233? par Karl Wiegers est g\u233?n\u233?raliste, simple et
pragmatique, orient\u233? vers le d\u233?coupage fonctionnel. Il n'est pas tr\u232?
s d\u233?taill\u233?. Il pourra \u234?tre utilis\u233? pour sp\u233?cifier des
exigences pour un d\u233?veloppement sp\u233?cifique, mais \u233?galement pour un
progiciel. Structure du mod\u232?le Remarquons un certain nombre de particularit\
u233?s concernant ce mod\u232?le2 de document : \u8226? Les interfaces avec le mat\
u233?riel, le logiciel et l'utilisateur sont regroup\u233?es dans un m\u234?me
chapitre. La sp\u233?cification est centr\u233?e sur le produit, qui interagit avec
des acteurs externes. \u8226? Les mod\u232?les d'analyse (diagrammes de flux, de
classes, etc.) sont mis en annexe. Les diagrammes ne sont pas un but mais un moyen
d'arriver aux sp\u233?cifications sous forme textuelle. (E)\par\pard\plain\hyphpar}
{
Chapitre 14 - TaMaaa 14*3 - La modela propos\u233? par Karl TaMaaa 143 - La modela
propos\u233? par Karl Wiagars 1. Introduction 1.1 Purpose 1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions 1.4 Project Scope 1.5 R\u233?f\u233?
rences 2. Overall Description 2.1 Product Perspective 2.2 Product Features 2.3 User
Gasses and Characteristics 2.4 Operating Environment 2.5 Design and Implementation
Constraints 2.6 User Documentation 2.7 Assumptions and Dependencies 3. System
Features 3.1 System Feature 1 3.2 System Feature 2 (and so on) 4. External
Interface Requirements 4.1 User Interfaces 4.2 Hardware Interfaces 4.3 Software
Interfaces 4.4 Communications Interfaces 5. Other Nonfunctional Requirements 5.1
Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4
Software Quality Attributes 6. Other Requirements Appendix A : Glossary Appendix
B : Anarysis models Appendix C : Issues lists Structure du cahier des charges 1.
Introduction 1.1 Objectif 1.2 Conventions documentaires 1.3 \u192? qui s'adresse ce
document ; guide de lecture 1.4 P\u233?rim\u232?tre du projet 1.5 R\u233?f\u233?
rences 2. Description g\u233?n\u233?rale 2.1 Perspective du produit 2.2 Caract\
u233?ristiques du produit 2.3 Profit utilisateurs et caract\u233?ristiques 2.4
Environnement d'op\u233?ration 2.5 Contraintes de conception et de r\u233?alisation
2.6 Documentation utilisateur 2.7 Hypoth\u232?ses et d\u233?pendances 3. Caract\
u233?ristiques du syst\u232?me 3.1 Caract\u233?ristique 1 3.2 Caract\u233?ristique
2 (etc) 4. Exigences d'interface externe 4.1 Interfaces utilisateur 4.2 Interfaces
avec le mat\u233?riel 4.3 Interfaces avec le logiciel 4.4 Interfaces de
communication 5. Autres exigences non fonctionnelles 5.1 Exigences de performance
5.2 Exigences de s\u233?curit\u233? (innocuit\u233?) 5.3 Exigences de s\u233?curit\
u233? 5.4 Attributs de qualit\u233? du logiciel 6. Autres exigences Annexe A :
Glossaire Annexe B : Mod\u232?les d'analyse Annexe C : Liste de probl\u232?mes fm\
Partie 2 - D\u233?veloppement des exigences Contenu du document de sp\u233?
cifications Dans ses ouvrages. Wiegers insiste sur la n\u233?cessit\u233? de d\
u233?crire pr\u233?cis\u233?ment la vision et la port\u233?e du projet (vision and
scope) dans un document particulier, lors de la phase de pr\u233?paration. S'il ne
d\u233?taille pas ce point dans son mod\u232?le de document, c'est par ce qu'il pr\
u233?conise de se r\u233?f\u233?rer au document en question, ou de le recopier.
Chaque rubrique (chapitres et paragraphes) est comment\u233?e en quelques lignes.
Ces diff\u233?rents points sont repris avec plus de d\u233?tails dans l'ouvrage
Software Requiremenls. une lecture utile \u224? tout analyste des exigences.
Avantages et inconv\u233?nients De par sa simplicit\u233?, ce mod\u232?le pourra \
u234?tre utilis\u233? par tout analyste ou consultant charg\u233? d'\u233?laborer
un cahier des charges, m\u234?me d\u233?butant. Ce dernier pourra enrichir le mod\
u232?le pour traiter des cas plus complexes. Sans n\u233?gliger l'essentiel, le
mod\u232?le est un peu pauvre en ce qui concerne les exigences non fonctionnelles.
On pourra enrichir le paragraphe sur les attributs de qualit\u233?, par exemple en
reprenant des \u233?l\u233?ments de la norme ISO 25000 d\u233?j\u224? d\u233?crite.
Le mod\u232?le Volere (Robertson & Robertson) Orientation Utilis\u233? sur de tr\
u232?s nombreux projets informatiques (plus de deux mille, d'apr\u232?s leurs
auteurs), le mod\u232?le Volere3 est fortement orient\u233? vers le d\u233?
veloppement de logiciels sp\u233?cifiques. C'est n\u233?anmoins un mod\u232?le
suffisamment complet pour \u234?tre utilis\u233? sur quasiment tout type de projet
(choix de progiciel et mise en \u339?uvre, d\u233?veloppement sp\u233?cifique) quel
que soit le domaine d'application. Structure du mod\u232?le Le mod\u232?le est
structur\u233? de mani\u232?re \u171? descendante \u187?, les paragraphes
correspondent \u224? l'ordre de lecture et, dans une tr\u232?s large mesure, \u224?
l'ordre d'\u233?laboration du cahier des charges, depuis la d\u233?finition des
objectifs jusqu'aux d\u233?tails les plus fins. Le tableau 14-4 donne la structure
du mod\u232?le et sa traduction en fran\u231?ais. 3. Le mod\u232?le volere est t\
u233?l\u233?chargeable sur www.volere.co.uk. ira\par\pard\plain\hyphpar} {
Chapitre 14 Tabfeau 14-4 - U raod\u224?U Votera PROJECT DRIVERS 1. The Purpose of
the Project 2. Qient, Customer and other Stakeholders 3. Users of the Product
PROJEaCONSTRAINTS 4. Mandated Constraints 5. Naming Conventions and D\u233?
finitions 6. Relevant Facts and Assumptions RJNaiONAL REQUIREMENTS 7. The Scope of
the Work 8. The Scope of the Product 9. Functional and Data Requirements NON-
FUNCTIONAL REQUIREMENTS 10. Look and Feel Requirements 11. Usability and Humanity
Requirements 12. Performance Requirements 13. Operational Requirements 14.
Maintainability & Support Requirements 15. Security Requirements 16. Cultural and
Political Requirements 17. L\u233?gal Requirements PROJECT ISSUES 18. Open Issues
19. \u219?ff-the-Shelf Solutions 20. New Problems 21.Tasks 22. Cutover 23. Risks
24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for
Solutions Structure du cahier des charges MOTIVATIONS DU PROJET 1. Objet du projet
2. Clients et autres parties prenantes 3. Les utilisateurs du produit CONTRAINTES
DU PROJET 4. Contraintes obligatoires 5. Conventions de noms et d\u233?finitions 6.
Faits et hypoth\u232?ses d\u233?terminants EXIGENCES FONCTIONNELLES 7. P\u233?rim\
u232?tre de l'\u339?uvre 8. P\u233?rim\u232?tre de l'ouvrage 9. Exigences sur les
fonctions et donn\u233?es EXIGENCES NON FONCTIONNELLES 10. Exigences d'interface
utilisateur 11. Exigences d'utiiisabilit\u233? 12. Exigences de performance 13.
Exigences op\u233?rationnelles 14. Exigences de maintenabilit\u233? et support 15.
Exigences de s\u233?curit\u233? 16. Exigences culturelles et politiques 17.
Exigences l\u233?gales QUESTIONS SUR LE PROJET 18. Questions ouvertes 19. Solutions
sur \u233?tag\u232?re 20. Probl\u232?mes nouveaux 21. T\u226?ches 22. Finalisation
23. Risques 24. Co\u251?ts 25. Documentation utilisateur et formation 26. Questions
mises en attente 27. Id\u233?es de solutions ITIEI\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Le mod\u232?le Volere est r\u233?guli\
u232?rement revu et am\u233?lior\u233? par ses auteurs, avec la contribution des
analystes qui l'utilisent sur les projets. La derni\u232?re version est t\u233?l\
u233?chargeable sur le site de Volere. Le t\u233?l\u233?chargement du document en
version anglaise est payant, et son utilisation sur un ou plusieurs projets est
soumise au paiement d'une redevance. On trouve sur le site plusieurs traductions,
dont une traduction partielle en fran\u231?ais (t\u233?l\u233?chargement gratuit).
Contenu du document de sp\u233?cifications Le mod\u232?le de cahier des charges de
Volere contient tous les \u233?l\u233?ments indispensables \u224? la sp\u233?
cification des exigences pour un logiciel, qu'il s'agisse d'une application sp\
u233?cifique ou du choix d'un progiciel. Dans le mod\u232?le fourni sur le site,
chaque \u233?l\u233?ment de la structure est abondamment comment\u233? et justifi\
u233?. Notons que les contraintes, au sens large du terme, pr\u233?c\u232?dent les
exigences fonctionnelles. C'est une mani\u232?re de baliser le terrain et de
rappeler que les exigences fonctionnelles sont limit\u233?es par des contraintes
inamovibles. Autre particularit\u233? : les exigences non fonctionnelles, ailleurs
trait\u233?es comme le parent pauvre, occupent huit grands paragraphes. Avantages
et inconv\u233?nients Test\u233? sur plus de deux mille projets, r\u233?guli\u232?
rement mis \u224? jour, le mod\u232?le est d'une solidit\u233? \u224? toute \u233?
preuve... ou presque. Son principal d\u233?faut (qui n'en est pas un. bien s\u251?
r) est d'\u234?tre trop riche pour la plupart des projets. Pour l'adapter, il
suffit la plupart du temps de tailler cette arborescence un peu trop touffue. De
par sa complexit\u233? et sa compl\u233?tude, les diff\u233?rentes rubriques sont
parfois difficiles \u224? interpr\u233?ter. L'utilit\u233? de certains paragraphes
ne saute pas imm\u233?diatement aux yeux. Plut\u244?t que de les supprimer, nous
recommandons de les laisser \u171? sans objet \u187?. du moins en phase d'exp\u233?
rimentation, car ils pourraient se r\u233?v\u233?ler tr\u232?s utiles par la suite.
Les aspects juridiques sont volontairement exclus par ses auteurs, et devront \
u234?tre rajout\u233?s pour faire du document un CCTP (cahier des clauses
techniques particuli\u232?res) utilisable dans le cadre des march\u233?s publics.
Construire son propre mod\u232?le \u192? moins de travailler dans un laboratoire de
recherche, inutile de \u171? r\u233?inventer la poudre \u187?. Construire son
propre mod\u232?le de cahier des charges consiste \u224? adapter un mod\u232?le,
essentiellement par \u233?limination de paragraphes inutiles, \u233?ventuellement
par un apport venu d'un autre mod\u232?le. ira\par\pard\plain\hyphpar} {
Chapitre 14 - Structure du cahier des charges La m\u233?thode est donc la
suivante : 1. Examiner les diff\u233?rents mod\u232?les parmi les plus \u171?
classiques \u187?. 2. Pour chaque mod\u232?le, cocher les rubriques qui seront
utiles dans le cadre du (ou des) projets \u224? traiter. 3. Choisir le mod\u232?le
le plus proche. 4. \u201?liminer les paragraphes inutiles. 5. Si cela s'av\u232?re
n\u233?cessaire, introduire avec prudence de nouveaux paragraphes, de pr\u233?f\
u233?rence \u224? partir de paragraphes repris sur d'autres mod\u232?les. 6. V\
u233?rifier et assurer la coh\u233?rence de l'ensemble. 7. Exp\u233?rimenter le
mod\u232?le, et \u233?ventuellement le modifier si n\u233?cessaire, en faisant
valider les modifications. Rappelons-le. un mod\u232?le de document est un
investissement \u224? long terme, particuli\u232?rement lorsqu'il s'agit d'un
document comme un cahier des charges, et plus particuli\u232?rement si l'on a
l'intention d'\u233?laborer plusieurs cahiers des charges dans des domaines
proches. Il ne faut donc pas h\u233?siter \u224? investir quelques heures \u224?
quelques jours sur cette adaptation. Check-list : cahier des charges
Contrairement \u224? la check-list du chapitre pr\u233?c\u233?dent, qui concernait
une exigence individuelle, cette check-list s'applique au document de sp\u233?
cification des exigences (cahier des charges) dans sa totalit\u233?. \u8226? Compl\
u233?tude. Le document est complet. L'ensemble des exigences qui le composent
couvre la totalit\u233? du probl\u232?me. \u8226? Coh\u233?rence. Il n'y a pas de
conflit entre deux exigences, ni de redondance. \u8226? Tra\u231?abilit\u233?.
Toute exigence peut \u234?tre trac\u233?e vis-\u224?-vis d'une exigence de plus
haut niveau ou d'un objectif. \u8226? Maintenabilit\u233?. Le document est
maintenable. Un historique des modifications, ou tout m\u233?canisme \u233?
quivalent, permet de r\u233?\u233?crire une exigence sans perte de coh\u233?
rence. \u8226? Priorisation. Entre deux exigences de m\u234?me niveau, il est
possible d'indiquer laquelle des deux est prioritaire. \u8226? Monos\u233?mie. Tout
terme utilis\u233? a la m\u234?me signification pour tous les lecteurs dans tout le
document. \u8226? Fonctions de persistance (CRUD). Toute entit\u233? du syst\u232?
me peut \u234?tre cr\u233?\u233?e (C - cr\u233?ait), consult\u233?e (R = read),
mise \u224? jour (U = update) et supprim\u233?e (D = delete) (ou l'absence de cette
fonction justifi\u233?e). ira\par\pard\plain\hyphpar} {
Chapitre 15 L'\u233?tape de validation La validation des exigences permet de
s'assurer que le document d'exigences est complet, correct et coh\u233?rent, que
les exigences correspondent \u224? des objectifs du ma\u238?tre d'ouvrage ou \u224?
des besoins des utilisateurs, et que ces exigences sont correctement formul\u233?
es. Concr\u232?tement, la validation consiste en des revues de document, des
inspections et des check-lists. Le principe est simple et la m\u233?thode efficace.
Le reste est une question de discipline. Int\u233?r\u234?t de la validation La
validation des exigences n'est pas qu'une formalit\u233? bureaucratique.
Lorsqu'elle est men\u233?e avec s\u233?rieux par des gens de terrain, elle
multiplie consid\u233?rablement l'efficience du processus d'exigences. Cest un
investissement extr\u234?mement rentable. Les raisons sont faciles \u224?
comprendre : \u8226? Les exigences sont syst\u233?matiquement relues par d'autres
que ceux qui les ont \u233?crites, d'o\u249? une meilleure d\u233?tection des
incoh\u233?rences. \u8226? La ma\u238?trise d'ouvrage (ou le marketing) ne perd pas
de temps \u224? interpr\u233?ter des exigences floues et se concentre sur le
contenu. \u8226? Le processus d'\u233?laboration est mieux g\u233?r\u233?, car il
fournit des indicateurs d'avancement (un pourcentage d'exigences valid\u233?es est
plus parlant que le nombre total d'exigences produit). \u8226? Le niveau de qualit\
u233? des exigences devient pr\u233?visible, ce qui permet de planifier plus pr\
u233?cis\u233?ment le d\u233?veloppement et les tests. \u8226? Apr\u232?s
validation, les exigences refl\u232?tent, dans une large mesure, les vrais besoins
(on n'aura pas \u224? recommencer le d\u233?veloppement).\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Il est rare que la validation soit la <
tasse de th\u233? \u187? d'un groupe de travail ou d'un analyste. Cette activit\
u233? en rebute plus d'un, car la plupart des personnes pr\u233?f\u232?rent aller
de l'avant et voient donc les sessions de validation comme du temps perdu. Pour \
u233?viter de tomber dans ce pi\u232?ge, 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 v\
u233?rifications par check-lists et de revues et inspections. -Sp\u244?dflcatkMv*H
^S\u207?\u207?S\u239? i--*. l Prototypage Revues Check-Hsts J Livraison CdC H --\
u9658?" I r__J. \u201?laboration de ' cas de test Figure 15-1 : Le processus de
validation Une validation formelle doit avoir lieu pour valider la totalit\u233?
des sp\u233?cifications (cahier des charges). Cependant, des validations partielles
peuvent avoir lieu \u224? divers moments, par exemple pour un ensemble de
fonctions. On peut pr\u233?voir des minivalidations suite \u224? une session d'un
groupe de travail, soit par les membres du groupe lui-m\u234?me, soit en organisant
des validations crois\u233?es. Des formes simples et rapides de validation (check-
lists) peuvent avoir lieu quasiment \u224? tout moment. Les diff\u233?rentes formes
de reformulation d'une exigence lors d'une interview sont en quelque sorte des
microvalidations. Les techniques Les techniques de validation des exigences
sont : \u8226? la revue de document, plus ou moins formelle, qui est la technique
de validation \u224? proprement parler ; (ED\par\pard\plain\hyphpar} {
Chapitre 13 - L'\u233?tape de validation \u8226? le maquettage et le prototypage.
d\u233?j\u224? mentionn\u233?s, qui sont \u233?galement des techniques de recueil
et d'analyse ; \u8226? l'\u233?laboration de cas de test \u224? partir des
exigences, qui constitue leur \u171? \u233?preuve du feu \u187?. Ces trois familles
de techniques peuvent, bien entendu, \u234?tre combin\u233?es. Dans ce chapitre,
nous d\u233?crirons dans les d\u233?tails les diff\u233?rentes formes de revue,
depuis la liste de contr\u244?le jusqu'\u224? la revue formelle. V\u233?rification
par check-lists Check-lists de propri\u233?t\u233?s Le moyen le plus simple de
valider les exigences consiste \u224? les confronter \u224? une liste de contr\
u244?le (check-list). C'est aussi la premi\u232?re \u233?tape de la validation, qui
permet de d\u233?grossir la v\u233?rification. Les check-lists peuvent \u234?tre
utilis\u233?es par l'auteur du document \u224? valider (premi\u232?re v\u233?
rification) et doivent \u234?tre utilis\u233?es par tous les autres. On trouve dans
la litt\u233?rature des dizaines de variantes de check-lists, mais le principe est
toujours le m\u234?me. Il s'agit de v\u233?rifier les exigences individuellement
(atomicit\u233?, non-ambigu\u239?t\u233?, concision...) et le cahier des charges en
tant qu'ensemble d'exigences (compl\u233?tude, coh\u233?rence...). Le lecteur
pourra utiliser les diff\u233?rentes check-lists d\u233?j\u224? pr\u233?sent\u233?
es dans cet ouvrage. Check-lists de contenu Ces check-lists permettent de v\u233?
rifier que le document de sp\u233?cifications (cahier des charges) contient toutes
les rubriques n\u233?cessaires. 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 sp\u233?cifi\u233? la fiabilit\u233? ?
Etc. Nous conseillons de se servir du mod\u232?le de cahier des charges lui-m\u234?
me comme check-list. Si on a bien choisi et bien adapt\u233? le mod\u232?le de
cahier des charges, on n'a besoin de rien d'autre. Il suffit de v\u233?rifier que
tous les paragraphes ont \u233?t\u233? correctement remplis et qu'il ne reste pas
de paragraphe vide. De plus, la plupart des mod\u232?les de cahier des charges
contiennent non seulement l'ensemble des rubriques utiles, mais \u233?galement des
instructions sur comment les remplir. Cette autodocumentation dispense de toute
check-list suppl\u233?mentaire. ITO\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Relecture simple C'est, comme son nom
l'indique, la forme la plus simple de contr\u244?le d'un document. Elle fait
intervenir deux personnes : l'auteur et le lecteur. Les \u233?tapes sont les
suivantes : 1. L'auteur fournit le document au lecteur. 2. Le lecteur parcourt le
document, y cherche les erreurs ou non-conformit\u233?s, et note ses remarques (le
plus souvent, sur le document lui-m\u234?me). 3. Le lecteur retourne le document
annot\u233? \u224? l'auteur. 4. L'auteur prend en compte les remarques. Ce type de
relecture rel\u232?ve plus de la v\u233?rification que de la validation. Il est
utile pour passer rapidement en revue un ensemble de sp\u233?cifications assez
court ( une dizaine de pages de cahier des charges est un maximum). L'action doit \
u234?tre br\u232?ve, le cycle complet ne devrait pas d\u233?passer 48 heures. La
revue simple est efficace si l'auteur et le lecteur sont du m\u234?me niveau hi\
u233?rarchique. Il ne s'agit ni de se faire approuver par son sup\u233?rieur, ni de
sous-traiter une t\u226?che de relecture \u224? son subordonn\u233?. La lecture
elle- m\u234?me devrait \u234?tre rapide (cinq minutes par page, pour fixer les id\
u233?es). Les annotations peuvent parfaitement se faire sur papier. De telles
revues se font souvent spontan\u233?ment, bas\u233?es sur le donnant- donnant (je
relis ton document en esp\u233?rant que tu reliras le mien). La difficult\u233?
n'est pas de les faire, mais de les institutionnaliser et de les bud- g\u233?ter.
Autrement, elles d\u233?pendent d'une initiative individuelle et risquent de se
faire rares lorsque les projets ou les coll\u232?gues sont sous pression. Relecture
crois\u233?e La relecture crois\u233?e est un peu plus formelle que la lecture
simple et fait intervenir un plus grand nombre d'acteurs : un r\u233?dacteur et
plusieurs relecteurs. La proc\u233?dure est la suivante : 1. Lors d'une r\u233?
union, l'auteur fait une pr\u233?sentation g\u233?n\u233?rale du document \u224?
plusieurs lecteurs et leur fournit le document. 2. Chaque lecteur lit le document
isol\u233?ment, y cherche les erreurs ou non-conformit\u233?s, et note ses
remarques. 3. Les participants se r\u233?unissent. Le document est parcouru pas \
u224? pas. Chaque participant indique les points qui lui semblent critiques. Un des
participants note la liste des modifications \u224? apporter. 4. L'auteur prend en
compte les remarques et apporte les corrections. \u338?)\par\pard\plain\hyphpar} {
Chapitre 13 - L'\u233?tape de validation Cette proc\u233?dure est plus longue, plus
co\u251?teuse et plus efficace. Le cycle complet ne devrait pas d\u233?passer deux
semaines. L'\u233?quipe de relecture (auteur et relecteurs) doit \u234?tre compos\
u233?e de trois \u224? six personnes. Revue Formelle et inspection Une revue
formelle est pluscomplexe, plus co\u251?teuse et plus longuequ'une simple relecture
du document. Cela demande une certaine discipline et un investissement important en
temps, mais le retour sur investissement est beaucoup plus cons\u233?quent. Une
revue doit n\u233?cessairement avoir lieu \u224? toute nouvelle version du cahier
des charges, avant sa publication ou sa diffusion. On pourra aussi organiser des
revues interm\u233?diaires, sur un extrait du document, \u224? la fin de
certaines \u233?tapes. On indique ici la proc\u233?dure formelle, sachant que
celle-ci peut \u234?tre simplifi\u233?e en fonction des m\u233?thodes de travail,
du budget-temps imparti et de la criticit\u233? du syst\u232?me. Planification \'5c
Pr\u233?sentation Modfflcattons Lecture Retour R\u233?union de revue 1 OK T Suivi
Figure 15-2 : Le processus de revue La revue des sp\u233?cifications d'exigences
est analogue \u224? toute revue de document. Les \u233?tapes d'une inspection
sont : la planification, la r\u233?union de pr\u233?sentation, la pr\u233?paration,
la r\u233?union de revue, les modifications et le suivi. Les participants \u224?
une revue sont : \u8226? l'animateur (ou mod\u233?rateur) de la revue, dans l'id\
u233?al diff\u233?rent de l'auteur du document ; \u8226? l'auteur du document ; \
u8226? les relecteurs ; \u8226? le secr\u233?taire, de pr\u233?f\u233?rence diff\
u233?rent de l'animateur. GD\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences L'objectif d'une revue est d'obtenir un
consensus sur le document, et non \u224? corriger des erreurs ou des non-conformit\
u233?s sur lesquelles tout le monde s'accorde. Si on veut \u233?viter que les
participants gaspillent leur temps et leur \u233?nergie sur des d\u233?tails, il
faut pr\u233?alablement < toiletter \u187? le document, selon la check-list : \
u8226? Le document est conforme au mod\u232?le. \u8226? Les fautes d'orthographe
les plus grossi\u232?res ont \u233?t\u233? corrig\u233?es. \u8226? La formulation
est conforme aux r\u232?gles de bonne pr\u233?sentation (voir check-list). \u8226?
On a pr\u233?par\u233? une liste des points \u224? discuter en s\u233?ance. \u8226?
Le document a \u233?t\u233? relu par une autre personne que l'auteur, qui n'y a pas
trouv\u233? de d\u233?fauts majeurs. La revue comprend les \u233?tapes
suivantes : \u8226? Planification. Choix des participants, du temps \u224?
consacrer par chaque participant, des dates de r\u233?union, du nombre de r\u233?
unions. La revue est une d\u233?marche it\u233?rative que l'on pourrait affiner \
u224? l'infini, il est pr\u233?f\u233?rable de fixer des limites par avance. \
u8226? R\u233?union de pr\u233?sentation. L'auteur du document explique aux
participants le contenu du document et ce qu'il attend de la revue. Cette \u233?
tape peut \u234?tre supprim\u233?e si les participants ont l'habitude de travailler
ensemble. \u8226? Lecture. C'est l'\u233?tape la plus importante ; chaque
participant passe en revue le document, \u224? la recherche de d\u233?fauts ; il
peut s'aider d'une check- list et/ou s'appuyer sur son exp\u233?rience. Il remplit
une fiche de revue de document ou coche une check-list. \u8226? Retour. Les
participants renvoient leur fiche \u224? l'auteur, qui prendra en compte les
remarques. \u8226? R\u233?union de revue. Les participants se r\u233?unissent pour
discuter des points obscurs ou de d\u233?saccord. Chaque paragraphe est lu, et tout
participant peut faire ses remarques. Les participants d\u233?cident si une
nouvelle r\u233?union doit \u234?tre programm\u233?e. \u8226? Modifications.
L'auteur du document prend en compte les remarques et fait les modifications
convenues. \u8226? Suivi. Un participant v\u233?rifie que toutes les remarques et
points obscurs ont \u233?t\u233? pris en compte. On peut boucler sur ces \u233?
tapes jusqu'\u224? obtenir un niveau de qualit\u233? satisfaisant. Pour d\u233?
cider s'il faut planifier une nouvelle tourn\u233?e de revue ou s'arr\u234?ter, on
pourra utiliser la check-list suivante : \u8226? Toutes les remarques ont \u233?t\
u233? prises en compte : - soit le document a \u233?t\u233? modifi\u233? ; - soit
la remarque a \u233?t\u233? rejet\u233?e avec une justification. GB\par\pard\plain\
hyphpar} {
Chapitre 13 - L'\u233?tape de validation \u8226? Le document modifi\u233? est
correct sur la forme. \u8226? Tous les points obscurs ont \u233?t\u233? lev\u233?s.
\u8226? Le document est g\u233?r\u233? (nom et version, stockage, etc.). Longue et
co\u251?teuse, mais utile et rentable, l'inspection formelle doit \u234?tre
institutionnalis\u233?e \u224? haut niveau, d'autant plus que les participants
peuvent faire partie d'entit\u233?s tr\u232?s diff\u233?rentes et ne sont pas
toujours des parties prenantes actives (il peut s'agir d'experts ext\u233?rieurs).
La difficult\u233? est ici de retenir l'int\u233?r\u234?t de relecteurs qui ne
participent pas \u224? l'\u233?laboration du document. Elaboration de cas de test \
u201?laborer des cas de test correspondant \u224? des exigences, c'est d\u233?j\
u224? mettre ces exigences \u224? l'\u233?preuve. Pour \u233?laborer un cas de
test, il faut imaginer le comportement r\u233?ciproque de l'utilisateur et du syst\
u232?me, ce qui fait ressortir toutes les incoh\u233?rences qui \u233?taient
auparavant pass\u233?es inaper\u231?ues. C'est donc un excellent moyen de faire \
u233?merger les d\u233?fauts dans un document de sp\u233?cification. Les cas de
test qui sont \u233?labor\u233?s \u224? ce niveau concernent \u233?videmment des
tests de validation et non des tests de v\u233?rification. Comme leur pendant au
niveau des sp\u233?cifications, ils d\u233?crivent le quoi, et non le comment. Il
est utile d'\u233?laborer les cas de test le plus en amont possible. Plut\u244?t
que d'attendre d'avoir un cahier des charges enti\u232?rement boucl\u233?, il est
plus int\u233?ressant d'anticiper et de commencer l'\u233?laboration des cas de
test d\u232?s que l'on dispose d'un ensemble suffisamment autonome (c'est-\u224?-
dire coh\u233?rent et complet) d'exigences. D\u233?tecter des failles rapidement
est tr\u232?s avantageux : cela \u233?vite de refaire les m\u234?mes erreurs sur
d'autres parties du cahier des charges. Avant d'\u233?laborer ces cas de test, nous
conseillons de passer les check-lists concernant toutes les autres propri\u233?t\
u233?s des sp\u233?cifications (compl\u233?tude, coh\u233?rence, etc.). L'\u233?
laboration de cas de test constitue pour ainsi dire l'\u233?preuve du feu pour un
ensemble d'exigences. Elle d\u233?montre leur teslabilit\u233?, qui suppose que les
autres propri\u233?t\u233?s (compl\u233?tude. coh\u233?rence, non-ambigu\u239?t\
u233?, etc.) sont v\u233?rifi\u233?es. Une variante de cette technique consiste \
u224? \u233?laborer, \u224? partir des exigences, la documentation du logiciel. L'\
u233?laboration de cette documentation peut \u234?tre confi\u233?e \u224? une autre
\u233?quipe que celle responsable de l'\u233?laboration du cahier des charges, ce
qui permet de tester qu'elle est compr\u233?hensible par un lecteur ext\u233?rieur.
On proc\u233?dera par la suite \u224? une relecture crois\u233?e. GD\par\pard\
plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Contr\u244?le qualit\u233? des
exigences L'id\u233?e est d'avoir un ou plusieurs points de passage oblig\u233?s
par lesquels toute exigence passe syst\u233?matiquement et sans exception. Robert
son1 parle de quatily gateway que l'on pourrait traduire par \u171? passage \u224?
niveau de la qualit\u233? \u187?. On peut d\u233?cider que toute exigence peut se
trouver dans l'un des deux \u233?tats suivants : non valid\u233?e ou valid\u233?e.
Le point de bascule d'un \u233?tat \u224? l'autre d\u233?pend bien s\u251?r du
niveau de rigueur du processus d'\u233?laboration, et en particulier de validation.
Les variantes sont \u233?videmment possibles. On peut imaginer un syst\u232?me \
u224? trois \u233?tats ou plus, par exemple : 0. Propos\u233?e. 1. V\u233?rifi\
u233?e (check-list minimale). 2. Formellement accept\u233?e (par le comit\u233? de
validation). La gestion de ces changements d'\u233?tat est facilit\u233?e avec les
outils de gestion des exigences. Avec de tels outils. \u171? \u233?tat \u187? est
une des propri\u233?t\u233?s de l'exigence. Certains outils permettent de d\u233?
finir une baseline, ou version de r\u233?f\u233?rence d'un ensemble d'exigences, o\
u249? toutes les exigences sont valid\u233?es. Impliquer les personnes concern\
u233?es Ces actions de validation ne serviraient \u224? rien si elles n'\u233?
taient faites par les personnes ad\u233?quates au moment ad\u233?quat. De plus, les
diff\u233?rentes parties prenantes doivent s'impliquer v\u233?ritablement. C'est
tout l'art de la validation. Le reste n'est que proc\u233?dure. C'est l\u224? que
l'analyse des parties prenantes, qui a \u233?t\u233? faite lors de l'\u233?tape pr\
u233?alable, va s'av\u233?rer utile. Par exemple, le cahier des charges en version
finale sera sign\u233? par le directeur g\u233?n\u233?ral, apr\u232?s que de
nombreuses validations partielles ont eu lieu, par d'autres analystes puis par les
repr\u233?sentants des utilisateurs. Le ma\u238?tre d'oeuvre devra s'engager \u224?
r\u233?aliser, ce qui est aussi une forme de validation. Auparavant, des experts
auront v\u233?rifi\u233? que les exigences sont effectivement r\u233?alisables. Il
s'agit l\u224? d'un cas parmi d'autres. R\u233?ussira impliquer tous les acteurs au
bon niveau au bon moment demande un minimum d'organisation : \u8226? avoir d\u233?
fini une carte des acteurs, c'est-\u224?-dire un sch\u233?ma ou un graphe des
parties prenantes ; \u8226? d\u232?s que possible, proc\u233?der \u224? des
validations informelles de sp\u233?cifications partielles par les personnes du
terrain (repr\u233?sentants des utilisateurs) ; 1. V. S. & J.Robert- son. Mastering
the Requirements Process, Addison-Wesley. CD\par\pard\plain\hyphpar} {
Chapitre 13 - L'\u233?tape de validation \u8226? au fur et \u224? mesure que les
sp\u233?cifications se consolident, proc\u233?der \u224? des validations de plus en
plus formelles ; \u8226? tenir inform\u233?es les parties prenantes de plus haut
niveau de responsabilit\u233? sans leur demander une validation formelle ; \u8226?
lorsque le document est finalis\u233?, revu par toutes les parties prenantes, faire
signer au plus haut niveau (par exemple, directeur g\u233?n\u233?ral). Cette mani\
u232?re de proc\u233?der ne garantit pas le succ\u232?s, mais elle y contribue
grandement. La pire des choses est d'obtenir un accord purement formel, une
signature \u171? les yeux ferm\u233?s \u187?. A contrario de la signature de pi^
fp(p^ sans r\u233?eAi\u232? mîcaliw, Tapprobation du cahier des chaiges au plus
haut niveau dte responsabifit\u233? peut l\u233?gftm importante que l\u235?d\u233?
dsionnaireder\u224?utmve^\u233? Un directeur va signer s'il a compris que le cahier
des diarg^ o^ vient tf refl\u232?te sa strat\u233?gie, et la d\u233?mine sur le ^
tedrnkûes.mabcompi\u233?liensiblespa f\'5c)uramW\u224?\u339?r\u233?sultat il nya ^
boiit en bout; un piocessus structur\u233? de d\u233?^ acteur y ga\u231?^ en tennes
oe \u171?\u187?\u219?ts, de del\u224?\u187?, de colite. lUen de magique. Cela s'ap-
\u8226?' pdlering\u233?îerie des exigences. '"' Check-list : validation \u8226? Le
r\u233?dacteur a pass\u233? la check-list de bonne formulation. \u8226? Le r\u233?
dacteur a pass\u233? la check-list de structuration. \u8226? Une personne ext\u233?
rieure a relu les sp\u233?cifications. \u8226? Les diff\u233?rentes parties
prenantes ont particip\u233? \u224? la validation. \u8226? Une revue au moins a \
u233?t\u233? effectu\u233?e. \u8226? Un consensus sur les exigences a \u233?t\u233?
obtenu. \u8226? Les exigences sont aptes \u224? \u234?tre communiqu\u233?es pour r\
u233?alisation. GD\par\pard\plain\hyphpar} {
Chapitre 16 Un mod\u232?le de processus lusqu'ici. nous avons d\u233?crit tr\u232?s
globalement la d\u233?marche g\u233?n\u233?rale de d\u233?veloppement des exigences
puis, plus en d\u233?tail, les \u233?tapes qui la composent et les techniques que
l'analyste peut mettre en \u339?uvre \u224? chaque \u233?tape. Nous proposons ici
un processus, que chacun pourra adapter \u224? son environnement. Un processus-type
Nous donnons donc ici un mod\u232?le g\u233?n\u233?rique, simple, facile \u224?
utiliser. Il devra \u234?tre adapt\u233? et compl\u233?t\u233? en fonction des
particularit\u233?s du projet et du produit, en particulier : \u8226? les objectifs
\u224? atteindre ; \u8226? le type de produit (sp\u233?cifique, adaptation ou choix
de progiciel) ; \u8226? le mode de d\u233?veloppement en interne ou en externe ; \
u8226? la taille et complexit\u233? du produit attendu ; \u8226? la structure des
parties prenantes ; \u8226? l'organisation de la ma\u238?trise d'ouvrage et de la
ma\u238?trise d'oeuvre ; \u8226? les proc\u233?dures d\u233?j\u224? existantes dans
l'organisation : \u8226? les risques. On fera particuli\u232?rement attention \
u224? adapter le vocabulaire, tr\u232?s diff\u233?rent d'un domaine d'application \
u224? l'autre. Des expressions comme comit\u233? de pilotage, comit\u233?
directeur, ou plan projet peuvent avoir des significations sensiblement diff\u233?
rentes selon les organisations. En cas de divergences entre le vocabulaire de la
ma\u238?trise d'ouvrage et celui de la ma\u238?trise d'oeuvre, c'est g\u233?n\u233?
ralement celui de la ma\u238?trise d'ouvrage (votre client) qui prime.\par\pard\
plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences teppeloitt la phrase du c\u233?l\u232?
bre certaHK ntod\u232?Wsoirt utite carte n'est pas te terrain. Une \u226?a^ re^le
cte cahier des cta^ prt*abtemertpascesse|rt\u233?ta responsabte de f\u233?labor\
u226?t\u187?^ tf^ souvent adapter, ce processus. En aucun cas, ce mod\u232?le de
processus ne devra \u234?tre sarvi\u224?laletbeetenl'e^ r\u233?
*texk>n,etnonunepit>cidure. Ce di\u224?prtre dcfli\u187? une c\u224?rtede processus
de d\u233?veioppemem des \u244? Le lecteur doit acfepter cette carte en ajoutarrt,
en^ r^ nrveauctechaQ^\u233?t\u226?pe/BdeWadaptCT^ proc\u233?dure. La figure 16-1
donne la carte du processus mod\u232?le. \u163? -It\u233?ration \u233?ventueMe- I
1. Cadrer 2. Planifier 3. Analyser l'existant 4. Recueillir et analyser le besoin
Approbation du plan 6. Valider le cahier des charges I CdC incomplet : Reiterer-
Figure 16-1 : Mod\u232?le de processus Etape 1 : cadrer Entr\u233?e Le seul \u233?
l\u233?ment \u233?crit en entr\u233?e est \u233?ventuellement une lettre de
mission. Ce document n'est pas n\u233?cessairement une < lettre \u187?. Mais en
tout \u233?tat de cause, c'est un document sign\u233? par le donneur d'ordres (ma\
u238?tre d'ouvrage strat\u233?gique) et adress\u233? \u224? l'assistant \u224? la
ma\u238?trise d'ouvrage (ma\u238?tre d'ouvrage d\u233?l\u233?gu\u233?). (Q3\par\
Chapitre 16 - Un mod\u232?le de processus L'approbation formelle du donneur
d'ordres est parfois difficile \u224? obtenir. Si elle ne peut \u234?tre obtenue \
u224? cette \u233?tape, elle devra l'\u234?tre au plus tard dans la note de
cadrage. Actions Il s'agit d'avancer autant que possible sur le triangle objectifs-
parties prenantes-p\u233?rim\u232?tre. Les actions sont : \u8226? Recueillir les
objectifs, par interview des parties prenantes c\u244?t\u233? client (ma\u238?tre
d'ouvrage) au plus haut niveau de responsabilit\u233?. \u8226? Analyser les parties
prenantes, du c\u244?t\u233? du client et du fournisseur, directes (utilisateurs et
d\u233?veloppeurs) et indirectes (impact\u233?es par le produit), strat\u233?giques
et op\u233?rationnelles. \u8226? D\u233?finir le p\u233?rim\u232?tre du projet et
du produit, au moyen de r\u233?unions, dont une r\u233?union formelle. Au plus t\
u244?t, il faudra entamer l'\u233?laboration du diagramme de contexte de
l'existant, et \u233?ventuellement de la cible. On peut \u224? ce stade \u233?
laborer les en-t\u234?tes des cas d'utilisation m\u233?tier. Sortie Le document en
sortie de cette \u233?tape est la note de cadrage. Il contient les \u233?l\u233?
ments suivants : \u8226? objectifs du projet ; \u8226? structure des parties
prenantes ; \u8226? diagramme de contexte ; \u8226? liste des \u233?v\u233?nements
m\u233?tier ; \u8226? cas d'utilisation m\u233?tier ; \u8226? description des
cinq \u224? dix exigences de haut niveau -, \u8226? chiffrage grossier de la r\
u233?alisation du produit. Conditions de sortie La note de cadrage ne doit pas n\
u233?cessairement faire l'objet d'une validation formelle. On peut attendre la
sortie de l'\u233?tape 2 (planification) pour faire approuver ce cadrage par le
donneur d'ordres. Il est cependant utile de le formaliser pour en discuter entre
analystes et le soumettre au donneur d'ordres pour avis. Etape 2 : planifier Entr\
u233?es \u8226? Lettre de mission. \u8226? Note de cadrage. (FJj)\par\pard\plain\
hyphpar} {
Partie 2 - D\u233?veloppement des exigences Actions \u8226? Choisir et adapter le
processus de d\u233?veloppement des exigences. \u8226? Choisir et adapter le mod\
u232?le de cahier des charges. \u8226? Choisir et adapter les techniques. \u8226?
Choisir les outils. \u8226? D\u233?terminer les profils utilisateur. \u8226?
Planifier les jalons importants (comit\u233?s de pilotage). \u8226? Planifier les
plages de travail pour les interviews. \u8226? Planifier les groupes de travail.
Sortie : le plan projet \u8226? Profils utilisateurs types. \u8226? Sources
d'exigences. \u8226? Tableau des charges, d\u233?lais et planning. \u8226? Fiches
de risques. Conditions de sortie \u192? ce stade, le donneur d'ordres devra avoir
approuv\u233? la note de cadrage et le plan projet. Ces deux documents peuvent
d'ailleurs \u234?tre r\u233?unis en un seul. Etape 3 : analyser l'existant Entr\
u233?es \u8226? Liste des documents existants. \u8226? Tableau des parties
prenantes. \u8226? Documentation de l'organisation existante. \u8226? Documentation
du syst\u232?me existant. Actions \u8226? Rassembler la documentation sur
l'existant. \u8226? Analyser le cadre organisationnel. \u8226? Examiner les
services impact\u233?s par le fonctionnement du syst\u232?me. \u8226? Si n\u233?
cessaire, enrichir le diagramme de contexte de l'existant. \u8226? Si n\u233?
cessaire, enrichir le tableau des parties prenantes. \u8226? Analyser les processus
actuels. fETft\par\pard\plain\hyphpar} {
Chapitre 16 - Un mod\u232?le de processus \u8226? Dresser un diagramme de flux de
processus pr\u233?sentant le circuit des informations entre services. \u8226? D\
u233?crire les fonctions dans leur \u233?tat actuel. \u8226? Dresser le bilan de la
situation actuelle : - inefficience des processus et leurs causes : circuits trop
complexes, documents inutiles, r\u232?gles de gestion obsol\u232?tes, moyens inad\
u233?quats ; - fonctions inadapt\u233?es, manquantes, inutilisables ; - difficult\
u233? d'utilisation ; - performances du syst\u232?me : temps de r\u233?ponse trop
longs, consommations ; - faiblesse des attributs non fonctionnels : fiabilit\u233?,
portabilit\u233?, maintenabilit\u233? ; - support aux utilisateurs insuffisant,
faible efficacit\u233? de la maintenance. \u8226? Mentionner par sous-syst\u232?me
ou domaine : - les principes ou les m\u233?thodes \u224? remettre en cause -, - les
processus ou proc\u233?dures \u224? revoir ; - les facteurs de qualit\u233? \u224?
revoir ; - les informations \u224? pr\u233?ciser. \u8226? Examiner, pour chacun des
points pr\u233?c\u233?dents : - ce qui est \u224? conserver, voire \u224? amplifier
-, - ce qui est \u224? supprimer ou \u224? remplacer ; - ce qui est \u224?
modifier. \u8226? Analyser l'existant en termes d'offre sur le march\u233?. \u8226?
Si n\u233?cessaire, \u233?tudier les sc\u233?narios d'\u233?volution (red\u233?
veloppement, migration, choix de progiciel...). Sorties \u8226? Panorama de l'\
u233?tat actuel du syst\u232?me. \u8226? Organigramme des services concern\u233?
s. \u8226? Liste des fonctions, en leur \u233?tat actuel. \u8226? Diagrammes de
processus, de s\u233?quence, d'\u233?tats. \u8226? Vision organisationnelle (postes
de travail, nature des traitements, types de traitements). \u8226? Solution
technique actuelle : proc\u233?dures, mat\u233?riels et logiciels de base,
logiciels applicatifs, progiciels. \u207?ET1\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences \u8226? Bilan de la situation
actuelle : principaux axes d'am\u233?lioration n\u233?cessaires au syst\u232?me
actuel. \u8226? Axes d'\u233?volution (si une \u233?tude d'\u233?volution a \u233?
t\u233? men\u233?e) : - liste (non d\u233?taill\u233?e) des diff\u233?rents types
de solutions fonctionnelles envisageables -, - br\u232?ve pr\u233?sentation des sc\
u233?narios \u233?tudi\u233?s ; - justification du sc\u233?nario retenu ; - mesures
envisag\u233?es pour conduire le changement : - mesures envisag\u233?es pour
faciliter l'appropriation du nouveau syst\u232?me par les utilisateurs. \u8226?
Comptes-rendus d'interview ou note de synth\u232?se. Conditions de sortie On peut
passer \u224? l'\u233?tape suivante lorsque les documents de sortie sont jug\u233?s
suffisamment complets et lorsqu'un consensus s'est fait autour des sc\u233?narios
d'\u233?volution. L'analyse de l'existant peut remettre en cause l'objectif ou le
p\u233?rim\u232?tre, avec \u233?ventuellement des r\u233?percussions sur les
charges ou le planning. Si tel est le cas. il faudra obtenir l'approbation formelle
du donneur d'ordres, apr\u232?s passage \u233?ventuel par les \u233?tapes I et/ou
2. Etape 4 : recueillir et analyser les besoins Entr\u233?es Les entr\u233?es de
cette \u233?tape sont les \u233?l\u233?ments de sortie des trois \u233?tapes pr\
u233?c\u233?dentes, en particulier : \u8226? lettre de mission ; \u8226? note de
cadrage-, \u8226? plan projet ; \u8226? \u233?tude de l'existant. A ce stade,
l'absence d'une lettre de mission donnant formellement \u224? l'analyste les moyens
et l'autonomie de mener sa mission est un facteur de risque important. Actions \
u8226? Planifier le recueil. \u8226? Assembler la documentation. ito\par\pard\
plain\hyphpar} {
Chapitre 16 - Un mod\u232?le de processus \u8226? Recueillir les besoins
organisationnels : - inventorier les r\u232?gles de gestion ; - inventorier les
contraintes. \u8226? Recueillir les besoins utilisateurs : - mener les interviews ;
- animer les groupes de travail ; - lire les documents. \u8226? Synth\u233?tiser et
classer les informations recueillies : - exigences m\u233?tier ; - cas
d'utilisation ; - exigences fonctionnelles ; - exigences non fonctionnelles ; -
contraintes produit ; - contraintes projet : - faits et hypoth\u232?ses pertinents.
\u8226? Reformuler les exigences recueillies (cf. check-list de formulation des
exigences). \u8226? Distribuer les exigences recueillies aux participants aux
groupes de travail. \u8226? Analyser les exigences en groupe de travail : -
discuter, en r\u233?union de groupe, les informations recueillies ; - enrichir, si
n\u233?cessaire, le diagramme de contexte ; - \u233?laborer tout diagramme \u224?
m\u234?me de faciliter la compr\u233?hension commune ; - r\u233?aliser, si n\u233?
cessaire, des maquettes papier ; - r\u233?aliser, si n\u233?cessaire, un prototype.
\u8226? V\u233?rifier les exigences (check-list de recueil et d'analyse). Sorties \
u8226? Comptes-rendus d'interview ou note de synth\u232?se. \u8226? Exigences
reformul\u233?es. \u8226? Diagrammes. Conditions de sortie Lorsque les exigences
recueillies forment un tout coh\u233?rent, les inclure dans le cahier des charges
en cours d'\u233?laboration (\u233?tape 5). ira\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences Etape 5 : sp\u233?cifier les exigences
Entr\u233?es \u8226? Mod\u232?le de cahier des charges. \u8226? Exigences formul\
u233?es. Actions \u8226? Reformuler si n\u233?cessaire les exigences recueillies \
u224? l'\u233?tape pr\u233?c\u233?dente. \u8226? Passer la check-list de
formulation des exigences. \u8226? Enrichir le cahier des charges avec les
exigences recueillies \u224? l'\u233?tape pr\u233?c\u233?dente. \u8226? Passer la
check-list de l'\u233?tape de sp\u233?cification. Sorties \u8226? Cahier des
charges enrichi. \u8226? Plan projet r\u233?actualis\u233?. Conditions de sortie
Apr\u232?s passage r\u233?ussi des check-lists. passer \u224? l'\u233?tape
suivante. Etape 6 : valider les exigences Entr\u233?es Lors de la premi\u232?re it\
u233?ration, c'est uniquement le squelette de cahier des charges qui devra \u234?
tre valid\u233?. Pour les it\u233?rations suivantes, on devra valider le contenu,
sauf si le squelette a d\u251? \u234?tre modifi\u233?. Les \u233?l\u233?ments
d'entr\u233?e sont donc : \u8226? cahier des charges ; \u8226? note indiquant
quelles parties du cahier des charges sont \u224? l'\u233?tat \u171? \u224? valider
\u187? ; \u8226? mod\u232?le de fiche de lecture, vierge. Les indications sur les
parties du cahier des charges \u224? valider peuvent se trouver dans le cahier des
charges lui-m\u234?me, par exemple sous forme de texte en couleurs, surlign\u233?,
ou en utilisant le mode r\u233?vision d'un outil de traitement de texte. Actions
Appliquer la proc\u233?dure de validation, selon le protocole convenu : \u8226?
revue ou inspection de document ; ira\par\pard\plain\hyphpar} {
Chapitre 16 - Un mod\u232?le de processus \u8226? maquette, prototype ; \u8226? \
u233?laboration de cas de test. Sorties \u8226? Exigences valid\u233?es. \u8226?
Fiches de relecture remplies. Conditions de sortie Les validations \u224? chaque
it\u233?ration peuvent \u234?tre formelles ou informelles. La derni\u232?re it\
u233?ration donnera lieu \u224? une validation formelle. S'il reste des exigences \
u224? recueillir, repasser \u224? l'\u233?tape 4. Si le cahier des charges est
exhaustif, mais que les parties prenantes ont fait des remarques, repasser \u224?
l'\u233?tape 5. Si la totalit\u233? du cahier des charges est valid\u233?e par la
totalit\u233? des parties prenantes concern\u233?es (donneur d'ordres, ma\u238?
trise d'ouvrage), le processus d'\u233?laboration du cahier des charges est termin\
u233?. L'\u233?tape suivante (capitalisation) permettra d'am\u233?liorer le
processus d'\u233?laboration lui- m\u234?me. Etape 7 ' capitaliser Entr\u233?es
Tous les documents \u233?labor\u233?s lors des \u233?tapes pr\u233?c\u233?dentes.
Actions \u8226? Lors d'une r\u233?union, solliciter un feedback des parties
prenantes. \u8226? Modifier, si n\u233?cessaire, le mod\u232?le de cahier des
charges. \u8226? Modifier ou enrichir les check-lists. \u8226? Modifier, si n\u233?
cessaire, les proc\u233?dures d'\u233?laboration du cahier des charges. \u8226?
Remercier les participants. \u8226? C\u233?l\u233?brer la fin de la mission.
Sorties \u8226? Nouveau mod\u232?le de cahier des charges. \u8226? Proc\u233?dures
modifi\u233?es ou enrichies. \u8226? Rapport de mission. \u338?B\par\pard\plain\
hyphpar} {
Chapitre 17 Am\u233?liorer e processus Dans les chapitres pr\u233?c\u233?dents,
nous avons vu que le processus de d\u233?veloppement des exigences doit \u234?tre
adapt\u233? \u224? l'organisation, aux objectifs et au type de projet. Et comme
tout processus, il y a des moyens pratiques de l'am\u233?liorer. Pour rendre le
processus plus efficace, il faut chercher o\u249? se trouvent les gisements
d'efficacit\u233?. Apr\u232?s une explication des facteurs d'am\u233?lioration,
nous donnons quelques conseils pratiques1. 1. La lecture de ce chapitre n'est pas
indispensable \u224? la compr\u233?hension des chapitres qui suivent Pourquoi le
processus peut \u234?tre am\u233?liore ? Quelle que soit la d\u233?marche choisie,
le processus comporte, dans ses grandes lignes, toujours les m\u234?mes \u233?tapes
: recueil, analyse, sp\u233?cification et validation. Peuvent s'y ajouter, selon
les auteurs, l'\u233?tape pr\u233?alable de cadrage ou pr\u233?paration, et l'\
u233?tape suppl\u233?mentaire de capitalisation. Les ouvrages sur l'ing\u233?nierie
des exigences nous disent que les quatre (ou cinq, ou six...) \u233?tapes du
processus sont \u171? imbriqu\u233?es \u187?. Et tout praticien de la m\u233?thode
sait que ce processus n'est ni lin\u233?aire ni ferm\u233?. Comprendre comment et
pourquoi ces \u233?tapes sont \u171? imbriqu\u233?es \u187? va nous permettre d'am\
u233?liorer le processus. Or. il y a trois raisons pour lesquelles les \u233?tapes
sont interd\u233?pendantes : \u8226? Le processus n'est pas lin\u233?aire : il
contient des boucles de r\u233?troaction. \u8226? Le processus est r\u233?cursif :
chaque \u233?tape contient les autres. \u8226? Le processus est it\u233?ratif : on
travaille par couches successives.\par\pard\plain\hyphpar} {
Partie 2 - D\u233?veloppement des exigences 2. Retravail (rework). Formellement,
c'est T\u233?tape de prise en compte des remarques suite \u224? une inspection ou
une revue formelle. Nous allons d\u233?crire ces trois m\u233?canismes et voir
comment ils peuvent influencer, positivement ou n\u233?gativement, l'efficience du
processus. Apr\u232?s cette analyse, nous aurons en main les moyens d'am\u233?
liorer cette efficience. R\u233?troactions Le premier m\u233?canisme est facile \
u224? comprendre : les retours \u224? une \u233?tape pr\u233?c\u233?dente2 sont in\
u233?vitables. Ainsi, si au cours d'une \u233?tape, il manque des informations
(incompl\u233?tude). on remontera \u224? l'\u233?tape de recueil. Si l'on d\u233?
couvre une incoh\u233?rence, on remontera \u224? l'\u233?tape d'analyse. Cela n'a
rien de dramatique, bien s\u251?r. mais occasionne des pertes de temps et d'\u233?
nergie. Rappeler une personne au t\u233?l\u233?phone pour lui demander des pr\u233?
cisions est plus co\u251?teux en temps et en effort que. par exemple, reformuler ce
qu'il vient de dire. Ainsi, pour optimiser le processus, il faudra faire en sorte
que les retours aux \u233?tapes pr\u233?c\u233?dentes soient les moins fr\u233?
quents possibles. Remise en cause de l'objectif- Incoh\u233?rences- -incompr\u233?
hensions- Analyse Sp\u233?cification "\u239? Validation CdC Impr\u233?cisions- -
Incompi\u233?tudes-: Incompi\u233?tudes- Incoh\u233?rences, incompi\u233?tudes,
incompr\u233?hensions Figure 17-1 : R\u233?troactions R\u233?cursions La deuxi\
u232?me raison pour laquelle les quatre \u233?tapes sont imbriqu\u233?es tient \
u224? la nature r\u233?cursive du processus. Dit plus simplement, chaque \u233?tape
contient des \u233?l\u233?ments des autres \u233?tapes. Par exemple, lorsque l'on
recueille les exigences, on ne va pas se contenter d'\u233?couter et de transcrire.
On va aussi analyser, voire sp\u233?cifier, cette exigence. On va pouvoir anticiper
sur les \u233?tapes \u224? suivre. Cette anticipation peut acc\u233?l\u233?rer le
processus, mais aussi le d\u233?grader. (ED\par\pard\plain\hyphpar} {
Chapitre 17 - Am\u233?liorer \u239?e processus Validation Figure 17~2 : R\u233?
cursivit\u233? du processus It\u233?rations La troisi\u232?me raison, c'est que le
processus est it\u233?ratif : les sp\u233?cifications 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 sp\u233?cifier et les faire
valider. L'\u233?tape pr\u233?alable n'est ni plus ni moins qu'un minicycle de la
phase d'exigences. Il est possible de syst\u233?matiser cette approche et de
fournir, par it\u233?rations, des cahiers des charges de plus en plus pr\u233?cis.
Ici aussi, cette fa\u231?on de travailler peut acc\u233?l\u233?rer le processus ou
le d\u233?grader. Figure 77-3 : Processus it\u233?ratif Comment le processus peut \
u234?tre am\u233?lior\u233? En r\u233?sum\u233?, trois moyens sont \u224? notre
disposition pour optimiser le processus de d\u233?veloppement des exigences : \
u8226? minimiser les retours en arri\u232?re chaque fois que cela est possible ;
G3j)\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences \u8226? anticiper sur les \u233?tapes
suivantes, lorsque cela est utile ; \u8226? consid\u233?rer l'option de travailler
de mani\u232?re it\u233?rative, par couches successives. Voyons comment, de mani\
u232?re pratique, ces moyens peuvent \u234?tre mis en \u339?uvre. Minimiser le
retravail (rework) Nous avons introduit, tout au long de cet ouvrage, un outil
simple et efficace pour minimiser les retours en arri\u232?re : la check-list. Un
simple contr\u244?le nous permet de savoir si nous avons fait tout ce qui devait
l'\u234?tre \u224? une \u233?tape donn\u233?e. Le pr\u233?sent ouvrage contient
plusieurs check-lists. \u224? plusieurs niveaux, mais d'autres check-lists
peuvent \u234?tre \u233?labor\u233?es pour enrichir le r\u233?f\u233?rentiel m\
u233?thodologique d'une \u233?quipe d'analystes. Remarquons que les documents types
sont \u233?galement des check-lists d'une forme plus \u233?labor\u233?e. C'est en
particulier le cas du mod\u232?le de cahier des charges. La technique de
l'anticipation Anticiper ne signifie pas, bien s\u251?r. br\u251?ler les \u233?
tapes (cela aurait l'effet contraire \u224? celui escompt\u233?), mais bien pr\
u233?parer chaque sous-\u233?tape ou micro-\u233?tape pour analyser, sp\u233?cifier
ou faire valider au plus t\u244?t ce qui peut l'\u234?tre. Pour anticiper sur les \
u233?tapes suivantes, nous avons d\u233?j\u224? donn\u233? quelques \u171? trucs \
u187? dans les diff\u233?rents chapitres. Cette technique d'anticipation peut \
u234?tre syst\u233?matis\u233?e. Anticiper sur les \u233?tapes \u224? venir a des
avantages et des inconv\u233?nients. Parfois, il est int\u233?ressant d'apporter de
la pr\u233?cision le plus vite possible, et de sortir d'une interview avec des
exigences d\u233?j\u224? clairement formul\u233?es. \u192? d'autres moments, il
sera inutile de sp\u233?cifier avec pr\u233?cision des exigences qui seront remises
en cause \u224? la prochaine interview. Prenons l'exemple d'un outil de recueil
bien connu : l'interview. Suite \u224? l'interview proprement dite, l'analyste peut
mener les actions suivantes : \u8226? mini-analyse : confronter les notes
d'interview avec les autres \u233?l\u233?ments recueillis et chercher \u224? lever
les ambigu\u239?t\u233?s et les incoh\u233?rences ; \u8226? minisp\u233?
cification : les notes d'interview peuvent \u234?tre structur\u233?es et bien
formul\u233?es au lieu d'\u234?tre laiss\u233?es telles quelles ; \u8226?
minivalidation : l'analyste envoie \u224? la (ou aux) personnel s) interview\u233?
e(s) ces sp\u233?cifications partielles pour validation. Ces op\u233?rations
peuvent \u234?tre men\u233?es pour la plupart des activit\u233?s de recueil : r\
u233?union de groupe de travail, brainstorming. et m\u234?me analyse de la
documentation. \u338?D\par\pard\plain\hyphpar} {
Chapitre 17 - Am\u233?liorer \u239?e processus Cette d\u233?marche de pr\u233?
analyse, pr\u233?sp\u233?cification et pr\u233?validation peut se faire au niveau
des micro\u233?tapes. Par exemple, lors d'une interview sur le terrain, suite \
u224? une r\u233?ponse apport\u233?e par l'interview\u233? \u224? une question,
l'analyste peut, si les circonstances le permettent, faire en temps r\u233?el
une: \u8226? microanalyse : confronter la r\u233?ponse donn\u233?e \u224? d'autres
exigences ; utiliser des diagrammes et en discuter avec son interlocuteur ; \u8226?
microsp\u233?cification : reformuler le plus pr\u233?cis\u233?ment possible la r\
u233?ponse de l'interview\u233?, sous une forme claire et coh\u233?rente, pr\u234?
te \u224? \u234?tre ins\u233?r\u233?e dans le cahier des charges ; \u8226?
microvalidation : l'exigence ainsi sp\u233?cifi\u233?e par \u233?crit est montr\
u233?e s\u233?ance tenante aux interlocuteurs pour validation. Plus rapidement on \
u233?liminera les erreurs, et plus on pourra s'appuyer sur un terrain solide pour
continuer. Cet ouvrage donne plusieurs exemples de mini-anticipations, comme les
check-Iists. et de microanticipations, comme la reformulation. Cependant, ces
microanticipations ne sont pas toujours r\u233?alisables, ni m\u234?me
souhaitables. C'est l'exp\u233?rience qui permet de savoir s'il est opportun de les
mettre en \u339?uvre. L'analyste doit mettre en balance le b\u233?n\u233?fice
apport\u233? par une analyse ou une formalisation imm\u233?diate, et sa possible
remise en question par la suite (lors d'une autre interview, par exemple). Le
travail it\u233?ratif Travailler par < couches horizontales \u187? peut \u234?tre
tr\u232?s int\u233?ressant. Mais l\u224? aussi, il n'y a pas de r\u232?gle absolue.
Dans son ouvrage sur le travail collaboratif sur les exigences3. Ellen Gottesdiener
consacre un chapitre entier aux diff\u233?rentes mani\u232?res de naviguer entre
les exigences avec les groupes de travail, soit horizontalement, par couches
successives, soit verticalement, en descendant dans les d\u233?tails au cours d'une
r\u233?union, soit m\u234?me en zigzag. La premi\u232?re couche horizontale, celle
de la d\u233?finition des objectifs et du cadre, sera g\u233?n\u233?ralement bien
s\u233?par\u233?e des autres. Nous l'avons d\u233?crite en d\u233?tail au chapitre
6. Elle donne lieu \u224? un livrable particulier. Rien n'emp\u234?che d'ailleurs
d'utiliser ce livrable comme premier chapitre du cahier des charges. 3. Ellen
Gottesdiener, Requiiements by collaboration, Addi- son-Wesley, 2002. La m\u233?
thode du document navette Un principe simple La technique consiste \u224? mener les
travaux, du premier recueil des objectifs jusqu'\u224? la validation finale, autour
de la cr\u233?ation et de la tenue \u224? jour fm\par\pard\plain\hyphpar} {
ie 2 - D\u233?veloppement des exigences d'un document unique, le cahier des
charges. Cette d\u233?marche simple et efficace pr\u233?sente plusieurs avantages :
\u8226? Le cahier des charges devient le fil directeur du projet. Il est \u224? la
fois le mat\u233?riau sur lequel on travaille et l'objectif \u224? atteindre. \
u8226? La progression est visible de tous. L'enrichissement progressif d'un
document partag\u233? permet \u224? chacun de constater les progr\u232?s en temps
r\u233?el. \u8226? Les acteurs ont un seul et unique document \u224? g\u233?rer. Ce
document central va devenir un v\u233?ritable outil de communication entre les
parties prenantes. Avant de partager le document, il faudra figer, autant que
possible, le mod\u232?le de cahier des charges, qui va couvrir les diff\u233?rents
aspects du projet et faciliter la structuration des id\u233?es et des activit\u233?
s. Le sommaire du document va constituer un guide pour le recueil et l'analyse des
besoins, la d\u233?finition fonctionnelle et les orientations de solution. Toute
modification ult\u233?rieure devra faire l'objet de n\u233?gociations. Cette \u233?
tape est sous la responsabilit\u233? de l'analyste, qui est le garant de la forme
et de la m\u233?thode. En s'\u233?toffant, le document va permettre de contr\u244?
ler la couverture et la progression de tous les aspects, au fur et \u224? mesure de
l'avancement du projet. Bien entendu, cela n'emp\u234?che pas de pr\u233?voir des
documents compl\u233?mentaires (comptes-rendus de r\u233?unions du comit\u233? de
pilotage, par exemple). Mais c'est toujours le document navette qui fait foi. De
mani\u232?re \u224? optimiser ses travaux d'animation et de conseil \u224? la ma\
u238?trise d'ouvrage, l'analyste va enrichir le cahier des charges de fa\u231?on
continue au cours des \u233?tapes de recueil, d'analyse et de sp\u233?cification,
ce qui r\u233?duira l'effort de r\u233?daction et de validation. Le document
changera de version au cours du projet, en passant d'un \u233?tat exploratoire \
u224? un \u233?tat provisoire, pour se figer, apr\u232?s validation par les parties
prenantes, \u224? l'\u233?tat de r\u233?f\u233?rence. Cette mani\u232?re de proc\
u233?der permet le partage du contr\u244?le de la qualit\u233? des livrables pour
ainsi dire en temps r\u233?el, et un dialogue plus fluide entre ma\u238?trise
d'ouvrage et ma\u238?trise d'oeuvre. Le mod\u232?le de cahier des charges, puis les
versions successives de celui-ci serviront de support \u224? ce dialogue. Cette
coconstruction permet de d\u233?terminer pr\u233?cis\u233?ment les priorit\u233?s
en termes d'exigences non fonctionnelles, car ma\u238?trise d'ouvrage et ma\u238?
trise d'oeuvre construisent ensemble un vocabulaire commun et non ambigu. Une
pratique simple et efficace La technique du document unique ne r\u233?sout pas tous
les probl\u232?mes. Elle minimise le nombre de documents et demande beaucoup de
rigueur dans la gestion des versions du cahier des charges. Plut\u244?t que de g\
u233?rer une multitude de documents (g\u233?n\u233?ralement non versionn\u233?s).
on devra g\u233?rer les versions multiples, et g\u233?n\u233?ralement
arborescentes, d'un document iro\par\pard\plain\hyphpar} {
Chapitre 17 - Am\u233?liorer \u239?e processus central. C'est tout aussi complexe,
mais plus efficace lorsque l'on ma\u238?trise la technique. Par exemple, le cahier
des charges est \u224? mi-parcours : \u8226? Lors de la r\u233?union d'un groupe de
travail, l'animateur note les exigences au fur et \u224? mesure du recueil, soit
sur papier, soit directement sur le document lui-m\u234?me. Il peut utiliser une
couleur diff\u233?rente pour les diff\u233?rentes modifications apport\u233?es
(vert pour un nouveau texte, rouge pour un texte \u224? supprimer, violet pour un
texte \u224? revoir, etc.). Il peut \u233?galement utiliser le mode r\u233?vision
du traitement de texte (attention, certains ont beaucoup de mal avec le mode r\
u233?vision, d'autres ne le supportent tout simplement pas). \u8226? \u192? la fin
de la r\u233?union, ou dans les deux jours qui suivent, l'animateur envoie le
document aux diff\u233?rents acteurs, pour validation. \u8226? Les remarques sont
prises en compte et une nouvelle version du document est cr\u233?\u233?e. Cette
mani\u232?re de proc\u233?der peut \u233?galement \u234?tre mise en oeuvre si l'on
utilise des outils de gestion des exigences. En fonction des circonstances et de la
typologie des acteurs, l'outil sera soit directement utilis\u233? par les groupes
de travail, soit uniquement utilis\u233? par le consultant ou les animateurs. La
plupart des outils permettent de g\u233?n\u233?rer un document de sp\u233?
cifications (cahier des charges en devenir) qui est le reflet de la base
d'exigences. Ici. il n'y a pas de m\u233?thode unique, elle est tr\u232?s d\u233?
pendante des outils utilis\u233?s et de la culture de l'entreprise. (ED\par\pard\
plain\hyphpar} {
(PARTE Faire vivre les exigences Il est bien s\u251?r illusoire de penser que les
exigences, une fois formul\u233?es, vont rester grav\u233?es dans le marbre. En r\
u233?alit\u233?, les exigences \u233?voluent tout au long du cycle de vie du
logiciel, c'est-\u224?-dire avant, pendant, et apr\u232?s la phase d'exigences. Les
changements dans les exigences vont donc impacter non seulement le cahier des
charges, mais le produit en cours d'\u233?criture ou d\u233?j\u224? \u233?crit. La
gestion des exigences est donc tr\u232?s li\u233?e \u224? la gestion des versions
et de la configuration du logiciel. Dans ce cadre, les outils de gestion des
exigences peuvent am\u233?liorer l'efficacit\u233? et la s\u233?curit\u233? de ce
processus.\par\pard\plain\hyphpar} {
Chapitre 18 La gestion des exigences Dans cet ouvrage, il a \u233?t\u233?
essentiellement question de ce qu'il est convenu d'appeler le d\u233?veloppement
des exigences, processus qui permet, en partant d'un objectif, d'aboutir \u224? un
cahier des charges. En r\u233?alit\u233?, les demandes et contraintes \u233?voluent
tout au long du cycle de vie du logiciel : pendant la phase d'exigences, mais \
u233?galement pendant les phases ult\u233?rieures : conception, r\u233?alisation,
int\u233?gration et maintenance. Il est illusoire de penser que les exigences sont
un jour stabilis\u233?es. Ce chapitre est consacr\u233? \u224? la gestion des
demandes de changement, activit\u233? appel\u233?e gestion des exigences. La
gestion des changements La gestion des changements des exigences est \u224? la
fronti\u232?re de plusieurs activit\u233?s d'ing\u233?nierie 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 : \u8226? la configuration du logiciel1 ; \u8226? les co\u251?ts et les d\u233?
lais de livraison des diff\u233?rentes versions ; \u8226? les ressources engag\
u233?es pour op\u233?rer les modifications. L'\u233?tude de ces disciplines
(gestion de configuration et gestion de projet) d\u233?passe le cadre de cet
ouvrage. Nous n'en aborderons ici que les aspects en relation directe avec l'\u233?
volution des exigences. Le changement en lui-m\u234?me est in\u233?vitable. Il doit
\u234?tre contr\u244?l\u233? de mani\u232?re \u224? : \u8226? conserver la coh\
u233?rence entre demandes \u233?manant d'utilisateurs ou d'acteurs diff\u233?rents
et non concert\u233?s ; 1. Gestion de configuration : discipline qui consiste \
u224? g\u233?rer les divers composants d'un syst\u232?me, ainsi que les
modifications apport\u233?es au cours de son \u233?volution.\par\pard\plain\
hyphpar} {
Partie 3 - Faire vivre les exigences 2. Le plus difficile : constituer une
commission de contr\u244?le des changements qui soit l\u233?gitime et
institutionnaliser le processus de contr\u244?le de mani\u232?re \u224? le rendre
incontournable \u8226? ma\u238?triser le co\u251?t induit par une modification (une
modification en apparence l\u233?g\u232?re, pourra induire un impact tr\u232?s
important en termes de co\u251?ts, de d\u233?lais, d'architecture du produit) ; \
u8226? \u233?viter les \u171? sp\u233?cifications rampantes \u187?, suite \u224?
une demande initiale souvent mal formul\u233?e et peu formalis\u233?e, avec des d\
u233?rives sur les d\u233?lais, les charges et la qualit\u233? du produit ; \u8226?
contr\u244?ler le circuit de d\u233?cision, \u233?viter de court-circuiter les
parties prenantes qui ont la l\u233?gitimit\u233? pour d\u233?cider ou conseiller ;
\u8226? tracer les modifications demand\u233?es et les modifications faites. Les
activit\u233?s Cette gestion du changement est donc essentielle, et \u233?vite que
l'effort initial de recueil, d'analyse et de structuration des exigences soit
perdu. Les activit\u233?s de gestion consistent \u224? : \u8226? \u233?valuer
l'impact d'une exigence sur les exigences existantes, et l'impact de sa mise en \
u339?uvre sur le produite d\u233?velopp\u233? ou en cours de d\u233?veloppement ; \
u8226? estimer l'importance, l'urgence et la difficult\u233? de r\u233?alisation
d'une modification, qui peuvent \u234?tre tr\u232?s diff\u233?rentes lorsqu'elles
sont estim\u233?es par le demandeur (qui a une vision partielle de la situation) ou
par les d\u233?veloppeurs (qui voient surtout les contraintes techniques) ; \u8226?
n\u233?gocier les modifications et g\u233?rer les exigences selon les priorit\u233?
s ainsi d\u233?finies, apr\u232?s obtention d'un consensus ; \u8226? suivre les
modifications, et mettre \u224? jour les plannings ; \u8226? enregistrer les
demandes et les modifications ; \u8226? mettre \u224? jour les documents (cahier
des charges, sp\u233?cifications, documentation du produit). La commission de
contr\u244?le des changements (CCB) Afin que les changements soient g\u233?r\u233?s
plut\u244?t qu'impos\u233?s ou subis, la bonne pratique consiste \u224? mettre en
place une commission de contr\u244?le des changements (en anglais. CCB. change
conlrol board). Cette commission devra \u234?tre un passage incontournable pour
toute demande de modification des exigences2. Toute demande de changement, m\u234?
me minime, devra \u234?tre formalis\u233?e au moyen d'un formulaire ad hoc. puis
passer par cette commission. La commission d\u233?cide de la suite \u224? donner,
en fonction des priorit\u233?s de l'entreprise, des impacts sur les co\u251?ts et
les d\u233?lais, des modalit\u233?s de prise en compte d'un changement dans les
exigences. Plusieurs mod\u232?les d'organisation sont possibles, en fonction de la
taille de l'organisation et du nombre de projets en cours. L'organisation la plus
QJD\par\pard\plain\hyphpar} {
Chapitre 18 - La gestion des exigences classique consiste \u224? mettre en place
une commission par projet, pr\u233?sid\u233?e par le chef de projet ma\u238?trise
d'\u339?uvre. La commission est form\u233?e au minimum d'un repr\u233?sentant de la
ma\u238?trise d'\u339?uvre et d'un repr\u233?sentant de la ma\u238?trise d'ouvrage,
ainsi que d'un expert et d'un gestionnaire de configuration. Elle se r\u233?unit \
u224? dates fixes, ou en cas de besoin. Ses pr\u233?rogatives sont : \u8226? la
revue les demandes de changement ; \u8226? l'analyse d'impact (d\u233?l\u233?gu\
u233?e \u224? un d\u233?veloppeur ou expert) ; \u8226? la priorisation des demandes
; \u8226? la d\u233?cision de faire, de ne pas faire, ou de reporter le changement,
en fonction des impacts sur les co\u251?ts et les d\u233?lais ; \u8226? le suivi de
la mise en \u339?uvre du changement ; \u8226? en cas de difficult\u233?, l'escalade
du probl\u232?me au plus haut niveau de d\u233?cision. La r\u233?union de la
commission La gestion des changements sur les exigences est un processus rigoureux,
illustr\u233? par la figure 18-1. *. <^D\u233?dsloo^> 1 ' PIA\u187?. .\u171?ut îor
OK-^ ^ \'5cJf\'5c r^ Ordre de modification * Modification \'5c <^pprobatia\u239?>\
u8212? Figure 18-1 : Le processus de gestion des changements (ED\par\pard\plain\
hyphpar} {
ie 3 - Faire vivre les exigences Chaque demande de changement est enregistr\u233?e,
puis examin\u233?e par la commission de contr\u244?le des changements qui, en
fonction de la nature, de l'urgence et de l'importance du changement \u224?
apporter, la transmettra \u224? un expert (concepteur, d\u233?veloppeur, souvent
plusieurs personnes) qui va analyser l'impact de la modification. Suite \u224?
cette analyse, la commission de contr\u244?le des changements peut, soit rejeter la
demande, soit d\u233?cider de demander une ou plusieurs modifications. Cette
modification peut \u234?tre planifi\u233?e pour la version en cours de d\u233?
veloppement, ou pour une version ult\u233?rieure. Lorsque toutes les modifications
relatives \u224? une demande de changement ont \u233?t\u233? effectu\u233?es et
approuv\u233?es, la demande est close. L'analyse d'impact L'analyse d'impact peut \
u234?tre effectu\u233?e par un ou plusieurs experts (assistant ma\u238?trise
d'ouvrage, d\u233?veloppeur, testeur), mais elle est sous la responsabilit\u233?
d'une seule personne, nomm\u233?ment d\u233?sign\u233?e. Elle se cona\u233?tise par
une fiche (le tableau 18-1 est un exemple de fiche d'analyse d'impact). Les
attributs des exigences Afin de pouvoir \u234?tre g\u233?r\u233?e, chaque exigence
doit comporter un certain nombre d'attributs : \u8226? date de cr\u233?ation ; \
u8226? num\u233?ro de version ; \u8226? demandeur (partie prenante \u224? l'origine
de la demande) ; \u8226? auteur (personne qui a formalis\u233? la demande) ; \
u8226? son statut (provisoire, mise en \u339?uvre, supprim\u233?e, ajourn\u233?e) ;
\u8226? priorit\u233? ; \u8226? degr\u233? de stabilit\u233? ; \u8226? version du
logiciel impact\u233? par le changement ; \u8226? et composant du logiciel o\u249?
l'exigence est mise en \u339?uvre. Pour g\u233?rer tous ces attributs avec rigueur,
mais sans surcharge excessive de travail, les outils de gestion des exigences
deviennent vite indispensables. \u338?)\par\pard\plain\hyphpar} {
Chapitre 18 - La gestion des exigences Tabfeau 18-1 - Un nod\u232?fe d\u171? fidw
d'analyse d'impact Rapport d'analyse d'impact Num\u233?ro de demande de changement
Intitul\u233? de la demande Description pr\u233?cise de l'exigence Pris en charge
par : Le: Risques encourus si le changement est mis en \u339?uvre Risques encourus
si le changement n'est pas mis en \u339?uvre Estimation du co\u251?t du changement
(jours* hommes) Estimation de l'effort perdu (co\u251?t de la suppression d'une
fonction d\u233?j\u224? existante + co\u251?t d'un d\u233?veloppement qui sera
abandonn\u233?) Impact sur le planning global du projet Impact du changement sur
les charges totales Impact sur la qualit\u233? finale des livrables (performances,
maintenabilit\u233?... ) Autres exigences impact\u233?es T\u226?ches affect\u233?es
si le changement est mis en \u339?uvre Probl\u232?mes d'int\u233?gration estim\
u233?s Liste des documents qui seront touch\u233?s par une modification Liste des
modules de code qui seront touch\u233?s par une modification Liste de tous les
autres \u233?l\u233?ments qui seront touch\u233?s par une modification L'\u233?
volution des demandes de changement La figure 18-2 pr\u233?sente le diagramme d'\
u233?tats des demandes de changement et d'ordres de modification. fliTI\par\pard\
plain\hyphpar} {
ie 3 - Faire vivre les exigences MOA ? Demande enregistr\u233?e Z\u239?Z' Demande \
u233?valu\u233?e nz D\u233?cision prise f Changements effectu\u233?s \u239? Demande
dose \u239? MOE 1 Modification demand\u233?e \u239? ModBcattoo effectu\u233?e \
u239? Modification approuv\u233?e Figure 18-2 : Diagramme d'\u233?tat des demandes
de changement Une demande de changement pourra donner lieu \u224? plusieurs ordres
de modification (en effet, une demande peut impacter plusieurs composants du
logiciel et faire appel \u224? des expertises diverses). Toute demande de
changement va passer par des \u233?tats successifs : \u8226? propos\u233?e :
enregistr\u233?e, soit sur une fiche pr\u233?vue \u224? cet effet, soit au moyen
d'un outil de gestion des changements ou d'un outil de gestion des exigences ; \
u8226? approuv\u233?e par la commission de contr\u244?le des changements, elle a
donn\u233? un ou plusieurs ordres de modification ; SB\par\pard\plain\hyphpar} {
Chapitre 18 - La gestion des exigences \u8226? modifi\u233?e : les modifications
correspondant \u224? la demande ont \u233?t\u233? prises en compte ; \u8226? v\
u233?rifi\u233?e : les tests correspondant \u224? la demande de changement ont \
u233?t\u233? effectu\u233?s ; \u8226? supprim\u233?e ou rejet\u233?e : la demande
peut avoir \u233?t\u233? retir\u233?e par le demandeur ou rejet\u233?e (avec
justification) par la commission. Une discipline n\u233?cessaire et rentable Le
processus de gestion des changements des exigences que nous venons de d\u233?crire
est complexe et demande de la rigueur et de la discipline : proc\u233?dures,
commission, fiches \u224? remplir, analyses d'impact, suivi et tra- \u231?abilit\
u233?. Ces op\u233?rations ne sont pas si consommatrices de temps que l'on pourrait
penser. Et contrairement \u224? ce que l'on pense souvent, elles ne sont pas un
frein \u224? la cr\u233?ativit\u233? des d\u233?veloppeurs, elles ne servent qu'\
u224? canaliser cette cr\u233?ativit\u233?. Mettre en place cette \u171?
bureaucratie de projet \u187? n\u233?cessite un changement culturel. La mise en
place et l'institutionnalisation d'un tel processus peuvent prendre plusieurs mois.
H faudra surtout \u233?viter de s'embarquer dans des processus \u171? usines \u224?
gaz \u187?. disproportionn\u233?s \u224? la taille des projets et au type de
produit d\u233?velopp\u233?. En revanche, cette discipline, m\u234?me l\u233?g\
u232?re, devra \u234?tre incontournable. Cette discipline permet de pr\u233?server
une grande partie de l'effort consenti en amont, en phase de d\u233?veloppement des
exigences. La coh\u233?rence des exigences, et donc du produit livr\u233?, est \
u224? ce prix. Remarquons que cet effort de gestion sera de toute fa\u231?on n\
u233?cessaire aux autres activit\u233?s de d\u233?veloppement, en particulier : \
u8226? \u233?valuation pr\u233?cise des charges ; \u8226? gestion optimale des
ressources (d\u233?veloppeurs, testeurs) ; \u8226? alignement entre produit, sp\
u233?cification et documentation. \u338?)\par\pard\plain\hyphpar} {
Chapitre 19 Les outils \u192? partir d'une certaine complexit\u233?, le besoin de
mettre en \u339?uvre des outils de d\u233?finition ou de gestion des exigences se
fait sentir. Utilis\u233?s \u224? bon escient par des personnes comp\u233?tentes,
ils vont contribuer efficacement au processus. Mais attention, il y a aussi de
fausses raisons de les utiliser et des pi\u232?ges \u224? \u233?viter. Check-list :
votre projet en a-t-il besoin ? Comme nous l'avons vu. pour g\u233?rer les
exigences et leurs \u233?volutions, il est n\u233?cessaire de tenir \u224? jour un
certain nombre d'attributs pour chacune d'elles. Le besoin est fonction de
l'importance du projet, c'est-\u224?-dire du p\u233?rim\u232?tre fonctionnel, de la
taille des \u233?quipes et des besoins de tra\u231?abilit\u233? exig\u233?s. Sur
un projet d'importance, la gestion d'informations telles que la date de cr\u233?
ation ou de modification d'une exigence et ses liens de tra\u231?abilit\u233?
deviennent un vrai casse-t\u234?te. Il est difficile, voire impossible, de g\u233?
rer toutes ces informations \u224? la main. L'utilit\u233? des outils de gestion
des exigences est fonction, entre autres : \u8226? du nombre d'exigences \u224?
traiter, qui d\u233?pend du p\u233?rim\u232?tre fonctionnel et du niveau de d\u233?
tail ; \u8226? du nombre d'attributs \u224? g\u233?rer pour chaque exigence, qui d\
u233?pend de la rigueur demand\u233?e au processus ; \u8226? du nombre de personnes
en charge de recueillir, analyser, sp\u233?cifier, modifier les exigences ; \u8226?
du temps d'historisation pr\u233?vu pour ces donn\u233?es, de la p\u233?rennit\
u233? dans le temps des exigences ; \u8226? du degr\u233? de r\u233?utilisation des
exigences d'un projet \u224? l'autre ; \u8226? de la volatilit\u233? des exigences
(n\u233?cessit\u233? de les modifier souvent) ;\par\pard\plain\hyphpar} {
Partie 3 - Gestion des exigences \u8226? du nombre de r\u232?gles de gestion dont
d\u233?pendent ces exigences ; \u8226? de la possibilit\u233? d'investir du temps \
u224? se former aux outils. Cette liste peut servir de check-list pour estimer
grossi\u232?rement (mais rapidement) le besoin d'outiller. Les bonnes raisons
d'utiliser les outils La premi\u232?re raison d'acqu\u233?rir un outil est li\u233?
e au processus de d\u233?finition et de gestion des exigences elles-m\u234?mes. Un
bon outil facilite l'application des bonnes pratiques de d\u233?veloppement
(utilisation d'un mod\u232?le, mise en forme du texte) et de gestion des exigences
(tra\u231?abilit\u233? des changements, gestion du cycle de vie des modifications).
La seconde raison d'utiliser les outils concerne la gestion des changements dans
leur ensemble. Dans un monde o\u249? tout va tr\u232?s vite et o\u249? les
changements sont constants, les exigences sont rarement stables. Cela est vrai
qu'il s'agisse des besoins (\u233?manant des clients) ou des contraintes (li\u233?
es aux technologies), et m\u234?me des r\u232?gles de gestion. Tout changement dans
les exigences aura des r\u233?percussions sur l'ensemble des autres activit\u233?
s : conception, r\u233?alisation, tests, maintenance. La troisi\u232?me raison est
la conformit\u233?. Les changements eux-m\u234?mes devront \u234?tre trac\u233?s.
En effet, de nos jours, les entreprises sont soumises \u224? des contr\u244?les de
plus en plus nombreux : audits, certifications (ISO ou autres), \u233?valuation des
pratiques professionnelles, accr\u233?ditations, normes et standards de conformit\
u233?, de tra\u231?abilit\u233?. de s\u233?curit\u233?... le logiciel lui-m\u234?me
n'\u233?chappe pas. bien s\u251?r. \u224? ces obligations : s\u233?curit\u233?,
interop\u233?rabilit\u233?, conformit\u233? \u224? des r\u232?gles de gestion de
toute sorte font partie du lot quotidien des analystes et d\u233?veloppeurs. On se
dit que bient\u244?t, la for\u234?t de la conformit\u233? va cacher l'arbre de la
fonctionnalit\u233?. \u219?uoi qu'il en soit, il faudra faire avec. Fonctions de
base et Fonctions avanc\u233?es Fonctions de r\u233?f\u233?rentiel Un outil de
gestion des exigences est avant tout un r\u233?f\u233?rentiel. Il permet de
stocker, et de retrouver facilement, l'ensemble des exigences, leurs attributs et
leurs liens de tra\u231?abilit\u233?. Il arrive avec un certain nombre de fonctions
de cr\u233?ation, de retrait, de modification, et de suppression des exigences ou
de leurs attributs. Il permet de contr\u244?ler l'acc\u232?s \u224? ces
informations, d'o\u249? son utilit\u233? pour le travail de groupe. SD\par\pard\
plain\hyphpar} {
Chapitre 19 - Les outils \u8226? Stockage. Les exigences sont stock\u233?es, g\
u233?n\u233?ralement dans une structure arborescente, sous une forme ind\u233?
pendante du document final de sp\u233?cifications (cahier des charges). Le r\u233?
f\u233?rentiel stocke, en plus des attributs, l'\u233?tat de chaque exigence
(propos\u233?e, en cours, valid\u233?e, etc.). \u8226? Filtrage. Il est possible
d'utiliser des filtres pour visualiser une partie seulement de l'arborescence. \
u8226? Tra\u231?abilit\u233? des acc\u232?s. L'outil trace tous les acc\u232?s \
u224? une exigence ou \u224? un attribut. \u8226? Gestion des liens entre
exigences, et possibilit\u233? de suivre les liens de tra\u231?abilit\u233?
horizontale ou verticale. Tra\u231?abilit\u233? horizontale et verticale Les
exigences sont reli\u233?es entre elles de plusieurs fa\u231?ons. On d\u233?nombre
au moins deux types de tra\u231?abilit\u233? : \u8226? La tra\u231?abilit\u233?
verticale lie les exigences et leur \u233?volution au long du cycle de vie du
logiciel, depuis les exigences de haut niveau jusqu'aux composants du logiciel. \
u8226? La tra\u231?abilit\u233? horizontale lie les versions successives d'une m\
u234?me exigence. i > Objectif X \u239? Exigence m\u233?tier Y \u239? Exigence
utilisateur Z (VO) \u239? Exigence utilisateur Z (V1) Exigence utilisateur Z <V2)
Exigence utilisateur Z <V3) Exigence \u233?l\u233?mentaire VO Tra\u231?abilit\u233?
horizontale Figure 19-1 : Tra\u231?abilit\u233? horizontale et verticale Ces deux
types de lien de tra\u231?abilit\u233? sont indispensables si l'on veut contr\u244?
ler et g\u233?rer \u224? long terme les demandes de changements. Or, au-del\u224?
d'une certaine taille de projet, le maintien de ces liens de tra\u231?abilit\u233?
est quasiment impossible sans la mise en \u339?uvre d'outils ad\u233?quats. QJB\
Partie 3 - Gestion des exigences Gestion des attributs Seul un outil permettra de
renseigner facilement tous ces attributs, dont certains (date, auteur, etc.) de
mani\u232?re automatique. Avec un document texte, cet exercice est un v\u233?
ritable casse-t\u234?te. L'utilisation d'un tableur est une solution de
contournement. mais ne permet pas de stocker (ou tr\u232?s difficilement) les
exigences qui se pr\u233?sentent sous forme de tableau ou de graphique. La plupart
des outils permettent \u224? un administrateur de param\u233?trer les attributs et
de cr\u233?er des types d'attributs diff\u233?rents en fonction du type d'exigence.
Tout utilisateur pourra visualiser les attributs de chaque exigence, et certains
utilisateurs pourront modifier des attributs en fonction de leur habilitation. Un
tr\u232?s grand iM\u239?mbre d'attributs peuvem \u234?tre quekjuesflrts : \u8226?
date de cr\u233?ation; \u171? version actuelle; \u8226? auteur (te r\u233?
dacteur) ; \u8226? responsable de la mise en \u339?uvre; \u8226? demandeur (pas n\
u233?cessairement utilisateur du produit) ; \u8226? b\u233?ii\u233?iKfc^\u233?n g\
u233?nfo^^ \u8226? version dVproduit o\u249? fexi^ \u8226? statiit (provisoire, en
cours d*\u233?tu^ \u8226? volatilit\u233? (exigence provisone ou p\u233?ienne) ; \
u8226? seufls de tol\u233?rant (pour les exigera \u8226? tra\u231?atrtit\u233?
horizontate et verticale. S'y ajoutent les attributs concernant la modification
apport\u233?e \u224? une exigence : date, auteur/oînarrfeui;justi6(ation,ete.
Travail d'\u233?quipe Ces fonctions favorisent un travail d'\u233?quipe suret
efficace, qui est p\u233?nible et risqu\u233? (voire impossible) lorsque l'on
partage un document sous traitement de texte. \u8226? Tra\u231?ablllt\u233?.
L'outil garde la trace de toutes les modifications faites sur une exigence ou un
attribut, ainsi que de la date et l'auteur de chaque modification. SD\par\pard\
plain\hyphpar} {
Chapitre 19 - Les outils \u8226? Contr\u244?le d'acc\u232?s. L'outil g\u232?re les
acc\u232?s aux exigences et aux diff\u233?rents attributs, en fonction de droits
d'acc\u232?s param\u233?trables. \u8226? S\u233?curisation des modifications.
L'outil bloque l'acc\u232?s en \u233?criture \u224? des exigences en cours de
modification, n'autorisant que les acc\u232?s en lecture. \u8226? Communication de
projet L'outil envoie un message aux diff\u233?rents utilisateurs lorsqu'une
exigence ou un ensemble d'exigences viennent d'\u234?tre modifi\u233?es. Il garde
la trace d'une discussion concernant une exigence particuli\u232?re. \u8226?
Gestion de projet L'outil conserve l'\u233?tat de chaque exigence (en cours, \u224?
valider, \u224? modifier...). Cela facilite le suivi. Gestion des versions et des
changements Ces fonctions rendent ce type d'outil proche des outils de gestion des
versions et de la configuration (ils peuvent d'ailleurs s'interfacer avec certains
d'entre eux). \u8226? Versionnement L'outil garde la trace des changements faits
sur une exigence et incr\u233?mente son num\u233?ro de version. \u8226? Mise en r\
u233?f\u233?rence (basellning). L'outil permet de figer une configuration de r\
u233?f\u233?rence (baseline) et de cr\u233?er de nouvelles versions d'une sp\u233?
cification d'exigences en s'appuyant sur une configuration de r\u233?f\u233?rence
existante. \u8226? Automatisation du processus. Certains outils facilitent le
processus de gestion des changements d'exigences en liaison avec la gestion des
versions des exigences. R\u233?daction et documentation On constate donc qu'un
outil de gestion des exigences est beaucoup plus int\u233?ressant qu'un traitement
de texte. Il n'emp\u234?che qu'une large partie du travail consiste \u224? r\u233?
diger et que le livrable final est souvent un texte avec toutes les contraintes de
r\u233?daction et de typographie en vigueur. L'outil doit donc \u234?tre capable de
faciliter la r\u233?daction et la pr\u233?sentation documentaire. Entre autres
fonctions, on trouve les suivantes : \u8226? Respect du mod\u232?le de sp\u233?
cifications. Il est possible de param\u233?trer la structure des exigences selon un
mod\u232?le pr\u233?d\u233?fini. On force ainsi le respect d'un mod\u232?le de
cahier des charges. \u8226? Glossaire. L'outil permet d'alimenter et maintenir un
glossaire des termes, et chercher les occurrences d'un terme du glossaire. \u8226?
Respect des r\u232?gles d'\u233?criture. Outre le classique correcteur
orthographique, l'outil poss\u232?de des fonctions de recherche contextuelle de
termes flous, de phrases ambigu\u235?s, de mots inconnus, de certaines incoh\u233?
rences. \u338?)\par\pard\plain\hyphpar} {
Partie 3 - Gestion des exigences \u8226? G\u233?n\u233?ration automatique de
documents. \u192? partir d'un mod\u232?le de document pr\u233?d\u233?fini, du
contenu du r\u233?f\u233?rentiel et d'un ensemble de filtres, l'outil g\u233?n\
u232?re automatiquement le cahier des charges ou tout autre document de sp\u233?
cifications. \u8226? Int\u233?gration de graphiques. L'outil permet de cr\u233?er
ou d'int\u233?grer des exigences sous forme graphique : sc\u233?narios, mod\u232?
les de donn\u233?es, etc. \u8226? Import de documents. L'outil permet d'int\u233?
grer des exigences contenues dans un cahier des charges dans le r\u233?f\u233?
rentiel, en fonction de r\u232?gles param\u233?trables -. par exemple, niveau de
titre ou style de paragraphe correspondant \u224? un niveau ou type d'exigence.
Attention aux mirages On le voit, les avantages de ces outils sont certains.
Prenons garde, n\u233?anmoins, \u224? ne pas tomber dans le pi\u232?ge des
outils. \u192? lui seul, aucun outil ne se substituera \u224? une bonne
organisation et \u224? une discipline rigoureuse. Si les exigences sont mal g\u233?
r\u233?es, un outil n'y fera rien. Il pourra m\u234?me avoir un effet contre-
productif. Citons quelques-unes des fausses bonnes raisons d'acqu\u233?rir un outil
: \u8226? \u171? Il g\u232?re mieux les sp\u233?cifications et la documentation des
exigences \u187?. C'est faux. La r\u233?daction du cahier des charges se fait par
des personnes comp\u233?tentes. Un traitement de texte pourra les aider, bien mieux
qu'un outil de gestion des exigences. \u8226? \u171? Il g\u232?re mieux les
changements des sp\u233?cifications et de la documentation \u187?. C'est vrai, mais
partiellement. La gestion des changements est une affaire de processus et de
personnes. En termes d'outils, un tableur pourra faire l'affaire. Ce n'est que sur
la combinatoire gestion des changements et gestion de la documentation qu'un outil
apportera sa pleine puissance, car il permet de lier automatiquement les deux. \
u8226? \u171? Il facilite le travail de v\u233?rification et de validation \u187?.
Ce n'est que tr\u232?s partiellement vrai. Effectivement, certains outils disposent
de fonctions de recherche en plein texte et de d\u233?tection de phrases douteuses,
mais le gros du travail est intellectuel et ne peut \u234?tre pris en charge par
quelque outil que ce soit. Quand et comment choisir un outil ? Inutile de choisir
un outil si l'on n'a pas, d\u233?j\u224?, un mod\u232?le de document \u224? peu pr\
u232?s stable et un processus rigoureux de d\u233?finition et de gestion des
exigences. Comme nous l'avons dit plus haut, un bon outil ne peut pallier QQ\par\
Chapitre 19 - Les outils un processus d\u233?faillant, il ne peut qu'empirer la
situation. De plus, il vaut mieux choisir un outil en fonction du processus que
l'inverse. Un outil de gestion des exigences doit \u234?tre s\u233?lectionn\u233?
comme tout logiciel : \u8226? en analysant l'existant et le contexte de
l'organisation ; \u8226? en pr\u233?cisant les objectifs (par exemple, am\u233?
liorer la productivit\u233?, s\u233?curiser les acc\u232?s, automatiser la
production de documents, r\u233?utiliser les exigences) ; \u8226? en recueillant
les besoins, en les analysant, en les sp\u233?cifiant dans un cahier des
charges ; \u8226? en pr\u233?parant une grille de s\u233?lection efficace (on
s'inspirera des fonctions d\u233?crites plus haut) ; \u8226? en \u233?tant
rigoureux jusqu'au bout. Pour un analyste des exigences, ces actions semblent aller
de soi, mais l'exp\u233?rience montre qu'il est plus difficile d'\u234?tre
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 \u224? la fin du mois). Une fois l'outil s\u233?lectionn\u233?, acquis,
install\u233?, il faudra le traiter comme tout autre logiciel. En particulier, il
faudra se former \u224? l'outil, \u234?tre conseill\u233? par l'\u233?diteur
(attention : la conduite du changement co\u251?te g\u233?n\u233?ralement beaucoup
plus cher que l'outil lui-m\u234?me), et travailler sur le param\u233?trage. D'une
mani\u232?re g\u233?n\u233?rale, il faut \u233?viter de se pr\u233?cipiter, et
avoir un processus bien r\u244?d\u233? avant de \u171? l'embarquer \u187? dans
l'outil. Ce que l'on ne peut pas accomplir avec un papier et un crayon, inutile de
tenter de le faire avec l'outil, car sa complexit\u233? peut perturber. A
contrario, si l'on s'est \u171? pris la t\u234?te \u187? \u224? de nombreuses
reprises, avec un traitement de texte, l'arriv\u233?e de l'outil sera v\u233?cue
comme un soulagement et ses b\u233?n\u233?fices vite appr\u233?ci\u233?s. GD\par\
Chapitre 20 Au-del\u224? des exigences Le travail de l'analyste consiste \u224? sp\
u233?cifier les exigences, mais aussi \u224? \u233?valuer les solutions propos\
u233?es, et leur ad\u233?quation aux exigences sp\u233?cifi\u233?es. Pour y
parvenir, nous pouvons utiliser diverses techniques, en compl\u233?ment ou \u224?
la place de l'\u233?laboration d'un cahier des charges. Nous sommes ici aux confins
de la phase d'exigences, et p\u233?n\u233?trons parfois dans la zone floue entre
exigences et conception. Etude de choix Pour une \u233?tude comparative ou une \
u233?tude de choix, la d\u233?marche parfois appel\u233?e \u171? en entonnoir \
u187? (figure 20-1 ) est la plus classique : elle permet d'aller du g\u233?n\u233?
ral au particulier et du global au d\u233?taill\u233?. Les \u233?tapes Les \u233?
tapes de la d\u233?marche sont les suivantes : \u8226? Screenlng. Une dizaine de
fournisseurs de logiciels, dont les produits correspondent, dans les grandes
lignes, aux besoins du client, sont identifi\u233?s, et leurs produits sont pass\
u233?s en revue. On peut inclure dans cet ensemble des logiciels qui ne pr\u233?
sentent pas toutes les caract\u233?ristiques requises, mais dont l'examen peut
apporter des informations int\u233?ressantes, ou r\u233?v\u233?ler de nouveaux
crit\u232?res de choix. \u8226? Pr\u233?s\u233?lection. En collaboration avec le
client, nous examinons les cinq progiciels qui correspondent au mieux aux crit\
u232?res d\u233?finis par le client ; parall\u232?lement, la liste des crit\u232?
res est affin\u233?e. On d\u233?termine les crit\u232?res obligatoires et les crit\
u232?res \u233?liminatoires. \u8226? Short-list. Toujours en collaboration avec le
client, une liste restreinte (g\u233?n\u233?ralement trois logiciels) est fix\u233?
e ; ces logiciels sont examin\u233?s de\par\pard\plain\hyphpar} {
Partie 3 - Gestion des exigences pr\u232?s ; parall\u232?lement, et ind\u233?
pendamment, les crit\u232?res sont pond\u233?r\u233?s lors d'une r\u233?union avec
les responsables, chez le client. Approfondissement Les trois logiciels \u171?
short-list\u233?s \u187? sont examin\u233?s de pr\u232?s. Une note est attribu\
u233?e \u224? chaque crit\u232?re. On aboutit, selon la demande du client, soit \
u224? la s\u233?lection d'un produit unique, soit \u224? un tableau comparatif
permettant une prise de d\u233?cision efficace. Scraening Pr\u233?s\u233?lection
Shortlist Approfondissement Figure 201 : La m\u233?thode de l'entonnoir Etude
comparative complexe Il y a plusieurs fa\u231?ons de traiter les r\u233?ponses \
u224? un cahier des charges. On peut proc\u233?der \u224? une analyse comparative
tenant compte de contraintes multiples, non seulement fonctionnelles, techniques et
organisationnelles, mais \u233?galement strat\u233?giques ou politiques. Une fois
l'\u233?tude faite, le challenge est de donner \u224? un d\u233?cideur de haut
niveau, non sp\u233?cialiste, une vision tr\u232?s claire des potentialit\u233?s
des diff\u233?rentes solutions en pr\u233?sence, et ce. souvent en moins de cinq
minutes. L'\u233?tude se fera comme pr\u233?c\u233?demment, et inclura des \u233?l\
u233?ments suppl\u233?mentaires d'expertise sur des points particuliers (int\u233?
grabilit\u233?, d\u233?ploiement, conduite du changement, etc.). La pr\u233?
sentation des r\u233?sultats devra \u234?tre < percutante \u187?. Pour cela, on
devra fournir aux d\u233?cideurs des tableaux et des sch\u233?mas extr\u234?mement
simples, contenant le minimum d'informations. L'information plus d\u233?taill\u233?
e sera jointe si n\u233?cessaire en annexe. Tableau de B.O.R.D. Le tableau de
B.O.R.D. (B\u233?n\u233?fices, Opportunit\u233?s. Risques. Dangers) est une
variante du tableau SWOT (Strengths. Weaknesses. Opportumtks, Threats, GD\par\pard\
plain\hyphpar} {
Chapitre 20 - Au-del\u224? des exigences c'est-\u224?-dire forces, faiblesses,
opportunit\u233?s et menaces) en plus contrast\u233?. L'id\u233?e est de pr\u233?
senter un tableau tr\u232?s synth\u233?tique, \u224? l'usage des d\u233?cideurs. Ce
tableau indique, pour chaque solution pr\u233?sent\u233?e, les : \u8226? B\u233?n\
u233?fices : avantages procur\u233?s de fa\u231?on certaine ou tr\u232?s probable
par l'acquisition du produit, \u224? court ou moyen terme, sans investissement, ou
avec un investissement faible. \u8226? Opportunit\u233?s : avantages apport\u233?s
par le produit, au prix d'un effort financier ou organisationnel raisonnable. \
u8226? Risques : difficult\u233?s pouvant surgir, avec une probabilit\u233? faible
ou moyenne, suite \u224? la mise en place du produit, et pouvant \u234?tre surmont\
u233?es avec un investissement financier ou organisationnel raisonnable. \u8226?
Dangers : difficult\u233?s lourdes de cons\u233?quences, ayant une forte
probabilit\u233? de surgir suite \u224? la mise en place du produit, et ne
pouvant \u234?tre jugul\u233?es que par un effort financier ou organisationnel
important. Dans l'exemple1 donn\u233? au tableau 20-1. la solution Y a \u233?t\
u233? choisie, car elle apporte un v\u233?ritable avantage concurrentiel sans
risques insurmontables. La solution X semble moyennement bien plac\u233?e, la
solution Z risqu\u233?e. Cependant, le choix revient au d\u233?cideur, qui aurait
pu en d\u233?cider autrement. Tableau 20-1 - Tabteau d\u171? B.O.R.D B 0 R D
Solution X Possibilit\u233? pour le client de d\u233?velopper sa propre solution.
Manque d'exp\u233?rience du fournisseur sur des projets d'envergure similaire.
Solution Y Exp\u233?rience dans au moins un projet d'envergure et de nature
similaires. Excellente capacit\u233? de conseil et de gestion de projet. Solution
ouverte, en particulier extensible (workfiow). Possibilit\u233? de tirer profit de
l'exp\u233?rience chez un autre client Produit complexe, exigeant une bonne
formation et un bon suivi de projet Solution Z Possibilit\u233? de tirer profit de
l'exp\u233?rience de l'entreprise \u171? W \u187?. Solution ferm\u233?e,
difficilement extensible ; n\u233?gociations techniques difficiles. Solution tr\
u232?s contraignante pour l'utilisateur final 1. L'exemple pr\u233?sent\u233? id
correspond \u224? un cas r\u233?d (outil de workfiow pour le syst\u232?me
d'information administratif dans l'industrie automobile). Q0\par\pard\plain\
hyphpar} {
Partie 3 - Gestion des exigences Graphique de synth\u232?se Le graphique de la
figure 20-2 fait la synth\u232?se des \u233?l\u233?ments mentionn\u233?s dans le
texte du rapport et les tableaux, et permet de comparer les diff\u233?rentes
solutions propos\u233?es en mettant en balance les b\u233?n\u233?fices apport\u233?
s et les difficult\u233?s pressenties. Il permet de comparer : \u8226? les b\u233?
n\u233?fices, qui se d\u233?composent en : - r\u233?ponse de l'offre aux exigences
du cahier des charges. - potentiel d'\u233?volution de la solution propos\u233?e. -
capacit\u233? de service du fournisseur : conseil, support, et assistance technique
; \u8226? et les co\u251?ts pour le client, qui se d\u233?composent en : - prix
d'achat et co\u251?t de la mise en \u339?uvre. - co\u251?ts de la phase transitoire
(baisse initiale de la productivit\u233? du personnel), - conduite du changement
(formation, information et accompagnement). " Solution X Solution Y Solution Z |
Capacit\u233? de service S Potentiel d'\u233?volution R\u233?ponse aux exigences I
Achat et mise en \u339?uvre Q Phase transloire | Conduite du changement Figure
202 : Graphique comparatif de synth\u232?se co\u251?ts/b\u233?n\u233?fices \u201?
tude d'opportunit\u233? complexe Un exemple d'\u233?tude Une \u233?tude
d'opportunit\u233? peut \u234?tre tr\u232?s complexe et faire \u224? appel \u224?
des comp\u233?tences et des savoir-faire tr\u232?s divers. Dans l'exemple qui suit,
nous QQ\par\pard\plain\hyphpar} {
Chapitre 20 - Au-del\u224? des exigences allons d\u233?crire une \u233?tude qu'un
cabinet de conseil a effectu\u233?e pour une grande ville fran\u231?aise. Il
s'agissait d'\u233?tudier l'opportunit\u233? de remplacer toute la bureautique
existante par du logiciel libre. L'\u233?tude a mobilis\u233? deux consultants
seniors (un consultant ma\u238?trise d'ouvrage et un expert technique) pendant
trois mois, avec une charge totale de 50 jours- hommes. \u8226? \u201?tape 1 :
lancement. Il s'agit ici de d\u233?finir le p\u233?rim\u232?tre de la mission,
d'identifier les acteurs (tr\u232?s nombreux), et de figer le plan d\u233?taill\
u233? des livrables \u8226? \u201?tape 2 : \u233?tude de la strat\u233?gie d'\u233?
volution. L'objectif est de d\u233?finir l'ordre et la strat\u233?gie de mise en
place d'un projet de passage au logiciel libre dans l'administration de la ville. \
u8226? \u201?tape 3 : \u233?tat des lieux fonctionnel et technique sur l'existant.
Elle consiste en une consultation de l'Administration (France) au moyen
d'interviews des responsables informatiques (d\u233?veloppement, maintenance et
exploitation). \u8226? \u201?tape 4 : \u233?tude de l'exp\u233?rience dans une
autre ville europ\u233?enne. L'objectif de cette \u233?tape est d'avoir un retour
d'exp\u233?rience dans une administration analogue, dans un autre pays europ\u233?
en, et de conna\u238?tre les avantages, inconv\u233?nients, co\u251?ts,
contraintes, difficult\u233?s rencontr\u233?es suite au passage au logiciel
libre. \u8226? \u201?tape 5 : \u233?tude des besoins des d\u233?cideurs et
utilisateurs. Ce n'est qu'\u224? cette \u233?tape qu'intervient l'\u233?tude des
besoins, \u224? tr\u232?s grosses mailles. L'objectif n'est pas de d\u233?finir des
besoins fonctionnels, mais d'avoir un avis des d\u233?cideurs et futurs
utilisateurs. Une majorit\u233? d'entretiens a \u233?t\u233? faite par t\u233?l\
u233?phone. \u8226? \u201?tape 6 : \u233?tude des produits disponibles et de leur
utilisation. L'objectif est ici de conna\u238?tre les contraintes techniques inh\
u233?rentes au passage au logiciel libre, les avantages, inconv\u233?nients, le
potentiel de ces outils. L'\u233?tape a consist\u233? \u224? examiner les diff\
u233?rents types de produits logiciels libres sur le march\u233? (r\u233?seaux,
syst\u232?mes d'exploitation, applicatifs...). On a essentiellement examin\u233?
l'utilisation qui en \u233?tait faite. Cela a n\u233?cessit\u233? de rencontrer \
u224? la fois les utilisateurs et les industriels. \u192? cette \u233?tape, les
aspects techniques \u233?taient secondaires. \u8226? \u201?tape 7 : \u233?tude des
contraintes techniques. On a examin\u233? les contraintes techniques sur le mat\
u233?riel et le logiciel, et analys\u233? l'impact li\u233? au renouvellement du
parc informatique (mises \u224? niveau, migration ou portage des applications,
impacts sur la s\u233?curit\u233?). QO\par\pard\plain\hyphpar} {
Partie 3 - Gestion des exigences L'analyse a permis de mettre en regard les
contraintes et les produits disponibles. \u8226? \u201?tape 8 : \u233?tude des
aspects financiers. On a examin\u233? les aspects financiers sur plusieurs crit\
u232?res : utilisation, mise en \u339?uvre, conversion de fichiers, co\u251?ts
des \u233?mulateurs (pour les applications qui n'ont pas d'\u233?quivalent dans le
monde du logiciel libre), mise en \u339?uvre de la s\u233?curit\u233?, migration
des applicatifs et formation. \u8226? \u201?tape 9 : synth\u232?se tenant compte
des aspects techniques, organisationnels et financiers. Cette synth\u232?se
comprend : les sc\u233?narios cibles de passage, l'analyse technique, l'analyse \
u233?conomique, l'analyse des risques. Elle est formalis\u233?e par un tableau de
synth\u232?se pour l'estimation du co\u251?t de la migration, et un tableau de bord
avantages et inconv\u233?nients pour chaque sc\u233?nario. Une mission \u224? la
limite Une mission de conseil de ce type est \u224? la fronti\u232?re entre la d\
u233?finition des besoins et une \u233?tude pr\u233?alable \u224? un sch\u233?ma
directeur. Dans cette mission, l'\u233?tude des besoins proprement dite, au sens de
l'ing\u233?nierie des exigences, n'occupe qu'une place modeste. L'\u233?tude a \
u233?t\u233? men\u233?e par un consultant senior et un expert technique. Les tr\
u232?s forts enjeux politiques ont constitu\u233? une difficult\u233? suppl\u233?
mentaire. Cependant, si le consultant senior avait eu le r\u233?flexe de mener une
analyse formalis\u233?e des parties prenantes, certains \u233?cueils auraient
probablement \u233?t\u233? \u233?vit\u233?s. Une autre difficult\u233? provient de
la dichotomie op\u233?r\u233?e entre les aspects techniques et les autres, accentu\
u233?e par le fait que les consultants \u233?taient de profils tr\u232?s diff\u233?
rents. Tout au long de cet ouvrage, nous avons pu voir que les exigences
pouvaient \u234?tre structur\u233?es en \u171? couches \u187?. depuis les exigences
strat\u233?giques (en l'occurrence, politiques) jusqu'aux exigences fonctionnelles
et techniques. Les consultants ont examin\u233? ces deux aspects extr\u234?mes,
sans consacrer le temps n\u233?cessaire \u224? l'examen des exigences de niveaux
interm\u233?diaires (exigences m\u233?tier et exigences utilisateurs). Etude d'int\
u233?grabilit\u233? et design Tout au long de cet ouvrage, nous avons r\u233?p\
u233?t\u233? cette recommandation \u224? la mani\u232?re d'un dogme : il faut sp\
u233?cifier des besoins, et non une solution. Cela reste toujours vrai lorsque l'on
\u233?labore un cahier des charges. QQ\par\pard\plain\hyphpar} {
Chapitre 20 - Au-del\u224? des exigences Ce n'est qu'\u224? la phase suivante, la
phase de conception, que l'on sp\u233?cifie la solution. Or. la fronti\u232?re
entre d\u233?finition des besoins et conception de la solution n'est pas toujours \
u233?tanche. Prenons un cas fr\u233?quent : nous avons \u233?labor\u233? un cahier
des charges pour une application de gestion complexe. Plus pr\u233?cis\u233?ment,
nous avons d\u233?fini les exigences pour un syst\u232?me d'information (sans m\
u234?me parler d'application, puisque nous cherchons une solution). Ce cahier des
charges, nous l'avons \u233?labor\u233? dans les r\u232?gles de l'art, dans le plus
strict respect de la m\u233?thodologie. Puis nous avons \u233?labor\u233? une
grille de d\u233?pouillement qui reprend point par point chaque exigence.
Cependant, les offres des fournisseurs ressemblent \u224? ce que l'on peut voir
dans la figure 20-3 : malgr\u233? leurs qualit\u233?s respectives, aucun produit ne
correspond parfaitement \u224? la demande. Cependant, le besoin peut \u234?tre
couvert par une int\u233?gration entre deux des logiciels, ou les trois logiciels.
Grill* de d\u233?pouillemenj Exigence 1i Exigence 2- Exigence 3' Exigence 4\'5c
Exigence 5' Exigence 6> Exigence 7. Exigence 8 X Offre A /Exigence 1 /Exigence 2
/Exigence 3 \u9632?XFxigenced X Exigence 5 Exigence 6 X Exigence 8 Offre C
/Exigence' X Exigence 2 X Exigence 3 V / Exigence 4 X Exigence 5 / Exigence 6 X
Exigence 7 /Exigence 8 Offre B ./Exigence 1 X Exigence 2 X Exigence 3 ./ Exigence 4
X Exigence 5 X Exigence 6 ./Exigence 7 X Exigence 8 Figure 20-3 : Des exigences \
u224? l'architecture de la solution Nous venons de franchir la fronti\u232?re qui
s\u233?pare les exigences de la conception. Nous sommes face \u224? un probl\u232?
me de design, d'architecture du syst\u232?me d'information. Nous devons faire un
choix entre trois sc\u233?narios : \u8226? choisir un produit parmi les trois et
faire d\u233?velopper en sp\u233?cifique les fonctions manquantes ; \u8226? faire
d\u233?velopper une interface entre les deux produits ; \u8226? faire int\u233?grer
les trois produits. QE)\par\pard\plain\hyphpar} {
ie 3 - Gestion des exigences L'\u233?tude de l'int\u233?gration entre diff\u233?
rentes < briques \u187? du syst\u232?me d'information doit se faire non seulement
sur le plan technique, mais aussi sur le plan \u233?conomique, et aussi sur le plan
de l'ergonomie. Deux produits peuvent tr\u232?s bien communiquer entre eux sur le
plan technique et aboutir \u224? une catastrophe en ce qui concerne l'utilisabilit\
u233?. la fiabilit\u233?, et bien s\u251?r la maintenabilit\u233? de la solution.
Apr\u232?s \u233?tude, nous devrons reformuler notre demande vis-\u224?-vis d'un,
de deux ou de trois fournisseurs, et donc \u233?laborer un nouveau cahier des
charges. Et nous voil\u224? de nouveau pass\u233?s de l'autre c\u244?t\u233? de la
fronti\u232?re, \u224? nouveau dans la phase d'exigences. Voil\u224? pourquoi on
dit que la fronti\u232?re entre la phase d'exigences et la phase de conception est
souvent floue. (ED\par\pard\plain\hyphpar} {
Chapitre 21 NeuF conseils Nous avons d\u233?crit le processus, la d\u233?marche d'\
u233?laboration, les \u233?tapes, techniques et outils. Nous avons montr\u233?
pourquoi et comment le processus peut \u234?tre adapt\u233? aux diff\u233?rents
contextes, et pourquoi et comment il peut \u234?tre am\u233?lior\u233?. Voici
quelques conseils pour r\u233?ussir encore mieux, plus efficacement. 1. Ayez
toujours l'objectif en t\u234?te En principe, vous connaissez l'objectif de votre
client, et si ce n'est pas le cas. votre premi\u232?re t\u226?che consiste \u224?
le d\u233?couvrir et le d\u233?finir avec pr\u233?cision. Votre objectif est align\
u233? sur celui de votre client, mais il n'est pas identique \u224? celui du
client. Votre objectif \u224? vous, analyste des exigences, est de livrer \u224?
votre client, \u224? l'heure convenue avec lui, un cahier des charges \u233?labor\
u233? selon les r\u232?gles de l'art. Vous pouvez affiner cette formulation et la
mettre par \u233?crit. Il faudra la garder en t\u234?te et avancer. Vous devez
tenir le cap contre vents et mar\u233?es. Il est parfaitement normal que le client
lui-m\u234?me retarde le projet, change d'avis, en demande trop ou au contraire
n'exprime rien. Il est normal que les id\u233?es divergent d'un acteur \u224?
l'autre, que la motivation passe par des hauts et des bas, que l'analyste devienne
l'exutoire de tous les conflits. Pour Hier la m\u233?taphore de la navigation,
c'est lorsque le bateau tangue qu'il est utile de savoir clairement o\u249? l'on
va. Vous devez garder le cap malgr\u233? les d\u233?rives. Cette vision claire de
l'objectif vous permettra de planifier l'\u233?laboration du cahier des charges, et
guidera vos d\u233?cisions lors de vos interventions sur le terrain.\par\pard\
plain\hyphpar} {
Partie 3 - Gestion des exigences 2. Analysez et validez au plus t\u244?t Dans les
chapitres pr\u233?c\u233?dents, nous avons indiqu\u233? plusieurs raisons
d'analyser et de valider au plus t\u244?t, et nous avons donn\u233? quelques
techniques pour y parvenir. Mais il y a aussi des raisons psychologiques, qui sont
compl\u233?mentaires aux raisons techniques. L'analyse au plus t\u244?t apporte une
visibilit\u233? qui permet de mieux ma\u238?triser la situation et encourage les
diff\u233?rents participants \u224? travailler ensemble. La validation au plus t\
u244?t donne un feedback rapide et une vision claire qui encouragent \u224? aller
de l'avant. 3. Lancez-vous un d\u233?fi et donnez-vous les moyens de le r\u233?
ussir La d\u233?finition des besoins ne devrait jamais \u234?tre une routine, car
deux clients n'ont jamais le m\u234?me objectif, les m\u234?mes besoins, le m\u234?
me pass\u233?, les m\u234?mes acteurs. \u201?laborer un cahier des charges est un
travail difficile, m\u234?me pour les plus dou\u233?s et les plus exp\u233?riment\
u233?s d'entre nous. Certains consultants font du travail \u224? la cha\u238?ne, en
br\u251?lant les \u233?tapes. Ils \u171? vendent \u187? \u224? leur client un
cahier des charges pr\u233?fabriqu\u233?, en sp\u233?cifiant de mani\u232?re
approximative des exigences valid\u233?es en vitesse par une minorit\u233?
d'acteurs. Malgr\u233? les apparences, la valeur ajout\u233?e d'un tel document est
faible. La satisfaction professionnelle, elle aussi, est faible. D'autres baissent
les bras devant les difficult\u233?s. Ils pensaient que la t\u226?che serait
facile. Elle ne l'est qu'en apparence. Les vraies difficult\u233?s sont humaines et
concernent la r\u233?solution de conflits et la gestion des priorit\u233?s. La
tentation est grande alors de faire de l'analyse des besoins une t\u226?che
purement technique, et de court-circuiter certaines parties prenantes. Au premier
abord, la qualit\u233? du livrable semble satisfaisante. L'ensemble est en
apparence correct et complet. Mais le v\u233?ritable besoin n'a pas \u233?t\u233?
cern\u233?. Le challenge est de concilier la rigueur et la souplesse, et de fournir
un livrable dans un temps court et au moindre co\u251?t, sans que cela se fasse au
d\u233?triment de la qualit\u233?. Pour y arriver, il faut utiliser la bonne d\
u233?marche et les bonnes techniques, s'y entra\u238?ner encore et encore, et aussi
c\u233?l\u233?brer les r\u233?ussites.\par\pard\plain\hyphpar} {
Chapitre 21 - Neuf conseils 4. Conciliez concepts et action de terrain Supposons
que vous ayez lu un ou plusieurs ouvrages sur l'ing\u233?nierie des exigences ou
l'\u233?laboration du cahier des charges pour le logiciel. Vous avez appris une d\
u233?marche, des concepts, sans rien mettre en pratique. Supposons maintenant
qu'apr\u232?s cela, vous partez sur le terrain avec un consultant aguerri pour \
u233?laborer un cahier des charges. Il est fort probable que vous constatiez un
fort d\u233?calage entre ce que vos avez lu et ce que vous voyez et entendez. Vous
commencez \u224? avoir des doutes. Ce que vous avez lu est-il pure th\u233?orie, ou
bien est-ce le consultant qui s'y prend mal ? La v\u233?rit\u233? doit se situer
entre les deux. Sans doute le consultant utilise sa m\u233?thode, qui a fait ses
preuves, sans chercher \u224? l'optimiser outre mesure. Peut-\u234?tre a-t-il pris
quelques mauvais plis en m\u234?me temps qu'il a pris de l'assurance vis-\u224?-vis
de ses clients. Mais le plus probable est qu'il utilise de nombreuses techniques d\
u233?crites dans cet ouvrage de mani\u232?re tr\u232?s souple. Pour un petit
projet, les objectifs peuvent \u234?tre d\u233?crits en quelques lignes et appara\
u238?tre dans le compte-rendu d'une r\u233?union de lancement. De m\u234?me,
l'analyse des parties prenantes peut \u234?tre faite rapidement et son r\u233?
sultat tenir en quelques lignes. Lorsqu'on est d\u233?butant, il vaut mieux aller
lentement, formaliser et tracer dans la mesure du possible, pour des raisons p\
u233?dagogiques et pour s\u233?curiser leur relation avec le client. Lorsque les
bonnes pratiques sont devenues des r\u233?flexes, on peut prendre de l'assurance et
de la vitesse. Dans le feu de l'action, quand le processus est optimis\u233?, les
concepts et la pratique sont une seule et m\u234?me chose. 5. Concentrez-vous sur
votre livrable Le d\u233?sir d'atteindre un livrable de qualit\u233? est le
meilleur moteur de l'action. En pratique, cela signifie que les livrables interm\
u233?diaires, c'est-\u224?-dire les versions interm\u233?diaires du cahier des
charges, m\u234?me \u171? en chantier \u187? doivent, toutes proportions gard\u233?
es, \u234?tre irr\u233?prochables. Un document navette n'est pas un document
poubelle. Les parties \u224? compl\u233?ter, \u224? retravailler, \u224? valider
doivent \u234?tre clairement signal\u233?es au moyen de conventions connues de
tous. Si des \u171? paquets d'exigences \u187?. en provenance de sources diverses,
doivent \u234?tre int\u233?gr\u233?s au document interm\u233?diaire, cela doit se
faire selon des r\u232?gles strictes, mais simples \u224? mettre en \u339?uvre.
Avec cette mani\u232?re de proc\u233?der, l'\u233?quipe d'analystes et leurs
clients ont \u224? leur disposition un document toujours pr\u233?sentable, sur
lequel on peut discuter, qui demandera le moins de remaniement possible. Dans le
cas contraire, l'\u233?quipe passera son temps \u224? bricoler et \u224?
rafistoler, ce qui consomme beaucoup de temps et d'\u233?nergie.\par\pard\plain\
hyphpar} {
Partie 3 - Gestion des exigences Sur le plan psychologique, cette m\u233?thode pr\
u233?sente aussi de nombreux avantages. On a plaisir \u224? 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, c'est l'\u233?nervement
permanent. 6. Sachez r\u233?ussir presque \u224? coup s\u251?r Savoir que l'on ne
court aucun risque, ou presque, de rater un cahier des charges, est tr\u232?s s\
u233?curisant et permet de travailler dans de bonnes conditions. Encore faut-il
savoir s'y prendre. Il y a un secret pour r\u233?ussir de cette mani\u232?re : la
mission d'\u233?laboration d'un cahier des charges doit \u234?tre structur\u233?e
de telle sorte que, quoi qu'il arrive, elle ne soit jamais un \u233?chec complet,
et toujours une r\u233?ussite ou une quasi-r\u233?ussite. Mais comment faire ?
D'apr\u232?s la \u171? loi \u187? de Pareto. 20 % de l'effort d'\u233?laboration
permettra d'atteindre 80 % du r\u233?sultat escompt\u233?. En d'autres termes, si
tout se met \u224? aller mal alors que vous n'en \u234?tes qu'\u224? un cinqui\
u232?me du parcours, le cahier des charges, lui. sera pr\u234?t aux quatre cinqui\
u232?mes. La loi de Pareto se v\u233?rifie si l'on choisit le bon mod\u232?le de
document, les bonnes m\u233?thodes, le bon rythme, et qu'on travaille de mani\u232?
re m\u233?thodique pour faire les choses dans le bon ordre. Il n'y a pas de r\u232?
gle absolue pour savoir quel est le bon ordre d'\u233?laboration, mais le plus
souvent, il vaut mieux travailler de mani\u232?re descendante, par raffinements
successifs, depuis les objectifs jusqu'aux d\u233?tails les plus fins. Dans le cas
contraire, o\u249? nous sommes face \u224? un existant, (par exemple une sp\u233?
cification existante), le bon ordre consiste \u224? consolider cet existant en le
(re)formalisant, puis \u224? remonter jusqu'aux objectifs, puis \u224?
redescendre \u224? nouveau dans les d\u233?tails de plus en plus fins. La loi de
Pareto s'applique \u233?galement en ce qui concerne le champ de l'\u233?tude, les
objectifs et les parties prenantes. D'o\u249? l'int\u233?r\u234?t de bien les
conna\u238?tre d\u232?s le d\u233?but, et de conna\u238?tre les priorit\u233?s. 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 C'est votre client, la ma\u238?trise d'ouvrage, qui \u233?labore le
cahier des charges, pas vous. Effacez-vous devant lui et valorisez son travail.
Vous \u234?tes animateur, facilitateur. expert, mais c'est votre client qui exprime
un besoin, et il l'exprime \u224? sa ma\u238?trise d'\u339?uvre. Se mettre en avant
n'est ni fair-play. ni efficace. Lorsque vous parlez au ma\u238?tre d'\u339?uvre.
vous \u234?tes le porte-parole \u338?D\par\pard\plain\hyphpar} {
Chapitre 21 - Neuf conseils du ma\u238?tre d'ouvrage, vous ne faites que traduire
ses besoins. Lorsque vous faites une pr\u233?sentation brillante en comit\u233? de
pilotage, rappelez-vous : votre pr\u233?sentation est une repr\u233?sentation des
besoins de votre client. Lorsque le cahier des charges sera livr\u233?, si tout se
passe bien, si votre client est g\u233?n\u233?reux et bon joueur, il reconna\u238?
tra peut-\u234?tre que vous avez fait du bon travail et vous remerciera pour le
service que vous lui aurez apport\u233?. Cela fait tr\u232?s plaisir et encourage \
u224? faire encore mieux la prochaine fois. Mais au cours de l'\u233?laboration,
votre ego doit rester au vestiaire. 8. Perdez un peu de temps pour en gagner
beaucoup Le temps \u171? perdu \u187? n'est pas toujours celui que l'on croit.
Faire l'impasse sur le recueil d'un objectif, laisser de c\u244?t\u233? une partie
prenante pour, soi-disant, gagner du temps, est purement et simplement un manque de
professionnalisme. Bien s\u251?r, votre hi\u233?rarchie, votre client, le ma\u238?
tre d'\u339?uvre ou toute autre partie prenante peut faire pression pour vous
pousser \u224? aller plus vite. Il est de votre responsabilit\u233? d'expliquer \
u224? vos interlocuteurs qu'il faut consolider les fondations avant de s'attaquer
aux murs, et que le temps investi sera r\u233?cup\u233?r\u233? au d\u233?cuple. Il
ne faut donc pas h\u233?siter \u224? consacrer du temps aux \u233?tapes en amont de
l'\u233?laboration : d\u233?finition de l'objectif, des parties prenantes et du
champ de l'\u233?tude. Si un de ces points est mal d\u233?fini, il faudra apr\u232?
s coup d\u233?faire le travail et le refaire. Et parfois, tout reprendre du d\u233?
but. Cela occasionne beaucoup de temps perdu, de fatigue inutile, de stress et de
d\u233?couragement. Ce qui est vrai pour le macroprocessus d'\u233?laboration l'est
aussi au niveau des microprocessus. Le temps pass\u233? \u224? pr\u233?parer une
interview ou une r\u233?union n'est pas du temps perdu. Parfois, il vaut mieux
passer beaucoup de temps \u224? discuter autour d'un sch\u233?ma que d'avancer.
C'est l'exp\u233?rience qui permet de distinguer l'investissement en temps, de la
perte de temps pure et simple. Aussi, est-il important d'observer sa propre mani\
u232?re de proc\u233?der et d'essayer de s'am\u233?liorer en permanence. 9. Faites
de la d\u233?finition des besoins un projet en soi D\u233?finir les besoins est un
vrai m\u233?tier, avec ses m\u233?thodes, ses techniques, ses outils, avec des
experts et un savoir-faire propre. Les analystes ont leur propre rythme de travail,
leurs r\u232?gles et leur code de bonne conduite.\par\pard\plain\hyphpar} {
ie 3 - Gestion des exigences qui diff\u232?rent de ceux des r\u233?alisateurs ou
des testeurs. Voil\u224? pourquoi il faut consid\u233?rer l'\u233?laboration d'un
cahier des charges comme un projet en soi. avec son livrable bien d\u233?fini. De
plus, avoir une vision globale de la mission de d\u233?finition des besoins est
beaucoup plus valorisant et pousse \u224? l'action. Consid\u233?rer la d\u233?
finition des besoins seulement comme un sous-projet, et non un projet en soi. n'est
pas tr\u232?s motivant. Vous avez acquis un savoir- faire, ou vous \u234?tes en
train de l'acqu\u233?rir, c'est votre m\u233?tier, vous \u234?tes pay\u233? pour \
u231?a, vous portez le projet. Bien s\u251?r, vous devez vous assurer que les
exigences que vous sp\u233?cifiez sont r\u233?alisables, que les contraintes
techniques sont elles aussi sp\u233?cifi\u233?es, que l'ensemble est coh\u233?rent.
Bien s\u251?r. vous pouvez, et parfois vous devez, dialoguer avec la ma\u238?trise
d'\u339?uvre. Mais ce qui adviendra du syst\u232?me apr\u232?s la livraison du
cahier des charges ne fait pas partie de votre mission. Cela peut l\u233?gitimement
vous int\u233?resser, mais ne doit en aucun cas consommer votre \u233?nergie. \
u338?)\par\pard\plain\hyphpar} {
Les questions \u224? large spectre Comment utiliser ces questions ? Ces questions
peuvent servir \u224? constituer un guide d'entretien de derni\u232?re minute, ou \
u224? d\u233?fricher un terrain inconnu, en \u233?vitant l'angoisse de la page
blanche. Il ne s'agit en aucun cas de les \u233?grener de la premi\u232?re \u224?
la derni\u232?re : cela ne ferait que mettre l'interlocuteur mal \u224? l'aise (ou
s'il l'est d\u233?j\u224?, de le mettre encore plus mal \u224? l'aise). Et de toute
fa\u231?on, elles sont redondantes. Quoi qu'il en soit, ces questions g\u233?n\
u233?riques peuvent \u234?tre une aide : elles ne sont pas une panac\u233?e. Liste
de questions Questions de situation, questions g\u233?n\u233?riques Ces questions
permettent de conna\u238?tre le contexte. \u8226? En quoi consiste votre activit\
u233? actuelle ? (Cette question permet de d\u233?finir ou de cerner la partie du
processus qui va impacter le futur utilisateur interview\u233?.) \u8226? Pouvez-
vous d\u233?crire la mani\u232?re dont votre service ( bureau, organisation,
entreprise...) fonctionne actuellement ? \u8226? Quel est votre r\u244?le
actuel ? \u8226? Dans quelle mesure votre activit\u233? sera-t-elle impact\u233?e
par le futur syst\u232?me ? Les questions suivantes sont tr\u232?s g\u233?n\u233?
rales. La premi\u232?re, tr\u232?s (trop) g\u233?n\u233?rique, est \u224? utiliser
avec mod\u233?ration. \u8226? Ou'attendez-vous du futur syst\u232?me ?\par\pard\
plain\hyphpar} {
Expression des besoins pour le syst\u232?me d'information \u8226? Que souhaitez-
vous que le syst\u232?me fasse ? \u8226? En quoi le futur syst\u232?me va-t-il am\
u233?liorer votre activit\u233? ? Questions d'objectif Ces questions sont \u224?
poser au ma\u238?tre d'ouvrage strat\u233?gique et aux parties prenantes d\u233?
cisionnaires. \u8226? Quel probl\u232?me voulez-vous r\u233?soudre ? \u8226?
Qu'attendez-vous de la solution future, du futur logiciel ? \u8226? Comment saurez-
vous que la solution propos\u233?e aura atteint son objectif ? \u8226? Une fois que
votre syst\u232?me sera op\u233?rationnel, que va-t-il vous apporter ? \u8226?
Quelles seront les retomb\u233?es positives de la mise en place de la solution
future, du futur logiciel ? \u8226? Quelles seront les cons\u233?quences n\u233?
gatives de la mise en place de la solution future, le logiciel ? Questions de
manque Par d\u233?finition, un manque est un besoin. Chercher les manques est donc
une bonne fa\u231?on de faire exprimer les besoins. \u8226? Qu'est-ce qui manque au
syst\u232?me actuel ? \u8226? Comment ce manque qui pourrait-il \u234?tre combl\
u233? par le futur syst\u232?me ? \u8226? Qu'est-ce qui est d\u233?faillant avec le
syst\u232?me actuel ? \u8226? Qu'est-ce qui vous d\u233?range le plus dans le syst\
u232?me actuel ? \u8226? Si une chose vous d\u233?rangeait avec le syst\u232?me
actuel, ce serait quoi ? \u8226? Que voudriez-vous que le syst\u232?me \u224? venir
fasse et que le syst\u232?me actuel ne fait pas ? \u8226? Peut-on faire ensemble la
liste de toutes les fonctions que le syst\u232?me actuel accomplit mal ? Questions
sur le syst\u232?me \u224? l'\u233?tude Pour conna\u238?tre les donn\u233?es : \
u8226? Quelles sont les donn\u233?es manipul\u233?es par le syst\u232?me ? \u8226?
Quelles donn\u233?es le syst\u232?me devra-t-il stocker ? \u8226? Quelles sont les
donn\u233?es contenues dans cette entit\u233? ? \u8226? Quelles sont les relations
entre ces deux donn\u233?es ? Pour identifier les \u233?tats et transitions d'un
objet : \u8226? Quel est le cheminement du dossier, d'un objet ? \u8226? Dans quels
\u233?tats peut se trouver le dossier, l'objet ? \u338?\par\pard\plain\hyphpar} {
Annexe - Les questions \u224? large spectre \u8226? Quel \u233?v\u233?nement va
modifier le dossier, l'objet ? \u8226? Que se passe-t-il suite \u224? cet \u233?v\
u233?nement ? \u8226? Oue se passe-t-il si cet \u233?v\u233?nement n'a pas lieu ?
(Exception) Questions de perspective On demande au futur utilisateur ou toute autre
partie prenante de se projeter dans l'avenir. \u8226? Ou'attendez-vous du futur
syst\u232?me ? \u8226? Que voudriez-vous que le syst\u232?me \u224? venir fasse ? \
u8226? Que voudriez-vous que le syst\u232?me \u224? venir fasse mieux que le syst\
u232?me actuel ? \u8226? Qu'est-ce qui doit \u234?tre am\u233?lior\u233? par le
futur syst\u232?me ? (Sans n\u233?cessairement d\u233?finir une solution, cette
question approfondit le besoin.) \u8226? Quel crit\u232?re doit-on utiliser pour
prouver que le syst\u232?me satisfait cette exigence ? \u8226? Pouvez-vous d\u233?
crire le futur syst\u232?me, tel que vous l'imaginez ? Questions de pr\u233?
cision \u8226? Oui... ? (Se taire et attendre que l'interview\u233? pr\u233?cise
spontan\u233?ment la pens\u233?e.) \u8226? Oui. et plus pr\u233?cis\u233?ment ? (\
u201?viter \u171? oui. mais... \u187? ; pr\u233?f\u233?rer \u171? oui. et... \
u187?.) \u8226? Un de vos coll\u232?gues (si n\u233?cessaire, pr\u233?server la
confidentialit\u233?) a exprim\u233? le besoin d'avoir |...|. \u202?tes-vous du m\
u234?me avis que lui ? (Rassurer l'interlocuteur : il a le droit d'avoir un avis
diff\u233?rent.) \u8226? Comment faites-vous ? (Apporte du d\u233?tail.) \u8226?
Pourquoi|...| ? (Remonte \u224? des exigences de plus haut niveau ; \u224? utiliser
avec prudence, et ne jamais impliquer l'interview\u233? avec ce type de questions.)
Crit\u232?res de priorisation et de validation On demande maintenant \u224?
l'utilisateur de d\u233?finir ses priorit\u233?s et des crit\u232?res de validation
de l'exigence. \u8226? En quoi cette exigence est-elle importante pour vous ? \
u8226? Qu'est-ce qui fera que vous serez satisfait avec le futur syst\u232?me ? \
u8226? Comment saurez-vous que le futur syst\u232?me est satisfaisant ? \u8226?
Pouvez-vous indiquer les trois fonctions indispensables du futur syst\u232?me? \
u8226? Si vous ne deviez conserver que trois fonctions parmi celles d\u233?crites,
lesquelles conserveriez-vous ? QD\par\pard\plain\hyphpar} {
Besoin. N\u233?cessit\u233? ou d\u233?sir \u233?prouv\u233? par un utilisateur
(AFNOR X50-150). Cahier des charges. Document par lequel le demandeur exprime son
besoin (ou celui qu'il est charg\u233? de traduire), en termes de fonctions de
service et de contraintes. Pour chacune d'elles, sont d\u233?finis des crit\u232?
res d'appr\u233?ciation et leurs niveaux. Chacun de ces niveaux doit \u234?tre
assorti d'une flexibilit\u233? (AFNOR X50-150). Client. Le client (ou ma\u238?tre
d'ouvrage) sera le propri\u233?taire de l'objet du cahier des charges. Il est
responsable de la d\u233?finition des exigences, du financement, et de
l'approbation de la solution. Contrainte. Limitation \u224? la libert\u233? de
choix du concepteur r\u233?alisateur du produit (AFNOR X50-150). Crit\u232?re
d'appr\u233?ciation. Caract\u232?re retenu pour appr\u233?cier la mani\u232?re dont
une fonction est remplie ou une contrainte respect\u233?e (AFNOR X50-150). Demande.
Expression, encore subjective et partielle, de la perception d'un besoin, \u224? un
instant donn\u233?. D\u233?veloppement de logiciel. Processus par lequel les
besoins des utilisateurs sont transform\u233?s en sp\u233?cifications, les sp\u233?
cifications en conception, la conception en code, et le code test\u233?, document\
u233? et valid\u233? en vue d'un usage op\u233?rationnel (d\u233?finition IEEE).
Domaine fonctionnel. Ensemble d'activit\u233?s coh\u233?rentes concourant \u224?
une finalit\u233? de l'organisme. \u201?l\u233?mentaire (exigence). Se dit d'une
exigence qui ne peut \u234?tre d\u233?compos\u233?e, ins\u233?cable (en anglais,
atomic). Ergonomie. Discipline scientifique qui vise la compr\u233?hension
fondamentale des interactions entre les \u234?tres humains et les autres
composantes d'un syst\u232?me, et la mise en \u339?uvre dans la conception de th\
u233?ories, de principes, de m\u233?thodes et de donn\u233?es pertinentes afin
d'am\u233?liorer le bien-\u234?tre des hommes et l'efficacit\u233? globale des
syst\u232?mes (Association Internationale d'Ergonomie). GD\par\pard\plain\hyphpar}
{
ion des besoins pour le syst\u232?me d'information Exigence. Description formelle
d'un objectif. L'appr\u233?ciation de la satisfaction d'une exigence peut \u234?tre
mesur\u233?e. \u201?tat de l'art Ensemble des r\u232?gles respect\u233?es
implicitement par les professionnels d'une activit\u233?. Fonction. Action d'un
produit, ou de l'un de ses constituants, exprim\u233?e exclusivement en termes de
finalit\u233?s (AFNOR X50-I50). Fonction de service. Action attendue d'un produit
(ou r\u233?alis\u233?e par lui) pour r\u233?pondre \u224? un \u233?l\u233?ment du
besoin d'un utilisateur donn\u233? (AFNOR X50-150). Fournisseur. Le fournisseur (ou
ma\u238?tre d'ceuvre) s'engage sur les conditions qu'il accepte : \u233?ch\u233?
ancier des livraisons, ma\u238?trise des co\u251?ts, satisfaction des exigences.
Ing\u233?nierie du logiciel ou g\u233?nie logiciel (en anglais. Software
Engineering). Approche syst\u233?matique du d\u233?veloppement, de l'exploitation,
de la maintenance et de la mise \u224? la retraite d'un logiciel (d\u233?finition
IEEE). Logiciel. La somme des programmes, proc\u233?dures, r\u232?gles de gestion,
en rapport avec le fonctionnement d'un ordinateur, ainsi que la documentation et
les donn\u233?es qui leur sont associ\u233?es (d\u233?finition IEEE). Maquette.
Objet destin\u233? \u224? aider un client \u224? sp\u233?cifier ses demandes.
Processus. Ensemble d'activit\u233?s corr\u233?l\u233?es ou interactives qui
transforme des \u233?l\u233?ments d'entr\u233?e en \u233?l\u233?ments de sortie
(ISO 9000). Produit. Ce qui est (ou qui sera) fourni \u224? un utilisateur pour r\
u233?pondre \u224? un besoin. Le produit peut \u234?tre un objet, un fluide, une
prestation de service, un processus industriel ou administratif (proc\u233?d\u233?,
logiciel, proc\u233?dure, etc) ou toute combinaison de ceux-ci (AFNOR X50-150).
Prototype. Objet destin\u233? \u224? v\u233?rifier la faisabilit\u233? d'une
solution sous un aspect particulier : conceptuel, organisationnel ou technique. Un
prototype encha\u238?ne des parties r\u233?elles (celles dont on veut montrer la
faisabilit\u233?) et des parties fictives (en g\u233?n\u233?ral, celles qui
correspondent \u224? des fonctions dont la r\u233?alisation ne semble poser aucun
probl\u232?me). Qualit\u233?. Ensemble des propri\u233?t\u233?s et caract\u233?
ristiques d'un produit, ou service, qui lui conf\u232?rent l'aptitude \u224?
satisfaire des besoins, exprim\u233?s ou implicites. La ma\u238?trise d'ouvrage et
l'utilisateur s'int\u233?ressent principalement \u224? la qualit\u233? du produit,
alors que la ma\u238?trise d'ceuvre s'int\u233?resse \u224? la qualit\u233? du
processus. Cette derni\u232?re contribue \u224? la qualit\u233? du produit.
Solution. Ensemble coordonn\u233? de moyens mat\u233?riels, logiciels, humains,
organis\u233?s pour satisfaire un ensemble d'exigences. Sp\u233?cification.
Traduction d'exigences en \u233?l\u233?ments techniques.\par\pard\plain\hyphpar} {
Glossaire fran\u231?ais Syst\u232?me. Ensemble coh\u233?rent d'\u233?l\u233?ments
mat\u233?riels et logiciels en interaction dynamique, destin\u233? \u224? assurer
une finalit\u233? pr\u233?alablement d\u233?finie. UML (Unifted Modeling Language).
Langage standard de repr\u233?sentation de l'information (donn\u233?es,
traitements), principalement sous forme de diagrammes. Utilisateur. Personne ou
entit\u233? pour qui le produit a \u233?t\u233? con\u231?u, qui exploite au moins
une des fonctions du produit. (AFNOR X50-150).\par\pard\plain\hyphpar} {
Glossaire bilingue) La litt\u233?rature anglophone sur les exigences (en anglais,
requiremenls) est tr\u232?s riche et le vocabulaire s'y rapportant fait l'objet
d'un large consensus entre auteurs. Ce n'est pas le cas en fran\u231?ais, o\u249?
l'on emploie des mots diff\u233?rents pour d\u233?signer les m\u234?mes objets ou
concepts. De plus, les termes et expressions varient en fonction du pays (France,
Canada. Belgique, Suisse), du m\u233?tier (informatique technique, syst\u232?mes
d'information, ing\u233?nierie syst\u232?me) et des auteurs. Le lecteur ne devra
donc pas s'\u233?tonner si les termes employ\u233?s dans cet ouvrage sont diff\
u233?rents de ceux avec lesquels il a \u233?t\u233? familiaris\u233?. Malgr\u233?
notre effort de minimiser le nombre de termes flous et d'utiliser autant que
possible les m\u234?mes mots pour d\u233?signer les m\u234?mes concepts, certaines
ambigu\u239?t\u233?s n'ont pu \u234?tre \u233?vit\u233?es. Voici une liste d'\u233?
quivalence (non exhaustive) entre les termes anglophones et le(s) \u233?
quivalent(s) utilis\u233?(s) en fran\u231?ais dans cet ouvrage. Analyst ou
requiremenls analysl. Litt\u233?ralement \u171? analyste des exigences \u187?.
Analyste fonctionnel ; analyste m\u233?tier ; assistant \u224? la ma\u238?trise
d'ouvrage, conseil \u224? la ma\u238?trise d'ouvrage. Business requiremenls.
Exigences m\u233?tier (au Qu\u233?bec : exigences d'affaires). Client, customer.
Client ; ma\u238?trise d'ouvrage (strat\u233?gique ou op\u233?rationnelle).
Elldtation (requlrements). Recueil des besoins, ou capture des besoins ou des
exigences. Need. Besoin. Dans le cadre de l'analyse des besoins, terme beaucoup
moins usit\u233? que requirement. NFR, non-functional requiremenls : exigences non
fonctionnelles. Owner. Litt\u233?ralement < propri\u233?taire \u187?. Ma\u238?tre
d'ouvrage strat\u233?gique, donneur d'ordres. Requirement Besoin ou exigence (cet
ouvrage fait explicitement le distinguo entre ces deux termes).\par\pard\plain\
hyphpar} {
ion des besoins pour le syst\u232?me d'information Requirements engineering. Ing\
u233?nierie des besoins ; ing\u233?nierie des exigences. Software requirements.
Exigences logicielles, exigences du logiciel. SRS, Software requirements sp\u233?
cification. Sp\u233?cification du besoin, sp\u233?cification des exigences. SRS
document, Software requirements sp\u233?cification document. Cahier des charges ;
cahier des charges fonctionnel ; sp\u233?cifications fonctionnelles g\u233?n\u233?
rales ; sp\u233?cification des exigences.\par\pard\plain\hyphpar} {
Alistair Cockburn. R\u233?diger des cas a*utilisation efficaces, Eyroi les. 2001.
Yves Constantinidis. Le logiciel \u224? valeur ajout\u233?e, la perspective de
l'utilisateur, Herm\u232?s Science. 2001. Yves Constantinidis, D\u233?finition des
besoins pour le logiciel, Herm\u232?s Science, 2006. Tom Giib, Comp\u233?titive
Engineering : A handbook for Systems engineering, requirements engineering, and
software engineering management using planguage. Butterworth-Heinemann. 2005. Ellen
Gottesdiener. Requirements by collaboration. Addison-Wesley. 2002. Elien
Gottesdiener. Software requirements memory \'5cogger, Goai/\u219?PC. 2005.
International Institute of Business Anaiysts, A guide to Business Analysis Body of
Knowledge (BABOK Guide), version 2.0. 2010. Soren Lauesen, Software Requirements -
Styles and Techniques, Addison-Wesley. 2002. Hugues March\u226?t. La gestion de
projet par \u233?tapes, \u233?tude des besoins, Eyrolles. 2008. Paul-Hubert des
Mesnards, R\u233?ussir \'5c'7banalyse des besoins, Eyrolles, 2007. Suzanne and
lames Robertson. Maslering the Requirements Process, Addison- Wesley. 1999. Karl
Wiegers. Software requirements, Microsoft Press, 2003. Karl Wiegers. More Aboul
Software requirements, Microsoft Press. 2006.\par\pard\plain\hyphpar} {
Index A accompagnement (services d'~) 139 acteurs 12, 18,43,93 activit\u233?s
(diagramme d'~) 113 affinit\u233?s (diagramme des -) 83 AfnorX50-f 51 (mod\u232?le)
158 AHP (Analytical Hierarchical Pro- cess) 112 ambigu\u239?t\u233?s 32,83,88 am\
u233?lioration du processus d'\u233?laboration 26, 187 analyse 107 check-list d'-
126 comparative Voir \u233?tude comparative de documents 74 de l'existant 12, 180
de produits existants 86 des besoins 182 des exigences 16,44,45 des r\u232?gles m\
u233?tier 107 des risques 63,218 d'impact 199,200 \u233?tape 103 \u233?tape d'- 54
parties prenantes 54 processus 104 analyste 9, 11, 18, 24, 27, 28. 54 activit\u233?
2 comp\u233?tences 27 engagements de I'- 40 savoir-\u233?tre 30 savoir-faire 29
Analytical Hierarchical Process (AHP) 112 animateur (qualit\u233?s d'-) 29
anticipation (technique de l'~) 190 arbres de d\u233?cision 121 assistant ma\u238?
trise d'ouvrage Voir analyste assistant, ma\u238?trise d'ouvrage Voir analyste
atomic requlrements Voir exigences \u233?l\u233?mentaires attributs de qualit\u233?
15 des exigences 200 automate d'\u233?tats finis 120 B besoins alternatifs 89
concept 18 exceptionnels 89 n\u233?gatifs 90 B.O.R.D. (tableau de ~) 214 Box,
George 178 bralnstorming 29,83 business requlrement Voir exigence m\u233?tier \
u199? cadrage document 58 \u233?tape 178\par\pard\plain\hyphpar} {
Expression des besoins pour le syst\u232?me d'information cahier des charges 12, 19
mod\u232?le 106, 155 utilit\u233? 21 des clauses techniques particuli\u232?res
(CCTP) 164 capacit\u233? fonctionnelle 129 capitalisation (\u233?tape de ~) 185
caract\u233?ristiques de qualit\u233? 127 carte de processus 113 cas d'utilisation
15, 42, 93, 105. 126 avantages 96 contenu 94 diagramme 100 difficult\u233?s et
risques 99 \u233?laboration 96 mod\u233?lisation 96 cat\u233?gories d'exigences 15,
105 CCB (Change Control Board) 198 CCTP (cahier des clauses techniques particuli\
u232?res) 24, 164 cent points (m\u233?thode des ~) 110 Change Control Board (CCB)
198 changement demandes de- 201 gestion des 197,209 charges enregistrement 63 et d\
u233?lais, estimation 62 check-list cahier des charges 165 d'analyse 126 de bonne
formulation 145 de contenu 169 de l'\u233?tape de validation 175 de propri\u233?t\
u233?s 169 de s\u233?lection d'outils 205 de sp\u233?cification d'une exigence 152
d'\u233?tape de sp\u233?cification 153 \u233?tape de concept et objectifs 58 \u233?
tape de recueil 91 plan projet 47.64 r\u232?gle des 5 C 146 v\u233?rification par -
s 169 classes (diagramme de -) 117 classification des exigences 42 Cockburn,
Allstair 94,95, 100, 101 coh\u233?rence 89 commission de contr\u244?le des
changements 198 compatibilit\u233? (ergonomie) 134 concept check-list 58 et
objectifs 49 concision (d'ergonomie) 136 contexte (diagramme de -) 14, 53,58,94,97,
116, 126, 157, 179, 180, 183 contraintes 13, 15 de co\u251?t 137 de maintenance 140
d'environnement 138 de projet 137 de support 140 organisationnelles 42 r\u233?
glementaires 42 techniques 16.25.49 contr\u244?le explicite (ergonomie) 136 co\
u251?t contraintes de - 137 de correction d'une erreur 22 des exigences 25 des
exigences (\u233?valuation) 124 cr\u233?ativit\u233? 25,31,73 CRUD (matrice) 124
cycle de vie du logiciel 35 d\u233?lais, enregistrement 63 demandes concept 18 de
changement 201 d\u233?veloppement des exigences 21,44,65 2D\par\pard\plain\hyphpar}
{
Index diagramme d'activit\u233?s 113 de cas d'utilisation 100 d\u233?classes 117 de
contexte 53, 58.94,97. 116. 126. 157. 179. 180. 183 de flux de donn\u233?es 114
deKano 124 des affinit\u233?s 83 de s\u233?quence 116 entit\u233?s-associations 117
\u233?tats-transitions 120 process map 113 UML 113 dictionnaire de donn\u233?es
107,126 directeur d\u233?mission 62 de projet 62 documentation des besoins 69 des
exigences 41 exigences de- 141 documents analyse de- 74 de cadrage 58 navette (m\
u233?thode du ~) 191 documents-types 61 domaine d'application (d\u233?termination)
52 donneur d'ordres 23, 54, 86 E \u233?chelle de Ukert 85 \u233?coute (qualit\u233?
d'~) 30, 80, 90 Elsenhower (principe d'~) 110 \u233?l\u233?mentaires (exigences) 42
entit\u233?s-associations (diagramme) 117 entonnoir d\u233?marche de recueil 80 m\
u233?thode de s\u233?lection 213 environnement contraintes 138 de d\u233?
veloppement (contraintes) 138 physique d'utilisation 141 estimation charges et d\
u233?lais 62 \u233?tape d'analyse 54. 103. 182 d'analyse de l'existant 180 de
cadrage 178 de capitalisation 185 de planification 179 de recueil 67. 182 de sp\
u233?cification 143,184 de validation 167, 184 planification 59 processus
d'exigences 43 \u233?tats-transitions (diagramme ~) 120 \u233?tude comparative 60,
214 de choix 213 design 218 d'int\u233?grabilit\u233? 218 d'opportunit\u233? 216 \
u233?v\u233?nement m\u233?tier 94, 97 exigences 11, 19 comportementales 42 de haut
niveau 42 de qualit\u233? 42. 106 d'int\u233?gration 140 d'interface 106
d'interfaces externes 15 \u233?l\u233?mentaires 42.97, 151 fonctionnelles 14. 15.
106 formulation 147 m\u233?tier 14. 16. 108 non fonctionnelles 15, 106. 127, 151
caract\u233?ristiques de qualit\u233? 127 norme ISO 25000 128 processus de d\u233?
veloppement 44 sp\u233?cifications rampantes 111 sur les donn\u233?es 15 sur les
formats de donn\u233?es 106 GD\par\pard\plain\hyphpar} {
Expression des besoins pour le syst\u232?me d'information expert m\u233?tier 62
technique 63 expression \u233?crite (aptitude) 30 H facilit\u233? d'utilisation
(utillsabilit\u233?) 130 faisabilit\u233? des exigences (\u233?valuation) 124
feedback 69,88 fiabilit\u233? 129 flnalit\u233?-avantage-mesure (objectifs) 51 flux
de donn\u233?es (diagramme de ~) 114 fonction \u224? satisfaction proportionnelle
125 attractive 125 obligatoire 125 fonctionnalit\u233? 129 formalisation des
objectifs 51 formation (exigences de ~) 141 forme de description des exigences 150
formulation des exigences 143, 144 gains 23 g\u233?n\u233?ralisations 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 homog\u233?n\u233?it\u233? (ergonomie) 135 I IEEE 830 (mod\
u232?le) 149,156 IEEE 982 (cycle de vie du logiciel) 35 impact (analyse d'~) 200
Ing\u233?nierie des besoins 27 des exigences 9, 11, 13, 14, 19, 35,41,44,67 du
logiciel 197 installation 137 int\u233?grabilit\u233? (\u233?tude d'-) 140 int\
u233?gration (exigences d'-) 140 interface contraintes 139 exigences d'- 106
interview d\u233?roulement 77 distorsions 82 structur\u233?e individuelle 76 types
de questions 78 ISO 25000 (norme) 128,152 It\u233?rations, processus d'exigences
189 jurisprudence 17 K Kano (diagramme de ~) 124 L langue de bois 90, 146 lettre de
mission 24, 58, 74, 178 Llkert (\u233?chelle de ~) 85 liste des parties prenantes
54 logiciel 35 loldePareto 224 sb\par\pard\plain\hyphpar} {
Index M maintenabilit\u233? 132 maintenance contraintes de - 140 phase de- 35 ma\
u238?tre d'oeuvre 11, 36 ma\u238?tre d'ouvrage 36 engagements du - 40 op\u233?
rationnel 11 strat\u233?gique 12 ma\u238?trise d'ouvrage 54 maquette 29 matrice
CRUD 124 RACI 124 McCall (typologie de ~) 127 m\u233?thode des cent points 110 m\
u233?thodologie 60 migration 138 mise en exploitation 137 mod\u232?le AfnorX50-l5l
158 de cahier des charges 155 de document 61 de processus d'exigences 177 deWiegers
160 IEEE 830 149, 156 Volere 132, 149. 162 mod\u233?lisation 9,44,63 cas
d'utilisation 96 graphique 112 bo\u238?te \u224? outils 122 maquette 122 prototype
122 techniques de - 28 MTBF, mean time between failures 130 N n\u233?gociation
des exigences 15, 29, 89, 110, 192 niveau d'exigences 42 norme ISO 25000 128, 152
norme ISO/CEI 25000 128 o objectifs 50, 105 strat\u233?giques 42 observation
directe 84 observation (qualit\u233? d'~) 31 Ockham (rasoir d'~) 119 omissions 81
op\u233?rateurs modaux 81 organigrammes 121 outils 60, 205 choix 210 fonctions de
base et avanc\u233?es 206 P Pareto (loi de -) 224 parties prenantes 12, 43, 50
analyse 18, 54 concept de - 18 liste 54 tableau 57 p\u233?rim\u232?tre 50, 52 phase
d'exigences 38 plan de recueil 70 planguage (planning language) 151 planification
59 aptitude 29 \u233?tape 179 recueil des besoins 68 plan projet 59 check-list
47,64 contenu 63 \u233?laboration 61 portabilit\u233? 132 pouvoir-impact (grille ~)
55 principe d'Eisenhower 110 principe de simplicit\u233? 119 \u163?E)\par\pard\
plain\hyphpar} {
Expression des besoins pour le syst\u232?me d'information priorisation, projet 109
processus carte de- 113 d'analyse 104 d'\u233?laboration 185 de recueil 68 de sp\
u233?cification 143 de validation des exigences 168 d\u233?veloppement des
exigences 45 d'exigences am\u233?lioration 187 processus d'exigences 60 am\u233?
lioration 189 description formelle 44 description pratique 45 \u233?tapes 43 it\
u233?rations 189 mod\u232?le 177 r\u233?cursions 188 r\u233?troactions 188 profils
utilisateurs 25 d\u233?termination 71 exemple de typologie 72 identification des -
61 segmentation (ergonomie) 134 typologie 71 projet d'\u233?laboration 59 m\u233?
thodologie 60 priorit\u233?s (d\u233?finition des -) 109 prototypage 123 QFD
(Quality Functlon D\u233?ployaient) 112 qualit\u233? contr\u244?le des exigences
174 Quality Functlon D\u233?ployaient 112 quantificateurs universels 81
questionnaires (recueil par ~) 85 questionnement (recueil d'objectifs ; grille de
~) 56 RACI (matrice) 124 rasoir d'Ockham 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 \u233?tape 67 grille de questionnement 56 par observation
directe 84 par questionnaires 85 plan de- 70 processus 68 risques 70 techniques 73
v\u233?rification 69 r\u233?cursions sur le processus d'exigences 188 r\u232?gles
analyse 107 de gestion 13. 15, 105, 107 m\u233?tier 15. 16. 105, 108 tra\u231?
abilit\u233? 109 relationnelle (qualit\u233? -) 31 relecture crois\u233?e (v\u233?
rification par -) 170 simple (v\u233?rification par -) 170 rendement 131 ressources
(identification des ~) 62 retour sur investissement 23 retravail 190 r\u233?
troactions, processus d'exigences 188 r\u233?utilisation des exigences 86, 150
rework 188, 190 risques 24 analyse 63 Robertson, James 174 GD\par\pard\plain\
hyphpar} {
Index Robertson, Suzanne 174 Robertson, Suzanne et James 162 S SAE (syst\u232?me \
u224? l'\u233?tude) 14 savoir-faire 27 screening 213 segmentation des profils
utilisateurs 134 s\u233?quence (diagramme de -) 116 services d'accompagnement 139
short-list 213 simplicit\u233? (principe de -) 119 solutions (suggestions de ~) 106
souplesse (ergonomie) 135 sources d'exigences 61, 72, 74 sous-sp\u233?ciflcation 25
sp\u233?cification concept 18 des exigences 45, 184 \u233?tape 184 processus de -
143 rampante 24,26, 123, 198 structuration des exigences 105, 144, 149 suggestions
de solutions 106 support (contraintes de -) 140 sursp\u233?cification 25 SWOT
(analyse) 214 syst\u232?me 13 T tableau deB.O.R.D. 214 des parties prenantes 57
tables de d\u233?cision 121 techniques de l'anticipation 190 de recueil 73 de
recueil des objectifs 52 de validation 168 template 61 tra\u231?abilit\u233? des
exigences 207 typologie de McCall 127 U UML (Unifled Modeling Lan- guage) 93, 100,
105, 113, 118 Unifled Modeling Language Voir UML use cases Voir cas d'utilisation
utilisabiltt\u233? 130 utilisateurs besoins des- 15 participation des - 23 profils
25 y validation check-list 175 des exigences 44,45, 184 \u233?tape 167. 184
processus de- 168 v\u233?rification cas de test (\u233?laboration de ~) 173 cont\
u244?le qualit\u233? des exigences 174 crois\u233?e 170 des exigences 144
inspection 171 parcheck-lists 169 par relecture crois\u233?e 170 simple 170 revue
formelle 171 simple 170 versions (gestion des) 209 Volere (mod\u232?le ~)
132,149,162 W Wlegers, Karl 15, 105, 160 Wlegers (mod\u232?le de -) 160 Z zone
floue 39,89,213 SB\par\pard\plain\hyphpar} {
pour le syst\u232?me d'information rr L'auteur Consultant en syst\u232?mes
d'information. Yves Constantinidis a dirig\u233? avec succ\u232?s l'\u233?
laboration de plusieurs cahiers des charges de port\u233?e nationale (minist\u232?
re de la Sant\u233?, minist\u232?re de l'\u201?ducation nationale). Informaticien
de formation, il intervient sur des missions de choix de solutions, de diagnostic
du syst\u232?me d'information et d'am\u233?lioration du processus de d\u233?
veloppement. Son expertise l'a amen\u233? \u224? publier trois ouvrages sur l'ing\
u233?nierie du syst\u232?me d'information et la qualit\u233? du logiciel (\u233?
ditions Herm\u232?s), et \u224? intervenir comme formateur aupr\u232?s d'\u233?
tablissements d'enseignement sup\u233?rieur (Epita. \u201?cole des hautes \u233?
tudes en sant\u233? publique). lie est pr\u233?sident cfhonneur du Club des Martres
d'Ouvrage des Syst\u232?mes d'Information - omment recueillir tous tes besoins des
acteurs du syst\u232?me d'information, et rien que leurs besoins r\u233?els?
Comment se mettre \u171?d'accord sur la sp\u233?cification des exigences? Comment
aboutir \u224? un cahier des charges clair, complet et consensuel? Phase cruciale
dans le choix, le d\u233?veloppement ou ta mise en oeuvre d'une solution
d'entreprise, la d\u233?finition des besoins conditionnera en effet la r\u233?
ussite du projet, notamment son co\u251?t et sa qualit\u233?. Mais cette \u233?tape
est complexe et d\u233?licate, en raison du nombre et de la diversit\u233? des
parties prenantes, des demandes souvent divergentes, des contraintes vari\u233?es
et. last but not least. du facteur humain. V\u233?ritable guide de terrain, nourri
par la grande exp\u233?rience de son auteur, cet ouvrage pr\u233?sente une d\u233?
marche et des techniques \u233?prouv\u233?es pour recueillir et formaliser les
vrais besoins, afin d'\u233?laborer un cahier des charges dune qualit\u233? irr\
u233?prochable, dans des d\u233?lais raisonnables et au moindre co\u251?t. \u192?
partir d'un exempte permettant de mieux saisir les enjeux, la premi\u232?re partie
expose les pr\u233?requis, puis d\u233?crit le processus et les activit\u233?s pr\
u233?paratoires indispensables : d\u233?finition des objectifs et du p\u233?rim\
u232?tre, analyse des parties prenantes, planification de l'\u233?laboration. La
deuxi\u232?me partie d\u233?taille les quatre grandes \u233?tapes de cette m\u233?
thode (recueil, analyse, sp\u233?cification et validation), avec \u224? la cl\u233?
des mod\u232?les de documents, des grilles et des check-lists. Enfin, ta troisi\
u232?me partie porte sur les techniques et les outils de gestion des exigences, et
s'ach\u232?ve par des conseils pour s'am\u233?liorer encore. Gr\u226?ce \u224? cet
ouvrage d'une clart\u233? exceptionnelle, te lecteur sera ainsi pr\u234?t \u224?
relever les d\u233?fis que pose toute mission de d\u233?finition des besoins. \
u192? qui s'adresse ce livre ? \u8226? Aux assistants \u224? la ma\u238?trise
d'ouvrage (AMOA) \u8226? Aux consultants en syst\u232?mes d'information \u8226? Aux
experts techniques et m\u233?tier \u8226? Aux architectes du syst\u232?me
d'information \u8226? \u192? tous ceux qui sont impliqu\u233?s dans l'\u233?
laboration d'un cahier des charges Au sommaire M\u233?thodologie. La m\u233?thode
en action. Les enjeux d'une bonne d\u233?finition des besoins. Comp\u233?tences et
savoir-faire. Exigences et cycle de vie du logiciel. La d\u233?marche. D\u233?finir
le concept et les objectifs. Planifier le projet d'\u233?laboration. D\u233?
veloppement des exigences. L'\u233?tape de recueil. Les cas d'utilisation. L'\u233?
tape d'analyse. Les exigences non fonctionnelles. Exigences projet et contraintes
techniques. L'\u233?tape de sp\u233?cification. Structure du cahier des charges.
L'\u233?tape de validation. Am\u233?liorer le processus. Faire vivre les exigences.
La gestion des exigences. Les outils. Au-del\u224? des exigences. Neuf conseils.
www.editions-eyrolles.com Groupe Eyroles |\par\pard\plain\hyphpar} {\page } }

Langue

Expression Des Besoins Pour Le Système D'information

Transféré par

Informations du document

Description :

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Expression Des Besoins Pour Le Système D'information

Titre original :

Transféré par

Description :

Droits d'auteur :

Formats disponibles

{\rtf1{\info{\title index}{\author Unknown}}\ansi\ansicpg1252\deff0\deflang1033

{\fonttbl{\f0\froman\fprq2\fcharset128 Times New Roman;}{\f1\froman\fprq2\

Centres d'intérêt liés

Vous aimerez peut-être aussi