Association

Franaise
dIngnierie
Systme

Recommandations pour llaboration d'un

rfrentiel d'exigences techniques

Auteurs :
G. FANMUY
G. LEVY
J. FOISSEAU
P. LAMOTHE
B. HERMANS
P. DE CHAZELLES
E. CHOVEAU

(DASSAULT-AVIATION)
(ALCATEL)
(ONERA Toulouse)
(PSA Peugeot Citron)
(GIAT Industries)
(AIRBUS Industrie)
(EADS Airbus)

Abstract
Ce document prsente le concept dexigence . Il liste
des bonnes pratiques dlaboration dun rfrentiel
dexigences techniques. Il dcrit lintrt dun tel
rfrentiel.
A) Introduction
1 Problmatique
Lingnierie des exigences est la cl du dveloppement de systmes complexes. Dans les
modles de maturit (Capability Maturity Models), lingnierie des exigences est un
facteur essentiel de maturit des processus dingnierie des systmes. Cest galement une
des activits qui influe le plus sur la qualit du systme qui en rsulte.
La dfinition de rfrentiels dexigences est lun des facteurs de succs dun processus
rptable.
Par ailleurs, des tudes ont montr que les erreurs les plus courantes sont celles relatives
la spcification des besoins (ex. tudes Sheldon sur projets de lUS Air Force, Standish
Group). Ces tudes illustrent galement le fait que les erreurs faites en spcification
sont trs coteuses corriger.

2 Objectif
Lobjectif de ce document est d'introduire lingnierie des exigences par une liste de
pratiques essentielles pour laborer un rfrentiel dexigences partir d'un besoin.

AFIS 2001 GT Ingnierie des Exigences

Page 1 / 20

Association
Franaise
dIngnierie
Systme

B) Le concept d'exigence
Notion de besoin exprim
Le besoin nat de la ncessit, dune insatisfaction ou du dsir dun utilisateur en
relation avec un environnement. Lanalyse du besoin consiste alors rvler et
identifier, puis exprimer le besoin (besoin exprim).
Une activit de structuration et de choix permet ensuite de transformer le besoin
exprim en besoin spcifi qui peut tre reprsent par un ensemble dexigences.
Dfinition d'une exigence
Une exigence est un nonc qui traduit (ou exprime) un besoin, des contraintes
(techniques, cots, dlais). Cet nonc est rdig dans un langage qui peut prendre
la forme dun langage naturel, dune expression mathmatique arithmtique
gomtrique, informatique ...
Dans le langage naturel, cet nonc comporte : un sujet, un verbe et un complment.
Exemples :
1) Le groupe de travail Ingnierie des Exigences dcrit les concepts relatifs au
domaine de la spcification.
2) Une partie du travail ralis par le groupe Ingnierie des Exigences est exprim et
formalis sous la forme dun ensemble de bonnes pratiques.
Nota 1 : Une exigence peut tre alloue un composant physique ou logique. Un
Composant physique peut dsigner le systme attendu, un sous-systme, un
quipement, Un composant logique peut dsigner une fonction, une sous-fonction,
une catgorie d'objets
Nota 2 :Toute exigence de bas niveau (i.e. exigence lmentaire) doit tre alloue un
et un seul composant.

Informations associables une exigence

Aux exigences d'une spcification est associe une structure de gestion qui comporte
des informations associes (liste non exhaustive, liste ajuster en fonction des
projets):
Ces informations peuvent tre soit des attributs d'exigences, soit des relations avec des
entits associes l'exigence.
Recommandation : il convient de limiter le nombre d'informations associes aux
exigences ncessaires au projet en rflchissant leffort de gestion associ.

AFIS 2001 GT Ingnierie des Exigences

Page 2 / 20

Association
Franaise
dIngnierie
Systme

Types d'informations
Signification
associables une exigence
Identificateur
Symbole alphanumrique permettant de reprer l'exigence
parmi les autres ; l'identificateur est unique, non
destructible.
metteur
Client, autres parties prenantes : rglementation, normes,
concepteur, cooprants, sous-traitants , exigence drive,

Mthode de vrification et
Ensemble de tches et de moyens permettant d'assurer que
validation
l'exigence est satisfaite (vrification) et que le systme
correspond lutilisation attendue par le client (validation).
Indiquer le type de mthode (inspection, analyse,
dmonstration, essai ou test), et la rfrence de la
description.
Hypothses
Conditions sur la validit de l'exigence (phase du cycle de
vie produit, condition d'environnement, stratgie
d'entreprise )
Justification
lments permettant de dmontrer (ou prouver) le bien
fond ou les raisons du choix de l'exigence.
Relations
Donner les liens avec d'autres exigences ou avec les sources
associs.
Catgorie
Exemples de catgories:
Fonctionnelle, performance, interface, oprationnelle
(disponibilit, maintenabilit, fiabilit, scurit,
vulnrabilit, logistique, environnement, qualit de
service), contrainte , validation.
Criticit
Niveau de criticit vu de lutilisateur. Permet d'aider la
dtermination de l'effort de vrification d'une exigence.
Flexibilit
Capacit de lexigence tre ngocie
Priorit
Niveau d'importance pour la prise en compte de l'exigence
par rapport aux autres
Risques
Niveau de risque ou liste des risques engendrs par la prise
en compte de l'exigence exprime tel quel.
tat / maturit
tat d'avancement de l'exigence (li au management du
projet) : nonce, officialise, implmente, satisfaite
Confidentialit
Niveau de confidentialit de lexigence
Choix / compromis /
Trade Off Analysis (EIA 632)
dcision
Historique
Ensemble de repres permettant d'identifier les
modifications qu'a subi l'exigence : date, auteur,
identification et contenu de la modification, type de
modification (ajout, suppression, ), justification ou raison
de la modification.
Commentaires
Remarques pertinentes permettant de comprendre l'origine
de l'exigence, les liens avec d'autres lments

AFIS 2001 GT Ingnierie des Exigences

Page 3 / 20

Association
Franaise
dIngnierie
Systme

3. Recommandations pour llaboration d'un rfrentiel d'exigences systmes

Un processus type d'ingnierie des exigences comporte les activits suivantes:
Activits de capture du besoin: dcouverte / collecte et comprhension / analyse des
besoins utilisateurs / parties prenantes, synthse.
Activits danalyse des exigences : traduction des besoins en exigences techniques
lmentaires, analyse technique des exigences, catgorisation des exigences, synthse.
Activits de vrification et validation des exigences: analyse individuelle de la qualit
des exigences, analyse de cohrence / compltude de l'ensemble des exigences (client,
parties prenantes, technique)
Activits de modification: correction / volution des exigences conscutives aux
diffrentes activits des processus d'ingnierie systme.
Activits d'allocation: dcomposition et allocation des exigences aux composants du
systme (en parallle de la conception du systme)
Activits de management: management de projet (prparation, suivi), gestion de la
configuration des modifications dexigences
Nota : L'activit de management n'est pas traite dans ce document.
Ces activits permettent daboutir un rfrentiel dexigences techniques ngoci et accept
par les diffrentes parties prenantes (utilisateurs, client(s), concepteur, )

MANAGER
Dfinir le plan de
management

Dfinir la gestion
des exigences

valuer l'avancement

SPECIFIER
Exprimer ou faire voluer le besoin
Capturer le besoin

Analyser les exigences

Modifier les exigences

CONCEVOIR
Dfinir la
solution

Allouer les exigences

la solution

VRIFIER ET VALIDER
Vrifier et valider le
besoin et les exigences

Vrifier et Valider la
solution

Le schma prsente une organisation type des activits entre - elles, mais ne prsuppose pas
d'un droulement temporel
Nota: les activits lies aux productions documentaires ne sont pas dcrites. Ce sont des
activits en marge de l'ingnierie des exigences et sont volontairement exclues du prsent
document. Il est considr que si ncessaire, des documents d'exigences peuvent tre labors
partir du rfrentiel d'exigences.

AFIS 2001 GT Ingnierie des Exigences

Page 4 / 20

Association
Franaise
dIngnierie
Systme

3.1. Bonnes Pratiques de Capture du Besoin

BP1.1. Identifiez et consultez toutes les parties prenantes du systme concevoir (acteurs,
entits ou organisations pouvant gnrer des exigences).
Cette consultation doit permettre de capturer lensemble des besoins des parties
prenantes : recherche du besoin rel utilisateur, client ou autres parties prenantes
(maintenance, formation, environnement) - Cf. exemples A.1 et A.2 en annexe.
BP1.2. Formalisez les besoins sous forme dexigences
A ce niveau les exigences peuvent tre incompltes et ne pas prsenter les facteurs qualit
attendus. Si les exigences sont volumineuses, il est recommand de reprer dans le texte les
exigences lmentaires possibles.
BP1.3. tablissez la traabilit descendante et remontante de chaque exigence
Lenregistrement de lorigine (client, utilisateur, concepteur ...) permet de garder la trace
qui a demand lexigence et dans quel contexte (traabilit remontante). Les liens avec les
exigences aval permettent de sassurer que ce qui est spcifi est correctement implment
(traabilit descendante). Cette traabilit dans les deux sens permet deffectuer des
analyses dimpact en cas de modifications. Permet galement danalyser les exigences en
fonction du porteur de lexigence (ex. un seul systme ralis pour plusieurs clients avec
des besoins diffrents). Cf. exemples A.3.1 et A.3.2 en annexe
BP1.4. Utilisez un langage simple et concis pour formuler une exigence.
La formulation dune exigence doit tre claire et sans ambiguts afin dtre comprise.
Typiquement une exigence est btie sur une structure sujet, verbe, complment et se
limiter quelques lignes.
BP1.5. Justifiez lexigence.
La justification de lexigence permet de comprendre lenjeu et la priorit de celle-ci. La
justification peut se limiter dans certains cas la demande client. La justification permet
dviter les cas de sur-spcification. Elle permet galement de comprendre pourquoi
lexigence a t demande.
BP1.6. Dfinissez une structure standard de document pour le recueil des exigences (plan
type).
Lutilisation dune structure standard permet dassurer une meilleure communication des
exigences entre les acteurs du projet et permet de construire un rfrentiel dexigences.
BP1.7. Utilisez des scnarios oprationnels afin de comprendre le besoin rel.
Nota :A ce stade des exigences nouvelles peuvent merger Cf. exemple A.4 en annexe
BP1.8. Vrifiez au moins ladquation des exigences rutilises au nouveau contexte.
La rutilisation dune exigence ou dun ensemble dexigences permet de gagner du temps
dans la phase danalyse et peut tre dans la phase de conception du produit (pr-requis :
existence dun organe rpondant strictement lexigence ou lensemble dexigences). Il
est ncessaire avant de rutiliser de vrifier si le contexte a chang ou non. Cf. exemple
A.5 en annexe
Plus gnralement, avant de rutiliser, il convient de se poser un certain nombre de
questions: vrifier si le contexte a chang, vrifier si l'exigence est justifie

AFIS 2001 GT Ingnierie des Exigences

Page 5 / 20

Association
Franaise
dIngnierie
Systme

3.2. Bonnes Pratiques dAnalyse des exigences

BP2.1. Formalisez les exigences de besoin en exigences techniques
Une exigence doit faire quelques lignes. Attention, trop dcouper une exigence risque de faire
perdre son contexte une fois prise isolment. Lorsque lon a un nombre important dexigences
(> quelques centaines) il faut privilgier la comprhensibilit. Il est parfois prfrable quune
exigence soit associe son contexte, mais que le libell mme de lexigence soit repr dans
le texte.
Utilisez des rgles dcriture pour homogniser les formulations et viter des ambiguts.
BP2.2. Regroupez les exigences techniques en catgories
Laffectation de catgories aux exigences facilite les activits danalyse technique et de
validation par les parties prenantes : compltude des exigences, cohrence des
performances Elle permet de sassurer de limplication de lensemble des parties prenantes
(pas doublis). Il est recommand dutiliser des catgories standard pour une meilleure
efficacit. Cf. exemple A.6 en annexe.
BP2.3. Etablissez la traabilit descendante et remontante de chaque exigence.
Cf. paragraphe 3.1 n3
BP2.4. Justifiez les exigences techniques drives (terminologie EIA632 derived
requirement).
Des exigences techniques peuvent tre rvles au cours du dveloppement (ex. exigences
de conception, exigences normatives). Tout comme les exigences de besoin, leur
justification permet de comprendre lenjeu et leur priorit.
BP2.5. Prvoyez la mthode de vrification et de validation du produit associe chaque
exigence (thorique, exprimentale, examen visuel, simulation, essai ...).
Permet de se poser la question : le produit est-il testable (comment et par quels moyens) ?
Saura-ton assurer la conformit du produit aux exigences (vrification) ; saura-ton
satisfaire les besoins utilisateurs (validation)? Si la testabilit du produit nest pas
acquise, les exigences concernes sont-elles ralistes ? Cf. exemples A.7.1 et A.7.2 en
annexe
Une exigence non testable sur le produit nest pas toujours rejeter.
Une mthode de vrification/validation du produit peut couvrir plusieurs exigences.
Une exigence est en gnral couverte par plusieurs essais.
Assurez la traabilit des mthodes de vrification/validation avec les exigences associes.
BP2.6. Modlisez, simulez pour lever les ambiguts
La modlisation / simulation permet de lever les ambiguts, de prciser/complter des
exigences. Elle permet de se poser les questions sur le besoin rel et de valider le besoin.
BP2.7. Vrifiez au moins ladquation des exigences rutilises au nouveau contexte.
Cf. paragraphe 3.1 n9

AFIS 2001 GT Ingnierie des Exigences

Page 6 / 20

Association
Franaise
dIngnierie
Systme

3.3. Bonnes Pratiques de Vrification et de Validation des besoins et des

exigences
BP3.1. Dfinissez les facteurs de qualit attendus dune exigence/d'un rfrentiel d'exigence
et laborez une liste de vrification.
Checklist : proprits d'une exigence

Concise : pas de hors sujet

Non ambigu : une seule interprtation possible (aspects syntaxique et

smantique)

Ncessaire : quel besoin rpond-elle?

Exacte : vis vis de lexpression initiale du besoin

Atteignable :ralisable, faisable

Vrifiable

Traable
Checklist : proprits d'un rfrentiel d'exigences

Cohrent : pas de contradictions entre exigences ou avec les besoins

oprationnels

Complet : pas d'omissions ni de rfrences inexistantes

Nota : un stade initial du processus (laboration dun premier rfrentiel dexigences
systme), il n'est pas garanti que les exigences soient toutes faisables et vrifiables. Dans
certains cas cette garantie ne pourra tre assure qu'au cours des activits
d'allocation/conception. Par contre ce premier rfrentiel d'exigences obtenu doit tre
cohrent. La compltude 100% du rfrentiel d'exigences n'est galement pas assure ce
stade car des exigences issues de la dcomposition des exigences (allocation) ou induites par
la conception peuvent tre manquantes.
BP3.2. Relisez lensemble des exigences et vrifiez leur comprhension.
De cette premire relecture le lecteur doit comprendre dans les grandes lignes ce que lon
attend du systme dans son environnement oprationnel. En particulier, on doit tre
capable didentifier lensemble des acteurs externes au systme, leurs interactions et
interfaces ( haut niveau tout au moins). Cette analyse permet daider dtecter des
exigences manquantes ou incompltes.
Lnonc dune exigence doit tre court (quelques lignes) et concis ("pas de littrature").
Les exigences qui contiennent des mots imprcis sont retravailler (ex. adverbes: peu,
assez, souvent, rapidement, aussitt; adjectifs: divers, plusieurs, rapide, quelques)
Les exigences suspectes (significations obscures/ clarifier, significations multiples,
noncs longs ou complexes, exigences incorrectes, exigences dont lorigine est
clarifier) doivent tre repres.

BP3.3. Vrifiez la ncessit des exigences

Une exigence na de sens que si elle rpond un besoin (explicite ou implicite). Une
exigence non justifie est une exigence suspecte reprer. On doit pouvoir rpondre
la question suivante : pourquoi cette exigence est-elle ncessaire ? (cf. traabilit).

AFIS 2001 GT Ingnierie des Exigences

Page 7 / 20

Association
Franaise
dIngnierie
Systme

BP3.4. Assurez-vous que les exigences sont vrifiables

Une exigence doit tre vrifiable et validable (par des moyens thoriques, des essais),
c'est dire il est prvu une mthode de vrification / validation (ex. mthode de tests,).
Toute exigence non trace vers une mthode de vrification est considrer comme
suspecte (cf. traabilit).
Nota: il se peut qu'une exigence ne soit pas testable (ex. technologie de tests non
disponible, infinit de scnarios de tests). C'est alors une exigence risque.
BP3.5. Contrlez la traabilit des exigences
Une exigence dont lorigine nest pas connue est une exigence suspecte reprer. Elle
est dautant plus suspecte quelle nest pas justifie et on peut alors sinterroger sur son
intrt.
Une exigence a dautant plus de chances dtre juste que son origine est trace.
Plus gnralement, toute exigence doit tre trace. A ce stade les questions se poser
sont : comment est-on arriv cette exigence ? , Cette exigence est-elle
ncessaire ?
BP3.6. Contrlez labsence de conflits , dincohrences, dans le rfrentiel d'exigences
Un nouveau parcours du rfrentiel d'exigences doit permettre de s'assurer de la
cohrence de l'ensemble des exigences. Il s'agit de vrifier la cohrence interne et externe.
Cohrence interne: aucune exigence ne contredit une autre exigence et aucune exigence
n'est redondante avec une autre exigence.
Cohrence externe: aucune exigence ne contredit les besoins oprationnels du systme
(ou besoins initiaux).
Ce parcours est d'autant plus difficile que le nombre d'exigences est important (il est
difficile de se rappeler de l'exigence n1 l'exigence n300). Nanmoins cette vrification
peut tre effectue en s'aidant de catgories d'exigences (analyse par point de vue). Elle
peut galement tre facilite par la hirarchisation en sous-systmes.
BP3.7. Contrlez la compltude du rfrentiel d'exigences
Un premier niveau de compltude doit tre atteint pour le rfrentiel d'exigences. Il
convient de s'assurer que l'on a couvert l'ensemble des besoins. De mme que pour la
cohrence, cette vrification peut tre assure en s'aidant des catgories d'exigences
(analyse par point de vue).
Cette premire vrification sera complter dans les phases suivantes du processus par
la compltude de l'ensemble des exigences (systme + alloues).
BP3.8. Reprenez lensemble des exigences suspectes , repres. Ritrez l'ensemble du
processus.
Ritrer jusqu' limination des exigences suspectes (i.e. risque ).
BP3.9. Organisez des revues formelles dexigences
Organisez des revues formelles dexigences avec lensemble des parties prenantes. Pour
chaque intervenant, dfinissez des rles de vrification clairement dfinis. Dfinissez des
critres dacceptation dexigences.
BP3.10. Obtenir laccord du client sur les exigences qui sont de sa responsabilit

AFIS 2001 GT Ingnierie des Exigences

Page 8 / 20

Association
Franaise
dIngnierie
Systme

3.4. Bonnes Pratiques dAllocation des exigences la solution

BP4.1. Dcomposez les exigences en exigences lmentaires
Une exigence de niveau systme est dcomposer en exigences lmentaires applicables
aux diffrents composants du systme (composants logiques ou physiques) : cf. bonnes
pratiques dlaboration des exigences techniques. Lorsque lon dcompose une exigence,
il convient de trouver le niveau de dcomposition adapt la comprhensibilit des
exigences lmentaires. Lobjectif est didentifier les services attendus des composants du
systme (avec leur contexte). Il ne faut dcomposer une exigence que si cette
dcomposition prcise la dfinition de lexigence (ajout dinformation). Les exigences
candidates la dcomposition sont principalement celles qui sont affectes plusieurs
catgories, celles qui ne sont affectes aucunes catgories, celles qui ne sont pas
alloues aux composants du systme, celles dont lnonc est volumineux
BP4.2. Identifiez les exigences issues de la conception
Des exigences peuvent tre induites par les activits de conception du systme (exemples :
exigences de rutilisation, exigences darchitecture logique, exigences dinterfaces). Il
convient dintgrer ces exigences avec leur historique dans le rfrentiel (cf. paragraphe
3.5). Il est prfrable de les distinguer des autres exigences.
BP4.3. Allouez les exigences lmentaires aux constituants du systme
On doit sefforcer ce que chaque exigence lmentaire issue dune dcomposition soit
alloue un composant du systme. Une exigence qui est alloue plusieurs composants
nest pas considrer comme lmentaire : cest une exigence risque.
BP4.4. Etablissez la traabilit descendante et remontante de chaque exigence (traabilit).
Permet de sassurer que les exigences lmentaires sont ncessaires et suffisantes pour
satisfaire les objectifs des exigences des niveaux suprieurs. Permet de sassurer que
chaque exigence lmentaire est alloue un composant du systme / chaque composant
du systme est spcifi par au moins une exigence. Permet deffectuer des analyses
dimpact en cas de modifications.
3.5. Bonnes Pratiques de Modification des exigences
Une modification dexigence peut avoir deux origines :
Evolution du besoin
Modification de la solution en cours de dveloppement / ralise

BP5.1. Analysez l'impact des modifications d'exigences

Lorsqu'une exigence est modifie, contrlez la cohrence interne et externe en s'aidant
des liens de traabilit. Cette cohrence peut tre vrifie en s'aidant des catgories
d'exigences (analyse par point de vue).
Identifiez et mettez jour les autres exigences impactes par la modification.

AFIS 2001 GT Ingnierie des Exigences

Page 9 / 20

Association
Franaise
dIngnierie
Systme

BP5.2. Maintenez l'historique des modifications apportes aux exigences

Permet de connatre qui, quand et pourquoi une exigence a t modifie : point
fondamental pour des systmes longs cycles de dveloppement, des systmes destins
plusieurs clients avec des fonctions assures diffrentes. Dans un souci d'efficacit
(lourdeur de formalisation), il n'est pas toujours ncessaire d'laborer un historique. C'est
le cas par exemple des modifications touchant la forme et non le fond tels que des
reformulations, des dcoupages d'exigences Seules les dcisions qui ont un effet
significatif sur le cot, la technique , la logique de dveloppementsont maintenir.

4. Intrts d'un Rfrentiel d'exigences techniques

Nous avons dtaill dans le paragraphe prcdent un ensemble d'activits du processus
d'ingnierie des exigences; le rsultat de ces activits se concrtisent par une base
d'informations, le rfrentiel d'exigences.
Le rfrentiel est un instrument de communication entre les diffrents intervenants
dans la dfinition d'un systme.
C'est le support de la collecte des exigences, de leurs analyses et de leur validation par
les diffrentes parties prenantes.
C'est aussi le support pour la production de documents du style spcification des
besoins, cahiers des charges, exigences utilisateur, etc. Le standard retenu peut imposer une
mise en forme, une prsentation type de tels documents.
Le rfrentiel d'exigences est une base d'informations vivante.
Plusieurs raisons:
- Il est illusoire de croire qu'on pourra disposer de toutes les exigences avant que ne
commencent les tapes de conception et ralisation. Il faut donc pouvoir faire
voluer un tel rfrentiel d'exigences en contrlant la cohrence de ces volutions.
- De nouvelles exigences vont surgir pendant les activits de dveloppement de la
solution en rponse au systme dsir. Ces exigences, appeles exigences drives
dans l'EIA 632, dcoulent des activits d'ingnierie, des savoir-faire mtier, des
techniques envisages, etc. Ces exigences drives doivent faire partie du
rfrentiel d'exigences; exigences initiales et exigences drives doivent bien sr
constituer un ensemble organis, structur et cohrent
- Un systme volue au fil de sa vie : ajout de nouvelles fonctionnalits,
remplacement de composants ou de sous ensembles pour cause d'obsolescence
techniques ou de performances insuffisantes, etc. Matriser les exigences du
systme implique de grer ces volutions dans le rfrentiel d'exigences pour aider
mesurer les impacts des modifications, et aussi pour disposer tout instant de la
vie du systme les exigences qu'il remplit.
Les activits de conception et de ralisation de la solution systme interagissent avec
le rfrentiel d'exigences
La ncessit, le rle, et la dfinition des fonctions, sous fonctions, ainsi que les
composants physiques identifis tout au long de ces activits dcoulent du rfrentiel
dexigences courant. Le rfrentiel dexigences est alors utilisable pour montrer
- la couverture des exigences , et

AFIS 2001 GT Ingnierie des Exigences

Page 10 / 20

Association
Franaise
dIngnierie
Systme

- la satisfaction des exigences

par la solution dveloppe (do la ncessit de relier ces exigences aux lments de
conception par des relations dallocation par exemple)
La satisfaction du besoin est tabli laide du rfrentiel dexigences
Quelques soient les tests raliss sur la solution dveloppe (tests unitaires, tests
dintgration), il faut aborder la validation par les utilisateurs et les parties prenantes du
systme ralis. Le rfrentiel dexigences est la traduction des besoins. Les informations sur
la vrification des exigences quil contient sont alors exploites pour argumenter que la
solution fournie satisfait bien les besoins.
Vritable carte didentit du systme (futur ou existant), le rfrentiel dexigences est la
structure dinformations pivot de lingnierie des systmes. Cest la rfrence, (qui peut
voluer dans le temps) des activits de conception, vrification, validation et soutien. Il doit
cependant tre accompagn dune structure de traabilit pour permettre de relier les
exigences aux lments de conception, les exigences entre elles et les exigences avec leur
origine.

AFIS 2001 GT Ingnierie des Exigences

Page 11 / 20

Association
Franaise
dIngnierie
Systme

5. Conclusion
Un rfrentiel dexigences est un outil puissant daide la matrise du dveloppement dun
systme et aussi la matrise de son volution tout au long de sa vie. Il permet de rpondre
des questions importantes telles que :
A quel client est destin quelle fonctionnalit du systme ?
Combien dexigences sont identifies sur ce projet ? Combien parmi elles ont-elles
une priorit leve ?
Quand seront implments les exigences dans le produit ?
Quelles exigences ont t modifies depuis la dernire revue client ? Qui est
responsable des modifications ?
Quel est limpact du cot estim des modifications proposes ?

Llaboration dun rfrentiel dexigences est complexe mais ncessaire pour lobtention dun
systme de qualit (technique, cots, dlais). Il ncessite limplication des diffrentes parties
prenantes externes (utilisateurs, client(s)) et internes (direction, chefs de projets, mtiers ,
partenaires, sous-traitants). Il met en uvre un ensemble dactivits ncessitant une gestion
rigoureuse.
Besoins parties
prenantes

Capture du besoin
Analyse des
exigences
Modification
Management
Rfrentiel
dexigences

Allocation

Vrification /
Validation

Conception

Les bonnes pratiques listes dans ce document sont des pistes pour laborer un rfrentiel de
qualit. Ces pratiques sont issues dexpriences industrielles relles. Elles sont ajuster par
chacun ses propres processus.

AFIS 2001 GT Ingnierie des Exigences

Page 12 / 20

Association
Franaise
dIngnierie
Systme

Annexe A: Exemples
A.1. Exemples de parties prenantes
(source AFIS)

Client(s)
Utilisateurs
Direction de lentreprise
Organismes normatifs
Gouvernement
Marketing
Fournisseurs
Public
Concepteur
Aprs-vente, maintenance
Testeurs
Qualit
Soutien
Formateurs
Systmes connexes (production, vente, transport )

A.2. Exemple sur lintrt de consulter toutes les parties prenantes

(source Arospatiale Matra Airbus)

La capture d'une exigence trs tt dans le cycle permet de prendre en compte l'ensembles des contraintes et de
faire les compromis ncessaire.
Dans l'exemple, la prise en compte des contraintes de soutien en conception permet de se proccuper des
problmes d'accessibilit pour la maintenance.
Une simulation permet de valider l'exigence.

AFIS 2001 GT Ingnierie des Exigences

Page 13 / 20

Association
Franaise
dIngnierie
Systme

A.3. Exemple de transformation dune exigence par niveaux / intrt de la

traabilit
A.3.1 Critres de chocs automobile EURONCAP
(source PSA)
Cet exemple permet de visualiser la transformation dune exigence par niveau de dcomposition dun systme
vhicule et dillustrer la notion de traabilit entre exigences.
Lexigence dorigine correspond la protection des passagers vis--vis des chocs latraux ; il sagit ce niveau
dun besoin client.
Cette exigence se transforme en exigence technique systme laide de critres issus de normes sur le crash
vhicule ; ce sont les critres EURONCAP, ils sont souvent cits dans la presse automobile.
On peut reprsenter les diffrentes tapes de cette transformation dexigence sur le tableau ci-dessous. Les
paramtres numriques associs chaque niveau de transformation sont obtenus laide du calcul crash
vhicule.
Niveaux de dcomposition
Client
Vhicule
Sous-systme vhicule
Organes
Sous-organes
Composants
Sous-composants

Enonc de lexigence
Protger les passagers des chocs latraux.
Le vhicule tient les critres EURONCAP 4* en choc latral.
La dclration du sous-systme structure est limite x m/s2.
La vitesse de dformation de la structure est limite x m/s.
La dformation maximale du renfort de porte est de x m.
La gomtrie raliser est : ( ensemble de coordonnes).
Lpaisseur et la nuance des matriaux.
Le plan de fabrication est :

Cet exemple illustre galement les points fondamentaux suivants:

Intrt de la traabilit:
En cas de modifications de la norme, de l'exigence mre, des contraintes de style, des contraintes de
poids
Vrifier la prise en compte de l'exigence du client tous les niveaux
Niveau de dcomposition: risque de trop dcomposer les exigences (lourdeur, gestion difficile, perte de
comprhensibilit)

A.3.2. Sige Avant dun vhicule automobile

(source AFNOR/AFAV ouvrage Exprimer le besoin )
Cet exemple permet dillustrer la diffrence entre un besoin et une exigence technique.
Lexigence dorigine est de raliser un sige avant pour permettre au conducteur de se positionner dans le poste
de conduite .
Cette exigence dorigine se dcline en exigences techniques
Niveaux de dcomposition
Enonc de lexigence
Permettre au conducteur de se positionner dans le poste de conduite
Exigence dorigine
Dimensions principales dun sige selon une population hommes/femmes
Exigences techniques
hauteur buste
largeur aux paules
largeur bassin
largeur hanches
largeur du torse

AFIS 2001 GT Ingnierie des Exigences

Page 14 / 20

Association
Franaise
dIngnierie
Systme

Angles de confort assurer

20<A1<30
95<A2<120
95<A3<135
86<A4<105
0<A5<45

Angles de vision prserver

Confort de membres infrieurs : choix dun Hx (hauteur dassise en fonction des

points dacclration)

A.4. Exemple sur lintrt des scnarios dutilisation

A.4.1 Exemple manuvre parking : rayon de braquage
Cet exemple dcrit un scnario dutilisation du vhicule. Le but est spcifier des hypothses de gomtrie
(formes) et de direction du vhicule pour avoir des degrs de flexibilit et pouvoir spcifier des grandeurs en
fonction des diffrentes contraintes de style, technique
Ltude du scnario permet :
de prendre conscience dventuelles nouvelles exigences pour le systme ;
daffiner la dfinition des fonctions rellement attendues ;
de prciser le contexte dutilisation et donc les parties concernes par la satisfaction de la fonction.
Description du scnario dans ce cas prcis :
Le vhicule roule basse vitesse, volant braqu fond droite (idem gauche). On sintresse principalement
aux rayons de braquage entre murs et entre trottoirs, qui correspondent respectivement aux maximum des rayons
des trajectoires des points de la caisse dune part et des roues dautre part.
La finalit de cette utilisation est de dplacer le vhicule dans un endroit exigu. On constate alors que parcourir
la trajectoire dcrite implique un changement de position et dorientation. La recherche de compromis entre des
deux valeurs permet d'aboutir de nouvelles exigences comme par exemple : contrle en translation du vhicule
et contrle en rotation du vhicule.

Trajectoire du vhicule lors de la manipulation rayon de braquage.

AFIS 2001 GT Ingnierie des Exigences

Page 15 / 20

Association
Franaise
dIngnierie
Systme

A.5. Exemple sur lintrt de vrifier ladquation au contexte avant de

rutiliser
(source communiqu de presse ESA-CNES du 23/07/99)
Le vol inaugural dAriane 5 qui a eu lieu le 4 juin 1996 sest sold par un chec : environ 40s aprs le dmarrage
de la squence de vol, le lanceur a dvi de sa trajectoire, sest bris et explos.
Les causes de cet chec ont t attribues au Systme de Rfrence Inertiel (SRI) dont la conception logicielle
est pratiquement la mme que celle dun SRI Ariane 4 : une exception logicielle a provoqu lenvoi de donnes
dattitudes errones (azimut, assiette, gte).
Cette exception logicielle sest produite pendant une conversion de Biais Horizontal (BH) de reprsentation
flottante 64 bits en valeurs entires 16 bits. Or Ariane 5 a des valeurs de vitesse horizontales
considrablement suprieures Ariane 4, ce qui se traduit pour la 1re partie de la trajectoire par une valeur de
BH plus leve que la valeur escompt.
Les donnes transmises par le SRI au calculateur de bord (OBC), qui correspondaient un profil de bit
spcifique de la panne, ont t interprtes comme tant des donnes de vol. LOBC a command le braquage
des tuyres sur la base de ces informations. Langle dattaque rsultant a conduit, sous leffet des charges
arodynamiques la dsintgration du lanceur.
Dans cet exemple, cest une exigence impose il y a plus de 10 ans sur les premiers modles de lanceurs Ariane
qui est lorigine de cet chec. Lexigence rutilise spcifiait un maintien de la fonction alignement pendant
50s aprs le passage en mode vol. Sur Ariane 4, cette fonction particulire devait permettre la possibilit de
conserver une fentre de lancement troite face lventualit peu probable dun arrt de chronologie entre H09s et H0-5s, en vitant un lancement de la procdure normale dalignement de 45 minutes.
Or cette exigence navait pas lieu dtre sur Ariane 5 dont la procdure dalignement est diffrente. Elle a t
conserve pour des raisons de communalit, qui semblent reposer sur le principe selon lequel il nest pas
opportun, sauf preuve du contraire, de procder des modifications sur des logiciels qui ont bien fonctionn.

A.6. Exemples de catgories

(source AFIS)

Fonctionnelle
Performance
Interface
Oprationnelle (disponibilit, maintenabilit, fiabilit, scurit, vulnrabilit, logistique, environnement,
qualit de service)
Contrainte
Validation

A.7. Exemples sur lintrt de dfinir des mthodes de vrification/validation

A.7.1. Validation dexigence technique dun systme de Chane de Traction
automobile (partie commande dembrayage)
(source PSA)
Un profil effort / course pdale d'embrayage est labor suite des calculs et un retour d'exprience.
Il rsulte:

d'une somme d'exigences techniques (dont passage C=C moteur C=0)

exigence de confort : agrment de conduite au passage de vitesse

AFIS 2001 GT Ingnierie des Exigences

Page 16 / 20

Association
Franaise
dIngnierie
Systme

exigence de scurit : viter les -coups au passage de vitesse (viter que l'effort chute brusquement avant de
dbrayer)
Le systme, une fois conu, doit vrifier ce profil.

ST Chane de Traction (CdT)

Q grandeurs
Obtenir une loi course / effort de la pdale dembrayage
physiques propres aux mtiers CdT spcifier :

Dbrayer X mm avant le point densellement E (point de

libration du disque dembrayage induisant un relchement de
leffort sur la pdale);
Obtenir un cart deffort Y entre les points Fmaxi et E ;

Obtenir un retour dinformation de la position de la

pdale au moment du dbrayage et un avalement ncessaires
pour laide au dbrayage

Respecter une pente mini au point D et ensellement Y mini ;

encadrement de lensellement E ;

SavantRespecter
la contrainte de dbrayer partir de 35 mm
la position pdale en fin de course (contrainte
normative) permettant dassurer que C=0 lorsque le pied est
fond

35 mm

Pied
lev

Pied
fond

dbray
Pied en bute

bute
tablier

> X mm

Fpdale

Fmax

Y
E

R
Course pdale
> 35 mm

embray
Couple = C moteur

AFIS 2001 GT Ingnierie des Exigences

transition
glissement

dbray
C=0

Page 17 / 20

Association
Franaise
dIngnierie
Systme

Exemples de validation sur banc dessai :

Q Loi position / effort pdale dembrayage :

Validation de la pente densellement autour du point dembrayage D

Validation du dbrayage X mm minimum avant le point densellement

par ce biais est valid la contrainte de dbrayer 35 mm au plus tard avant la position pied fond
Flexibilit du systme de commande intgr : mesurer leffort pdale Y / effort fourchette en fonction de la

course pdale
Couple transmis par lembrayage :
mesure couple transmis en fonction de la position fourchette pour sassurer que C=0 partir du point E

A.7.2. Validation dexigence dutilisation oprationnelle dun avion darmes

(source Dassault Aviation)
Lexigence est Le systme darmes de lavion sera dfini pour une utilisation dans un environnement
lectromagntique particulirement dense, comprenant des systmes amis et ennemis
Commentaires :
Les conditions de vrification / validation sont imprcises : pas de prcisions sur les niveaux
lectromagntiques respecter
Plusieurs moyens / scnarios de vrification car plusieurs systmes amis/ennemis : AWACS, radars sol,
radars aroports, porte-avions, systmes de dfense arienne
Risques :
Impact cots, dlais
Insatisfaction client : dmonstration de satisfaction de lexigence non faisable
Bnfices :
Dans cet exemple, dfinir les mthodes de vrification / validation de lexigence permet de se mettre daccord
sur les Conditions dAcceptation et dviter tout conflit potentiel ultrieur.

AFIS 2001 GT Ingnierie des Exigences

Page 18 / 20

Association
Franaise
dIngnierie
Systme

Annexe B: Correspondance avec les pratiques CMMi

Activits
d'Ingnierie
des Exigences
Analyse
Modifications
Capture /
Modifications
Management
Management

Capture
Capture
Capture
Capture
Capture
Validation
Validation
Allocation
Allocation
Allocation
Allocation
Analyse
Management

CMMi continuous representation (V0.2)

Requirement Management
Goal 1 - SP1 "Obtain Requirements"
Goal 1 - SP2 "Manage Requirements Changes (Level 2)"
Goal 1 - SP3 "Manage Requirements Traceability (Level 2)"
Goal 1 - SP4 "Track Work Effort Against Requirements"
Generic Practices
Establish an Organizational Policy
Plan the Process
Train People
Manage Configurations
Monitor and Control the Process
Objectively Verify Adherence
Provide Resources
Customer and Product Requirements
Goal 1 SP1 "Collect Stakeholder needs"
Goal 1 SP2 "Elicit needs (Level 2)"
Goal 1 SP3 "Transform Stakeholder needs, Expectations, and Constraints into
Customer Requirements "
Goal 1 SP4 "Obtain Agreement"
Goal 1 SP5 "Develop Operational Concepts and Scenarios"
Goal 1 SP6 "Validate Customer Requirements (Level 3)"
Goal 1 SP7 "Perform Quantitative Validation of Customer Requirements (Level 4)"
Goal 2 SP1 "Derive Product Requirements"
Goal 2 SP2 "Establish a Functional Architecture"
Goal 2 SP3 "Reduce Product Cost and Risk (Level 3)"
Goal 2 SP4 "Identify Internal Interface Requirements"
Goal 2 SP5 "Analyze the Adequacy of Requirements (Level 2)"
Generic Practices
Establish an Organizational Policy
Plan the Process
Assign Responsibility
Train People
Manage Configurations
Monitor and Control the Process
Objectively Verify Adherence
Provide Resources

AFIS 2001 GT Ingnierie des Exigences

Page 19 / 20

Association
Franaise
dIngnierie
Systme

Activits
d'Ingnierie
des Exigences
Management
Management
Management
Management
Management
Analyse
Modifications
Capture /
Modifications
Management
Management
Management
Management
Management
Management
Management
Management
Management
Management
Management
Capture
Capture
Analyse /
Validation
Capture
Analyse
Capture
Management
Allocation
Analyse /
Allocation
Management
Management
Management
Management
Management

CMMi staged representation (V0.2)

Requirement Management (Level 2)

CO1 "Establish an Organizational Policy"
AB1 "Plan the Process"
AB2 "Provide Resources"
AB3 "Assign Responsibility"
AB4 "Train People"
AC1 "Obtain Requirements"
AC2 "Manage Requirements Changes (Level 2)"
AC3 "Manage Requirements Traceability (Level 2)"
AC4 "Track Work Effort Against Requirements"
DI1 "Perform Managed Process"
DI2 "Manage Configurations"
DI3 "Monitor and Control the Process"
VE1 "Review Activities and Results with Management"
VE2 "Objectively Verify Evidence"
Customer and Product Requirements (Level 3)
CO1 "Establish an Organizational Policy"
AB1 "Plan the Process"
AB2 "Provide Resources"
AB3 "Assign Responsibility"
AB4 "Train People"
AC1 "Elicit Needs"
AC2 "Transform Stakeholder needs, Expectations, and Constraints into Customer
Requirements "
AC3 "Obtain Agreement"
AC4 "Develop Operational Concepts and Scenarios"
AC6 "Validate Customer Requirements"
AC7 "Derive Product Requirements"
AC8 "Reduce Product Cost and Risk"
AC9 "Identify Internal Interface Requirements"
AC10 "Analyze the Adequacy of Requirements"
DI1 "Perform Defined Process"
DI2 "Manage Configurations"
DI3 "Monitor and Control the Process"
VE1 "Review Activities and Results with Management"
VE2 "Objectively Verify Evidence"

AFIS 2001 GT Ingnierie des Exigences

Page 20 / 20