Vous êtes sur la page 1sur 110

REQB Certified Professional for Requirements Engineering

Niveau Fondation

Syllabus

REQB
Professionnels Certifis en
Ingnierie des Exigences

Niveau Fondation

Version 1.3 FR

31 octobre 2011

Le copyright de cette dition du syllabus dans toutes les langues est dtenu par le Gasq
Global Association for Software Quality.

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Historique des modifications

Version

Date

Commentaire

1.0

15 janvier 2008

Version 1.0 diffuse

1.1

29 mai 2008

Mise jour : version 1.1

1.2

1er juillet 2008

Mise jour : version 1.2

1.2 FR

15 dcembre 2010

Version 1.2 en franais

1.3

15 juin 2011

Mise jour : version 1.3

1.3 FR

5 fvrier 2012

Version 1.3 en franais

2
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Ide principale
Le thme central pour llaboration de ce syllabus tait la croissance constante de la complexit
du logiciel et de notre dpendance au logiciel. Ceci implique une exigence importante dabsence
derreurs dans le logiciel. Le Requirements Engineering Qualifications Board (REQB) a donc
dcid de crer des standards internationaux uniformes dans le domaine de lIngnierie des
Exigences. Pour des standards comme les langages, cest uniquement si vous les comprenez que
vous pourrez travailler efficacement. Pour crer un tel langage standard dans ce domaine
important quest lIngnierie des Exigences, des experts internationaux se sont runis au sein du
REQB et ont dvelopp ce syllabus.

Remerciements
Le groupe de travail pour llaboration du niveau Fondation du ReqB (Edition 2011) :
Karolina Zmitrowicz (prsident), Alain Betro, Dorothe Blocks, Jrme Khoualed, Eric Riou du
Cosquer, Chris Hofstetter, Micha Figarski, Francine Lafontaine, Beata Karpiska, Folke Nilsson,
Ingvar Nordstrm, Alain Ribault, Radosaw Smilgin.

3
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

1 Sommaire
1

Sommaire........................................................................................................................................ 4

Introduction .................................................................................................................................... 9

Fondamentaux (K2) ...................................................................................................................... 11


1.1
1.1.1

Dfinition et classification (K2) ........................................................................................ 12

1.1.2

Problmes avec les exigences (K2) .................................................................................. 13

1.1.3

Critres qualit des exigences (K2).................................................................................. 14

1.1.4

Solution (K1) .................................................................................................................... 15

1.1.5

Engagement (K1) ............................................................................................................. 15

1.1.6

Responsabilits lgales et fautes (K1) ............................................................................. 16

1.1.7

Priorit et criticit des exigences (K2) ............................................................................. 16

1.1.8

Vrification et validation (K1) .......................................................................................... 17

1.1.9
(K2)

Ingnierie des Exigences, Gestion des Exigences et Dveloppement des Exigences


17

1.2

Exigences (K2) ...................................................................................................................... 12

Exigences (K2) ...................................................................................................................... 19

1.2.1

Standards (K1) ................................................................................................................. 19

1.2.2

Normes processus (K1) .................................................................................................... 20

1.2.3

Les raisons de ngligence de lIngnierie des Exigences (K2).......................................... 20

Modles de processus et Processus dIngnierie des Exigences (K2) .......................................... 21


2.1

Modles de processus (K2) .................................................................................................. 22

2.1.1

Les modles de processus (K2) ........................................................................................ 22

2.1.2

Modle de cycle en V gnral (K2) .................................................................................. 22

2.1.3

Rational Unified Process (RUP) (K2) ............................................................................. 23

2.1.4

Approches Agiles ............................................................................................................. 23

2.1.5

Extreme Programming (K2) ............................................................................................. 24

2.1.6

Scrum (K2) ....................................................................................................................... 25

2.1.7

Modle de maturit (K2) ................................................................................................. 26

2.2

Processus dIngnierie des Exigences (K2)........................................................................... 28

2.2.1

Dfinition du processus dIngnierie des Exigences (K2) ................................................ 28

2.2.2

Influences de lIngnierie des Exigences ......................................................................... 28

4
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Gestion de projet et du risque (K2) .............................................................................................. 30


3.1
3.1.1

Ncessit de lIngnierie des Exigences dans les projets (K2)......................................... 31

3.1.2

Quelles erreurs peuvent survenir dans lingnierie des Exigences ? (K2) ....................... 32

3.2

Gestion de risques (K2) ........................................................................................................ 33

3.2.1

Ncessit de la gestion de risque (K2) ............................................................................. 33

3.2.2

Risque (K2) ....................................................................................................................... 33

3.2.3

Gestion de risque (K2) ..................................................................................................... 34

3.2.4

Analyse des modes de dfaillance et de leurs effets (K2) ............................................... 35

Rles et responsabilits (K2) ........................................................................................................ 37


4.1

Rles fondamentaux (K1) ..................................................................................................... 38

4.1.1

Rles fondamentaux (K2) ................................................................................................ 38

4.1.2

Parties prenantes (K2) ..................................................................................................... 39

4.2

Gestion de projet (K2) .......................................................................................................... 31

Tches de lIngnierie des Exigences (K2)............................................................................ 41

4.2.1

Tches de lIngnierie des Exigences (K2) ....................................................................... 41

4.2.2

Connaissance dun Professionnel de lIngnierie des Exigences (K1) ............................. 41

Identification des Exigences (K2) .................................................................................................. 42


5.1

Client (K1)............................................................................................................................. 43

5.1.1

Client (K1) ........................................................................................................................ 43

5.1.2

Contrat (K1) ..................................................................................................................... 43

5.2
5.2.1
5.3

Visions et objectifs projet (K2) ............................................................................................. 45


Vision (K2) ........................................................................................................................ 45
Identification des parties prenantes (K2) ............................................................................ 47

5.3.1

Identification des parties prenantes (K2) ........................................................................ 47

5.3.2

Procdure didentification et dvaluation des parties prenantes (K2) .......................... 47

5.4

Techniques didentification des exigences (K2) ................................................................... 49

5.4.1

Identification des parties prenantes (K2) ........................................................................ 49

5.4.2

Techniques (K1) ............................................................................................................... 49

5.5

Exigence fonctionnelle et non-fonctionnelle (K2) ............................................................... 56

5.5.1

Exigences fonctionnelles (K2) .......................................................................................... 56

5.5.2

Exigences non-fonctionnelles (K2)................................................................................... 56

5
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5.6

5.6.1

Description des exigences (K2) ........................................................................................ 58

5.6.2

Procdure pour la construction des exigences (K2) ........................................................ 58

5.6.3

Document dexigence (K2)............................................................................................... 59

Spcification des Exigences (K2) ................................................................................................... 61


6.1

Spcifications (K2) ................................................................................................................ 62

6.1.1

Description des exigences (K2) ........................................................................................ 62

6.1.2

Spcifications des exigences (K2) .................................................................................... 62

6.1.3

User stories (K2) .............................................................................................................. 62

6.1.4

Spcifications de solution (K2) ........................................................................................ 63

6.1.5

Standards importants (K1)............................................................................................... 63

6.2
6.2.1
6.3
6.3.1
6.4

Description des exigences (K2) ............................................................................................ 58

Procdure (K3) ..................................................................................................................... 65


Procdure de spcification de solution (K3).................................................................... 65
Formalisation (K2) ................................................................................................................ 66
Degr de formalisation (K2)............................................................................................. 66
Qualit des exigences (K2) ................................................................................................... 68

6.4.1

Contexte (K2) ................................................................................................................... 68

6.4.2

Mesures damlioration de la qualit et assurance qualit des exigences (K2) ............. 68

Analyse des Exigences (K2) ........................................................................................................... 70


7.1

Exigences et solutions (K1) .................................................................................................. 71

7.1.1

Objectif de lanalyse des exigences (K2) .......................................................................... 71

7.1.2

Procdure danalyse des exigences (K2) ......................................................................... 71

7.1.3

Rupture structurelle entre les exigences et les solutions (K2) ........................................ 71

7.2

Mthodes et Techniques (K2) .............................................................................................. 72

7.2.1

Mthodes et modles danalyse (K2) .............................................................................. 72

7.2.2

Types de modles (K2)..................................................................................................... 72

7.2.3

Diffrentes perspectives du systme (K2) ....................................................................... 73

7.2.4

Diffrents modles (K1) ................................................................................................... 73

7.3

Analyse oriente-objet (K2) ................................................................................................. 75

7.3.1

UML (K1) .......................................................................................................................... 75

7.3.2

SysML (K2) ....................................................................................................................... 76

7.4

Estimations de cot (K2) ...................................................................................................... 78

6
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.4.1

Types destimation (K2) ................................................................................................... 78

7.4.2

Influence sur les cots de dveloppement (K2) .............................................................. 78

7.4.3

Les approches destimations de cot .............................................................................. 78

7.5
7.5.1

Priorisation (K2) ............................................................................................................... 83

7.5.2

Procdure de priorisation (K2) ........................................................................................ 83

7.5.3

chelle de priorisation (K2).............................................................................................. 84

7.6

Accord sur les exigences (K2) ............................................................................................... 85

7.6.1

Accord (K2) ...................................................................................................................... 85

7.6.2

Avantages de laccord sur les exigences (K2) .................................................................. 86

Suivi des Exigences (K2) ................................................................................................................ 87


8.1

Suivi au sein du projet (K2) .................................................................................................. 88

8.1.1

volution des exigences (K1) ........................................................................................... 88

8.1.2

Traabilit (K2) ................................................................................................................. 88

8.1.3

Traabilit (K2) ................................................................................................................. 89

8.2

Priorisation (K2) ................................................................................................................... 83

Gestion du changement (K2) ............................................................................................... 90

8.2.1

Changements des exigences (K1) .................................................................................... 90

8.2.2

Gestion du changement (K2) ........................................................................................... 90

8.2.3

Demande de changement (K2) ........................................................................................ 91

8.2.4

Commission de Gestion des Changement (K2) ............................................................... 91

8.2.5

Cycle de vie dune exigence (K2) ..................................................................................... 92

8.2.6

Distinction entre Gestion des Dfauts et Gestion du changement (K2) ......................... 92

8.2.7

Impact dun changement sur le projet (K2) ..................................................................... 92

Assurance Qualit (K2) ................................................................................................................. 94


9.1
9.1.1

Les facteurs dinfluence (K1) ................................................................................................ 95


Influences sur lIngnierie des Exigences (K1) ................................................................. 95

9.2

Vrification des exigences ltape dlucidation des exigences (K2) ................................ 96

9.3

Lassurance qualit via la testabilit (K2)............................................................................. 97

9.3.1

LIngnierie des Exigences et le test (K2) ........................................................................ 97

9.3.2

Le critre dacceptation (K2) ........................................................................................... 97

9.3.3

Mthodes de test (K2) ..................................................................................................... 97

9.3.4

Exigences et processus de test (K2) ................................................................................. 98

7
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

9.4

10

Les Mtriques (K2) ............................................................................................................... 99

9.4.1

La mtrique (K1) .............................................................................................................. 99

9.4.2

Les mtriques dans le contexte des exigences (K1) ........................................................ 99

9.4.3

Les mesures de la qualit des exigences (K2) .................................................................. 99

Outils (K2) ................................................................................................................................... 101


10.1

Avantages des outils (K2) ................................................................................................... 102

10.1.1

Utilisation des outils dans lIngnierie des Exigences (K2) ........................................ 102

10.1.2

Avantages de ces outils (K2)...................................................................................... 102

10.2

Catgorie des outils (K2) .................................................................................................... 103

10.2.1

Catgories des outils (K2) .......................................................................................... 103

11

Littrature ................................................................................................................................... 105

12

Index ........................................................................................................................................... 109

8
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

2 Introduction
Objectif de ce syllabus
Ce syllabus dfinit le niveau lmentaire (niveau Fondation) du
programme de formation pour devenir un Professionnel Certifi REQB
pour lIngnierie des Exigences (REQB Certified Professional for
Requirements Engineering - CPRE). REQB a dvelopp ce syllabus en
collaboration avec le gasq - Global Association for Software Quality. Le
sujet du primtre REQB est tout type de produits IT pouvant inclure du
matriel et des services ainsi que du logiciel avec leurs exigences
valides, les exigences mtier et la documentation associe.
Le syllabus a pour but de servir de base pour les organismes de formation qui sont la recherche
dune accrditation en tant que formateur. Toutes les parties de ce syllabus doivent par
consquent tre inclues dans les documents de formation. Cependant, le syllabus devrait
galement servir au stagiaire dans sa prparation la certification. Toutes les parties numres
ici sont donc utiles pour lexamen qui peut tre pass aprs des cours accrdits ou en candidat
libre.
Le syllabus fournit aussi des ides de dure recommande pour chaque chapitre.

Examen
Lexamen pour devenir un Professionnel Certifi REQB pour lIngnierie des Exigences est bas sur
ce syllabus. Toutes les sections de ce syllabus peuvent ainsi tre examines. Les questions
dexamen ne sont pas ncessairement divises en diffrentes sections. Une question peut se
rfrer plusieurs sections.
Le format de lexamen est un Questionnaire Choix Multiples.
Les examens peuvent tre passs aprs avoir suivi des cours accrdits ou en candidat libre (sans
cours prliminaire). Vous trouverez des informations dtailles concernant les dures des
examens sur le site du Gasq (www.gasq.org), sur le site du REQB (www.reqb.org) ou sur le site du
CFTL (www.cftl.fr)

Accrditation
Les organismes fournissant des cours Professionnels Certifis REQB pour lIngnierie des Exigences
niveau Foundation doivent tre accrdits par le Gasq - Global Association for Software Quality.
Les experts du Gasq revoient lexactitude de la documentation des organismes de formation. Un
cours accrdit est considr comme conforme au syllabus. A la fin dun tel cours, un examen
officiel Professionnels Certifis REQB pour lIngnierie des Exigences (examen CPRE) peut tre
ralis par un organisme de certification indpendant (selon les rgles de lISO 17024).
Les organismes de formation accrdits peuvent tre identifis par le logo officiel REQB
Organisme de Formation Accrdit.

9
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Internationalit
Ce syllabus a t dvelopp en collaboration par plusieurs experts internationaux. Le contenu de
ce syllabus peut donc tre considr comme un standard international. Le syllabus permet ainsi de
former et de faire passer des examens internationalement au mme niveau.

Niveaux K
Les objectifs dapprentissage de ce syllabus ont t classs en diffrents niveaux K de
connaissance. Cela permet au candidat de reconnaitre le niveau de connaissance de chaque
point.
Il y a 3 niveaux K dans ce syllabus :

K1 se rappeler, reconnaitre, rappeler


K2 - comprendre, expliquer, donner des raisons, comparer, classifier, rsumer
K3 appliquer dans un contexte spcifique

10
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

1 Fondamentaux (K2)

40 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des Exigences


Les objectifs identifient ce que vous tes capable de faire, en ayant suivi chaque module.

1.1 Exigence (K2)


OA-1.1.1

Rappeler la dfinition dune exigence (K1)

OA-1.1.2

Expliquer la signification et le but des exigences (K2)

OA-1.1.3

Expliquer comment les exigences peuvent tre classes (K2)

OA-1.1.4

Dcrire les diffrents types dexigences (K2)

OA-1.1.5

Expliquer quels sont les problmes lis aux exigences (K2)

OA-1.1.6

Dcrire quels sont les concepts importants en lien avec les exigences (K2)

OA-1.1.7

Expliquer la diffrence entre GE (Gestion des Exigences) et IE (Ingnierie des


Exigences) (K2)

1.2 Standards et normes (K1)


OA-1.2.1

Rappeler les normes et standards importants relatifs lIngnierie des Exigences (K1)

OA-1.2.2

Expliquer pourquoi lIngnierie des Exigences est importante (K2)

11
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

1.1

Exigences (K2)

20 minutes

Termes
Engagement, Criticit, Exigence Fonctionnelle, Exigence Non-Fonctionnelle, Exigence, Ingnierie
des Exigences, Gestion des Exigences, Exigences Processus, Exigences Produit, Priorit, Solution,
Validation, Vrification

1.1.1 Dfinition et classification (K2)


Dfinition de ce quon entend par le terme Exigence (K1)

Exigence [IEEE 610.12] :

Condition ou aptitude requise par un utilisateur pour rsoudre un problme ou atteindre


un objectif
Condition ou aptitude qui peut tre rencontre ou possde par un systme ou un
composant dun systme pour satisfaire un contrat, un standard, une spcification ou
tout autre document compos formellement
Document reprsentant une condition ou une aptitude comme dcrit ci-dessus

Quels sont la signification et le but des exigences ? (K2)

Fondement pour lvaluation, la planification, lexcution et le suivi de lactivit de projet


Attentes client
Composante daccords, de commandes, de plans projet,
Dfinition des limites dun systme, du primtre dune livraison, de services contractuels

Classification des exigences (selon [Ebert05]) (K2)


Les exigences comprennent :

des exigences processus


des exigences produit.

Les exigences processus concernent les processus de dveloppement et de livraison. Cela inclut,
par exemple : les cots, le marketing, le temps de traitement, les ventes et la distribution,
lorganisation, la documentation.

12
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Les exigences produit comprennent les exigences produit fonctionnelles et non fonctionnelles. Ces
deux types dexigences peuvent tre considrs du point de vue de lutilisateur (externe) ou du
client et du point de vue de lquipe de dveloppement (interne). Il est important de rappeler que
le client et le dveloppeur peuvent tre diffrents.
Les exigences fonctionnelles dcrivent la fonction (comportement) dun systme.
Les exigences non-fonctionnelles dcrivent les attributs qualit dun systme. Ils sont souvent
appels attributs qualit .
Les diffrences entre les exigences fonctionnelles et non-fonctionnelles peuvent tre exprimes de
la faon suivante :

Les exigences fonctionnelles dcrivent ce QUE le systme fait


Les exigences non-fonctionnelles dcrivent COMMENT le systme se comporte (pour faire
quelque chose)

Exemples :

Exigences produit fonctionnelles du point de vue de lutilisateur et client : interface


utilisateur, applications, services
Exigences produit fonctionnelles dun point de vue de lquipe de dveloppement :
architecture, alimentation lectrique, rpartition de charge
Exigences produit non-fonctionnelles du point de vue de lutilisateur et du client : fiabilit,
performance, utilisabilit (facilit demploi)
Exigences produit non-fonctionnelles du point de vue de lquipe de dveloppement :
testabilit, services offerts, outils

Types de base dexigences (K1) :

Exigences client
o Dsirs clients, besoins et attentes (exigences mtier de haut niveau)
o Limitations mtier
Exigences solutions / systmes
o Spcification des besoins client (spcifications dtailles des exigences mtier de
haut niveau)
Exigences produit / composant
o Fonctions et caractristiques de la solution
o Les bases pour lanalyse et la conception dtaille (exemple : cas dutilisation)

1.1.2 Problmes avec les exigences (K2)


Les principaux problmes avec les exigences sont :

13
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Objectifs imprcis
Problmes de communication
Barrires de la langue
Barrires de connaissance
Formulation vague
Formulations trop formelles
Instabilit des exigences
Mauvaise qualit des exigences (incluant des exigences ambiges, trop spcifies, pas
claires, impossibles, contradictoires)
Placage dor (trop de description dune exigence qui implique que lexigence relle est
couverte par des descriptions inutiles)
Implication insuffisante des utilisateurs
Classes utilisateur oublies (impliquant des parties prenantes oublies)
Planning inadapt
Spcification minimale

1.1.3 Critres qualit des exigences (K2)


Les critres qualit des exigences (daprs Wiegers05) sont les suivantes : (K2)
1. Chaque exigence doit tre
Correcte : lexigence doit dcrire de faon prcise la fonctionnalit fournir. La
base de rfrence pour valuer la prcision est la source de lexigence (par
exemple, les clients ou une exigence systme de haut niveau)
Faisable : il doit tre possible dimplmenter lexigence partir des capacits et
limitations connues dun systme et de son environnement
Utile : lexigence doit documenter ce dont le client (ou les autres parties
prenantes) a rellement besoin et ce qui est exig pour raliser une exigence
externe ou une interface ou un standard spcifi
Priorise : lexigence devrait avoir une priorit alloue indiquant son niveau
dimportance pour une release donne dun produit
Non ambigu : lexigence devrait tre interprte de faon unique. Des personnes
diffrentes prenant connaissance dune exigence doivent avoir la mme
interprtation et la mme comprhension de lexigence
Vrifiable : il devrait tre possible de vrifier si lexigence est implmente
correctement
Unique : ne doit pas contenir de multiples exigences ; ncessite une granularit
suffisante pour spcifier une exigence de faon unique
Indpendante de la conception : dcrit le QUOI , pas le COMMENT
2. La spcification des exigences doit tre :
Complte : aucune exigence ni information ncessaire ne devrait tre oublie
dans la spcification des exigences. La compltude est aussi exprime comme une
caractristique dsire pour une exigence individuelle et un niveau de dtail

14
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Cohrente : lexigence ne peut rentrer en conflit avec dautres exigences ou avec


des exigences de haut niveau (systme ou mtier)
Modifiable : la spcification doit permettre dintroduire des changements dans les
exigences. Lhistorique des changements effectus sur chaque exigence doit tre
conserv
Traable : il doit tre possible de tracer chaque exigence vers sa source (par
exemple, une exigence systme de plus haut niveau, un cas dutilisation ou une
assertion client) et vers les artefacts dimplmentation correspondants (par
exemple, des lments de conception, le code source et les cas de tests)

1.1.4 Solution (K1)


Solution (K1)
Une solution est limplmentation dune exigence.
La solution peut tre un systme logiciel, lamlioration dun processus, etc.

1.1.5 Engagement (K1)


Engagement (K1)
Lengagement est le degr dobligation de respect des exigences.
Lengagement est dfini via des mots-cls allous aux exigences de haut niveau :

Le systme devrait

Les mots-cls peuvent inclure : doit , sera , devrait , serait , pourrait


Les mots-cls doit, devrait, pourrait sont lis aux exigences mtier et utilisateur avant
lengagement. Aprs la phase de contractualisation et de rfrencement des exigences, les motscls devraient dterminer strictement le degr dobligation :

Le systme fera

Le niveau dobligation dune exigence peut tre exprim en utilisant la notation Moscow (Must
Have, Should Have, COuld have, Would have).
Une fois que le fournisseur de la solution et le client se sont mis daccord contractuellement,
lengagement sur les exigences est obtenu des participants au projet.
Les exigences doivent voluer tout au long du projet. Comme les exigences voluent, obtenir
lengagement sur les exigences des participants du projet assure que les participants du projet

15
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

sont daccord avec les exigences courantes et approuves et avec les changements rsultant dans
les plans projets, les activits et lments produits.

1.1.6 Responsabilits lgales et fautes (K1)


Responsabilit lgale (K1)
Il y a des responsabilits lgales lies la qualit du logiciel. Les responsabilits lgales sont
souvent en relation avec des exigence spcifiques (i.e. exigence sur lenvironnement pour une
centrale nuclaire, un avion) qui doivent tre satisfaites dans le produit livr. Les responsabilits
doivent tre en relation avec les dfauts dans le produit.

Faute (dfaut) (K1)


Une faille dans un composant ou dans un systme qui peut engendrer, pour ce composant ou ce
systme, une dfaillance dans lexcution dune fonction exige, par exemple une instruction ou
une dfinition de donne incorrecte.
Un dfaut, si rencontr pendant une excution, peut causer une dfaillance dun composant ou
dun systme [ISTQB].

1.1.7 Priorit et criticit des exigences (K2)


Priorit des exigences (K1)
La priorit est lvaluation de limportance / urgence dune exigence.
Daprs le document [SWEBOK], en gnral, plus la priorit est leve, plus lexigence est
essentielle pour rpondre aux objectifs gnraux du logiciel.
Souvent classes sur une chelle de points fixes comme obligatoire, hautement dsir, dsir ou
optionnel, la priorit doit souvent tre confronte au cot du dveloppement et de
limplmentation.
Exemples de priorit dexigences :

Haute
Moyenne
Basse

Criticit des exigences (K1)

16
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

valuation du risque dune exigence en valuant le dommage en cas de non-respect dune


exigence
La criticit est exprime sous forme de niveaux : plus le niveau est lev, plus critiques sont les
consquences dans le cas dune dfaillance fonctionnelle.

1.1.8 Vrification et validation (K1)


La validation est un processus de confirmation que la spcification dune phase ou le systme
complet satisfait les exigences client.
La validation est gnralement ralise avec le support des utilisateurs dont le but est de
confirmer que les exigences ou la spcification des exigences ont dcrit ce dont le client a besoin.
Daprs CMMi, les activits de validation dmontrent que le produit ou que le composant dun
produit rpond son usage prvu quand il est plac dans lenvironnement cible. Donc, nous
savons que nous avons construit le bon produit . Les clients identifient souvent les descriptions
produit ou les exigences dune manire insuffisante et la validation aide la comprhension de ce
qui est ncessaire (en utilisant des outils comme des scenarii, des cas dutilisation ,du prototypage,
etc.).

La vrification est la comparaison dun lment intermdiaire produit avec ses spcifications. Cela
dtermine ainsi si le logiciel a t dvelopp correctement et si les spcifications fixes lors de la
phase prcdente sont remplies.
Daprs CMMi, la vrification fournit des points de contrle au cours desquels les livrables
slectionns ou les lments intermdiaires produits sont vrifis pour confirmer quils rpondent
leurs exigences ; ils permettent de confirmer tt et en cours de ralisation que le produit est
construit correctement.
Les techniques les plus connues pour la vrification et la validation sont les revues, les audits, les
checklists et le test.
La diffrence entre la validation et la vrification peut tre exprime de la faon suivante :

Vrification : avons-nous cr le produit correctement ?


Validation : avons-nous cr le bon produit ?

1.1.9 Ingnierie des Exigences, Gestion des Exigences et Dveloppement des


Exigences (K2)
Dlimitation entre gestion, dveloppement et ingnierie des exigences (K2)

17
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

LIngnierie des Exigences est une sous-discipline de lIngnierie Logicielle (Ingnierie Systme), se
focalisant sur lidentification et la gestion des exigences des systmes matriels et logiciels.
LIngnierie des Exigences comprend la Gestion des Exigences et le Dveloppement des Exigences.
La discipline dIngnierie des Exigences implique les diffrents sous-processus : lucidation des
exigences, analyse et ngociation (incluant la priorisation des exigences), les spcifications, la
modlisation systme, la validation des exigences.
Ces sous-processus peuvent se recouvrir, par exemple, la modlisation systme peut tre la fois
une partie de lanalyse et de la spcification, et dans certains cas de llucidation.
La gestion des exigences constitue un cadre de travail pour lIngnierie des Exigences et les
interfaces avec les autres processus comme la gestion de projet, la gestion de configuration et la
gestion de la qualit.
Le but de la gestion des exigences est de grer les exigences des produits de projets et les
composants, pour assurer lalignement entre ces exigences, les plans projet et les produits de
travail tout au long du cycle de vie des projets de produits (cycle de dveloppement et cycle de
maintenance).
La Gestion des Exigences (GE) inclut les processus pour le management global des exigences. Cest
un processus continuel de documentation, danalyse, de traabilit, de priorisation, de
communication et daccord sur les exigences et sur la gestion des changements des exigences.
Le Dveloppement des Exigences (DE) est un ensemble dactivits, de tches, de techniques et
doutils pour identifier, analyser et valider les exigences, qui inclut le processus de transformation
des besoins en exigences.
Le but du dveloppement des exigences est dlucider, danalyser, dtablir et de valider les
exigences client, produit et composants de produits.

18
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

1.2

Exigences (K2)

20 minutes

Pour passer lexamen, il nest pas ncessaire de connatre le contenu de toutes les normes. Il est,
nanmoins, important (K1) de connatre quelles normes sont importantes pour lIngnierie des
Exigences.

1.2.1 Standards (K1)


ISO 9000 :
Exigences dun systme de management de la qualit :
Concepts et fondements dfinis dun SMQ
Indpendant dun domaine ou de lindustrie

ISO 9126 (remplac par lISO/IEC 25000) :


Dfinit un modle qualit en six catgories : fonctionnalit, fiabilit, utilisabilit (facilit
dutilisation), efficacit, maintenabilit, portabilit

IEEE 610 :
Glossaire standard de la terminologie de lingnierie logicielle

IEEE 830 :
Pratique recommande pour les spcifications dexigences logicielles

IEEE 1233 :
Guide pour la Spcification d'Exigences de Systme

IEEE 1362:
Guide pour la technologie de linformation Dfinition Systme

SWEBOK Guide pour le Software Engineering Body of Knowledge (connu comme un rapport
technique ISO 19759)

19
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

SWEBOX dcrit gnralement les principes accepts en Ingnierie Logicielle. Ses 10 parties
rsument les concepts fondamentaux et incluent une liste de rfrence pointant sur des
informations dtailles.

1.2.2 Normes processus (K1)


ISO 12207 :
Standard pour le processus du cycle de vie logiciel

ISO 15288 :
Processus de cycle de vie systme

ISO 15504:
Software Process Improvement and Capability Determination (SPICE)

1.2.3 Les raisons de ngligence de lIngnierie des Exigences (K2)


LIngnierie des Exigences est dune importance vitale. Et pourtant, elle est maintes fois nglige.

Les raisons de la ngligence dIngnierie des Exigences peuvent tre les suivantes (K2) :

Pression importante des dlais


Orientation exclusive vers des rsultats rapides
Fixation exclusive des cots
Mauvaises interprtations (beaucoup de choses sont considres comme connues) et
manque de comprhension de limportance de lIngnierie des Exigences pour le succs
dun projet

Consquences possibles causes par la ngligence de lIngnierie des Exigences (K2) :

Les exigences deviennent imprcises


Les exigences sont ambiges
Les exigences sont contradictoires
Les exigences changent souvent pendant le dveloppement logiciel
Les exigences ne remplissent pas les critres
Les exigences peuvent tre interprtes diffremment
Des exigences manquantes

20
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

2 Modles de processus et
dIngnierie des Exigences (K2)

Processus

60 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des


Exigences
Les objectifs identifient ce que vous tes capable de faire, en ayant suivi chaque module.

2.1 Modles de processus (K2)


OA-2.1.1

Dcrire les diffrents modles de processus (K2)

OA-2.1.2

Dcrire quelles sont les diffrences entre modles de processus (K2)

2.2 Processus dIngnierie des Exigences (K2)


OA-2.2.1

Dcrire les caractristiques du processus dIngnierie des Exigences (K2)

OA-2.2.2

Expliquer les phases du processus dIngnierie des Exigences (K2)

21
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

2.1

Modles de processus (K2)

30 minutes

Termes
Extreme Programming, Modles de processus, Cycle de vie produit, Rational Unified Process, Cycle
en V

2.1.1 Les modles de processus (K2)


Les modles de processus sont des processus de description des processus de dveloppement,
indpendants de mthodes.
Les rles, activits, phases et documents sont ainsi pris en compte
Un modle de processus logiciel fournit un format standard pour la planification, lorganisation et
le droulement dun projet logiciel.

Cycle de Vie Produit (PLC Product Life Cycle) (K2)


Dfinit les diffrentes phases du dveloppement dun produit.
Les phases lmentaires sont :
1.
2.
3.
4.

Planification
Dveloppement
Maintenance
Fin de vie

La phase de planification inclut : la vision, la stratgie, le business plan et lanalyse de bnfices.


La phase de dveloppement inclut : la spcification, le maquettage et limplmentation. La phase
de dveloppement est souvent divise en quatre phases :

Analyse
Conception
Implmentation
Test

2.1.2 Modle de cycle en V gnral (K2)

22
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Les tapes de dveloppement sont :


Dfinition des exigences, dtermination des exigences (spcifications des exigences de hautniveau)
Maquettage fonctionnel du systme, analyses systmes (spcifications fonctionnelles)
Maquettage technique du systme, maquettage de larchitecture (conception logicielle)
Spcification des composants
Implmentation
Ce modle a une forme de cycle en V et chaque niveau a un niveau de test correspondant.

Analyse/dfinition des exigences

Conception fonctionnelle systme

Conception technique

Conception de composant

Tests dAcceptation
Tests Systme
Tests dintgration
Tests unitaires

Implmentation

Pour les organismes de formation : reprsentation graphique du modle de cycle en V gnral ;


description approfondie du modle de cycle en V gnral

2.1.3 Rational Unified Process (RUP) (K2)


Rational Unified Process est un modle de processus dfini par IBM Rational .
Cest un modle itratif (i.e. le processus est rpt jusqu ce que tous les scenarii, les risques et
les changements soient adresss). Il a 9 disciplines (6 disciplines dingnierie et 3 disciplines de
support) incluant la discipline Exigences . Chaque discipline est couverte par 4 phases
conscutives du cycle de vie projet : cration, laboration, construction et transition.

Pour les organismes de formation : approfondissement de RUP avec une reprsentation


graphique, tude approfondie de la discipline relative aux exigences

2.1.4 Approches Agiles


Gestion des exigences

23
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Dans les environnements agiles, les exigences sont communiques et traces via des mcanismes
comme les backlogs produit, les user stories et les maquettes cran. Les engagements sur les
exigences sont pris soit collectivement par lquipe soit par un responsable dquipe habilit. Les
affectations de tches sont ajustes rgulirement (e.g. quotidiennement, de faon
hebdomadaire) sur la base de lavancement et comme une comprhension accrue des exigences
et de la solution qui merge. La traabilit et la cohrence entre les exigences et les lments
produits sont raliss via des mcanismes dj mentionns au dbut dune itration ou la fin
dune itration comme les rtrospectives ou les dmonstrations .

Dveloppement des exigences


Dans les environnements agiles, les besoins client et les ides sont lucids, labors, analyss et
valids de faon itrative. Les exigences sont documentes sous diffrentes formes comme les
user stories , les scenarii, les cas dutilisation, les backlogs produit et les rsultats des
itrations (code dans le cas de logiciel). Le choix des exigences traiter dans une itration est fait
suite une analyse de risques et en fixant des priorits sur ce qui reste dans le backlog produit. Le
niveau de dtail des exigences (et des autres artfacts) documenter est fix pour le besoin de
coordination (entre les membres de lquipe, les quipes et les prochaines itrations) et le risque
de perdre ce qui a t appris. Lorsque le client est dans lquipe, il peut tout de mme y avoir un
besoin pour un client diffrent et une documentation produit autorise lexploration de multiples
solutions. Quand la solution merge, les responsabilits pour les exigences drives sont alloues
aux quipes adquates.

2.1.5 Extreme Programming (K2)


Extreme Programming est une mthodologie de dveloppement logiciel dfinie par Kent Beck et
al en rponse au changement des exigences client. La gestion de projet (par exemple SCRUM,
2.1.6) dfinit comment et quand les changements des exigences client sont implmentes dans la
solution logicielle (par exemple, dans quel Sprint). Elle prconise des releases frquentes du
logiciel au client avec des cycles de dveloppement courts (unit de temps), dont le but est
damliorer la productivit et de fournir des points de contrle pour vrifier o les nouvelles
exigences peuvent tre prises en compte.
Quelques caractristiques de lExtreme Programming comprennent :

La programmation par les pairs


Revue de code intensive
Tests unitaires du code
viter de programmer des fonctionnalits tant quelles ne sont pas absolument
ncessaires

24
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Structure de gestion horizontale (pas de structure hirarchique complexe au sein de


lquipe. Cela peut tre le mieux observ dans les quipes Scrum lquipe Scrum est
autogre , il ny a pas de rle comme : rle principal, chef de projet, etc.)
Simplicit et clart dans le code
Sattendre des changements dans les exigences client malgr le temps qui passe et le
problme qui est mieux compris
Communication frquente avec le client et entre les dveloppeurs
Renoncement complet la dtermination des exigences (pas de phase dexigences
spare avant que le dveloppement dbute : le dveloppement, le raffinement et la
dcouverte des exigences font partie du dveloppement logiciel (codage))

2.1.6 Scrum (K2)


Scrum est un cadre de travail agile. Scrum a t originellement formalis pour les projets de
dveloppement logiciel.
Scrum contient un ensemble de pratiques et de rles prdfinis. Les rles principaux dans Scrum
sont :

Scrum Master (responsable de la maintenance des processus)


Product Owner (reprsente les parties prenantes et les aspects mtier)
Lquipe (un groupe fonctionnel transversal effectuant lanalyse, la conception,
limplmentation, le test, etc.)

Une des caractristiques principales de Scrum est le dcoupage du dveloppement en sprint


(typiquement dune dure de 2 ou 4 semaines). Pendant chaque sprint, lquipe cre ce qui
sappelle un incrment produit potentiellement livrable.
Scrum permet la gestion des exigences via les backlogs . Il y a deux types de backlogs :

Le backlog produit : une liste de haut niveau maintenu tout au long du projet. Il
regroupe toutes les exigences sous forme dune description gnrale des fonctionnalits
potentielles, priorise via les priorits business. Le backlog produit est la proprit du
Product Owner .
Le backlog de sprint : la liste du travail raliser par lquipe durant le prochain sprint.
Les fonctionnalits sont dcoupes en tches, qui, suivant les bonnes pratiques, doivent
tre comprises entre 4 et 6 heures de travail. Le backlog de sprint est la proprit de
lquipe.

Les caractristiques principales de lapproche Scrum sont :

A la fin de chaque sprint, le logiciel fonctionnel doit tre livr en pratique, les quipes
commence travailler sur lanalyse des exigences et continue pendant le sprint courant.
Pendant le dcoupage des tches, les exigences sont clarifies.

25
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Les membres de lquipe sont censs interagir entre eux, et limplication rgulire du
client est un concept cl dans le dveloppement agile. Les retours client peuvent tre
fournis lors des sessions de dmonstration dune nouvelle version logicielle la fin dun
sprint, ou via les tests dacceptation utilisateur.
Les exigences voluent via les retours client montrer du logiciel qui fonctionne aide les
clients clarifier leurs exigences.
Les exigences ne sont pas compltement spcifies avant le dmarrage du projet, mais les
exigences slectionnes pour un sprint sont spcifies au dbut du sprint.
Les fonctionnalits sont censes tre repriorises pendant que le projet avance.

Limpact principal de Scrum sur lIngnierie des Exigences est que les spcifications des exigences
ne sont pas compltes ni valides avant le dbut du dveloppement du projet.
Le product owner et lquipe se mettent daccord sur les fonctionnalits, provenant du backlog
produit, inclure dans le sprint venir, en se basant sur les priorits business et leffort de travail
requis. Les exigences utilisateur sont formules par le Product Owner sous forme de user
stories qui contiennent des informations sur Qui, Quoi, Pourquoi mais pas sur le
Comment de lexigence. Au dbut du sprint, les fonctionnalits slectionnes sont dcoupes
sous forme de tches dans le backlog de sprint, et ensuite dveloppes.
Limplication des product owners, par exemple en leur prsentant les fonctions implmentes du
logiciel, permet de clarifier les exigences pour lquipe et pour les product owners eux-mmes.

Pour les organismes de formation : donner des exemples de user stories et des lments
correspondants de backlog produit et de backlog de sprint.
Pour les organismes de formation : expliquer aussi deux autres modles agiles incluant Crystal.

2.1.7 Modle de maturit (K2)


Les niveaux de maturit servent pour lidentification et lamlioration de la maturit de processus
(valuation de processus et amlioration de processus)

ISO/IEC 15504 (SPICE Software Process Improvement and Capability dEtermination) (K1)
ISO/IEC 15504 (SPICE Software Process Improvement and Capability dEtermination) est un
ensemble de standards techniques pour le processus de dveloppement logiciel et les fonctions de
gestion mtier correspondant.
ISO/IEC 15504 peut tre utilis comme un moyen damliorer le processus et/ou la dtermination
des aptitudes (par exemple, lvaluation des aptitudes des processus dun vendeur).

26
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

SPICE dfinit des processus classs en cinq catgories de processus :

Client fournisseur
Ingnierie
Support
Gestion
Organisation

Pour chaque catgorie de processus ci-dessus, ISO/IEC 15504 dfinit un niveau daptitude :
5 Processus optimis
4 Processus prdictible
3 Processus tabli
2 Processus gr
1 Processus ralis
0 Processus incomplet

Pour les organismes de formation : approfondissement en utilisant lexemple de lISO 15504/SPICE,


avec une description des exigences typiques pour lIngnierie des Exigences

Capability Maturity Model Integrated (CMMI)


Le CMMI dfinit des niveaux de maturit pour le dveloppement, les services et lacquisition :
1 Initial (chaotique, ad hoc, hros individuels) le point de dpart pour lutilisation de
nouveaux processus
2 Gr - le processus est gr par rapport des mtriques valides
3 Dfini le processus est dfini / confirm comme un processus mtier standard et
dcompos en niveaux 0, 1 et 2
4 Gr quantitativement
5 Optimis la gestion du processus inclut des amliorations / optimisations dlibres du
processus

27
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

2.2

Processus dIngnierie des Exigences (K2)

30 minutes

Termes
Processus orient client, perspective, Ingnierie des Exigences

2.2.1 Dfinition du processus dIngnierie des Exigences (K2)


LIngnierie des Exigences est une discipline qui inclut les processus ncessaires pour
lidentification, la structuration et la gestion des Exigences. LIngnierie des Exigences contient les
sous-processus suivants :

Identification des exigences


Analyse des exigences
Spcification des exigences
Accord sur les exigences
Changements des exigences
Validation et Assurance Qualit

2.2.2 Influences de lIngnierie des Exigences


Certains facteurs peuvent avoir une influence ngative sur lIngnierie des Exigences :

Dun point de vue interne (au sein de lorganisation du vendeur de logiciels) :


o Manque de connaissance du domaine utilisateur
o Approche / mthodologie inefficace de lIngnierie des Exigences
o Exprience et comptence insuffisante du personnel
Dun point de vue externe (en dehors de lorganisation du vendeur de logiciels) :
o Manque de communication
o Objectifs business non clairs ou changeant donnant des exigences instables
o Pas de connaissance du processus de dveloppement logiciel
o Pas dimplication des utilisateurs et/ou des parties prenantes mtier

Il y a diffrentes parties prenantes avec diffrents points de vue sur le processus dIngnierie des
Exigences. En gnral, le processus peut tre vu dun point de vue du client et dun point de vue
du fournisseur (vendeur).

28
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Exemple :
Dun point de vue client, laspect le plus important de lIngnierie des Exigences peut tre :
linterface utilisateur, les applications et les services. Dun point de vue du fournisseur,
dautres aspects pouvant tre considrs sont : larchitecture, la rpartition de la charge,
etc.
Les mthodes de processus dIngnierie des Exigences avec le client au centre sont :

Analyse et conception orientes utilisateur


Approche par prototypage
Utilisation de dmonstrations comme moyen de validation des incrments dun systme

29
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

3 Gestion de projet et du risque (K2)

60 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des


Exigences
Les objectifs identifient ce que vous tes capable de faire, en ayant suivi chaque module.

3.1 Gestion de projet (K2)


OA-3.1.1

Expliquer pourquoi lIngnierie des Exigences est importante dans les projets (K2)

OA-3.1.2

Rappeler les erreurs qui peuvent survenir en Ingnierie des Exigences (K2)

3.2 Gestion de risque (K1)


OA-3.2.1

Reconnatre les risques relatifs lIngnierie des Exigences (K2)

30
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

3.1

Gestion de projet (K2)

30 minutes

Termes
Conception projet, ngociations de contrat, dfinition de projet, excution de projet

3.1.1 Ncessit de lIngnierie des Exigences dans les projets (K2)


Certaines des raisons principales de lchec de projets sont lies aux exigences. La ngligence vis-vis de lIngnierie des Exigences peut entraner des exigences imprcises, contradictoires, ne
rpondant pas aux critres ou ne satisfaisant pas les besoins des parties prenantes. Cest
pourquoi, une Ingnierie des Exigences structure et prcautionneuse est ncessaire chaque
projet.

LIngnierie des Exigences devrait contribuer aux domaines suivants :

Conception projet
o Identification des besoins et des attentes client concernant la solution du
problme
o Dfinition des exigences de haut niveau
Ngociations de contrat
o valuation des exigences client
o Dtermination du primtre initial et des ressources requises pour un projet
o Dtermination du cot de dveloppement (implmentation des exigences)
o Accord sur les priorits des exigences
Dfinition du projet
o Dfinition des rles, des tches, des activits et des processus additionnels
(exemple : gestion du changement)
o Conception dtaille mtier de la solution
o Contribution la conception de larchitecture
o Contribution aux livrables du processus de test
Excution projet
o Fourniture dune base pour le dveloppement des exigences et pour la vrification
et la validation des exigences (test)
o Forcer la revue des plans et leur ajustement au primtre courant de la solution
en cas de changement des exigences

31
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

3.1.2 Quelles erreurs peuvent survenir dans lingnierie des Exigences ? (K2)
Les erreurs les plus communes sont les suivantes :

Exigences non claires


Changement des exigences (si les changements rsultent dobjectifs projet non clairs ou
dimprcisions sur le domaine mtier du client ; les changements des exigences ne sont
pas perus comme une erreur dans les approches itratives et agiles)
Instabilit du produit et des bases de conception pour les commandes sous-traites
Manque de clart dans les responsabilits (aussi bien du ct client que du ct vendeur)
cart entre les attentes client et les contenus projet
Implication client insuffisante
Dfinition projet avec des jalons qui ne peuvent pas tre atteints
Estimation imprcise des dpenses
Estimation imprcise des impacts des changements des exigences sur les autres parties du
produit en cours de dveloppement
Manque de traabilit

32
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

3.2

Gestion de risques (K2)

30 minutes

Termes
Analyse des modes de dfaillance et de leurs effets, risque produit, risque projet, risque, gestion
de risque, plan de gestion de risque

3.2.1 Ncessit de la gestion de risque (K2)


Une gestion de risque efficace est une cl pour diminuer les risques produit et projet.
Lidentification des risques, leur analyse mene de faon approprie et la planification de
ractions adquates sur les risques minimisent les chances doccurrence dun risque et les
consquences si un risque survient.

3.2.2 Risque (K2)


Risque (K1)
Un risque est dfini comme leffet dune incertitude sur des objectifs, positif ou ngatif [ISO
31000].
Lautre dfinition dcrit le risque comme la chance quun vnement, un danger, une menace ou
une situation puisse survenir et rsulte en des consquences indsirables ou un problme
potentiel. Le niveau dun risque est dtermin par la probabilit dun vnement indsirable de se
produire et limpact (le prjudice rsultant de cet vnement) [ISTQB].

Type de risque (K2)


Il y a deux types de risques :

Risque projet
Risque produit

Risques projet (K2)


Les risques projet sont les risques qui empchent le projet datteindre ses objectifs, comme :

Facteurs organisationnels
o Comptences, formations et pnuries de ressources

33
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

o
o

Problmatiques sur le personnel


Problmatiques politiques, comme :
Problmes avec les parties prenantes communiquant leurs besoins et
leurs attentes
chec pour suivre les informations trouves dans les revues (exemple : ne
pas amliorer les pratiques documentant les exigences)
o Attitude ou attentes incorrectes concernant lIngnierie des Exigences
Problmatiques techniques
o Problmes pour dfinir les bonnes exigences
o La mesure selon laquelle des exigences ne peuvent pas rpondre des contraintes
existantes donnes
o Environnement de dveloppement ou de test pas prt temps
o Mauvaise qualit de la conception, du code, des donnes de configuration, des
donnes de tests et des tests
Problmatiques fournisseur
o Echec dune tierce partie (par exemple, des composants non livrs temps)
o Problmatiques contractuelles

Risques produit (K2)


Les zones dchec potentielles (vnements futurs adverses ou dangers) dans le logiciel ou
systme sont connues comme des risques produit, car ils sont un risque sur la qualit du produit.
Cela inclut :

Risque important dchec de livraison du logiciel (logiciel ou systme incapable de fournir


une fonction requise dans des limites spcifies), documentation logicielle de basse
qualit (incomplte, incohrente, difficile maintenir)
Le potentiel quun logiciel / matriel pourrait causer comme prjudice un individu ou
une socit
Caractristiques logicielles mdiocres (par exemple, fonctionnalit, fiabilit, facilit
demploi ou performance)
Mauvaises qualit et intgrit des donnes (par exemple, problmatiques de migration de
donnes, problmes de conversion de donnes, problmes de transport de donnes,
violation de standards de donnes)
Logiciel qui ne ralise par les fonctionnalits attendues et qui ne satisfait pas les besoins
des parties prenantes
Risques business bass sur une mauvaise qualit

3.2.3 Gestion de risque (K2)


La gestion de risque est un processus didentification, dvaluation et de priorisation, de
planification de raction sur les risques et de rsolution et de supervision des risques. Cela permet

34
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

didentifier des facteurs potentiels qui peuvent avoir un effet ngatif sur lexcution dun projet et
prparer une action approprie pour faire face un risque si il survient.
Diffrents risques peuvent provenir de diffrents groupes de parties prenantes : par exemple,
lquipe de dveloppement verra des risques diffrents de ceux considrs par les parties
prenantes mtier ou les utilisateurs finaux.
La gestion des risques comprend les activits suivantes [ISTQB] :

Identification du risque
Analyse du risque
Attnuation du risque

Traitements potentiel du risque


Les techniques pour grer le risque peuvent tre divises en quatre catgories principales :

vitement
Rduction
Partage
Maintien

Plan de gestion de risque


Le plan de gestion de risques devrait tre cr avant et aprs (priodiquement mis jour) la
cration du plan projet. Le plan de gestion des risques devrait fournir des contrles de scurit
efficaces pour grer les risques et contenir un planning pour le contrle de limplmentation et
des personnes responsables de ces actions.
Le plan de gestion des risques comprend :

la liste des risques


la probabilit doccurrence et/ou la priorit
la svrit de limpact de chaque risque (incluant le cot si applicable)
les stratgies de rduction pour chaque risque (incluant les personnes/groupes
responsables de prendre les actions)
la matrice dvaluation des risques

3.2.4 Analyse des modes de dfaillance et de leurs effets (K2)


Une technique commune de gestion de risques (identification, analyse et planning de ractivit)
est lanalyse des modes de dfaillances et de leurs effets (AMDE).

35
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

AMDE permet de prioriser les dfaillances potentielles par rapport la gravit des consquences,
la frquence doccurrence et comment elles peuvent tre facilement dtectes. AMDE documente
aussi la connaissance actuelle et les actions propos des risques de dfaillances pour une
utilisation en amlioration continue. Dans la plupart des cas, AMDE est utilis pendant la phase de
conception dun projet et son objectif principal est dviter les dfaillances futures. Dans des
phases suivantes, elle peut tre utilise pour contrler des processus. AMDE devrait commencer
dans les premires tapes conceptuelles du projet et continuer tout au long du cycle de vie.
Idalement, AMDE devrait tre planifie ds que les premires informations sont disponibles.
Les rsultats dune AMDE sont les actions pour prvenir et rduire la gravit ou la probabilit des
dfaillances.

tapes dimplmentation de lAMDE


LAMDE est droule en trois tapes principales :
tape 1 : gravit (identification de la gravit des dfauts potentiels)
Etape 2 : occurrence (identification de combien de fois un dfaut potentiel peut arriver)
Etape 3 : dtection (identification des techniques de dtection des dfauts)

36
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

4 Rles et responsabilits (K2)

60 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des Exigences


Les objectifs identifient ce que vous tes capable de faire, en ayant suivi chaque module.

4.1 Rles fondamentaux (K1)


OA-4.1.1

Rappeler les rles fondamentaux qui sont dans lIngnierie des Exigences (K1)

OA-4.1.2

Dcrire le but et le rle dune partie prenante (K2)

4.2 Tches de lIngnierie des Exigences (K2)


OA-4.2.1

Dcrire les tches de lIngnierie des Exigences (K2)

OA-4.2.2

Rappeler les caractristiques dun Professionnel de lIngnierie des Exigences (K1)

37
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

4.1

Rles fondamentaux (K1)

20 minutes

Termes
Client, Contractant, Partie prenante

4.1.1 Rles fondamentaux (K2)


Client
Une personne, un groupe ou une organisation exigeant une solution

Contractant (fournisseur, vendeur)


Une personne, un groupe ou une organisation fournissant la solution

Le client formule ses besoins et fournit des besoins et des attentes mtier initiales. Gnralement,
ses besoins sont fournis en mme temps que la requte de service / offre. Il est de la
responsabilit du vendeur dexplorer ces besoins et dextraire des exigences partir de ces
donnes.
Le contractant fournit des solutions bases sur les besoins client.

Rles dans lIngnierie des Exigences


Gestionnaire dexigence
Un gestionnaire dexigence est une personne responsable de la documentation, lanalyse, la
traabilit, la priorisation et laccord sur les exigences et aussi le contrle des changements et la
communication vers les parties prenantes correspondantes.

Dveloppeur dexigence
Un dveloppeur dexigence est une personne oriente technique gnralement implique dans
llucidation, lanalyse et la priorisation des exigences.

38
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

4.1.2 Parties prenantes (K2)


La partie prenante est un groupe ou un individu qui est affect par ou est en quelque sorte
responsable du rsultat d'une action. Les parties prenantes du projet sont des individus et des
organisations qui sont activement impliqus dans le projet, ou dont les intrts peuvent tre
touchs la suite de l'excution du projet ou de l'achvement du projet.
Les parties prenantes peuvent tre des personnes physiques, des socits ou des personnes
morales.
Les parties prenantes ont souvent des conflits d'intrts entre elles. Cela aboutit souvent des
exigences contradictoires. Le problme des exigences contradictoires doit tre aborde lors de la
phase d'analyse des exigences.
Il peut y avoir plusieurs catgories de parties prenantes, parmi lesquelles :

Les clients
Les utilisateurs finaux
Les managers
Les personnes impliques dans les processus organisationnels
Les ingnieurs chargs du dveloppement et de la maintenance des systmes
Les clients de l'organisation qui vont utiliser le systme
Les organismes externes (rglementation)
Les experts du domaine

Les parties prenantes typiques sont :

Client
Utilisateur final
Chef de projet
Chef de produit
Analyste systme
Analyste mtier
Reprsentants business
Personnel marketing et vente
Dveloppeur de logiciels
Personnel de l'assurance qualit
Experts techniques (architectes, ingnieurs base de donnes)
Gestionnaire des changements
quipe cur de projet
quipe de management

39
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Lidentification de toutes les parties prenantes est ncessaire pour prendre en considration tous
les points de vue dans la solution envisage.

Pour les organismes de formation: description des parties prenantes typiques (par exemple,
directeur gnral, directeur de projet, client)

40
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

4.2

Tches de lIngnierie des Exigences (K2)

30 minutes

4.2.1 Tches de lIngnierie des Exigences (K2)


Les tches principales de l'ingnierie des exigences sont les suivantes :

Analyse des processus mtier ralise au sein d'une organisation


Identification et analyse des exigences
Structuration et modlisation des exigences
Assurance qualit des exigences et des spcifications
Cration de la spcification des exigences
Analyse des risques (dans le contexte des exigences)
Gestion du changement des exigences
Accord sur les exigences avec les parties prenantes

4.2.2 Connaissance dun Professionnel de lIngnierie des Exigences (K1)


Un professionnel dIngnierie des Exigences devrait avoir les comptences suivantes :

Comptence de modration
Confiance en soi
Capacit convaincre
Comptences linguistiques
Capacit communiquer
Prcision
Capacit danalyse, pense rflchie
Capacit agir de faon structure
Comptence mthodologique
Rsistance au stress

41
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5 Identification des Exigences (K2)

150 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des Exigences


Les objectifs identifient ce que vous tes capable de faire, en ayant suivi chaque module.

5.1 Client (K1)


OA-5.1.1

Rappeler le contenu dun contrat (K1)

OA-5.1.2

Identifier ce qui devrait tre considr lors de lvaluation des exigences (K2)

5.2 Visions et objectifs projet (K2)


OA-5.2.1

Expliquer les caractristiques dune vision projet typique (K2)

5.3 Identification des parties prenantes (K2)


OA-5.3.1

Expliquer comment les parties prenantes peuvent tre identifies (K2)

OA-5.3.2

Identifier les parties prenantes pour un projet spcifique (K3)

5.4 Techniques pour identifier les exigences (K2)


OA-5.4.1

Identifier les objectifs de lidentification des exigences (K2)

OA-5.4.2

Appliquer les diffrentes techniques didentification des exigences (K2)

5.5 Exigences fonctionnelles et non-fonctionnelles (K2)


OA-5.5.1

Dcrire les caractristiques des exigences fonctionnelles et non-fonctionnelles (K2)

OA-5.5.2

Comparer les diffrences entre les exigences fonctionnelles et non-fonctionnelles (K2)

5.6 Description des exigences (K2)


OA-5.6.1

Dcrire le contenu dun document standard des exigences (K2)

OA-5.6.2

Dcrire les caractristiques dexigences de qualit (K2)

OA-5.6.3

Construire une exigence (K3)

42
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5.1

Client (K1)

20 minutes

Termes
Client, Contrat

5.1.1 Client (K1)


Le client, organisation ou personne qui achte le logiciel, est l'une des principales parties
prenantes du projet. Les besoins client doivent tre satisfaits.
Le client doit toujours tre impliqu. L'objectif est de comprendre le client et de dvelopper une
comprhension mutuelle avec lui. Le contractant (vendeur) doit donc toujours se mettre dans la
position du client.
En valuant les exigences des fins de planification du projet (ce qui est l'un des sujets qui seront
couverts par le projet), les diffrents points de vue doivent tre pris en considration comme une
exigence spcifique qui peut avoir des priorits et gravits diffrentes en fonction des parties
prenantes.

5.1.2 Contrat (K1)


L'accord (contrat) devrait officiellement dfinir et dcrire ce que veut le client. Cela doit assurer
que l'intrt du client est au centre (c'est dire le vendeur n'est pas contraint la solution quil
prfre mais il analyse les besoins du client et recommande une solution qui permet de satisfaire
ses besoins dans les meilleures conditions).
L'accord :

Doit tre compatible avec les ressources disponibles pour mettre en uvre la solution,
Est bas sur: les estimations, les dlais, les prix et les plans du projet.

LIngnierie des Exigences fournit des informations en entre pour de telles estimations.

Le contrat devrait inclure :

Une description brve de la solution planifie


La liste des exigences de haut niveau priorises
Les critres d'acceptation pour chaque exigence
La liste des lments produits (documentation, code, logiciel fonctionnant)

43
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Les dates limites pour le dveloppement et la livraison du produit


Dautres besoins et attentes comme la technologie utiliser de prfrence, les besoins en
ressources, etc.

44
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5.2

Visions et objectifs projet (K2)

20 minutes

Termes
Objectif, Vision

5.2.1 Vision (K2)


Le dveloppement de visions du projet est la premire tape de l'ingnierie des exigences.
Une vision devrait :

Dfinir les clients, les marchs et les concurrents


Dfinir les objectifs atteindre
Permettre d'atteindre une comprhension commune de toutes les parties prenantes

Il est crucial d'avoir une dfinition claire des visions du projet.

Pour les organismes de formation : prsentation des visions typiques dun projet

Questions importantes propos des visions dun projet (K2)

Que va changer le projet ?


Pourquoi le projet est-il ncessaire ?
Que se passe-t-il une fois le projet termin ?
Qui profitera du projet ?
Quels sont les cots prts tre assums ?
Quels sont les risques prts tre assums ?

Pour chaque projet, la vision doit tre r estime.

Influences sur la vision du projet (K1)


Les facteurs suivants peuvent influencer la vision :

Les clients
o Les objectifs des clients
o Les prfrences des clients
Stratgie

45
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

o Stratgie d'une organisation


o Positionnement sur le march
o Directions suivre
Concurrence
o Donnes de concurrence
o Dveloppement march
Produits
o Niveau d'innovation
o Groupe cible
Technologies
o Nouveaux outils
o Nouveaux standards
Ressources disponibles
o Temps, collaborateurs, capacits

46
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5.3

Identification des parties prenantes (K2)

20 minutes

Termes
Partie prenante

5.3.1 Identification des parties prenantes (K2)


Toutes les parties prenantes ct client et ct fournisseur doivent tre identifies.
Chaque partie prenante ou chaque groupe de parties prenantes peut fournir de nouvelles
exigences et influencer la conception de la solution envisage. Si toutes les parties prenantes ne
sont pas identifies, il y a un risque que certaines exigences importantes ou des limitations restent
inconnues et ne soient pas pris en compte dans la conception. Oublier des parties prenantes peut
entraner des changements complexes exigs dans le logiciel un stade avanc du projet ou aprs
la sortie du systme dans un environnement de production.
Certaines parties prenantes peuvent crer des groupes d'intrt (par exemple, toutes les parties
prenantes mtier). Les groupes d'intrt devraient tre runis, car cela permettrait de grer leurs
besoins de manire plus efficace.

5.3.2 Procdure didentification et dvaluation des parties prenantes (K2)


La procdure d'identification et d'valuation des parties prenantes comprend les activits
suivantes :

Identification des parties prenantes (analyse des processus mtier, dtermination des
propritaires des processus et des produits, analyse de la structure organisationnelle et du
march)
Classification des parties prenantes en groupes (si possible)
Dtermination des relations
Identification des conflits potentiels
Analyse des conflits, leurs sources et identification des opportunits gagnant-gagnant
Identification des parties prenantes minimisant des risques pour les impliquer davantage
dans les activits du projet
Identification des points de vue des parties prenantes

47
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Pour les organismes de formation : explication de l'identification et l'valuation des parties


prenantes

48
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5.4

Techniques didentification des exigences (K2)

40 minutes

Termes
Apprentissage, brainstorming, reprsentant du client,
questionnaire, revue, auto-enregistrement, groupe de travail

observation

terrain,

entretien,

5.4.1 Identification des parties prenantes (K2)


Les principaux objectifs de lidentification des exigences sont les suivants :

Identifier toutes les fonctions, caractristiques, limitations et attentes dsires


Orienter les exigences vers la vision du projet
Dtailler les exigences de haut-niveau et dcrire clairement les fonctions et les services
Exclure les fonctions et les fonctionnalits que le client ne veut pas

5.4.2 Techniques (K1)


Les techniques les plus courantes pour identifier les exigences sont :

Questionnaires
Entretiens
Auto-enregistrement
Reprsentants du client sur site
Identification sur la base de documents existants
Rutilisation (Rutiliser la spcification dun certain projet)
Brainstorming
Observation terrain
Apprentissage
Ateliers

5.4.2.1 Questionnaires
Un questionnaire peut tre constitu de questions ouvertes ou fermes. Une question ouverte
requiert de celui qui rpond de formuler sa propre rponse. Dans le cas d'une question ferme, la

49
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

personne qui rpond est invite choisir une rponse parmi un certain nombre d'options
possibles. Ces options doivent tre mutuellement exclusives.

Avantages :

Cots mineurs
Un public large peut tre cibl

Inconvnients :

Non applicable pour recueillir des connaissances implicites


Faible taux de retour sans motivation des personnes qui rpondent
Des questionnaires peuvent souvent tre directifs, ce qui empche l'identification des
besoins rels des utilisateurs

5.4.2.2 Entretien
Lentretien est une technique de conversation o l'intervieweur demande linterview d'obtenir
des informations sur un sujet spcifique. Cette technique est trs interactive et permet de
modifier l'ordre des questions pralablement prpares selon les rponses de linterview et de la
situation.
De bons entretiens sont plus difficiles mener que l'on pense cause du comportement dune
conversation normale (par exemple, les phrases de fin de l'interlocuteur), ce qui peut conduire
des interprtations introduites dans les donnes. L'intervieweur doit poser des questions ouvertes
pour obtenir des informations et poser des questions fermes juste pour confirmer les
informations recueillies (par exemple, confirmer les exigences dj identifies).

Avantages :

La progression peut tre adapte en fonction de la personne qui rpond

Inconvnients :

Consommateur de temps
Reproduction insuffisante des rsultats (difficult d'obtenir les mmes rponses lorsqu'on
rpte un entretien)

5.4.2.3 Auto-enregistrement

50
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Dans cette technique, la partie prenante (par exemple, un utilisateur final) documente ses activits
exerces pour accomplir une tche spcifique.
En plus de documenter les activits tel quel, l'utilisateur dcrit galement les modifications, les
dsirs et besoins.
Les techniques associes cette approche sont : des dmonstrations ou des revues de documents.

Avantages :

Faible temps et effort pour l'Ingnieur des Exigences ct vendeur logiciel

Inconvnients :

Ngliger des activits automatises (comme l'impression et la rception de copie


imprime)
Trs dpendante de la motivation et l'exprience de l'utilisateur

5.4.2.4 Reprsentants du client sur site


Cette approche est l'une des mthodes les plus efficaces pour lidentification des exigences (et la
validation) car elle permet au reprsentant de surveiller systmatiquement le progrs, de vrifier
l'exactitude de la conception et de fournir des commentaires et des informations supplmentaires
si ncessaire.
Avoir des reprsentants client sur site est l'une des principales rgles des mthodes Agiles.

Avantages :

Retours rapides
Fourniture dexigences orientes utilisateur qui sont facilement acceptes

Inconvnients :

Cots levs pour le client


Cots d'adaptation

5.4.2.5 Identification des exigences sur la base de documents existants


Cette technique peut tre utilise dans le cas o il y a de la documentation dj existante qui peut
aider identifier les besoins au sein d'une organisation. Cette documentation peut tre :
Modles de processus et cartographie

51
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Descriptions de processus
Organigrammes
Spcification produit (dans le sens, sortie de processus spcifique)
Procdures (i.e. procdures de travail)
Standards et instructions
Les exigences identifies sont la base pour une analyse ultrieure des exigences et les besoins
doivent tre dtaills et tendus avec d'autres exigences correspondantes et lies.

Avantages :

Aucune fonctionnalit n'est nglige

Inconvnients :

Coteux
Non applicable quand il n'y a pas de documents ou seulement des documents de base au
sein d'une organisation
Non applicable lorsque la documentation n'est pas maintenue correctement jour

5.4.2.6 Rutilisation (rutilisation de la spcification dun certain projet)


La spcification d'un certain projet peut tre ralise quand une organisation a dj ralis un ou
plusieurs projets similaires au projet en cours. La spcification des exigences ralise pour un (ou
plusieurs) projet(s) prcdent (s) peut tre utilise dans un autre projet pour raccourcir la dure
de l'analyse des exigences et de la documentation et donc - permet de lancer limplmentation
plus tt.
Dans la plupart des cas, seules certaines parties des spcifications existantes peuvent tre utilises
dans de nouveaux projets. La documentation rutiliser doit toujours tre vrifie par rapport la
conformit avec les besoins et exigences courants et correctement ajusts.

Avantages :

Rduction des cots

Inconvnients :

Cots levs du premier projet


La rutilisation des exigences peut demander une gestion du changement importante et
coteuse sielle n'a pas t prise en compte correctement dans les projets prcdents

52
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5.4.2.7 Brainstorming
Le brainstorming est une technique couramment utilise pour obtenir des exigences relatives
des domaines nouveaux ou pas bien connus concernant une nouvelle activit d'une organisation
ou une fonctionnalit du systme planifi. Cette technique permet de recueillir de nombreuses
ides de diverses parties prenantes en temps limit et faible cot. Lors de la sance de
brainstorming, les participants soumettent des ides et des concepts relatifs problme donn.

Avantages :

Faibles cots
Chance de recueillir de nombreuses ides valables en temps limit

Inconvnients :

Difficile si participants non motivs


Difficile appliquer dans des quipes distribues

5.4.2.8 Observation terrain


Lobservation sur le terrain permet des activits d'observation des utilisateurs et des processus en
cours et d'identifier les exigences du systme sur cette base. Une observation ralise sur site
permet de regarder les utilisateurs en train de travailler et de documenter les processus, les
tches et les rsultats. Dans certains cas, l'observation est prolonge par des entretiens des
utilisateurs au sujet de leurs emplois et sur la faon dont ils ralisent leurs tches.

Avantages :

Possibilit d'observer les utilisateurs pendant leur travail et didentifier de rels besoins
Utile lorsque les parties prenantes ont des problmes pour exprimer leurs besoins

Inconvnients :

Des cas exceptionnels peuvent tre omis


Non applicable dans certaines situations (par exemple, en scurit de fonctions et pour
des raisons lgales)

5.4.2.9 Apprentissage
Le but de lapprentissage est de recueillir des exigences d'un client, en particulier dans le cas o les
processus et les activits effectus par le personnel client ne sont pas faciles dcrire en utilisant

53
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

d'autres techniques, comme des entretiens, ou si le client a des problmes pour exprimer
clairement les exigences concernant le logiciel prvu.
Lapprentissage est un processus dtude, par le client de son travail. Le client, qui connat le
mieux comment faire son travail spcifiques, lenseigne l'ingnieur des exigences - comme un
matre son lve.

Avantages :

Aide pour surmonter la difficult que les employs du client peuvent avoir penser des
choses de faon abstraite et dcrire leurs tches verbalement

Inconvnients

Cots levs et consommateur de temps


Non applicable dans des environnements dangereux

5.4.2.10 Ateliers
Latelier est une sorte de runion sur un sujet spcifique (pralablement dfini et annonc aux
participants), impliquant gnralement les parties prenantes reprsentant diffrents secteurs et /
ou domaines pendant une priode courte et intensive.
Les ateliers peuvent avoir des objectifs diffrents

Identifier des exigences (i.e. afin d'tablir la porte d'une solution)


Dcouvrir des exigences caches (i.e. des exigences qui ne sont pas directement indiques
ou mme pas ralises par les parties prenantes, mais ncessaires pour accomplir certains
de leurs besoins ou des exigences de niveau suprieur)
Dvelopper des exigences (de faon dtaille) dans un secteur nouvellement identifi
Prioriser les exigences
Parvenir un consensus sur les exigences quand il s'agit de s'accorder sur les exigences
(signature)
Examiner les rsultats de processus spcifis ou activits (i.e. revoir la spcification des
exigences fonctionnelles) et rsoudre les problmes qui pourraient tre apparus

Avantages

Faire participer les personnes qui ont diffrents points de vue sur un problme donn
Permettre de dterminer et de dcrire les exigences provenant de diffrentes
perspectives
Permet de dcouvrir rapidement et de rsoudre des conflits potentiels entre les exigences
des parties prenantes

54
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Inconvnients :

Difficile dans le cas d'quipes gographiquement distribues


Disponibilit de toutes les personnes requises pour participer l'atelier
Le consensus n'est pas ncessairement facile atteindre lors d'un atelier, et la discussion
peut dcrocher sur de (petites) questions problmatiques, rendant ainsi le processus long
et dmotivant pour les participants

55
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5.5

Exigence fonctionnelle et non-fonctionnelle (K2)

20 minutes

Termes
Exigences fonctionnelles, exigences non-fonctionnelles

Pour passer lexamen, les tudiants doivent tre capables de fournir des exemples dexigences
fonctionnelles et non-fonctionnelles et de dtailler les caractristiques qualit.

5.5.1 Exigences fonctionnelles (K2)


Les exigences fonctionnelles prcisent ce que le systme fait. Elles prcisent les fonctions du
systme perues par l'utilisateur final. Les exigences fonctionnelles dcrivent aussi les
dclencheurs des processus (action de l'utilisateur, entre / sortie de donnes causant le
lancement dun processus mtier).
Les exigences fonctionnelles devraient tre classes par rapport aux caractristiques qualit
suivantes [ISO / IEC 25000] (K1) :

Pertinence
Prcision
Interoprabilit
Fonctionnalit
Conformit
Scurit

5.5.2 Exigences non-fonctionnelles (K2)


Les exigences non-fonctionnelles spcifient comment le systme fonctionne. Elles dcrivent les
attributs qualit de tout le systme ou de ses composants ou fonctions spcifiques. Elles limitent
la solution en exigeant des paramtres d'efficacit spcifiques.
Les exigences non-fonctionnelles sont difficiles dcrire, par consquent, elles sont souvent
exprimes de faon vague ou pas documentes du tout. Cela les rend difficiles tester. Une
attention particulire doit donc tre mise sur les exigences non-fonctionnelles toutes les tapes
du processus IE.

56
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

En raison des problmes dexpression des exigences non-fonctionnelles, elles peuvent tre
difficiles tester. Les exigences non-fonctionnelles devraient donc tre exprimes clairement et
tre mesurables.
Les exigences non-fonctionnelles sont [ISO / IEC 25000] (K1)

Fiabilit
Facilit demploi
Efficacit
Maintenabilit
Portabilit

Les exigences non-fonctionnelles spcifient les critres qui peuvent tre utiliss pour juger de
l'exploitation d'un systme donc elles ont un grand impact sur la satisfaction du client utilisant le
logiciel. Les exigences fonctionnelles ont pour but de fournir des fonctions; les exigences nonfonctionnelles dterminent la facilit et lefficacit de lutilisation des fonctions.

57
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

5.6

Description des exigences (K2)

30 minutes

5.6.1 Description des exigences (K2)


Les exigences doivent tre clairement et prcisment spcifies. Elles doivent tre mesurables afin
de s'assurer qu'elles sont testables et que leur implmentation peut tre correctement vrifie. Il
est important de rappeler quun langage commun a certaines limites et inconvnients. Ceci peut
causer une description des exigences obscure et ambigu. Par consquent, des standards
appropris et des modles devraient tre utiliss autant que possible. Les standards fournissent
une comprhension commune et de meilleures pratiques de spcification avec des modles qui
limitent le langage qui peut tre utilis.
En plus de standards et de modles, les vocabulaires sont un outil important en vue de faciliter la
communication entre les diffrentes parties prenantes et d'introduire un peu de contrle dans
l'ambigut du langage naturel.
La description d'une exigence doit rpondre diffrents critres (par exemple, clair, prcis, non
ambigu, mesurable, sans mots inutiles, etc.).

5.6.2 Procdure pour la construction des exigences (K2)


La construction d'une exigence est ralise daprs les tapes suivantes :
1. Dtermination du processus affect
Mettre l'accent sur la fonctionnalit
Dterminer les entres et sorties
2. Classification de l'activit du systme
Identification de l'activit indpendante du systme
Identification des interactions avec l'utilisateur
Identification des exigences d'interfaces
3. Dtermination de l'engagement juridique
Clarification de l'engagement juridique avec des mots-cls (devrait, doit, etc.)
4. Raffinement de la description du processus
Description dtaille des objets et des points d'intgration
5. Contraintes logiques et temporelles
tablir les conditions aux limites

Exemple: une exigence relative la gnration dune facture avec les donnes provenant dun
systme externe.

58
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

tape de la procdure

Sortie une description dexigence

Dtermination du processus :

Le systme gnre la facture

Le processus systme de gnration dune


facture
Classification de lactivit systme
Gnration dune facture aprs la commande
utilisateur en cliquant sur un bouton

Aprs que les utilisateurs aient soumis une


requte de facture, le systme gnre une
facture en utilisant des donnes provenant du
systme externe

Linterface avec le systme externe est tablie


Dtermination de lengagement lgal
Le systme doit gnrer une facture avec
donnes correctes provenant du systme
externe
Raffinement de la description du processus
Dfinition du nom du systme financier
externe
Contraintes logiques et temporelles
Dtermination de la contrainte de temps
dure maximale de lopration : 30 secondes

Aprs que les utilisateurs aient soumis une


requte de facture, le systme doit gnrer
une facture en utilisant des donnes
provenant du systme externe
Aprs que les utilisateurs aient soumis une
requte de facture, le systme doit gnrer
une facture en utilisant des donnes
provenant dun systme de Finance SAP
Aprs que les utilisateurs aient soumis une
requte de facture, le systme doit gnrer
une facture en utilisant des donnes
provenant dun systme de Finance SAP dans
les 30 secondes

Pour les organismes de formation : description des diffrentes tapes de construction d'une
exigence

5.6.3 Document dexigence (K2)


Le contenu standard du document dexigence est [IEEE 830] :
Table des matires
1. Introduction
1.1 Objectif
1.2 Porte
1.3 Dfinitions, acronymes et abrviations

59
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

1.4 Rfrences
1.5 Aperu
2. Description gnrale
2.1 Point de vue produit
2.2 Fonctions du produit
2.3 Caractristiques utilisateur
2.4 Contraintes
2.5 Hypothses et dpendances
3. Exigences spcifiques
3.1 Interfaces externes
3.2 Fonctions
3.3 Exigences de performance
3.4 Exigences de bases de donnes logiques
3.5 Contraintes de conception
3.5.1 Conformit aux standards
3.6 Attributs du systme logiciel
3.6.1 Fiabilit
3.6.2 Disponibilit
3.6.3 Scurit
3.6.4 Maintenabilit
3.6.5 Portabilit
Annexes
Index

60
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

6 Spcification des Exigences (K2)

100 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des Exigences


Les objectifs identifient ce que vous tes capable de faire, en ayant suivi chaque module.

6.1 Spcification (K2)


OA-6.1.1

Dcrire lobjectif et le contenu dune spcification dexigences (K2)

OA-6.1.2

Dcrire les caractristiques dune spcification dexigences (K2)

OA-6.1.3

Dcrire lobjectif et le contenu dune spcification de solution (K2)

OA-6.1.4

Dcrire les caractristiques dune spcification de solution (K2)

OA-6.1.5

Rappeler les standards qui sont importants pour la spcification dexigences et la


spcification de solution (K1)

OA-6.1.6

Expliquer ce quest une user story (K2)

6.2 Procdure (K3)


OA-6.2.1

Appliquer une procdure typique pour la spcification dexigences (K3)

6.3 Formalisation (K2)


OA-6.3.1

Expliquer les diffrents degrs de formalisation qui existent pour la formalisation


dexigences (K2)

OA-6.3.2

Appliquer le niveau de formalisation spcifique pour un scenario donn (K3)

5.4 Qualit des exigences (K2)


OA-6.4.1

Rappeler les consquences des erreurs dans les exigences (K1)

OA-6.4.2

Dcrire les possibilits pour viter les erreurs dans les exigences (K2)

61
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

6.1

Spcifications (K2)

30 minutes

Termes
IEEE830, Spcification dexigences, Spcification de solution

6.1.1 Description des exigences (K2)


Une spcification est un ensemble explicite d'exigences satisfaire par un matriel, produit ou
service.
La spcification permet de suivre et de grer les exigences. Dans la spcification, les exigences
sont spcifies de manire structure et sont modlises sparment (les exigences sont
modlises indpendamment , comme les exigences de haut niveau qui sont ventiles jusqu
un niveau o chaque exigence constitue une entit indpendante qui peut ensuite tre
dveloppe et suivie). La spcification est un accord formel sur les exigences implmenter dans
un systme logiciel prvu (ou dans toute autre forme de solution).
Le terme spcification peut tre utilis dans le contexte des exigences et de la solution.

6.1.2 Spcifications des exigences (K2)


La spcification des exigences dcrit le domaine du problme (une zone d'intrt, par exemple,
une solution un problme mtier, une nouvelle fonctionnalit, etc.) et contient au moins les
informations suivantes

Exigences client
Limitations
Critres d'acceptation

La cration de la spcification des exigences client devrait tre la tche du client. Toutefois, dans
certains cas, le vendeur peut soutenir la prparation des spcifications des exigences.
La cration d'autres types de spcifications pour les exigences systme, exigences logicielles,
exigences de scurit, exigences environnementales, exigences lgales, etc. sont des tches pour
d'autres rles.

6.1.3 User stories (K2)

62
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Les user stories sont utilises dans les mthodologies de dveloppement logiciel Agile. Les
user stories sont une faon rapide de grer les exigences client / utilisateur. Le but de
lutilisation des user stories est de permettre de rpondre plus rapidement et avec moins de
cot au changement rapide des exigences du monde rel.
Les user stories dcrivent les fonctionnalits qui seront utiles. Les user stories sont
composes de trois aspects :

Une description crite de la user story pour planification et rappel


changes sur la user story qui servira toffer les dtails
Les tests qui vhiculent et documentent les dtails et seront utiliss pour dterminer
quand une user story est termine [Mike Cohn : User Stories applique. 2009]

6.1.4 Spcifications de solution (K2)


Les spcifications de solution sont aussi appeles des spcifications fonctionnelles, des
spcifications des exigences systme ou des spcifications des exigences logicielles et dcrivent le
domaine de la solution.
Une spcification fonctionnelle est un document qui dcrit clairement les exigences pour la
solution. La spcification fonctionnelle est la base pour un futur dveloppement systme, donc
elle doit fournir des informations prcises sur tous les aspects fonctionnels du logiciel
implmenter. A partir de cela, les architectes et les dveloppeurs sont en mesure de concevoir
efficacement les aspects techniques du systme. La spcification fonctionnelle fournit des conseils
pour les testeurs pour la vrification de chaque exigence fonctionnelle (par exemple, une
spcification est un lment de base du test).
La spcification fonctionnelle ne dcrit pas comment la fonction du systme sera mise en uvre et
quelle technologie utiliser. Elle se concentre sur la fonctionnalit, sur les interactions entre
lutilisateur et le logiciel.
Le but de la spcification fonctionnelle peut tre

Fournir la base pour une comprhension commune de la porte et de la fonctionnalit


de la solution mettre en uvre
Assurer un consensus d'quipe sur ce que le systme doit faire avant de commencer
l'criture du code source, les manuels, la prparation des donnes et des tests
Fournir l'quipe de dveloppement la description dtaille de la fonctionnalit
ncessaire en termes d'interactions entre les utilisateurs et le logiciel
Fournir la base pour loracle de test pour l'quipe de test

6.1.5 Standards importants (K1)

63
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Les normes suivantes peuvent tre utilises pour la rdaction de spcifications :

IEEE 1362 (Spcifications de performance du systme)


IEEE 830 (Spcification des exigences logicielles)
IEEE 1233 (Spcifications du systme fonctionnel)

64
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

6.2

Procdure (K3)

30 minutes

6.2.1 Procdure de spcification de solution (K3)


La spcification sert comme une activit de formalisation des rsultats de l'Analyse des Exigences
(K2).
L'identification, l'analyse et les activits de spcification des exigences conduisent un accord sur
les exigences (voir Accord sur les exigences (K2)).
Les exigences, une fois identifies, analyses et modlises devraient tre documentes de
manire claire et sans ambigut.

Une procdure de spcification de solution comprend les activits suivantes :


1.
2.
3.
4.
5.
6.

Identification des parties prenantes


Dfinition de la vision et de l'objectif
Dtermination des exigences
Spcification structure des exigences
Description de l'environnement systme
Dtermination de la solution (dfinition du systme et du primtre avec des
aspects pertinents extrieurs, mais influenant, le primtre, comme les
interfaces vers des systmes externes)
7. Analyse des exigences
8. Modlisation du problme
9. Modlisation de la solution

La procdure formalise les rsultats du processus d'Analyse des Exigences. Le modle de solution
est une base pour la conception et limplmentation.
La procdure implique un certain nombre de parties prenantes qui supportent les travaux de
spcification dans diffrents domaines. La sortie de la procdure, la Spcification de Solution, sert
de point de dpart pour le logiciel, le matriel et la conception de base de donnes. Elle dcrit la
fonction (spcifications fonctionnelles et non fonctionnelles) du systme, la performance du
systme et les contraintes oprationnelles et d'interface utilisateur.

65
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

6.3

Formalisation (K2)

20 minutes

Termes
Niveau formel, niveau non-formel, niveau semi-formel

6.3.1 Degr de formalisation (K2)


Les exigences de spcification peuvent tre dfinies avec diffrents degrs de formalisation :

Non-formel
Semi-formel
Formel

6.3.1.1 Niveau non-formel


Lapproche non-formelle pour la rdaction de spcification signifie que le document est crit en
langage naturel, sans aucune notation formelle. Cette approche peut tre utilise lorsque les
lecteurs n'ont pas d'exprience avec des langages de spcification plus formels et techniques et
auraient des difficults pour comprendre le contenu du document. La faiblesse principale de cette
approche est qu'elle est ambigu et peut conduire des problmes de comprhension et
dinterprtation. En outre, la spcification non formelle n'est pas une bonne base ni pour
limplmentation ni pour le test parce quelle nest pas suffisamment claire ni prcise.

6.3.1.2 Niveau semi-formel


Une spcification semi-formelle comprendra quelques notations formelles et sera bien structure.
Habituellement, de telles spcifications sont bases sur un modle spcifique (souvent issus de
standards appropris). Des spcifications semi-formelles peuvent exprimer des exigences dans une
forme de modles et utiliser un langage commun formalis.
UML et SysML sont parmi les notations semi-formelles les plus utilises pour rdiger une
documentation semi-formelle.

66
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

6.3.1.3 Niveau formel


Une spcification formelle est une description mathmatique du logiciel qui peut tre utilise pour
raliser une implmentation. La spcification formelle dcrit ce que le systme doit faire, ne dcrit
gnralement pas comment le systme devrait le faire. Comme elle est base sur des formules
mathmatiques et quelle est plus difficile apprendre, la spcification formelle est utilise assez
rarement et ncessite des connaissances mathmatiques.

67
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

6.4

Qualit des exigences (K2)

20 minutes

Termes
Checkliste, caractristique qualit, revue, validation, vrification, traabilit

6.4.1 Contexte (K2)


Dfauts dans les exigences comme une cause de cots levs (K2).
Comme les exigences sont la base du dveloppement systme, toute erreur ou exigence
manquante va se propager tous les autres processus de dveloppement dans le projet. Il est
important de noter, que les dfauts rsultant d'exigences de faible qualit sont plus chers
corriger dans les phases ultrieures du projet que les autres types de dfauts. En outre, plus les
dfauts sont dtects tard, plus ils cotent chers.
Par consquent, l'utilisation de la vrification (avons-nous ralis le produit correctement) et de la
validation (avons-nous ralis le bon produit) des exigences est ncessaire.
Les exigences doivent tre documentes et testes au regard des critres de qualit (voir chapitre
1.1 Exigence (K2)).

6.4.2 Mesures damlioration de la qualit et assurance qualit des exigences


(K2)
Les outils et techniques suivants peuvent tre utiliss pour amliorer la qualit et assurance
qualit des exigences :

Standards et modles
Revues et inspections
Traabilit
Prototypage
Respect des critres de qualit (les critres de qualit peuvent tre : compltude,
exactitude, conformit de la spcification des exigences des standards appropris)

La qualit dune spcification dexigences peut tre amliore en incluant les lments suivants :

Description du but du document, de la porte, des dfinitions et du glossaire


Description des objectifs diffrents niveaux (i.e. une spcification des exigences de
haut niveau a des objectifs diffrents de ceux dune spcification dexigences
fonctionnelles dtaille)

68
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Dfinition des contraintes de conception et dimplmentation


Calibration / priorisation des exigences
Dclarations claires de ce que le systme devrait faire plutt que comment il doit le
faire
Documentation des aspects lgislatifs, des hypothses, des rgles mtier et des
dpendances
viter des descriptions complmentaires de schmas qui sont dj clairs et suffisent
eux-mmes (remplacer, si possible, des textes difficiles, abstraits par des schmas)
Catalogue utilisateur et schma de permissions clairement spcifis (droits utilisateurs
et privilges)
Utilisation de prsentation structure
Utilisation dun langage simple, clair, prcis et sans ambigut

69
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7 Analyse des Exigences (K2)

140 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des Exigences


Les objectifs identifient ce que vous tes capable de faire, en ayant suivi chaque module.

7.1 Exigences et solutions (K1)


OA-7.1.1

Rappeler lobjectif pour lanalyse des exigences (K1)

OA-7.1.2

Dcrire la procdure suivre pendant lanalyse des exigences (K2)

OA-7.1.3

Expliquer le concept de rupture structurelle entre les exigences et les solutions (K2)

7.2 Mthodes et Techniques (K2)


OA-7.2.1

Rappeler les diffrents modles danalyse des exigences (K1)

OA-7.2.1

Appliquer les diffrentes mthodes danalyse pour des types spcifiques de modles
(K3)

7.3 Analyse oriente-objet (K2)


OA-7.3.1

Dcrire les caractristiques dUML (K2)

OA-7.3.2

Dcrire les caractristiques de SysML (K2)

7.4 Estimations de cot (K2)


OA-7.4.1

Rappeler la raison de lestimation de cot (K1)

OA-7.4.2

Reconnatre les facteurs importants pour lestimation de cot (K2)

7.5 Priorisation (K2)


OA-7.5.1

Appliquer la procdure de priorisation pour un scnario donn (K3)

7.6 Accord sur les exigences (K2)


OA-7.6.1

Identifier ce qui doit tre considr lors de laccord sur les exigences (K2)

70
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.1

Exigences et solutions (K1)

20 minutes

7.1.1 Objectif de lanalyse des exigences (K2)


Le but de l'analyse des exigences est de crer une solution pour limplmentation des exigences.
Lanalyse des exigences prend en compte diffrentes parties prenantes de la solution, les conflits
potentiels entre exigences, les analyses des relations et des dpendances entre les exigences, etc.

7.1.2 Procdure danalyse des exigences (K2)


La procdure d'analyse des exigences comporte les tapes suivantes

Analyse des besoins


Description de la solution
Estimation des cots et priorisation

7.1.3 Rupture structurelle entre les exigences et les solutions (K2)


La rupture structurelle entre les exigences et les solutions signifie qu'il y a une diffrence entre les
exigences et les solutions. Une solution est limplmentation d'une exigence. Le modle
dexigences peut tre vu comme un modle mtier, prsentant le problme rsoudre par le
modle de solution. Un modle de solution est plus dtaill et inclut la spcification technique des
exigences ; c'est une base pour le dveloppement et le test.
Il existe trois niveaux de base des modles

Modle des exigences


o Souvent spcification non-formelle
o Notations de modlisation mtier (BPMN - Business Process Modeling
Notation)
Modle de solution
o Structures fonctionnelles (algorithmes, procdures, workflows)
Modle conceptuel
o Spcifications techniques logiciel / matriel

Il devrait y avoir une traabilit entre les modles.

71
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.2

Mthodes et Techniques (K2)

20 minutes

Termes
Modle de contexte, modle de flot de donnes, modle relation-entit, dcomposition
fonctionnelle, modles conceptuels, modles dexigence, modles de solution, modle de
transition dtats

7.2.1 Mthodes et modles danalyse (K2)


Les diffrents aspects d'un systme sont reprsents par des points de vue diffrents.
Les modles sont dvelopps grce des mthodes d'analyse appropries.

Mthode danalyse

Modle danalyse

Analyse du contexte

Modle de contexte

Analyse de larchitecture

Dcomposition fonctionnelle

Analyse du flot de donnes

Modle de flot de donnes

Analyse des conditions

Modle de conditions
Rseau de Ptri

Analyse des dcisions

Table de decisions

Analyse des donnes

Modle smantique de donnes


Modle relations-entits
Dictionnaire de donnes

7.2.2 Types de modles (K2)


Il y a trois types de modles de base :

Modle dexigences
o Dcrit le domaine du problme
o Conu ds les premires tapes du projet
o Sert pour l'analyse des exigences et l'estimation des cots
o Fournit une base pour le modle de solution

72
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Exemple : modle de cas dutilisation mtier, modle de classes mtier,


modle de processus mtier
Modle de solution
o Dcrit le domaine de solution partir de vues diffrentes du systme
o Conu en mme temps que le modle dexigences
o Dtermine la forme de limplmentation des exigences fonctionnelles et non
fonctionnelles
o Fournit une base pour la conception systme
o Exemple : modle de cas d'utilisation, diagramme de squences, diagramme
d'activits, diagramme de transitions d'tats
Modle conceptuel
o Spcifications techniques logiciel / matriel (modules, composants matriels,
caractristiques des PCs)

7.2.3 Diffrentes perspectives du systme (K2)


Certains des points de vue en relation avec le systme sont les suivants

Vue logique
o Exigences fonctionnelles
Vue processus
o Communication
o Interaction
o Exigences non fonctionnelles
Vue implmentation
o Composants (modules)
Vue de l'installation
o Intgration
o Architecture systme

7.2.4 Diffrents modles (K1)


Les modles suivants peuvent tre utiliss

Modle de contexte
o Description statique du systme
o Exprime larchitecture de base
Dcomposition fonctionnelle
o Description statique du systme
o Exprime les dcompositions successives du systme

73
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Modle de flot de donnes


o Description dynamique du systme
o Reprsentation graphique des flots de donnes au sein dun systme
o Ne fournit pas dinformation sur les temps processus et si les processus
fonctionnent en squentiel ou en parallle
Modle de transitions d'tats
o Description dynamique du systme
o Reprsente le comportement du systme en une srie d'vnements, qui
pourraient faire passer le systme dans un ou plusieurs tats possibles
Modle Entits Relations
o Reprsentation conceptuelle et abstraite des donnes
o Contient des blocs de construction : entits, relations et attributs

Quand un modle spcifique devrait-il tre appliqu ? Diffrents modles rpondent dautres
types de questions concernant la solution :

Modle Contexte QUOI (reprsentation des principaux flux entre le systme et


l'extrieur)
Dcomposition fonctionnelle QUOI (quelles sont les fonctions et les
caractristiques dans le primtre du systme ?)
Modle de flot de donnes QUOI (flux entre processus mtier / fonctions /
activits)
Modle Entits Relations QUOI (quelles relations existent entre les entits
spcifiques (objets) du systme ?)
Modle tats transitions POURQUOI (cause et effet)

74
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.3

Analyse oriente-objet (K2)

30 minutes

Termes
Diagramme dactivit, diagramme de comportement, diagramme de classe, diagramme de
communication, diagramme de composants, diagramme de structure composite, diagramme de
dploiement, diagramme dinteraction, diagramme objet, analyse oriente-objet, diagramme de
package, diagramme dexigences, diagramme de squence, diagramme de machine tats,
diagramme structurel, SysML, UML, diagramme des cas dutilisation

7.3.1 UML (K1)


Unified Modeling Language est une notation unifie pour l'analyse et la conception de systmes.
Elle contient diffrents types de diagrammes pour les points de vue diffrents sur le systme
(diagrammes de structure ou de comportement).

7.3.1.1 Diagramme de comportement (K2)


Les diagrammes de comportement montrent les caractristiques comportementales dun systme
ou d'un processus mtier.
Ces diagrammes comprennent les types de diagrammes suivants

Diagrammes d'activit
o Modle des comportements d'un systme, et la manire par laquelle ces
comportements sont lis dans un flux global du systme
Diagrammes de cas dutilisation
o Capture des cas dutilisation et des relations entre les acteurs et le systme
o Description des exigences fonctionnelles du systme, de la manire dont les
oprateurs externes interagissent la limite du systme, et les rponses du
systme
Diagrammes de machines d'tat
o Montrer comment un lment peut bouger entre les tats, en classant son
comportement en fonction des dclenchements de transitions et contraintes
de gardes
Diagrammes de temps (chronogramme)
o Dfinir le comportement des diffrents objets au sein d'une chelle de temps
o Fournir une reprsentation visuelle des objets changeant d'tats et
interagissant dans le temps

75
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Diagrammes de squences
o Reprsentation structure du comportement comme une srie d'tapes
squentielles dans le temps
o Utiliss pour dcrire le flux de travail, le passage de messages et comment les
lments, en gnral, cooprent dans le temps pour atteindre un rsultat
Diagrammes de communication
o Montrer les interactions entre les lments lors de l'excution, la visualisation
des relations inter-objets
Diagrammes des contextes d'interaction
o Visualisation de la coopration entre dautres diagrammes d'interactions pour
illustrer un flux de contrle servant un but atteindre

7.3.1.2 Diagramme structurel (K2)


Les diagrammes structurels reprsentent les lments structurels qui composent un systme ou
une fonction. Ces diagrammes refltent des relations statiques de la structure, tels que les
diagrammes de classes ou de paquetages, ou des architectures lexcution telles que des
diagrammes de structures dobjets ou composites.
Les diagrammes structurels incluent les types de diagrammes suivants

Diagrammes de classes
o Capture de la structure logique du systme, les classes et les objets crant le
modle, dcrivant ce qui existe et les attributs et comportements associs
Diagrammes de structure composite
o Rflchir la collaboration interne des classes, des interfaces et des
composants (et leurs proprits) pour dcrire une fonctionnalit
Diagrammes de composants
o Prsenter les morceaux de logiciel en crant un systme ainsi que leur
organisation et leurs dpendances
Diagrammes de dploiement
o Dcrire l'architecture d'excution du systme
Diagrammes d'objets
o Prsenter les instances dobjets de classes et leurs relations un instant donn
Diagrammes de paquetages
o Reprsenter l'organisation des lments du modle dans des paquetages et
leurs dpendances

7.3.2 SysML (K2)

76
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Modeling Language System est un langage de modlisation spcial pour lIngnierie Systme. C'est
une extension d'UML 2.1.

SysML offre quelques amliorations par rapport UML. Ces amliorations sont les suivantes :

Smantiques plus souple et expressive


o Rduit les restrictions UML centres sur le logiciel et ajoute deux nouveaux
types de diagrammes, diagramme des exigences et des paramtres
o Permet la modlisation d'une large gamme de systmes, qui comprennent du
matriel, du logiciel, de l'information, des processus, du personnel et des
installations.
Facile apprendre et appliquer
o Plus petit quUML (n'utilise pas beaucoup de constructions UML centres sur
le logiciel)
Support des modles et des vues
o Les modles et les vues sont architecturalement aligns sur le standard IEEEStd-1471-2000
Rutilisation des sept diagrammes UML et fourniture de deux nouveaux diagrammes
(diagrammes dexigences et de paramtres) pour un total de neuf types de
diagrammes
o Diagrammes dexigences pour capturer les exigences fonctionnelles, de
performance et d'interface
o Diagrammes de paramtres pour dfinir des contraintes de performance et
quantitatives

77
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.4

Estimations de cot (K2)

20 minutes

Contexte
Les estimations de cot permettent de relier lIngnierie des Exigences la Gestion de Projet.

7.4.1 Types destimation (K2)


Les aspects les plus sujets estimation sont

Les cots
Le temps
Les exigences

Les estimations de cots permettent de reconnatre les cots de dveloppement, de changement,


etc.

7.4.2 Influence sur les cots de dveloppement (K2)


Le cot du projet dpend de divers facteurs

Type de projet
Maturit des processus
Mthodes et outils de conception et de test
Technologie
Complexit de la solution envisage
Objectifs qualit (par exemple niveau souhait de qualit du logiciel)
Qualifications de l'quipe
Distribution de l'quipe
Expriences

L'exactitude des estimations de cots dpend de l'tat d'avancement du projet et de sa maturit.

7.4.3 Les approches destimations de cot

78
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

L'estimation des cots peut tre ralise en utilisant

Dduction analogique
Procdure algorithmique

7.4.3.1 Dduction par analogie (K2)


L'estimation des cots est base sur la comparaison des cots de projets similaires. Elle est base
sur l'exprience, et non sur des formules mathmatiques. Avec cette technique, le projet actuel
est compar des projets antrieurs. La comparaison peut comprendre

Le nombre d'exigences
Le primtre de la solution
La technologie utilise
Les caractristiques du personnel (comptences, exprience)

Sur la base des rsultats de cette comparaison, une estimation peut tre cre.
Les procdures d'estimation sont toujours bases sur des donnes historiques et des conditions
connues.

Mthode Delphi
C'est une technique de communication structure utilise pour effectuer des prvisions
interactives. Cela implique un panel d'experts [Linstone75].
Les experts sont invits rpondre des questionnaires en un certain nombre de tours. Aprs
chaque tour, il y a un rsum anonyme des prvisions des experts ainsi que les raisons des
jugements fournis. Puis les experts rvisent leurs rponses prcdentes en prenant en
considration les rponses des autres membres de leur panel.
On croit que pendant ce processus, le panel des rponses va diminuer et que le groupe va
converger vers la bonne rponse.
Le processus sarrte sur un critre d'arrt prdfini. Les scores moyens de la phase finale
dterminent les rsultats.

Estimations agiles
Dans les projets Agiles souvent grs en Scrum, il ya une mthode d'estimation appele Planning
game ou Planning poker . Cette mthode est utilise pour obtenir un consensus dans
l'quipe. La capacit de l'quipe est alors mesure travers quelque chose qui s'appelle le taux de
Burn Down et amliore via les sessions de rtrospective menes aprs chaque sprint, o les
chiffres prvus sont compars aux chiffres actuels. Cela permet d'amliorer la capacit de l'quipe
estimer.

79
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.4.3.2 Procdure algorithmique (K2)


Dans cette approche, les cots sont calculs sur la base de paramtres. Les paramtres peuvent
dcrire le produit (volume, dure), les conditions aux limites (efficacit), etc.
Les mthodes suivantes peuvent tre utilises :

Formule de Putnam (quation)


Points de fonction
Modle des cots constructifs (COCOMO)

quation de Putnam [Putnam91]


Effort = [Taille / Productivit * Temps 4/3] 3 * B

O :

Taille - la taille du produit (estime par nimporte quelle estimation de taille utilise
par une organisation). Putnam utilise ESLOC (Effective Source Lines Of Code)
B - facteur d'chelle, fonction de la taille du projet
Productivit - la productivit des processus, la capacit d'une organisation logiciel
particulire de produire des logiciels d'une taille donne, un taux de dfaut
particulier
Temps - le calendrier global du projet en annes
Effort - effort total appliqu au projet en hommes.annes

Points de fonction
Un point de fonction est une unit de mesure pour exprimer la quantit de fonctionnalits mtier
fournies par un systme d'information un utilisateur. Le cot d'un point de fonction unique est
calcul sur la base de projets antrieurs.
Il y a cinq fonctions standards prendre en compte comme points de fonction.
Fonctions de donnes
1. Fichiers de logique interne
o Tables dans une base de donnes relationnelle
o Informations de contrle de l'application
2. Fichiers d'interface externe
o Tables dans une base de donnes relationnelle, les informations de contrle
de l'application ne sont pas maintenues par l'application en cours d'examen

80
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Fonctions transactionnelles
1. Entres externes
o Donnes d'entre par utilisateur
o Alimentations de donnes ou de fichiers par des applications externes
2. Sorties externes
o Rapports crs par l'application, y compris des donnes drives
3. Enqutes externes
o Les rapports comptabiliss crs par l'application, o un rapport ne comporte
pas de donnes drives

Les fonctions identifies sont pondres en fonction de trois niveaux de complexit : le nombre de
points attribus chaque niveau diffre selon le type de point de fonction.

Un exemple est montr ci-dessous :

Complexit

Points

Mineure

Moyenne

10

leve

15

Cocomo
Cocomo permet de calculer leffort et le cot de dveloppement logiciel en fonction de la taille du
programme. La taille du logiciel est exprime en EKLOC (estim en milliers de lignes de code).
Cocomo s'applique trois catgories de projets logiciels

Les projets organiques


Les projets semi-dtachs
Les projets embarqus

Les quations de base COCOMO sont :

Effort appliqu (E) = ab (KLOC) bb [hommes.mois]


Temps de dveloppement (D) = cb (effort appliqu) db [mois]
Personnel requis (P) = Effort appliqu / Temps de dveloppement [nombre]

KLOC nombre estim de lignes livres (en milliers) de code pour le projet

ab, bb, cb et db :

81
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Projet logiciel

ab

bb

cb

db

Organique

2.4

1.05

2.5

0.38

Semi-dtach

3.0

1.12

2.5

0.35

Embarqu

3.6

1.20

2.5

0.32

82
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.5

Priorisation (K2)

20 minutes

Termes
Graduation, Graduation 3 niveaux

7.5.1 Priorisation (K2)


La priorisation permet d'tablir l'importance relative des exigences et limplmentation pour
rpondre dabord aux exigences les plus cruciales.
La priorisation supporte le dveloppement incrmental, car elle permet de regrouper des
exigences et dtablir des priorits dimplmentation.

7.5.2 Procdure de priorisation (K2)


La procdure pour dfinir les priorits des exigences comprend les activits suivantes :

1. Regroupement des exigences


Identifier les exigences qui sinfluencent mutuellement et celles qui dpendent les
unes des autres (par exemple : des exigences dcrivant une fonctionnalit complexe)
2. Analyse des exigences
Analyse de toutes les parties prenantes impliques afin de convenir du niveau
d'importance
Analyse d'impact comme un moyen de supporter l'analyse des exigences
tablir les priorits des exigences
3. Cration du plan projet des exigences
tablir un plan dans lequel les exigences avec des priorits leves sont dveloppes
en premier
Attribution des responsabilits (qui met en uvre l'exigence ?)
4. Planification des tests des incrments systme
Concevoir des cas de test pour tester chaque incrment systme (tabli sur la base des
exigences prioritaires) sur la base des priorits des exigences

83
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.5.3 chelle de priorisation (K2)


Une approche commune des priorisations consiste regrouper les exigences dans des catgories
prioritaires. Habituellement, une chelle trois niveaux est utilise (par exemple : lev, moyen et
faible).
Comme ces niveaux sont subjectifs et imprcis, toutes les parties prenantes concernes doivent
s'entendre sur la signification de chaque niveau de l'chelle quils utilisent. La dfinition de la
priorit doit tre clairement prcise et devrait tre un des attributs cl de chaque exigence.

Exemples dchelles trois niveaux :


Nom

Description

Haut

Exigence critique, exige dans la premire livraison du logiciel

Moyen

Supporte ncessairement les oprations systme mais peut attendre une


livraison future si ncessaire

Bas

Une amlioration fonctionnelle ou qualit, du type a serait bien de lavoir

Nom

Description

Essentiel

Le produit nest pas acceptable tant que lexigence nest pas remplie

Conditionnel

Permet damliorer le produit, mais le produit n'est pas inacceptable si


absent

Optionnel

Les fonctions qui peuvent ou non tre utiles

84
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.6

Accord sur les exigences (K2)

20 minutes

Termes
Signature

7.6.1 Accord (K2)


S'entendre sur les exigences, souvent appel engagement sur les exigences est un accord
formel prcisant que le contenu et le primtre des exigences sont prcis et complets.
Lentente officielle est une base pour le projet. Un accord sur les exigences de haut niveau
(exigences mtier) doit tre fait avant le dmarrage du projet. Les exigences dtailles (exigences
fonctionnelles et non fonctionnelles) devraient tre acceptes et signes avant de passer la
phase dimplmentation.

Lobtention de lengagement sur les exigences est habituellement la tche finale de l'analyse des
exigences et de la conception.
Lengagement sur les exigences devrait tre fait par les parties prenantes du projet, comprenant :

Chefs de projets la fois ct client et fournisseur


Reprsentant de l'activit du client
Analystes mtier et systme
Ingnieurs des exigences
Reprsentants de l'Assurance Qualit, quipes de dveloppement et de test.

La liste des exigences doit tre contraignante la fois pour le ct client et le ct vendeur.
Un des objectifs de lengagement sur les exigences est d'assurer que les exigences soient stables et
que les modifications soient gres via les demandes de changement formelles. Par consquent,
un accord formel rduit le risque d'introduction de nouvelles exigences pendant ou aprs
limplmentation.
S'entendre sur les exigences est considr comme acquis, lorsque les parties prenantes
pertinentes de tous les projets ont sign le document des exigences.
La finalisation de lengagement sur les exigences devrait tre communique l'quipe du projet et
cest gnralement une tape du projet.

85
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

7.6.2 Avantages de laccord sur les exigences (K2)

Laccord assure le dveloppement du bon produit (travaux bass sur la liste convenue
dexigences et couvre uniquement ce qui est ncessaire pour obtenir une valeur
ajoute pour les parties prenantes)
Rduction des risques de malentendus entre le client et le vendeur concernant le
primtre du projet
Base pour les futurs travaux de conception

86
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

8 Suivi des Exigences (K2)

60 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des Exigences


Les objectifs identifient ce que vous tes capable de faire, en ayant suivi chaque module.

8.1 Suivi au sein du projet (K2)


OA-8.1.1

Rappeler les moyens de traabilit (K1)

OA-8.1.2

Rappeler les raisons typiques pour des changements dexigences (K1)

OA-8.1.3

Dcrire les objectifs de traabilit (K2)

OA-8.1.4

Reconnatre les diffrentes sortes de traabilit (K1)

8.2 Gestion du changement (K2)


OA-8.2.1

Dcrire les caractristiques de gestion du changement (K2)

OA-8.2.1

Rappeler la constitution du comit de contrle du changement (K1)

87
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

8.1

Suivi au sein du projet (K2)

20 minutes

Termes
Suivi horizontal et vertical

8.1.1 volution des exigences (K1)


Les exigences ne sont pas stables, mais continuent dtre dveloppes au cours du cycle de vie du
projet.
Les raisons dun dveloppement continu et de changements proposs peuvent tre les suivantes

Nouvelles ides
Nouveaux besoins clients (rsultant, par exemple, dune nouvelle rglementation, de
nouvelles orientations business, de nouveaux produits, etc.)
Poursuite des travaux (par exemple, prochaine phase du projet, amlioration et
optimisation des fonctionnalits dj implmentes, etc.)
Nouvelles connexions au sein du projet (par exemple, intgration avec de nouveaux
systmes, nouveaux canaux de communication comme internet ou de nouveaux
canaux mobiles, etc.)

8.1.2 Traabilit (K2)


La traabilit fournit une solution de gestion du dveloppement des exigences et des autres
artefacts lis ces exigences.
La traabilit permet de vrifier que toutes les tapes importantes du processus de
dveloppement ont t ralises. Cela devrait tre implment de faon bidirectionnelle pour
tous les artefacts (par exemple : des exigences vers les artefacts de conception et des artefacts de
conception vers les exigences). La traabilit est galement importante pour les tests, la
vrification et la validation.

Objectifs de la traabilit :

Analyse d'impact
Analyse de couverture
Preuve dimplmentation

88
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Utilisation de l'exigence (exigences traces comme une preuve que les exigences sont
utilises et comment elles sont utilises)

Afin d'assurer une bonne traabilit, il est important d'identifier les exigences de faon unique.

8.1.3 Traabilit (K2)

Traabilit horizontale
Prsente les dpendances entre les exigences dun mme niveau (relations entre les
diffrents types d'exigences)
Traabilit verticale
Prsente les dpendances entre les diffrents artefacts (les exigences, la solution, la
spcification de performance, les cas de test, le code, les modules, les plans, etc.)

89
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

8.2

Gestion du changement (K2)

20 minutes

Termes
Changement, commission de gestion du changement, gestion du changement, demande de
changement

8.2.1 Changements des exigences (K1)


Les changements des exigences peuvent tre demands nimporte quel moment pendant la
ralisation du projet et aprs la sortie du logiciel final dans son environnement de production. Des
changements arriveront toujours et il est important de planifier les changements par rapport au
processus et au temps.

Les sources de changement peuvent tre les suivantes :

Extension des fonctionnalits existantes


Dfauts trouvs dans le logiciel / la documentation
Autres choses trouves, par exemple dans les tests telle que une mauvaise
performance, etc.
Demande dune nouvelle fonctionnalit ou dune modification dune fonctionnalit
existante
Changements rsultant de facteurs externes (changements organisationnels,
modifications rglementaires)

8.2.2 Gestion du changement (K2)


Le processus de gestion du changement est le processus de demande, dtude de faisabilit, de
planification, dimplmentation et d'valuation des changements dans un systme logiciel, des
documents ou autres produits du projet. L'objectif de la gestion du changement est de permettre
et de supporter le traitement des changements et dassurer la traabilit des changements.

Le processus de gestion des changements comprend les activits suivantes

Identification des changements potentiels


Demande dune nouvelle fonctionnalit
Analyse de la demande de changement

90
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

valuation du changement
Planification du changement
Implmentation du changement
Revue et clture du changement
Dploiement du changement

Selon sa complexit et son impact, un changement peut avoir des impacts diffrents sur le
systme. De petits changements peuvent ncessiter des modifications mineures, tandis que des
changements complexes peuvent changer radicalement la logique du systme. Tout changement
doit tre soigneusement analys afin d'tablir les risques relatifs et d'valuer la valeur de la
modification par rapport aux risques prvus.

8.2.3 Demande de changement (K2)


Un changement doit tre soumis via un document de demande de changement formelle (appel
aussi Request For Change (RFC)). Habituellement un tel document dcrit la raison du changement,
la priorit et la solution demande ainsi que des dtails supplmentaires comme :

Le nom de la personne / du dpartement ou d'une autre entit demandant le


changement
La date de soumission
La date prvue dimplmentation de la modification (si applicable)
Le cot du changement

8.2.4 Commission de Gestion des Changement (K2)


Les changements sont contrls et dcids par une Commission de Contrle des Changements
(CCB Change Control Board). Lintroduction dun CCB supporte d'une faon contrle
limplmentation dun changement ou dune modification propose, pour un produit ou service.
La Commission de Contrle des Changements est un comit qui repose sur des informations
fournies (comme le risque li un changement, son impact, leffort requis pour limplmenter) qui
prend des dcisions quant la ralisation ou non des modifications proposes. Le CCB est
constitu de parties prenantes du projet ou de leurs reprsentants.
La Commission de Contrle des Changements peut comprendre les rles suivants :

Gestion de projet
Gestion du Dveloppement
Assurance qualit (gestion de la qualit, gestion des tests)

91
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Gestion business, le cas chant


Client, le cas chant

8.2.5 Cycle de vie dune exigence (K2)


Selon le niveau d'analyse et / ou dimplmentation des exigences, diffrents tats sont assigns
une exigence. Le cycle de vie d'une exigence peut tre exprim en utilisant les tats suivants :

Nouveau (propos)
Pour revue
Approuv
Conflictuel
Implment
Mis jour
Supprim
Test
Dploy

Diffrentes approches et organisations peuvent utiliser diffrents cycles de vie des exigences (et
des tats diffrents). Dans de nombreux cas de cycles de vie des exigences, les demandes de
changement et les dfauts sont trs similaires et grs l'aide du mme outil.

8.2.6 Distinction entre Gestion des Dfauts et Gestion du changement (K2)


Il est important de faire la diffrence entre un changement et un dfaut. Un dfaut est dfini
comme une faille dans un composant ou un systme qui peut empcher un composant ou un
systme de remplir une fonction requise. Il s'agit d'une dviation par rapport un tat requis du
systme. Un changement est la modification de fonctionnalits existantes, dexigences ou de
fonctions, ou la cration de nouvelles.

8.2.7 Impact dun changement sur le projet (K2)


Les changements dans les exigences peuvent avoir des impacts diffrents sur le projet. Les
changements les plus communs sont :

Changement de calendrier, de budget, de ressources


Travaux rsultant de changements (en fonction de la phase du projet)

92
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

o
o
o
o
o
o
o

Mise jour de l'analyse et de la conception des artefacts (par exemple : les


spcifications)
Mise jour de la documentation technique et utilisateur
Changements dans la stratgie de test et les tests
Mise jour du plan de test
Mise jour des besoins en formation / plan
Extension / raccourcissement du primtre des travaux de programmation
Changement du primtre dexcution et de la prparation des tests

93
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

9 Assurance Qualit (K2)

30 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des Exigences


Les objectifs identifient ce que vous tes en mesure de faire, en ayant suivi chaque module.

9.1 Facteurs dinfluence (K1)


OA-9.1.1

Rappeler les facteurs qui influencent lIngnierie des Exigences (K1)

9.2 Vrification des exigences ltape dlucidation des exigences (K2)


9.3 Assurance qualit via la testabilit (K2)
OA-9.3.1

Expliquer comment les produits de lIngnierie des Exigences supportent les tests (K2)

OA-9.3.2

Dcrire lutilit du critre dacceptation (K2)

OA-9.3.3

Dcrire dans quelle mesure lIngnierie des Exigences peut contribuer aux tests (K2)

9.4 Mtriques (K2)


OA-9.4.1

Rappeler la dfinition de mtriques (K1)

OA-9.4.2

Dcrire quelles mtriques peuvent tre utilises pour lIngnierie des Exigences (K2)

94
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

9.1

Les facteurs dinfluence (K1)

10 minutes

9.1.1 Influences sur lIngnierie des Exigences (K1)


La qualit des produits issus de lIngnierie des Exigences dpend des facteurs suivants :

Le produit en cours de dveloppement


Lenvironnement dans lequel il est produit
Le domaine (complexit du domaine mtier, le niveau dinnovation, la frquence des
modifications dans le mtier, etc.)
Les facteurs lgaux, environnementaux et scuritaires
La pression par rapport au temps et au cot (les contraintes temps et cot peuvent
diminuer les possibilits dexcuter les processus de lIngnierie des Exigences)
Les facteurs culturels (langue, ducation, etc.)
Les contraintes technologiques et de conception

De tels facteurs doivent tre pris en considration lors de la planification des activits dassurance
qualit.

95
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

9.2

Vrification des exigences ltape dlucidation


des exigences (K2)

20 minutes

La vrification doit tre faite de faon continue durant le dveloppement de la solution. Afin de
vrifier les exigences aux tapes dlucidation, les techniques suivantes peuvent tre utilises :

Revues techniques
Simulations
Prsentations
Dmonstrations

Il est important de planifier la vrification ds le dbut dun projet.

96
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

9.3

Lassurance qualit via la testabilit (K2)

20 minutes

Termes
Critre dacceptation, testabilit

9.3.1 LIngnierie des Exigences et le test (K2)


Lingnierie des Exigences est fortement lie au test. Des cas de test satisfaisants ncessitent des
exigences parfaitement dfinies, et qui peuvent tre testes. Limplication des testeurs dans les
spcifications est donc primordiale.

9.3.2 Le critre dacceptation (K2)


Selon la nomenclature Prince2, le critre dacceptation, galement appel critre de succs,
reprsente la norme requise pour satisfaire les attentes qualit du client et obtenir son adhsion
au produit fini. En dautres termes, ce sont des critres mis sur des fonctions ou composants
spcifiques, ou tout autre lment du produit logiciel ou du projet qui doivent tre remplis afin de
satisfaire le client et gagner son adhsion.
Le critre dacceptation doit tre convenu entre les deux parties (le vendeur et le client) avant le
dbut du projet (cela devrait constituer une clause contractuelle) et servir de base au Plan de
Qualit du Projet. Chaque exigence dfinie doit aboutir au moins un critre dacceptation. Ces
critres forment la base du test dacceptation.
Chacun dentre eux doit tre quantifiable, et sa mthode de mesure doit tre raliste et convenue.
Exemple de critre dacceptation : lapplication doit rpondre en moins dune seconde, et dlivrer
un message dattente dans le cas contraire.

9.3.3 Mthodes de test (K2)


Les produits de lIngnierie des Exigences supportent le test en fournissant ce qui est appel les
bases de tests . Les exigences et leurs spcifications peuvent servir de bases de tests.
Les produits de lIngnierie des Exigences soutiennent les tests :

En acceptant la couverture fonctionnelle (couverture de toutes les exigences


fonctionnelles par les cas de test, et ces cas de test sont crits pour couvrir la totalit des
exigences fonctionnelles)
Couverture fonctionnelle = tests des exigences via des cas de test / les exigences

En fournissant une base de test fiable pour la boite-noire ou les tests bass sur les
spcifications, tels que :

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Valeurs limites pour les catgories de donnes dentre


tats dapplication
Contraintes logiques et conomiques
Etc.

En acceptant les techniques de test telles que : partition dquivalence, analyse des
valeurs limites, table de dcision, test de transition dtat, test de cas dutilisation.
Par exemple, la partition dquivalence est une technique de test qui divise les donnes
dentre utilises dans un module spcifique du logiciel en partitions de donnes, partir
desquelles il est possible dexcuter des cas de test. Ces derniers sont dvelopps pour
couvrir au moins une fois chaque partition.

Exemple de partition dquivalence :


1

La plage valide concernant lge de lutilisateur est de 1 99. Cette amplitude est appele
partition valide. Il y a donc deux autres partitions de plage invalide : la premire sera 0 et la
seconde sera 100.
La plage valide de rponses un questionnaire comprend les caractres suivants : A, B, C et D.
La partition invalide contiendra tout autre caractre de texte, y compris les caractres
spciaux.

Les cas de test doivent prendre en compte la fois les plages valides et invalides.
Dautres techniques de test peuvent galement tre utilises, comme lanalyse des valeurs limites,
les tests de transition dtat, les tests de cas dutilisation, etc. Elles doivent tre employes aprs
une analyse de tests des exigences et appliques selon le contenu des exigences.

9.3.4 Exigences et processus de test (K2)


Les exigences sont les informations dentre de base au processus de dveloppement et de test du
systme. Clairement dfinies, elles rduisent le risque dchec du projet (ou mme du produit) en
permettant des tests rigoureux. La stabilit de ces exigences entraine des dlais sur des tches
spcifiques.
Il est important de rappeler que les exigences doivent tre valides par des tests statiques (ce qui
inclus les testeurs) et acceptes par les responsables de test (en effet, dans certains cas les
exigences ne seront pas considres comme testables). Les testeurs jouent un rle prpondrant
dans lamlioration de la qualit des exigences en remontant les points faibles et les possibles
imperfections. Ils participent galement aux revues des exigences afin de garantir leur testabilit.

98
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

9.4

Les Mtriques (K2)

20 minutes

Termes
Mtrique

9.4.1 La mtrique (K1)


La mtrique est une chelle de mesure et une mthode utilise pour le mtrage (ISO 14598).
Les mtriques permettent dmettre un avis quantifiable sur le statut du projet et sa qualit.
Il est important de rappeler que les rsultats du mtrage (chiffres collects pendant la mesure)
doivent toujours tre compars aux donnes de rfrence (mesure correspondante).

9.4.2 Les mtriques dans le contexte des exigences (K1)


Les mtriques suivantes peuvent tre appliques aux exigences :

Le cot du projet
o Nombre des exigences
Le suivi du projet
o Nombre des exigences reports sur les autres objets
La stabilit du projet
o Nombre des exigences modifiables
Lvolution du processus
o Raisons des modifications concernant les exigences (dfauts, amliorations)
La qualit des spcifications
o Couverture des exigences par les modles
Le nombre des dfauts
o Type de dfaut
o Nombre de fautes dans les exigences pour chaque type (logique, cohrence,
donne, dfaut, etc.)

9.4.3 Les mesures de la qualit des exigences (K2)

99
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Quelques questions permettent dvaluer la qualit des exigences :

Les exigences sont-elles exactes ?


Sont-elles comprhensibles ?
Sont-elles ralisables ?
Sont-elles traables ?
Sont-elles identifiables ?
Sont-elles testables ?

Une formule possible pour mesurer la qualit des exigences :


Clart = Exigences sans dfauts ni problmes dtects / Exigences

Il est galement possible de mesurer le rapport de variation (celui-ci ne sapplique pas aux projets
Agile). Plus le rapport de variation du lot complet des exigences est lev (cela peut tre la cause
defforts apports la clarification dexigences incompltes, incohrentes ou incomprhensibles),
plus le projet est risqu. Aussi, ce taux doit tre mesur pour contrler les risques dun projet.

100
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

10 Outils (K2)

40 minutes

Objectifs dApprentissage (OA) pour le niveau Fondation de lIngnierie des Exigences


Les objectifs identifient ce que vous tes en mesure de faire, en ayant suivi chaque module.

10.1 Avantage des outils (K2)


OA-10.1.1

Expliquer lobjectif du support des outils dans lIngnierie des Exigences (K2)

OA-10.1.2
Dcrire quelles activits peuvent tre supportes par les outils dans lIngnierie
des Exigences (K2)

10.2 Catgories des outils (K2)


OA-10.2.1
(K2)

Quelles sont les exigences sur les outils utiliss pour lIngnierie des Exigences ?

OA-10.2.2

Quest-ce qui doit tre pris en compte dans le cot des outils ? (K2)

101
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

10.1 Avantages des outils (K2)

20 minutes

Termes
Outils de lIngnierie des Exigences

10.1.1 Utilisation des outils dans lIngnierie des Exigences (K2)


Les outils de stockage et dadministration des exigences facilitent lIngnierie des Exigences. Ils
prennent en charge les activits rptitives et mcaniques, et assurent une vue densemble. Il est
donc possible de maintenir des documents difficiles cohrents et jour. La slection doutils doit
seffectuer avant que le produit ne soit dvelopp. Dans le cas contraire, cela occasionnerait des
problmes importants.

Les outils jouent un rle dans les activits suivantes :

Identification et stockage des exigences


Modlisation des exigences (y compris les prototypes)
Documentation des exigences (cration des spcifications)
Dfinition et maintien de la traabilit des exigences

10.1.2 Avantages de ces outils (K2)

Assurer que toutes les exigences sont stockes en un seul endroit et accessibles tous les
participants
Maintenir la traabilit des exigences (des cas de test, etc.) et permettre la vrification de
la couverture des exigences correspondantes
Permettre une gestion facilite concernant la modification des exigences
Amliorer la qualit des spcifications des exigences en imposant lusage de modles de
documents dfinis et de notation.
Gagner du temps grce lautomatisation de certaines activits (telle que gnrer
lensemble des spcifications depuis un des outils)

102
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

10.2 Catgorie des outils (K2)

20 minutes

Termes
Catgories doutils

10.2.1 Catgories des outils (K2)

Outils dincitation aux exigences


o Carte heuristique
Outils de modlisation
o Outils UML
o Outils SysML
Outils de prototypes
Outils de gestion des exigences
Outils de gestion des anomalies
Outils de gestion des modifications
Outils de gestion de projet

Le cot dacquisition de ces outils varie amplement. Les outils commerciaux peuvent tre trs
onreux alors que ceux qui sont open source sont gratuits. La dcision de choisir tel ou tel outil
doit donc tre murement rflchie. Avant la slection, une analyse doit tre ralise. Elle doit
prendre en compte :

Le modle de notation utilis dans lentreprise et qui doit tre support par loutil
Sil est prvu dutiliser dautres modles de notation dans le futur (dans ce cas, il serait
raisonnable dacqurir un outil supportant les deux types de modles)
Les exigences de lentreprise concernant les fonctionnalits intgres loutil (les outils
commerciaux fournissent gnralement plus de fonctions que ceux qui sont open
source )
Le cout de loutil, en fonction de son utilisation (sil sera utilis pour un seul projet
spcifique ou bien sur la plupart des projets)
Sil est possible de lintgrer dautres outils ncessaires (tels quun outil de gestion des
erreurs, gestion de projet ou autre, en fonction des besoins de lentreprise)
Sil peut changer des informations avec les outils utiliss par les clients de lentreprise
(parfois, le client mne sa propre analyse des exigences, les produits de lanalyse dtaille
du vendeur devraient donc tre migrs dans lenvironnement du client).
La facilit dutilisation et de prise en main de loutil (avec dventuels cots de formation),
la disponibilit de laide en ligne, des manuels, tutoriaux et autres supports.

Un choix trop htif peut entrainer des cots importants :

103
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Cout dacquisition dun outil qui ne satisfait pas les exigences des utilisateurs et qui ne remplit pas
son objectif

Cout dacquisition dun outil onreux qui est utilis sur un projet unique ou acquisition
dun outil onreux disponible en open source avec des fonctions similaires.
Cout de formation en cas dacquisition dun outil qui ne prsente pas daide systme
suffisante (en particulier dans le cas o seules les fonctionnalits de base sont requises
depuis loutil)
Cout dextension de loutil acquis avec des fonctionnalits additionnelles, requises par les
utilisateurs et qui ne sont pas supportes par loutil (alors quil y a dautres outils incluant
ces fonctionnalits)
Cout de lintgration de loutil avec les autres outils utiliss dans lentreprise.

104
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

11 Littrature
Beck, K.: Extreme Programming. Munich 2003
Beck, K.: Extreme Programming Explained: Embrace Change. Boston 2000
Beck, K.: Test Driven Development. By Example. Amsterdam 2002
Beck, K.: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman 1999
Boehm, B.: Software Engineering Economics. Englewoods Cliffs, NJ 1981
Bohner, S.A. and R.S. Arnold, Eds. Software Change Impact Analysis. Los Alamitos, California, USA,
IEEE Computer Society Press 1996.
Bundschuh, M.; Fabry, A.: Aufwandschtzung von IT-Projekten. Bonn 2004
Cockburn, A.: Agile Software Development. Addison Wesley 2002
Cockburn, A.: Writing Effective Use Cases. Amsterdam 2000
Cohn M.: Estimating With Use Case Points, Fall 2005 issue of Methods & Tools
Cotterell, M. and Hughes, B.: Software Project Management, International Thomson Publishing
1995
Newman, W.M. and Lamming, M.G.: Interactive System Design, Harlow: Addison-Wesley 1995
Davis A. M.: Operational Prototyping: A new Development Approach. IEEE Software, September
1992. Page 71
Davis, A. M.: Just Enough Requirements Management. Where Software Development Meets
Marketing, Dorset House, 2005, ISBN 0932633641
DeMarco, T. et al.: Adrenalin-Junkies und Formular-Zombies Typisches Verhalten in Projekten.
Munich 2007
DeMarco, T.: Controlling Software Projects: Management, Measurement and Estimates. Prentice
Hall 1986
DeMarco, Tom: The Deadline: A Novel About Project Management. New York 1997
Dorfman, M. S.: Introduction to Risk Management and Insurance (9 ed.). Englewood Cliffs, N.J:
Prentice Hall 2007. ISBN 0-13-224227-3.
Dynamic Systems Development Method Consortium. See: http://na.dsdm.org
Ebert, Ch.: Systematisches Requirements Management. Anforderungen ermitteln, spezifizieren,
analysieren und verfolgen. Heidelberg 2005
Evans, E. J.: Domain-Driven Design: Tackling Complexity in the Heart of Software. Amsterdam 2003
Graham, D. et al: Foundations of Software Testing. London 2007
Gilb, T.; Graham, D.: Software Inspection. Reading, MA 1993

105
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Gilb, T.: What's Wrong with Requirements Specification. See: www.gilb.com


Heumann, J.: The Five Levels of Requirements Management Maturity, see:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/Management
Maturity_TheRationalEdge_Feb2003.pdf
Linstone H. A., Turoff M.: The Delphi Method: Techniques and Applications, Reading, Mass.:
Adison-Wesley, ISBN 9780201042948, 1975
Hull, E. et. All: Requirements Engineering. Oxford 2005
IEEE Standard 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
IEEE Standard 829-1998 IEEE Standard for Software Test Documentation
IEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements Specifications
IEEE Standard 1012-2004: IEEE Standard for Software Verification and Validation
IEEE Standard 1059-1993: IEEE guide for software verification and validation plans
IEEE Standard 1220-1998: IEEE Standard for Application and Management of Systems Engineering
Process
IEEE Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications
IEEE Standard 1362-1998 IEEE Guide for Information Technology-System Definition Concept of
Operations (ConOps) Document
ISO 9000
ISO/EIC 25000
ISO 12207
ISO 15288
ISO 15504
ISO 31000: RiskManagement - Principles and Guidelines on Implementation
IEC 31010: Risk Management - Risk Assessment Techniques
ISO/IEC 73: Risk Management Vocabulary
ISTQB: ISTQB Glossary of Testing Terms 2 1
ISTQB: Certified Tester, Foundation Level Syllabus, version 2011
Jacobsen, I. et al.: The Unified Software Development Process. Reading 1999
Jacobson, I.et al.: Object-Oriented Software Engineering. A Use Case Driven Approach. AddisonWesley 1993
Kilpinen, M.S.: The Emergence of Change at the Systems Engineering and Software Design
Interface: An Investigation of Impact Analysis. PhD Thesis. University of Cambridge. Cambridge, UK
2008.

106
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Lauesen, S.: Software Requirements: Styles and Techniques. London 2002


Mangold, P.: IT-Projektmanagement kompakt. Munich 2004
McConnell, S.: Aufwandschtzung fr Softwareprojekte. Unterschleiheim 2006
McConnell, S.: Rapid Development: Taming Wild Software Schedules (1st ed.). Redmond, WA:
Microsoft Press. ISBN 1-55615-900-5, 1996
Paulk, M., et al: The Capability Maturity Model: Guidelines for Improving the Software Process.
Reading, MA 1995
Pfleeger, S. L.: Software Engineering: Theory and Practice, 2nd edition. Englewood Cliffs, NJ 2001
Pfleeger, S.L. and J.M. Atlee: Software Engineering: Theory and Practice. Upper Saddle River, New
Jersey, USA, Prentice Hall 2006.
Pohl, K.: Requirements Engineering. Grundlagen, Prinzipien, Techniken. Heidelberg 2007
Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK
Guide). PMI 2004
Putnam, L.e H.; Ware M. Measures for excellence: reliable software On time, within budget.
Yourdon Press. ISBN 0-135676-94-0, 1991
Robertson, S.; Robertson, J.: Mastering the Requirements Process, Harlow 1999
Rupp,
C.:
Requirements-Engineering
und
Anforderungsanalyse in der Praxis. Munich 2007

Management.

Professionelle,

Iterative

Sharp H., Finkelstein A. and Galal G.: Stakeholder Identification in the Requirements Engineering
Process, 1999
Sommerville, I.: Requirements Engineering. West Sussex 2004
Sommerville, I.: Software Engineering 8. Harlow 2007
Sommerville, I.; Sawyer, P.: Requirements Engineering: A Good Practice Guide. Chichester 1997
Sommerville, I.; Kotonya, G.: Requirements Engineering: Processes and Techniques. Chichester
1998
Spillner, A. et all: Software Testing Foundations. Santa Barbara, CA 2007
SWEBOK - The Guide to the Software
http://www.computer.org/portal/web/swebok/home

Engineering

Body

of

Knowledge:

Thayer, R. H.; Dorfman, M.: Software Requirements Engineering, 2nd edition. Los Alamitos, CA
1997
V-Modell XT: http://www.vmodellxt.de/
Wiegers, K.E.: First Things First: Prioritizing Requirements. Software Development, September
1999
Wiegers, K. E.: Software Requirements. Redmond 2005

107
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Wiegers, K. E.: More About Software Requirements: Thorny Issues and Practical Advice. Redmond,
Washington 2006
Young, R. R.: Effective Requirements Practices. Addison-Wesley 2001

108
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

12 Index
Analyse des modes de dfaillance et de
leurs effets, 33
analyse oriente-objet, 75
Apprentissage, 49
auto-enregistrement, 49
brainstorming, 49
caractristique qualit, 68
Catgories doutils, 103
Changement, 90
Checkliste, 68
Client, 38, 43
commission de gestion du changement, 90
Conception projet, 31
Contractant, 38
contrat, 43
Contrat, 43
Critre dacceptation, 97
Criticit, 12
Cycle de vie produit, 22
cycle en V, 22
Cycle en V, 22
dcomposition fonctionnelle, 72
dfinition de projet, 31
demande de changement, 90
Diagramme dactivit, 75
diagramme dexigences, 75
diagramme dinteraction, 75
diagramme de classe, 75
diagramme de communication, 75

diagramme de composants, 75
diagramme de dploiement, 75
diagramme de machine tats, 75
diagramme de package, 75
diagramme de squence, 75
diagramme de structure composite, 75
diagramme des cas dutilisation, 75
diagramme objet, 75
diagramme structurel, 75
Engagement, 12
entretien, 49
excution de projet, 31
Exigence, 12
Exigence Fonctionnelle, 12
Exigence Non-Fonctionnelle, 12
Exigences fonctionnelles, 56
exigences non-fonctionnelles, 56
Exigences Processus, 12
Exigences Produit, 12
Extreme Programming, 22
Gestion de projet et du risque, 30
gestion de risque, 33
Gestion des Exigences, 12
gestion du changement, 90
Graduation, 83
groupe de travail, 49
IEC 31010, 106
IEEE830, 62
Impact Analysis, 105, 106

diagramme de comportement, 75

109
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011

REQB Certified Professional for Requirements Engineering


Niveau Fondation

Ingnierie des Exigences, 3, 9, 11, 12, 21,


28, 30, 37, 42, 61, 70, 87, 101
ISO 12207, 106
ISO 15288, 106
ISO 15504, 106
ISO 31000, 106
ISO 9000, 106
ISO/EIC 25000, 106
ISO/IEC 73, 106
Mtrique, 99
Modle de contexte, 72
modle de flot de donnes, 72
modle de transition dtats, 72
modle relation-entit, 72
modles conceptuels, 72
modles dexigence, 72
Modles de processus, 22
modles de solution, 72
ngociations de contrat, 31
Niveau formel, 66
niveau non-formel, 66
niveau semi-formel, 66
Objectif, 45
observation terrain, 49
Outils de lIngnierie des Exigences, 102
Partie prenante, 38, 47
perspective, 28
plan de gestion de risque, 33
Priorit, 12
Processus orient client, 28

Project Management, 105, 107


questionnaire, 49
Rational Unified Process, 22
reprsentant du client, 49
Requirements Engineering, 106, 107
revue, 49, 68
Risk, 105, 106
Risk Assessment, 106
Risk Management, 105, 106
risque, 33
risque produit, 33
risque projet, 33
Rles et responsabilits, 37
Signature, 85
Software Requirements Specifications, 106
Solution, 12
Spcification dexigences, 62
Spcification de solution, 62
Suivi horizontal, 88
Suivi vertical, 88
SysML, 75
testabilit, 97
traabilit, 68
UML, 75
validation, 68
Validation, 12
vrification, 68
Vrification, 12
Verification and Validation, 106
Vision, 45

110
Version 1.3 - FR
gasq Global Association for Software Quality

7 Novembre 2011