La Gestion Des Exigences Pour Les Débutants

Les cahiers techniques de CASE France
La gestion des exigences

et le suivi de projet
pour les dbutants
Par Jean-Claude JACQUIOT consultant CASE France & Future Tech Systems
Inc. Paris-Seattle, Fvrier 2014 - jean-claude.jacquiot@case-france.com
Pourquoi grer des exigences ?
Quest-ce que lIngnierie dExigences et le suivi de

projet ?
Requis par les processus CMMI niveau 2
La norme NF X50-151-153 applique aux exigences ?
Plus prcisment
Quel est le but ?

Quest-ce quune exigence ?
Qui les utilise ?
Pourquoi matriser les exigences ?
Do viennent-elles ?
LIngnierie dExigences, cest quoi ?
Spcificits pour lingnierie des systmes
Comment suivre un projet
Les exigences de sret et de scurit
Les difficults de mise en uvre
Comment choisir un outil ?
Ce document explique ce quest lingnierie dexigences, ses principes et ses

techniques. Il sadresse aux responsables projets, aux ingnieurs qualit,
risques, sret-scurit et aux architectes dentreprises, dans tous les
domaines : industrie, services, mdicale, organisation, science, ducation...
En 29 pages, la gestion des exigences et le suivi de projet nauront plus de
secret !
CASE France
Nouvelle dition 2014
2, alle de Londres
91969 Courtabuf Cedex - France
Tl. 01 69 86 95 46
Fax. 01 69 07 03 43
www.case-france.com
Copyright CASE France 2014 La gestion des exigences pour les dbutants
La gestion des exigences pour les dbutants

fonctionnelle pour les dbutants
Gnralits
1 INTRODUCTION
Ce document traite des exigences et des techniques associes leur gestion avec une approche
thorique, gnrale et multi domaines. Comme nous le verrons, les applications sont nombreuses et
tendues un grand nombre de secteurs de lindustrie et de la socit en gnrale. Pour tre
efficace et concret, nous tudierons en dtails leurs utilisations dans lingnierie des systmes (inclus
le gnie logiciel) ainsi que le secteur de la sret et de la scurit. Nous nous contenterons de
mentionner les autres domaines potentiels, qui ne font que reprendre, en les adaptant, les concepts
gnraux.
La gestion des exigences fait lactualit dans de nombreux secteurs industriels, conomiques et
politiques. Autant dire tout de suite que son utilisation couvre un champ dapplications trs vaste,
peut-tre mme encore plus tendu que celui de l Analyse fonctionnelle . Ceci sexplique par le
fait quune exigence est un concept plus gnrique quune fonction. Dailleurs, un lien troit relie ces
deux mondes et cest ce que nous mettrons en perspective tout au long de cette tude.
Selon le Journal du Net,
Composant essentiel des dmarches qualit et d'amlioration des cots, la
gestion des exigences capte les besoins des utilisateurs en amont de tout
projet, facilitant de fait les phases de modlisation [ndlr : de conception] et de
test. (27/06/2005)
En ralit, le concept dexigence est suffisamment gnrique pour tre employ dans virtuellement
tous les domaines de la cration humaine. Il est naturel dans ce cas, que se dveloppe un march
spcifique avec larrive dacteurs qui offrent des solutions techniques et mthodologiques ce
nouveau chalenge.
2 DEFINITION
2.1 Exigence
Ce qui est command par qqch, ncessit, obligation.
Ce qu'une personne exige, rclame une autre.
Source Le Petit Larousse 1996
Mathmatiquement
Exigence = Fonction
Les cahiers techniques de CASE France Copyright 2014

Le terme exigence est considr plus gnrique que le terme fonction . C'est--dire quune
exigence peu avoir les mmes attributs quune fonction et la mme faon de les dfinir et de les
caractriser (spcifier). Seul le contexte dutilisation est diffrent. Dailleurs la norme NF X50-151-153
sapplique aux deux sans distinction.
Dans lindustrie, il est courant de parler propos du mme concept, de fonction quand on est en
phase danalyse fonctionnelle, cela semble logique, et dexigence dans la phase de conception. Ceci
a lnorme avantage de conserver le lien de traabilit sur tout le cycle de vie du projet. Nous y
reviendrons en dtails plus loin dans ce cahier.
2.2 Gestion des exigences

Source Wikipdia
La gestion des exigences consiste grer les exigences hirarchises d'un projet, dtecter les
incohrences entre elles et assurer leur traabilit.
Dans de nombreux mtiers l'expression de ces exigences donne lieu une quantit importante de
documents dont la cohrence et la qualit conditionnent le succs ou l'chec des projets concerns.
3 SECTEURS DACTIVITES CONCERNES

Parmi les secteurs d'activits les plus friands de ce type de solutions, on trouve bien entendu les
industries aux produits les plus complexes et dont l'laboration peut prendre entre 10 et 15 ans,
comme l'aronautique ou l'armement.
Le secteur des tlcoms est galement consommateur de ces solutions, car il bouge trs vite. Si une
entreprise peut faire passer le temps de mise sur le march d'un produit de 6 3 mois, elle est
preneuse ! Du ct des banques, mme intrt, du fait des directives europennes (Ble) et des
normes IAS notamment.
Le secteur de Lnergie nuclaire est actuellement trs actif et demandeur pour la gestion des
exigences de sret et de scurit des centrales.
Cependant, la faon dapprhender les exigences et leur gestion est diffrente selon le domaine
dutilisation et de la position relative de lutilisateur dans ce domaine.
En fait, ce qui fait essentiellement la diffrence, concerne la gense des exigences, leur source, leur
origine, do elles sont issues et leurs finalits.
3.1 LIngnierie des Systmes (IS)

Ce secteur est historiquement le premier sintresser la gestion des exigences. Il inclut bien
videment lingnierie logicielle, qui est comme souvent, le principal moteur mthodologique de
lingnierie. Ici, il sagit de concevoir des produits, systmes ou services conformes aux besoins des
utilisateurs, dans les temps et dans les budgets.

En IS, lorigine des exigences provient idalement dune activit amont : lanalyse fonctionnelle (AF),
qui produit le Cahier des Charges Fonctionnel (CdCF), support originel des exigences, en thorie du
moins. LAF, tant elle-mme drive de lexpression formelle du besoin.
Pour plus de prcisions, lire le cahier technique CASE France : Lanalyse fonctionnelle pour les
dbutants .
Dans lindustrie on parle dingnierie des exigences. Cest un lment du processus dingnierie qui
est compos dactivits lies aux exigences, durant tout le cycle de vie du projet. Diffrents types
dexigences sont couramment utiliss : les exigences de besoin, les exigences fonctionnelles
(fonctions de service) et les exigences non fonctionnelles (fonctions de contrainte) des systmes,
produits ou services tudis. Nous traiterons ce domaine plus en dtail, dans un chapitre appropri.
3.2 La sret et la scurit

Lautre grand secteur en termes de quantit dexigences, concerne la scurit et la sret.
Principalement celle des installations de gnie civil et des sites industriels qui reprsentent les plus
gros dangers. Sans tre exhaustif, dautres secteurs sont galement concerns comme la sant
publique (les organismes), les laboratoires pharmaceutiques, lagroalimentaire, lcologie,
lducation etc. Ces exigences ont gnralement comme origine, une analyse des risques. Le but est
de diminuer larrive ou la gravit dvnements dangereux pour ltre humain, coteux ou
dgradant pour lenvironnement.
3.3 Autres secteurs concerns

Comme on la dj crit, la gestion dexigences est suffisamment gnrique pour tre employe
partout o il est ncessaire de spcifier une action, de suivre sa mise en uvre, son statut et son
volution.
Quelques exemples :
Le suivi des exigences stratgiques dune entreprise est trs en vogue actuellement avec la
gouvernance et larchitecture dentreprise. Lire le cahier technique de CASE France :
Larchitecture dentreprise intgre ;
La gestion des actions de maintenance sur un site industriel ou sur une base militaire sont
aussi des cas dutilisation de la gestion dexigences ;
Les actions sanitaires dans un tablissement de sant public sont traites galement comme
des exigences ;
Les gouvernements produisent des feuilles de route qui sont aussi composes dexigences et qui
heureusement pour les contribuables, ncessite un suivi
Dans tous processus dachat, dacquisition et de fourniture.
Cette liste nest pas exhaustive, beaucoup de domaines peuvent tre concerns, mais on ny pense pas
toujours

4 LE MARCHE DE LA GESTION DES EXIGENCES
4.1 Justification de la gestion des exigences
Chiffres 2009 de source Gartner
En 2009 les approches automatises de gestion des exigences ont permis de rduire le
cot-qualit des dveloppements applicatifs (informatiques) de 30% (avec une
probabilit de 0,8).
En 2009, le niveau de satisfaction des utilisateurs de systmes moyens ou grands dvelopps
avec des processus de gestion des exigences suffisamment automatiss est pass de
Correct Bon ou lquivalent (probabilit 0,8).
En 2009, les cots des phases de maintenance et dextension des systmes moyens grands
dvelopps avec des processus de gestion des exigences suffisamment automatiss ont
baiss de 10% (probabilit 0,8)
Depuis 2008, le march des outils dautomatisation de la gestion des exigences (licences,
services et maintenance) a dpass les 400 millions de dollars par ans (probabilit 0,6)
4.2 Etudes sur les cots et la russite des projets

Lors d'une rcente enqute IBM
Les entreprises interroges sur la gestion des exigences, ont dit subir un cot atteignant
parfois jusqu' 60% en termes de temps et de budget lorsqu'elles utilisaient des pratiques
mdiocres de gestion des exigences (ndlr : on sous-entend ici : Word et Excel) ;
Les entreprises dont les outils d'analyse mtier taient insuffisants enregistraient trois plus
d'checs de leurs projets que de russites ;
Lorsque les exigences sont correctement dfinies et gres, elles permettent de rduire de
prs de 20% les dpassements de projets, grce une rduction du nombre d'exigences
inexactes, incompltes ou oublies.
Selon MAP,
2/3 du cot final d'un systme est dtermin au moment de la formalisation des exigences ;
Un dfaut dtect ds la spcification cote 40 fois moins cher corriger que s'il est dtect
en phase de validation ;
La gestion des exigences est l'origine de 40% des facteurs de russite d'un projet ;
Une mauvaise ou une absence de gestion des exigences est l'origine de 48% des facteurs
dchec dun projet.
5 LA GESTION DES EXIGENCES VUE PAR LE CMMI (Capability

Maturity Model Integration)

Le CMMI est un modle de rfrence du processus dingnierie qui a un succs mondial certain, chez
les concepteurs de gros et moyen projets. Cest un ensemble structur de bonnes pratiques destin
apprhender, valuer et amliorer les activits des entreprises dingnierie.
Pour atteindre le niveau 2 CMMI, la gestion des exigences est obligatoire.
Le CMMI dcrit les activits lies la gestion des exigences dun projet
Obtenir une comprhension des exigences,

Dfinir un ensemble dexigences cohrent par rapport au produit,
Dfinir des critres pour lanalyse et lacceptation des exigences (testabilit, faisabilit ),
Obtenir des engagements sur les exigences,
Inspecter et approuver chaque document dexigences,
Grer les changements sur les exigences,
Maintenir un historique des changements,
Evaluer limpact dune demande de changement,
Maintenir une traabilit bidirectionnelle,
Garder le lien entre une exigence de bas niveau et une exigence de haut niveau,
Tracer les exigences tout au long du projet (design, test ),
Identifier les incohrences entre le projet et les exigences,
Identifier les incohrences dans les plannings, les plans de test
Mettre en place des actions correctives.
Le CMMI est un acclrateur puissant pour le dveloppement du march de lingnierie dexigences.

Cest une source dinspiration et une rfrence pour les PME.
6 POURQUOI MAITRISER LES EXIGENCES ?

6.1 Quapporte la gestion dexigences ?
En ingnierie, la gestion des exigences et de leurs volutions sur tout le cycle de vie d' un projet
matriel, logiciel ou mixte, permet de livrer des produits et des solutions conformes aux attentes des
utilisateurs, dans les dlais impartis et supprime de nombreux problmes de communication :
Exigences floues ou ambigus, cahier des charges inexploitable, manque de visibilit, changements
non contrls, statut du projet inconnu et analyse d'impact impossible mener.
Les exigences sont la base de lentente client-fournisseur car elles forment un contexte contractuel
avec un langage commun. De ce fait, lingnierie des exigences est une activit trs importante du
processus de fourniture et dacquisition.
Dautre part, elle contribue fortement la qualit des produits. Lobtention de la qualit tant un
processus itratif, les exigences sont donc sujettes une forte volution.
En rsum elles permettent de :
Contribuer augmenter la qualit,


Mesurer prcisment la conformit du systme ou du logiciel par rapport aux besoins ou aux
contraintes,
Connatre prcisment le statut du projet,
Dfinir et grer les tests associs,
Evaluer et grer les risques,
Rduire le nombre d'insatisfactions lies au systme ou au logiciel,
Limiter linterprtation, limprovisation et la subjectivit sans pour autant mettre en cause
la crativit,
Donner une base commune de ngociation, de dveloppement, de tests et d'acceptation du
systme ou du logiciel,
Faciliter les changes entre les diffrentes parties prenantes (client, fournisseurs, ...),
Organiser le dveloppement et de matriser les cots et les dlais (notamment lors des
phases d'intgration et de tests),
Suivre lvolution des changements,
Faciliter la maintenance, matriser la prennit (scuriser, rduire l'effort).
Atteindre le niveau 2 CMMI,
6.2 Interprtation des exigences

Une exigence nat gnralement d'une ncessit, d'une insatisfaction ou du dsir d'un utilisateur : les
besoins correspondants peuvent tre perus de diffrentes manires et tre exprims sous
diffrentes formes en fonction des acteurs qui les vhiculent, des contextes dans lesquels ils sont
utiliss ou analyss, de la prise de conscience progressive des concepts qu'ils supportent et de leur
faisabilit.
Il est donc indispensable que l'expression des exigences ne puisse pas tre interprte
diffremment selon les acteurs.
Cest le rle de la norme NF X50-151-153 qui dcrit la faon de dfinir qualitativement et de
caractriser quantitativement une exigence.

Les exigences et lingnierie
7 LA GESTION DES EXIGENCES DANS LINGENIERIE DES
SYSTEMES
Historiquement cest le premier secteur consommateur de gestion des exigences. Ici, on utilise
souvent le terme Ingnierie dExigences (IE).
7.1 Ce quest une exigence pour lingnierie

En ingnierie, et plus particulirement dans les procdures d'appel d'offres publiques et prives, les
exigences sont l'expression d'un besoin document sur ce qu'un produit ou un service particulier
devrait tre ou faire. Elles sont le plus souvent utilises dans un sens formel dans l'ingnierie des
systmes et dans l'ingnierie logicielle. Idalement, elles sont le produit dune analyse fonctionnelle.
Dans l'approche classique de l'ingnierie, les exigences sont considres comme des prrequis pour
les tapes de conception et de dveloppement d'un produit.
La phase de dveloppement et de gestion des exigences peut avoir t prcde par une tude de
faisabilit, et/ou mieux, une phase d'analyse fonctionnelle et conceptuelle du projet.
Lactivit de gestion des exigences peut tre dcompose en phases :
Capturer : obtenir les exigences en provenance du passeur dordre, sous une forme utile ;
Mettre jour les exigences: rassembler la dernire version des exigences des parties
prenantes;
Organiser : classer les exigences avec une mthode approprie au contexte: Par domaines,
par approche systmique, par mtiers, par technologies, par documents etc.
Analyser : vrifier la cohrence, l'exhaustivit et la non redondance, la complexit, le volume
etc.
Dfinir: dcrire les exigences sous une forme standard, rationnelle et aisment
comprhensible par les utilisateurs et les dveloppeurs, normalise de prfrence ;
Spcifier: crer une interaction initiale entre les exigences et la conception (souvent
synonyme de caractrisation);
Valider les exigences : aprs expertise des livrables et de la compltude ;
Historiser : suivre lvolution des changements et grer les demandes de modifications
Archiver : en fin de projet
7.2 Les rles des acteurs

Dans lindustrie, il est dusage de considrer les acteurs dun projet selon quils en sont les principaux
bnficiaires ou les concepteurs. Ce qui correspond respectivement aux termes de matrise
douvrage MOA et de matrise duvre MOE.

Ces rles sont les mmes, quil sagisse de socits diffrentes (passeurs dordres avec sous-traitants)
ou de services diffrents lintrieur dun mme organisme. Cependant, la perception des exigences
est trs diffrente en fonction du rle et de la position relative de lutilisateur par rapport au projet:
La MOA verra les exigences comme les fonctions de son cahier des charges fonctionnel
La MOE verra les fonctions du cahier des charges comme des exigences raliser
Dans le cas de la MOA les exigences sont les fonctions produites par lexpression du besoin et son
analyse fonctionnelle.
Pour la MOE, il y a deux cas :
La MOE peut poursuivre lanalyse fonctionnelle externe de la MOA par une analyse
fonctionnelle interne du produit et recenser les fonctions techniques de ses solutions. Le
cahier des charges de la MOA avec lanalyse fonctionnelle interne de la MOE forme
lensemble des exigences du projet raliser : La STB.
La MOE ne fait que suivre les fonctions du cahier des charges dtaill en STB (qui inclut dj
lanalyse fonctionnelle interne), elle drive alors les exigences client avec des exigences
techniques (conception - solutions). Lensemble constitue la liste des exigences raliser et
grer. Cest de la gestion dexigences pure.
En rsum, soit on voit les exigences comme le produit dune analyse fonctionnelle, soit comme une
liste dexigences fournie par la MOA, quil faut raliser et grer et ventuellement complter avec ses
propres exigences techniques, de conception, de qualit, de scurit, de normes etc.
7.3 Analyse fonctionnelle versus gestion dexigences

Historiquement et curieusement les concepts de fonctions et dexigences ont volus paralllement
dans lindustrie. Certaines personnes faisant de lAF et dautres de la gestion dexigences, sans
obligatoirement faire un lien direct entre les deux.
Quand on fait de lanalyse fonctionnelle, il semble vident dappeler les lments de cette activit :
des fonctions et non pas des exigences . Cest cette ambigit sur le nom qui a favoris (entre
autres) la sectorisation des marchs.
Aujourdhui on voit des marchs distincts, avec des diteurs de solutions danalyse fonctionnelle et
dautres diteurs de solutions de gestion dexigences. Rares, sont ceux qui intgrent les deux
concepts. Cependant, il en existe au moins un
Les plus grands fournisseurs de logiciels de gestion des exigences, par exemple DOORS pour nen
citer quun, nont toujours pas fait le lien avec lAF. Ainsi il est quasiment impossible de conserver
efficacement la traabilit des changements entre MOA et MOE, car il ny a pas de lien dynamique
entre les outils danalyse fonctionnelle et les outils de gestion des exigences proposs. Pourtant les
liens de dpendance sont au plus forts, lun tant le produit de lautre. Ceci est une lacune
importante, car le plus gros intrt de la gestion dexigence est justement ses possibilits de
traabilit amont et aval et donc avec lexpression du besoin.

Les liens, parce quil en faut bien, sont alors archaques et passent par des procdures
unidirectionnelles dimportation de texte depuis Word ou Excel, que lon appelle capture ou
import . Bien que nous saisissions lintrt ponctuel dutiliser des outils de bureautiques, il est
facile de comprendre les avantages dun rfrentiel centralis et dun outil commun (IHM) aux
deux. Curieux march que celui de la gestion des exigences !
7.4 Sources des exigences
Nous lavons dj crit, lanalyse fonctionnelle (AF) est la source naturelle des exigences, elle
en est la gense. Elle permet lexhaustivit et la justification des exigences par rapport au
besoin exprim, sur tout le cycle de vie du projet et avec tous les acteurs.
Les exigences ne tombent pas du ciel Elles sont le produit de lAF formelle ou non et sont
livres avec le CDCF et ou la STB, ou de faon dynamique avec la base de donnes, lorsque
les outils dAF et de gestion des exigences sont intgrs,
La mthode la plus courante se fait avec une liste dexigences, livre le plus souvent dans des
fichiers Word, Excel ou PDF, selon des formats libres et aussi divers que varis. Ces
fichiers sont ensuite imports dune faon ou dune autre dans loutil de gestion des
exigences. Cette mthode est utile, mais malheureuse car elle coupe le lien dynamique
bidirectionnel avec loutil dAF. On perd la traabilit de couverture avec lexpression du
besoin, qui est la vraie rfrence du projet ;
Manuelle,
Depuis un autre outil (par exemple en XML),
Rcupres dun projet prcdent.
7.5 Qui intervient dans la gestion des exigences ?

Selon le cas :
Le commanditaire ou demandeur (directeur de programme, chefs de projet, consultants...) :

Celui qui fait (ou fait faire) lanalyse fonctionnelle et qui est un bnficiaire direct des
conclusions de lanalyse ;
Les acteurs du dpouillement dappels doffres ;
Les responsables chargs daffaires ou de projets : suivit de projet ;
Les responsables chargs dtudes : les concepteurs des solutions techniques ;
Les responsable systmes : ddis un systme ;
Les experts qui doivent expertiser et valider le travail de la MOE ;
Les responsables des tests ;
Les responsables sret-scurit;
Les responsables de la recette (lors de la livraison).
La gestion dexigences est un travail collaboratif.
10

7.6 Quand fait-on de la gestion dexigences ?
En plus de la phase danalyse fonctionnelle :
Lors du dpouillement dappels doffres ;

Pendant la conception ;
Avec le suivi de projet, pendant la phase dexpertise ;
Pendant les tests ;
Durant lanalyse des risques
Au moment de la recette/livraison ;
Lors damlioration, de changements ou dvolution ;
En phase de maintenance ;
Lors du dmantlement du produit.
La gestion dexigences en phases de dfinition du besoin et danalyse fonctionnelle tant celles qui
ont le plus dimpact sur le projet.
7.7 Distinguer plusieurs sortes d'exigences

Dans l'ingnierie des systmes, une exigence peut tre la description de ce qu'un systme doit faire.
Ce type d'exigence spcifie quelque chose que le systme livr doit tre capable de faire.
Un autre type d'exigence spcifie quelque chose sur le systme lui-mme, et de quelle manire il
excute ses fonctions. De telles exigences s'appellent souvent exigences non fonctionnelles,
exigences de performance. Exemples de ce type d'exigences : la disponibilit, la testabilit, la
facilit de maintenance et la facilit d'utilisation.
Il est possible de multiplier les types dexigences afin dtre plus spcifique. Cependant une bonne
mthodologie propose toujours de rduire au maximum la diversit des types pour les rendre plus
gnriques, donc plus facilement applicables plus de domaines et ainsi simplifier les choix, la
comprhension et la gestion.
En ingnierie, les exigences sont classes gnralement en trois catgories :
1) Exigences fonctionnelles - Elles dcrivent les caractristiques du systme ou des processus que le
systme doit excuter. On trouve dans cette catgorie les rgles mtiers, et les exigences
fonctionnelles de scurit (confidentialit,...). Elles correspondent aux fonctions principales et de
service de lanalyse fonctionnelle.
2) Exigences non fonctionnelles - Elles dcrivent les proprits que le systme doit avoir ; par
exemple les exigences techniques de scurit informatique (confidentialit, intgrit, disponibilit),
de performance, d'accessibilit, selon des critres dfinis. Elles correspondent aux fonctions de
contrainte de lanalyse fonctionnelle.
3) Contraintes : Les limites du dveloppement en quelque sorte: comme dfinir un systme
d'exploitation sur lequel le systme doit fonctionner, ou dfinir quel langage de programmation doit
11

tre utilis pour mettre en uvre le systme. Elles correspondent galement aux fonctions de
contrainte de lanalyse fonctionnelle.
On voit quil est possible de rduire deux le nombre de types dexigences, sans perte dinformation,
en regroupant les exigences non fonctionnelles avec les contraintes. Ce que font dailleurs les
mthodes danalyse fonctionnelle.
8 ELEMENTS DEXIGENCES
8.1 Expression qualitative dune exigence
8.1.1 Identification (Id)
Une exigence est identifie par une numrotation (ex.: Ec01, Ef01) La structuration des exigences
peut se reprsenter comme ceci : Ec01-01 (reprsente la sous exigence de contrainte 01 de
lexigence Ec01) etc. Lutilisation du signe - matrialise le niveau.
Notez que dans ce cas, il est recommand de mettre systmatiquement un 0 (zro) devant tous les
nombres compris entre 1 et 9, afin de pour pouvoir faire ultrieurement et correctement des tris
alphanumriques.
Note : Ici, la signification des symboles des prfixes Ef : Exigence fonctionnelle et Ec : Exigence non
fonctionnelle (de contrainte), ces symboles sont arbitraires et peuvent tre changs.
8.1.2 Formulation (Libell)
Le libell est formul par un verbe linfinitif (action) suivi dun ou plusieurs complments
(Pour qui? Sur quoi?),
Choisir des verbes daction plutt que la forme passive ( Faire plutt que Permettre ),
Elle ne doit pas prjuger ni dune solution ni dun principe technique (ex.: Lier plutt que
visser),
Ne crer une nouvelle exigence que lorsque cest indispensable.
Une description plus dtaille doit galement tre possible lorsque cest ncessaire, mais dans un
champ description spar.
8.2 Expression quantitative dune exigence

Certains parlent de spcification, nous verrons cela plus bas.
8.2.1 Caractrisation (norme NF X50-151-153)

Cest la dfinition de critres dapprciation et de niveaux de performance qui permettront la MoA
de valider le choix dune solution technique. Une exigence caractrise doit avoir au moins un
critre, un critre, au moins un niveau et un niveau, une seule flexibilit.
12

8.2.2 Critres dapprciation
Caractre retenu pour apprcier la manire dont une exigence est remplie ou respecte (largeur,
couleur, dure de vie...).
Choix des critres : Exemple pour un stylo, on souligne les mots cls :
Ef01 Laisser une trace sur un support
Nature du support
Dure de vie
Couleur de la trace
Temps de fixation de la trace
Largeur de la trace
8.2.3 Niveau de performance demand

Echelle dapprciation dun critre. Un critre peut avoir plusieurs niveaux. Chaque niveau comprend
au minimum :
Un niveau de performance. Ex.: 0,5 mn

Dautres paramtres peuvent tre ajouts. Ex.: Limite (tolrance). Ex.: +/- 0.1 mn - Taux
dchange (pour lanalyse de la valeur).
8.2.4 Flexibilit
A chaque niveau, doit obligatoirement tre dfinie une flexibilit. La norme propose la dnomination
suivante :
F0 - naccorde aucune flexibilit. A un caractre obligatoire et contractuel,

F1- accorde une flexibilit ngociable. Peut tre lie un critre dchange. Exemple : si on
ne peut atteindre la performance demande, alors le critre prix doit tre x% plus faible,
On rencontre dautres flexibilits : F2, F3. Elles indiquent des degrs varis de ngociation.
8.3 Rsum Exigence-Critres-Niveaux-Flexibilit

Exigence
Critre
Niveau
Flexibilit
Ef01 Laisser une trace sur un support

Ef01Cr01 Largeur de la trace
Ef01Cr01Ni01 0.5 mn (+/-01mn) F0
Ef01Cr02 Dure de vie
Ef01Cr02Ni01 1 Km (-500m)
F1
...
13

Note : Ici, la limite (tolrance) est intgre dans le niveau.
8.4 Choix du systme de caractrisation (de spcification) des exigences
Caractrisation de toutes les exigences tous les niveaux

Caractrisation uniquement des exigences lmentaires (celles qui ne se dcomposent pas)
En toute rigueur, le deuxime choix vite la divergence des critres et des niveaux avec les exigences
parentes. Lautre avantage est la limitation du nombre de critres et de niveaux, ce qui est toujours
une bonne nouvelle quand on doit grer des milliers de dexigences.
On remarque que dans lindustrie on justifie, selon sa spcificit, son savoir-faire et son exprience,
une solution plutt quune autre et il existe des partisans farouches du premier choix.
Cest une dcision importante, mais non stratgique pour la russite du projet.
Exemple de caractrisation des exigences lmentaires (2me choix) :
Exigence
Critre
Niveau
Flexibilit
Ef01 Libell de Fp01 (pas de critre ni de niveau pour cette exigence)

Ef01-01 Libell de Fp01-01
Ef01-01Cr01 Critre de Fp01-01
Ef01-01Cr01Ni01 Niveau de Ef01-01Cr01 F0
Ef01-02 Libell de Ef01-02
Ef01-02Cr01 Critre de Ef01-02
Ef01-02Cr01Ni01 Niveau de Ef01-02Cr01 F1
...
8.5 Dfinition des attributs dune exigence

Une exigence possde divers attributs qui facilitent sa gestion et son suivi. La liste ci-dessous nest
pas exhaustive car certains attributs sont propres un mtier, un savoir-faire, une tradition ou un
besoin spcifique. En conclusion, cette liste doit tre complte ou adapte au besoin. Cest un des
lments cl de la phase de paramtrage de loutil.
Quelques exemples dattributs (liste non exhaustive)
Stabilit (bas-haut-moyen)
Difficult (bas-haut-moyen)
Priorit (bas-haut-moyen)
Compltude
Date dobjectif (livraison)
14

Statut (approuv-non-approuv-non vrifi)

Avis de conformit (conforme non conforme non expertis en cours dexpertise)
Avis de sret-scurit et des risques de dveloppement
Avis de tests
Nom de lexpert - Avis dexpert Date de conformit
Imposition et justification de solutions
Autres
8.6 Attributs de lien

Une exigence est quasiment et systmatiquement lie dautres lments, par exemples :
A des exigences drives (exigences techniques)

A des exigences lies (du domaine fonctionnel) dont la ralisation dpend dune ou de
plusieurs autres exigences dfinies dans un autre domaine (typiquement normatif))
A des sous-exigences (arborescence dexigences)
A des spcifications (si pas de caractrisation)
A des variantes (solutions fonctionnelles ou de conception)
A des cas dutilisation (Use Case)
A des sous-systmes (approche systmique)
A des rfrences (internes ou externes)
A des tests (et des rsultats de tests)
A des risques (et leur barrires)
A des documents externes (norme, lois, chapitre du CDCF, expertise)
Il est indispensable des pouvoir paramtrer ces liens en fonction du besoin.
8.7 Fonctionnalits associes la gestion dexigences

8.7.1 La traabilit
La traabilit est la possibilit de lire facilement ce qu'il est advenu et ce qu'il est cens advenir de
quelque chose.
La traabilit des exigences est le fait de pouvoir tout instant connatre facilement l'origine et les
liens entre les exigences, ainsi qu'entre les exigences et le reste du projet ou le contexte (notamment
les besoins des utilisateurs, les objets de la conception, les risques et les tests). Un exemple : La
traabilit de couverture des exigences techniques avec les exigences client.
Traabilit bidirectionnelle : Pouvoir tracer une exigence depuis son plus haut niveau jusqu'au plus
bas et rciproquement. Depuis les exigences du client vers les exigences techniques et
rciproquement.
Elle aide rpondre aux questions du type :
D'o vient une exigence ?

15

La solution ralise est-elle conforme aux exigences du client ?

De quelle(s) autre(s) exigence(s) cette exigence est-elle dpendante
Cette exigence est-elle ncessaire ?
Couvre-t-elle un besoin ?
Cette exigence est-elle couverte par des exigences de conception ?
Dans quel systme/lot met-on en uvre cette exigence ?
Quels sont les risques lis cette exigence ?
Comment testera-t-on cette exigence ? Quels tests ?
Toutes les exigences sont-elles prises en compte (compltude) ?
Et si non, quel est le pourcentage d'exigences qui restent prendre en compte ?
Quelles sont les exigences non (encore) prises en compte ?
Quel est l'impact du changement d'une exigence ?
Quel est le statut des difficults en cours ?
Quel est le statut du projet ?
Etc.
La traabilit va plus loin que le simple contexte de la gestion des exigences. Dans un projet, il est
trs utile de la prolonger aux phases amonts, lanalyse fonctionnelle (CDCF) et lexpression du besoin
ainsi quaux phases avales, notamment vers lexpertise, le suivi de projet et bien sr la maintenance
et le dmantlement.
La gestion des exigences est llment essentiel du suivi de projet.
8.7.2 Gestion des tats et de la compltude (gestion dvnements - Workflow)

8.7.2.1 Les tats
Un projet est essentiellement une affaire dquipe comprenant un nombre consquent de parties
prenantes ayant des rles et des objectifs diffrents (nous aborderons en dtail la gestion des rles
dans un prochain chapitre). Chacune des parties prenantes intervient sur les exigences en donnant
des avis ou en prcisant une date, un tat, un jalon etc.., relatif son rle. Ces lments doivent tre
scuriss, par exemple : une personne ne peut modifier les avis d'une autre. Par contre l'volution de
certains attributs d'une exigence doit pouvoir invalider certains statuts. Par exemple, la modification
du libell d'une exigence implique sa rvaluation complte par la chane de suivi, donc l'effacement
automatique de certains attributs. Ce fonctionnement est similaire un "WorkFlow". C'est de
l'ingnierie d'exigences, et lon voit que des mcanismes complexes se mettent en route et quil
faudra les grer.
L'ensemble des tats consolid reprsente le statut global du projet un instant "T". Afin de mieux
comprendre les volutions, il est recommand d'historiser chacun des statuts.
8.7.2.2 La compltude des exigences
Comme nous le verrons en dtail dans un prochain chapitre, les exigences sont organises en
arborescence de sous-exigences. On dit drive les exigences. On considre lexigence complte si
toutes ses sous-exigences sont elles-mmes compltes et valides et ceci jusqu la feuille de
larborescence. Loutil doit pouvoir calculer automatiquement la compltude sur toute
16

larborescence. Il peut galement afficher un symbole de validation, par exemple une coche verte,
lorsquune exigence et sa structure sont dclares compltes et valides.
L'ensemble de ces donnes, pour toutes les exigences, reprsente le statut global du projet un
instant "T".
Maintenant, on comprend mieux pourquoi les outils de gestion des exigences performants peuvent
apriori paratre chers.
8.7.3 Historisation
Dans lingnierie, comme dans la vie, tout change frquemment. Le changement est le moteur de
lvolution, de lamlioration du service et de la qualit des produits, condition de bien le grer.
Lenregistrement des changements afin de comprendre lvolution dune exigence est primordial. Il
nest pas ncessaire de tout historiser , cela peut engorger la base de donnes, mais plutt, de
slectionner les attributs essentiels tels que le libell et la raison des changements, la date et le nom
de la personne ayant effectu ces changements. Cette fonction est une aide efficace pour expliquer
bon nombre de difficults et trouver des solutions. Elle est trs apprcie par les responsables de
projet.
8.7.4 Gestion des demandes de modification

Lie lhistorisation, la gestion des changements permet le suivi des demandes, dvaluer leur
pertinence, limpact sur le projet et leur statut. Cest un lment cl de la qualit et de la prennit
du projet.
8.7.5 Les demandes dapprobation

La gestion dexigences est presque systmatiquement un travail dquipe. Lors dune modification,
les responsables des exigences lies ou drives doivent tre informs immdiatement afin
dapprouver le changement. Couramment ceci se fait par lenvoi automatique demails de
demande dapprobation .
8.7.6 Gestion des points ouverts

Tout nest pas parfait en ingnierie et des difficults interviennent dans la ralisation des exigences.
Celle-ci ou celle-l nest pas valide par lexpert car les niveaux des critres ne sont pas atteints. Dans
ce cas on peut crer un point ouvert . Il sagit de dfinir un responsable du suivi), de dfinir des
dates douverture, dobjectif et de fermeture, un statut et de prciser les actions entreprendre.
Ainsi les responsables du projet pourront tracer les exigences posant encore des problmes et
ventuellement les filtrer avec des critres. Ils pourront dterminer objectivement et tout moment,
le statut du projet.
8.7.7 Gestion des indicateurs cls

Il est du ressort des outils de gestion des exigences de fournir des fonctions daide la dcision. Ils
sont senss calculer et afficher des indicateurs cls de gestion, par exemple en termes de :
Quantit : correspondant au nombre dexigences filles chaque niveau.

Complexit : correspondant au nombre dexigences lies
17

Nombre dlment impliqus : Par exemple, des fonctions ou des lignes de code
Effort ncessaire : en jours, semaines, mois.
Ces informations concernent chacune des exigences et doivent tre consolides sur toute la
hirarchie. Ces donnes sont ensuite affiches dans des tableaux de bord avec des lments calculs
tels que : Les valeurs mini/maxi, les totaux, les moyennes et le nombre dlments concerns.
Ces donnes sont des outils daide la dcision pour le responsable du projet.
8.7.8 Gestion des risques de dveloppement

Il sagit ici des risques de dveloppement. Nous tudierons les risques fonctionnels dans un autre
chapitre. En fonction de facteurs de risques associs des coefficients, on calcule le Risque
technique et le Risque global de dveloppement pour chaque exigence. Ces informations
consolides seront utilises pour dfinir les priorits, les besoins de formation du personnel,
organiser et dimensionner les ressources. Ce sont des aides la prise de dcision.
8.7.9 Gestion des retours dexprience (REX)

Lanalyse et la gestion dexigence sont des moyens puissants pour capitaliser linformation afin de la
rutiliser dans dautres projets. Il est donc intressant de prvoir des attributs de retour dexprience
appropris (REX fonctionnels ou organiques) pour chaque exigence et de les grer globalement (base
de donnes REX inter projet). Cest un plus important qui contribue valoriser le savoir-faire de
lentreprise.
8.8 Hirarchisation des exigences

En thorie, toutes les exigences peuvent tre structures. C.--d. quelles peuvent se dcomposer (on
dit aussi : driver) en autant de sous exigences que ncessaire, sans limitation du nombre de niveau
(hirarchisation). Lensemble crant une arborescence dexigences (arborescence fonctionnelle).
En pratique, et pour respecter la mthode et contrler la complexit, une exigence ne doit pas
comporter plus de 7 (+/- 2) sous exigences. Le nombre des niveaux doit tre juste ncessaire
une parfaite comprhension et exhaustivit, dans la limite de lobjectif de ltude (lexprience de
est significative).
8.9 Travail collaboratif

Grer des exigences est essentiellement un travail de groupe qui comprend des parties prenantes
ayant des objectifs et de rles diffrents voir conflictuels. Certaines socits (la SNCF par exemple)
appellent cela une gestion daffaire . Une affaire tant dans ce cas synonyme de programme ou de
projet.
Deux critres pour le travail collaboratif sur des exigences :
8.9.1 Multiutilisateur
Pouvoir travailler simultanment et confortablement plusieurs sur un mme projet, qui est souvent
et physiquement une base de donnes sur un serveur. Ceci veut dire quil faut protger laccs aux
18

donnes pour en garantir lintgrit. La technologie de Check In et de Check Out standard aux
bases de donnes est utilise cet effet.
8.9.2 Gestion des rles et la confidentialit

Comme nous lavons dj soulign plusieurs fois plus haut, un projet peut impliquer plusieurs
quipes et un nombre important de parties prenantes, celles-ci ayant des rles et des objectifs
diffrents.
Certaines informations contenues dans les exigences peuvent tre confidentielles, ou rserves un
rle particulier. Il est alors important de pouvoir contrler laccs (lecture-criture-gestion) ce type
dinformation. Pour cela nous devons dfinir des privilges et des droits daccs.
Des rles correspondants des degrs de responsabilit sont dfinis pour la MOA et la MOE. Le
travail est souvent rparti par mtiers, comptences ou responsabilits de sous-systmes.
Lorganisation du travail collaboratif consiste former des quipes et affecter (mapper) les droits
daccs des exigences, des structures dexigences (une arborescence particulire dexigences
concernant par exemple un sous-systme ou un mtier, ou une technologie), des attributs
dexigence, des rles particuliers ou des groupes dutilisateurs.
On la vu dans un chapitre prcdent, la gestion des rles est ncessaire pour contrler efficacement
la gestion des modifications.
8.10 Gestion des tests

Dans un processus dingnierie en V avec gestion des exigences, les tests reprsentent la branche
montante. Ils sont composs de tests unitaires associs chaque exigence technique et des tests
organiques qui correspondent chacune des exigences clients. Le test final reprsente le niveau
projet, c'est--dire la racine de larborescence des exigences clients.
Une approche systmique est galement possible avec la gestion de la structure organique des soussystmes. Ceci implique une tape daffectation pralable des exigences aux sous-systmes.
8.10.1 Dfinition
Un test est une procdure de validation qui sert mesurer les performances des critres dune
exigence technique selon leurs niveaux prdfinis et leurs flexibilits. Ils sont mis en uvre pour
vrifier que le travail accompli correspond prcisment aux engagements contractuels.
Les tests concernent principalement les exigences techniques qui ont une contrepartie physique.
Cest un scnario et/ou un protocole conu par un expert. Il est rfrenc, identifi et appliqu la
contrepartie physique dune exigence, cest--dire au systme physique qui la ralise. Il propose de
jouer le scnario selon un protocole et de mesurer les rsultats puis de les comparer avec les
performances attendues par les niveaux de performance des critres de lexigence concerne.
19

8.10.2 Structure dun test (testabilit)
8.10.2.1 Avec la caractrisation

Dans le cadre de la norme NF X50-151-153, les tests devront tre structurs pour rpondre aux
niveaux de performance des critres de lexigence en respectant le degr de flexibilit. Cette
approche assure lexhaustivit des tests, les critres tant prcisment les lments tester
contractuellement. Cela rpond la question : Que doit-on tester ?
8.10.2.2 Avec une spcification technique
Dans lautre cas, il sera ncessaire de passer par une tape de spcification technique, soit lie aux
exigences soit aux tests. Cette spcification peut inclure des cas dutilisation en fonction du projet
(logiciel par exemple). En analysant les rsultats, lexpert pourra considrer lexigence valide, non
valide ou en cours de validation.
Un statut, une date de test devront tre prciss, ainsi que le nom de lexpert. Eventuellement un
rapport de test et consign.
Plusieurs tests seront peut tre ncessaires pour couvrir tous les attributs (ou spcifications) dune
exigence. Comme prcdemment, la gestion de lvolution des tests devra ncessiter une
historisation des paramtres critiques.
8.11 Gestion des risques fonctionnels

Pour la science du danger, les exigences sont potentiellement des sources de dangers. Voir le cahier
technique CASE France L'analyse de risques pour les dbutants .
Dans cette phase, il sagit des risques techniques sur les exigences. En ingnierie lAnalyse des Modes
de Dfaillance, de leurs Effets et de leur Criticit (AMDEC) ainsi que les Arbres de Dfaillance (AD)
sont les principaux outils danalyse de risques.
Ceci implique en prrequis quune phase darchitecture produit ait t ralise et quune structure
de systmes ou dquipements existe pour le projet. Voir plus loin, le chapitre sur le suivi de projet.
Les exigences sont alors affectes ( mappes ) dans les sous-systmes (ou quipements). Ainsi,
pour chaque exigence (ou fonction du CdCF) dun systme, on dtermine ses modes de dfaillance,
les causes, les effets, comment les dtecter, les dispositifs de remplacement, la criticit. Celle-ci est
value en fonction de la probabilit (ou frquence), de la gravit et de lacceptabilit du risque
concern.
Certains de ces lments comme le seuil dacceptabilit font partie dune ngociation. Dans le cas
dune criticit trop leve, on mettra en place un systme de barrires (techniques ou opratoires)
de protection ou de prvention. Le but : Rendre les consquences (effets) compatibles avec les
objectifs de sret/scurit du projet.
Arriv ce stade, nous avons alors tous les lments pour produire une AMDEC.
Les informations sont compiles par exigence/fonction et par sous-systme/quipement afin de
gnrer automatiquement et de faon exhaustive un tableau AMDEC.
20

En fonction des types de risques, dautres mthodes et outils danalyse peuvent tre utiliss, pour
exemples : Le modle MADS (Mthode dAnalyse des Disfonctionnement des Systmes) et les
AD (Arbres de Dfaillance). Ceux-ci doivent le cas chant faire partie de la solution.
La prvention est un processus itratif par nature car les barrires mises en uvre peuvent ellesmmes tre source de danger. Il faut donc rvaluer le risque aprs la dfinition des barrires pour
obtenir le risque rsiduel. Le niveau de risque rsiduel acceptable doit donc tre ngoci. Rappel : Le
risque zro nexiste pas !
La gestion de risque consiste aussi rdiger un plan dactions pour suivre : la mise place des
barrires, vrifier leur statut, grer lvolution de la criticit des risques actuels en fonctions des
changements de lenvironnement ou des retours dexprience et dtecter les nouveaux dangers lis
par exemple des modifications au niveau des exigences.
Dans certains projets sensibles, il peut tre utile de mettre en place un suivi des incidents afin
daffiner par retour dexprience, la criticit des risques concerns.
La gestion des risques est une tche couteuse mais ncessaire pour livrer des produits srs et de plus
grande qualit.
La gestion des exigences de sret et de scurit est un concept proche que nous traitons en dtail
dans le chapitre suivant.
Une Exigence
Exemple de relations
Exigences/Spcifications
techniques/Tests/Risques
MdD N
MdD 2
1 n Scnarios de tests
Test N
Test 2
Test 1
1n
MdD 1
1 n Modes de dfaillance (MdD)
Spcification N
Spcification 2
n1
Spcification 1
1 n Spcifications techniques ou Use Cases

Rsum de la structure des risques, des spcifications et des tests dune exigence.
21

9 LE SUIVI DE PROJET
Cest une des activits de la gestion de projet une fois le projet lanc. Elle consiste suivre
lexcution du plan de travail. Gnralement les travaux raliser se formalisent sous forme
dactions, de livrables... Elle prend naturellement la suite de la gestion des exigences avec laquelle
elle est troitement lie et contribue fortement la qualit des produits.
9.1
La mthode : Approche systmique
Dans lindustrie, le suivi de projet est majoritairement bas sur une architecture systme. Dautres
approches sont possibles, par exemple par livrable. Il est possible de mixer les deux. Lapproche
systmique est cependant la plus logique. On commence donc par modliser (cartographier ou
concevoir) la structure du projet en systmes et sous-systmes. En fait, on construit une
arborescence dont chaque sous-systme est li une ou plusieurs exigences du cahier des charges,
quil ralise. Avec cette dmarche, la structure finale est naturellement optimise et conforme au
cahier des charges. Bien videmment pour faciliter les choses et assurer la traabilit il faut que la
gestion des exigences et le suivi de projet partagent le mme rfrentiel.
Dans cette hirarchie, un sous-systme est justifi quand il ralise directement ou par lintermdiaire
dun de ses sous-systmes, une ou plusieurs exigences. Rciproquement, la couverture des exigences
par un ou plusieurs systmes garantie la conformit avec le cahier des charges. Ainsi vous tes
assurs que toutes les exigences sont bien ralises par le systme ou par un de ses sous-systmes.
Dans certains projets multi mtiers (type gnie civil), des structures de systmes peuvent tre
alloues des lots afin de sadresser plus efficacement des professionnels spcialiss.
9.2 La compltude des systmes

La vrification de la compltude du projet et sa validation sont les lments cls pour dterminer le
statut du projet. Un systme est dit complet lorsque tous les sous-systmes de son sous arbre sont
complets et valids et que toutes les exigences lies (et leur structure) sont elles-mmes ralises et
valides.
Ltat du projet, cest--dire de son arborescence, doit tre actualis en temps rel et en mode
collaboratif. Par exemple, lors dun changement sur une exigence, vous savez immdiatement quel
sous-systme est concern et rciproquement.
9.3 Le suivi de projet; une tche collaborative

Comme pour les exigences, un systme est souvent l'affaire de plusieurs parties prenantes :
Responsables projet, systme, scurit, qualit, conception, tests et dexperts internes ou externes
etc. En fonction de son rle, celui-ci va agir sur le systme ou sur ses exigences en modifiant ses
paramtres ddis. La gestion des rles permet de grer la scurit daccs linformation, les
responsabilits des intervenants dans un environnement collaboratif et de rpondre la question
"qui a fait quoi ?".
22

9.4 La gestion des interfaces
Avec la modlisation des systmes, il est facile de sintresser aux interfaces. Celles-ci reliant
naturellement les systmes entre eux pour former un bloc fonctionnel. Leur gestion est un lment
critique dans le suivi de projet car elles font partie intgrante du statut global. Selon les besoins, une
interface peut tre lie (ralise) des exigences fonctionnelles ou normatives, assurant la traabilit
de couverture avec le cahier des charges.
9.5 La gestion des tests systmes

Cette partie est identique la gestion des tests sur les exigences. Un systme hrite des tests lis
chacune de ses exigences. Maintenant on sait en plus quel systme appartient un test.
9.6 La gestion des risques sur les systmes

Voir chapitre 8.11 : La gestion des risques fonctionnels.
23

Les exigences et la sret-scurit
10 LA GESTION DES EXIGENCES DE SURETE ET DE SECURITE
La sret consiste en lensemble des dispositions prvues, au regard des risques de toutes origines
que peuvent prsenter une installation ou un systme tout au long de sa vie pour assurer ses
fonctions dans le respect des exigences de protection du public, des travailleurs et de
lenvironnement.
La notion dexigence de sret est lie lanalyse des dangers dune installation ou dun systme.
Elle vient en aval de lingnierie des systmes. A chaque danger correspond des risques dune
certaine typologie. Afin de rduire larrive dvnements non souhaits, des exigences sont dfinies
en accord avec les objectifs de scurit puis spcifies.
Dans un projet important et pour faciliter leur gestion, les exigences peuvent tre affectes des
sous-systmes qui eux-mmes pourront faire partie dun lot (souvent dtermin par un mtier).
Les risques sont regroups dans les documents danalyse de risques de linstallation ou du systme et
consultables par les diverse parties. Bien entendu, le risque ntant pas une science exacte, les
nombreuses volutions doivent tre suivies. La traabilit des changements est un des lments cls
du processus de gestion des exigences de sret. De multiples variantes dans lorganisation des
activits de sret-scurit sont observes dans lindustrie, souvent en fonction de la culture de
lentreprise et ou du mtier. Il est par consquent primordial davoir un outil versatile, facilement
adaptable (les ingnieurs de sret ne sont pas apriori des informaticiens) et fiable.
La gestion des exigences de sret et/ou de scurit est une tche difficile et dlicate pour les
organisations confrontes aux dangers.
Cette activit, pourtant indispensable et souvent obligatoire est consommatrice de temps et
dnergie. Elle est souvent perue comme frustrante et est relgue dans la classe des enfants
pauvres , car couteuse et sans retour rel mesurable. Cest un pis-aller. Dans ces conditions, les
investissements sont faibles et lutilisation de Word et dExcel est courante. Pourtant, dans
beaucoup de cas, ces outils sont technologiquement dpasss et sources de difficults
supplmentaires comme on la lu dans les chapitres 4.1 et 4.2 consacrs aux tudes marketing.
Dans ce cadre et bien que la source des exigences soit diffrente car elles proviennent trs souvent
dune analyse de risques, lobjectif est dassurer la sret et la scurit des utilisateurs et de
lenvironnement et non pas de crer un produit. Lessentiel de la philosophie, de la mthode et de
lutilisation restent trs semblables lanalyse de risques classique, mais la mise en uvre en est par
contre trs diffrente.
Le besoin de grer des exigences de sret ne se cantonne pas la gestion exclusive des exigences.
En effets dautres lments lis aux exigences sont prendre en compte et grer.
Tel quon peut le voir ci-dessous sur un cas rel dun leader de lnergie nuclaire.
24

Exemple rel denvironnement de gestion des exigences de sret et de scurit

Au-del de la pure gestion des exigences qui est similaire lingnierie des systmes, il est
indispensable de grer les liens avec les autres lments du processus de sret et de scurit.
La tche est simple, il suffit de grer la traabilit entre tous ces lments lors des changements
qui ne manqueront pas dans le temps. Ce dernier est souvent trs long : des dizaines dannes, peuttre plus. On le voit, la gestion des exigences de sret est un processus dont les activits sont
spcifiques ce domaine. La notion dexigence reste tout fois trs proche de celle utilise dans
lingnierie des systmes, bien que souvent adapte et simplifie au niveau de la dfinition
qualitative et quantitative. Les autres fonctions de gestion sont toujours valables : travail collaboratif,
historisation, validation, approbation etc.
11 DIFFICULTEES DE LA GESTION DEXIGENCES

Ce chapitre prsente les problmes courants :
1.
2.
3.
les exigences sont coteuses ;

les exigences sont incomprhensibles ;
les exigences sont incorrectes.
11.1 Exigences coteuses

La gestion des exigences est une activit souvent coteuse, pour les raisons suivantes :
les exigences incluent les moyens de ralisation ;

les exigences sont mal structures ;
le formatage manuel des exigences nest pas normalis ;
les exigences sont incomprhensibles ou incorrectes.
25

11.2 Exigences incomprhensibles
Les exigences sont souvent incomprhensibles, pour les raisons suivantes :
les exigences sont mal structures ;

les exigences sont ambigus ;
les exigences sont difficilement traables.
11.3 Exigences incorrectes

Les exigences sont souvent incorrectes, pour les raisons suivantes :
les exigences sont inexactes ;

les exigences sont incompltes ;
les exigences sont incohrentes ;
les exigences sont invalidables .
11.3.1 Exigences inexactes

Le produit na pas rpondre ces exigences du point de vue du client ou du fournisseur. Elles
proviennent gnralement dune incomprhension du besoin ou dun problme de gestion des
modifications dexigences.
11.3.2 Exigences incompltes

Elles ne couvrent pas tous les intrants et extrants requis, toutes les fonctions requises ou toutes
autres caractristiques telles les performances requises ; ou elles ne sont pas priorises, ne
fournissement pas toutes les informations ncessaires leur comprhension ou comportent
lexpression dterminer .
11.3.3 Exigences incohrentes

Elles se contredisent ou utilisent des termes diffrents, ou synonymes, pour dcrire des mmes
concepts.
11.3.4 Exigences invalidables

Il nexiste aucune procdure acceptable permettant de les valider. Ces exigences utilisent souvent
des intrants ou extrants internes ou des mots imprcis tels que habituel
12 LES OUTILS DE GESTION DES EXIGENCES

12.1 Justification dun outil
Comme toujours, un outil est indispensable pour mettre en pratique les ides. La gestion dexigences
ny chappe pas.
Le besoin de grer des exigences avec laide dun outil se fait sentir trs rapidement, souvent ds que
26

les premiers changements arrivent. On se penche alors naturellement vers des solutions
conomiques une porte de main : Word ou Excel.
Ces solutions semblent priori donnes satisfaction si lon se contente de peu, car elles ne
ncessitent pas de formation, sont largement diffuses, ne cotent rien et surtout ne posent pas de
problme politique : valuation puis standardisation dun nouvel outil quelque peu
STRATEGIQUE . Cest un choix facile, donc un mauvais choix
Ds quil sagit de grer dans le temps et plusieurs plus de quelques dizaines dexigences, les
problmes lis la technologie de ces outils deviennent prohibitifs. Entres autres :
Format des exigences non standardis, non normalis

Accs lInformation difficile car rpartie sur plusieurs systmes
Pas de traabilit
Pas de suivi de lvolution
Donnes non scurise
Pas de travail collaboratif en temps rel
12.2 Difficults mettre en uvre

Se pose alors la question de changer pour un vritable outil de gestion des exigences. Si le travail
dans ces conditions dure depuis longtemps, les difficults pour changer seront importantes voir
rdhibitoires. Les responsables projets, qui ont systmatiquement le nez dans le guidon d la
pression de la hirarchie, verront dun mauvais il larrive dun nouvel outil, qui sera peru comme
un frein et une perte de temps. Depuis leurs fentres , ils nen comprennent pas les avantages.
Leurs visions tant rduite leur propres proccupations : on a travaill comme a depuis
longtemps sans problme, a peut encore durer . La direction aura dans ce cas bien du mal pour
trancher.
Conclusion, il est prfrable de quitter au plus tt ou dviter la solution exclusive Word/Excel
avant que le passif ne devienne trop important et que les habitudes freinent le changement. Dans la
pratique, une solution mixte est prfre : Rdaction des exigences avec Word ou Excel pour des
cas exceptionnels (utilisation par un expert), avec import dans loutil de gestion des exigences. Ceci
obligera les rcalcitrants respecter au moins un certain format.
Dans ce cas, il serait intressant si loutil pouvait gnrer son tour des documents Word ou Excel.
Ceci faciliterait entre autres, la phase dappel doffres, et nobligerait pas les sous-traitants tre
quips du mme outil pour leurs rponses, au moins dans un premier temps. En autre, ces
fonctionnalits permettent le dploiement progressivement et sans heurt. Tout le monde est
content!
12.3 Critres pour choisir un outil de gestion dexigences

Un bon outil de gestion des exigences doit permettre la modification d'un mme item (objet) par de
nombreuses personnes en tenant compte des autorisations attribues chaque personne. Il doit
grer les versions et l'historique.
27

Le premier critre :
Simple paramtrer, mettre en uvre et utiliser avec une bonne IHM. Il ne doit pas tre une
usine gaz pour informaticiens et ne doit pas ncessiter un administrateur temps plein.
Dans la pratique, dautres fonctionnalits sont dterminantes :
Permettre la customisation (un paramtrage) prcise et facilement,

Centraliser et scuriser linformation dans une base de donnes,
Faciliter la saisie, la capture ou limportation dexigences,
Intgrer ou permettre des liens dynamiques avec la phase amont dAF et avale de suivi de
projet (traabilit avec les besoins et lexpertise),
Grer le travail collaboratif : Rles/Privilges,
Permettre de suivre les liens des exigences (traabilit) : Hirarchique (exigences drives),
avec des exigences lies, vers des documents extrieurs, vers les spcifications et les tests,
vers le suivi de projet
Sadapter au mtier : les attributs des exigences et leurs liens doivent tre paramtrables,
Gnrer automatiquement des livrables par mtiers vers Word ou Excel, aux formats de
lentreprise : Logo, entte, pieds de page, table des matires, tableaux divers, chapitrage ,
contenu.
Les fonctions suivantes sont considrer :
Permettre la cration de tableaux de bord dynamiques de rapprochement et danalyse avec

la possibilit de modification directement dans la base,
Grer dautres objets lis aux exigences et dfinir leurs attributs : document de risques, tests,
sous-systmes, lots etc. Afin de crer un processus dingnierie, un workflow avec traabilit,
Demande dapprobation de changement (envoi automatique demail),
Gestion des points ouverts,
Gestion des retours dexprience,
Gestion de la confidentialit.
13 CONCLUSION
Comme nous lavons vu, lintrt dune gestion des exigences concerne un grand nombre de
domaines. Elle contribue efficacement lagilit et la performance de lentreprise et la
valorisation de son savoir-faire.
Elle est obligatoire pour obtenir le niveau 2 CMMI.
Plusieurs dcennies dutilisation sur de nombreux projets : Airbus, TGV, centrales nuclaires etc. en
ont consacr ses bnfices et justifi son utilisation. Sa popularit ne fait que croitre dans le monde
entier. Elle atteint dj certaines PME avec des projets beaucoup plus modestes.
Les bnfices les plus importants sont la traabilit de limpact des changements, cl de la qualit
des produits, et la leve de toute ambigit qui diminue les conflits client/fournisseur et qui amliore
la communication.
28

La gestion dexigence ne ncessite pas une formation approfondie et son cot est faible en regard
des avantages quelle apporte. Elle demande plutt un engagement durable de toutes les parties
prenantes. Nous savons que la difficult la plus importante sa mise en uvre et son succs est
comme toujours, le refus de changer les mentalits. Dire je nai pas le temps , est un prtexte
qui dmontre une mauvaise organisation latente. Persvrer dans le refus est dangereux pour la
prennit de lentreprise. Plus tard rime avec trop tard !
La quantit de donnes et la complexit des liens rendent obligatoire lutilisation dun outil
spcifique et performant sans pour autant compltement abandonner Word et Excel, qui sont
alors utiliss seulement pour la saisie dexigences par certains experts temporaires (ou rcalcitrants),
mais en aucun cas comme moyen de stocker et de grer les exigences.
La disponibilit doutils modernes et conviviaux tel quEnvision Requirements(i) favorise la mise en
uvre de cette technique.
***
*
(i)
Les exemples de ce document ont t crs avec loutil de gestion des exigences : Envision
Requirements version 10.
Pour plus dinformation sur ce produit, consulter
www.case-france.com/exigence2.htm
Ce document est la proprit de CASE France - Copyright CASE France 2014

Utilisation des fins commerciales interdite sans autorisation crite de CASE France.
Copyright CASE France SARL
www.case-france.com
29

Table des matires
1
INTRODUCTION ............................................................................................................................... 2
DEFINITION ...................................................................................................................................... 2
2.1
Exigence ................................................................................................................................... 2
2.2
Gestion des exigences ............................................................................................................. 3
SECTEURS DACTIVITES CONCERNES ............................................................................................... 3

3.1
LIngnierie des Systmes (IS) ................................................................................................. 3
3.2
La sret et la scurit ............................................................................................................ 4
3.3
Autres secteurs concerns ...................................................................................................... 4
LE MARCHE DE LA GESTION DES EXIGENCES .................................................................................. 5

4.1
Justification de la gestion des exigences ................................................................................. 5
4.2
Etudes sur les cots et la russite des projets ........................................................................ 5
LA GESTION DES EXIGENCES VUE PAR LE CMMI (Capability Maturity Model Integration) ............ 5
POURQUOI MAITRISER LES EXIGENCES ? ........................................................................................ 6
6.1
Quapporte la gestion dexigences ? ....................................................................................... 6
6.2
Interprtation des exigences ................................................................................................... 7
LA GESTION DES EXIGENCES DANS LINGENIERIE DES SYSTEMES................................................... 8

7.1
Ce quest une exigence pour lingnierie ................................................................................ 8
7.2
Les rles des acteurs ............................................................................................................... 8
7.3
Analyse fonctionnelle versus gestion dexigences .................................................................. 9
7.4
Sources des exigences ........................................................................................................... 10
7.5
Qui intervient dans la gestion des exigences ? ..................................................................... 10
7.6
Quand fait-on de la gestion dexigences ? ............................................................................ 11
7.7
Distinguer plusieurs sortes d'exigences ................................................................................ 11
ELEMENTS DEXIGENCES ............................................................................................................... 12

8.1
Expression qualitative dune exigence .................................................................................. 12
8.1.1
Identification (Id) ........................................................................................................... 12
8.1.2
Formulation (Libell) ..................................................................................................... 12
8.2
Expression quantitative dune exigence................................................................................ 12
8.2.1
Caractrisation (norme NF X50-151-153) ..................................................................... 12
8.2.2
Critres dapprciation .................................................................................................. 13
8.2.3
Niveau de performance demand................................................................................. 13
8.2.4
Flexibilit ....................................................................................................................... 13
30

8.3
Rsum Exigence-Critres-Niveaux-Flexibilit ...................................................................... 13
8.4
Choix du systme de caractrisation (de spcification) des exigences................................. 14
8.5
Dfinition des attributs dune exigence ................................................................................ 14
8.6
Attributs de lien ..................................................................................................................... 15
8.7
Fonctionnalits associes la gestion dexigences ............................................................... 15
8.7.1
La traabilit .................................................................................................................. 15
8.7.2
Gestion des tats et de la compltude (gestion dvnements - Workflow) ............... 16

Les tats ..................................................................................................................... 16
8.7.2.2
La compltude des exigences .................................................................................... 16
8.7.3
Historisation .................................................................................................................. 17
8.7.4
Gestion des demandes de modification ........................................................................ 17
8.7.5
Les demandes dapprobation ........................................................................................ 17
8.7.6
Gestion des points ouverts ............................................................................................ 17
8.7.7
Gestion des indicateurs cls .......................................................................................... 17
8.7.8
Gestion des risques de dveloppement ........................................................................ 18
8.7.9
Gestion des retours dexprience (REX) ........................................................................ 18
8.8
Hirarchisation des exigences ............................................................................................... 18
8.9
Travail collaboratif ................................................................................................................. 18
8.9.1
Multiutilisateur .............................................................................................................. 18
8.9.2
Gestion des rles et la confidentialit ........................................................................... 19
8.10
Gestion des tests ................................................................................................................... 19
8.10.1
Dfinition ....................................................................................................................... 19
8.10.2
Structure dun test (testabilit) ..................................................................................... 20
8.11
9
8.7.2.1
8.10.2.1
Avec la caractrisation.......................................................................................... 20
8.10.2.2
Avec une spcification technique .......................................................................... 20
Gestion des risques fonctionnels .......................................................................................... 20
LE SUIVI DE PROJET........................................................................................................................ 22
9.1
La mthode : Approche systmique...................................................................................... 22
9.2
La compltude des systmes................................................................................................. 22
9.3
Le suivi de projet; une tche collaborative ........................................................................... 22
9.4
La gestion des interfaces ....................................................................................................... 23
9.5
La gestion des tests systmes................................................................................................ 23
9.6
La gestion des risques sur les systmes ................................................................................ 23

31

10 LA GESTION DES EXIGENCES DE SURETE ET DE SECURITE............................................................. 24
11 DIFFICULTEES DE LA GESTION DEXIGENCES ................................................................................. 25
11.1
Exigences coteuses .............................................................................................................. 25
11.2
Exigences incomprhensibles................................................................................................ 26
11.3
Exigences incorrectes ............................................................................................................ 26
11.3.1
Exigences inexactes ....................................................................................................... 26
11.3.2
Exigences incompltes .................................................................................................. 26
11.3.3
Exigences incohrentes ................................................................................................. 26
11.3.4
Exigences invalidables ............................................................................................. 26
12 LES OUTILS DE GESTION DES EXIGENCES ...................................................................................... 26

12.1
Justification dun outil ........................................................................................................... 26
12.2
Difficults mettre en uvre ............................................................................................... 27
12.3
Critres pour choisir un outil de gestion dexigences ........................................................... 27
13 CONCLUSION ................................................................................................................................. 28
32

La Gestion Des Exigences Pour Les Débutants

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

La Gestion Des Exigences Pour Les Débutants

Uploaded by

Copyright:

Available Formats

Les cahiers techniques de CASE France

La gestion des exigences

Pourquoi grer des exigences ?

Quest-ce que lIngnierie dExigences et le suivi de

Quel est le but ?

Ce document explique ce quest lingnierie dexigences, ses principes et ses

Nouvelle dition 2014

La gestion des exigences pour les dbutants

Les cahiers techniques de CASE France Copyright 2014

La gestion des exigences pour les dbutants

2.2 Gestion des exigences

3 SECTEURS DACTIVITES CONCERNES

3.1 LIngnierie des Systmes (IS)

Les cahiers techniques de CASE France Copyright 2014

La gestion des exigences pour les dbutants

3.2 La sret et la scurit

3.3 Autres secteurs concerns

Les cahiers techniques de CASE France Copyright 2014

La gestion des exigences pour les dbutants

4.2 Etudes sur les cots et la russite des projets

5 LA GESTION DES EXIGENCES VUE PAR LE CMMI (Capability

La gestion des exigences pour les dbutants

Obtenir une comprhension des exigences,

Le CMMI est un acclrateur puissant pour le dveloppement du march de lingnierie dexigences.

6 POURQUOI MAITRISER LES EXIGENCES ?

Contribuer augmenter la qualit,

La gestion des exigences pour les dbutants

6.2 Interprtation des exigences

Les cahiers techniques de CASE France Copyright 2014

La gestion des exigences pour les dbutants

7.1 Ce quest une exigence pour lingnierie

7.2 Les rles des acteurs

La gestion des exigences pour les dbutants

7.3 Analyse fonctionnelle versus gestion dexigences

La gestion des exigences pour les dbutants

7.4 Sources des exigences

7.5 Qui intervient dans la gestion des exigences ?

Le commanditaire ou demandeur (directeur de programme, chefs de projet, consultants...) :

La gestion dexigences est un travail collaboratif.

Les cahiers techniques de CASE France Copyright 2014

La gestion des exigences pour les dbutants

Lors du dpouillement dappels doffres ;

7.7 Distinguer plusieurs sortes d'exigences

Les cahiers techniques de CASE France Copyright 2014

La gestion des exigences pour les dbutants

8.1.2 Formulation (Libell)

8.2 Expression quantitative dune exigence

8.2.1 Caractrisation (norme NF X50-151-153)

Les cahiers techniques de CASE France Copyright 2014

La gestion des exigences pour les dbutants

Ef01 Laisser une trace sur un support

8.2.3 Niveau de performance demand

Un niveau de performance. Ex.: 0,5 mn

F0 - naccorde aucune flexibilit. A un caractre obligatoire et contractuel,

8.3 Rsum Exigence-Critres-Niveaux-Flexibilit

Ef01 Laisser une trace sur un support

La gestion des exigences pour les dbutants

8.4 Choix du systme de caractrisation (de spcification) des exigences

Caractrisation de toutes les exigences tous les niveaux

Ef01 Libell de Fp01 (pas de critre ni de niveau pour cette exigence)

8.5 Dfinition des attributs dune exigence

La gestion des exigences pour les dbutants

Statut (approuv-non-approuv-non vrifi)

8.6 Attributs de lien