INGENIERIE DES EXIGENCES

Professeur Nacer eddine ZAROUR

Enseignant-Chercheur
Département de Technologies des Logiciels et
Systèmes d’Information (TLSI)
Faculté des Nouvelles Technologies de
l’Information et de la Communication (NTIC)
Laboratoire LIRE- É quipe SIBC
Université Constantine 2- Algérie
nasro-zarour@umc.edu.dz
1
• Complexité des projets SI actuels
impliquent que les relations contractuelles
entre maîtrise d’ouvrage (MOA)et maîtrise
d’œuvre (MOE) ne sont pas aisées.
• Les équipes de la MOE doivent vérifier ce
qu’elles développent doit correspondre
bien aux besoins initiaux des utilisateurs
• Les équipes de la MOA doivent vérifier
que les besoins initiaux sont respectés

2
• Les exigences sont la solution à ces
problèmes

• Elles sont une traduction plus technique

des besoins de la MOA

• Elles constituent le fil conducteur du

développement du produit en question

3
 SOMMAIRE
• Introduction
• Ingénierie des exigences
• Processus d’IE
• Techniques d’IE
• Outils d’IE
• Conclusion

4
 Introduction
• Dans les années 70-80, les systèmes ont été
développés selon la vision des concepteurs
sans l’intervention des utilisateurs et autres
parties prenantes
• Conséquences: abandon de nombreux
systèmes malgré leur bonne construction
technologique mais ne correspondaient pas aux
besoins des utilisateurs
• Plus tard, le marketing a trouvé plus de succès
car les parties prenantes étaient impliquées
dans la définition des fonctionnalités du système
5
 Introduction
• Un grand nombre d’études a montré que les
échecs dans la mise en œuvre des systèmes
informatiques sont dus à une mauvaise
compréhension des besoins
• Conséquences:
– coûts de développement élevés (dépassement de
budget)
– Retard dans la livraison (dépassement de délai)
– Perte de crédibilité
• Cependant la correction des erreurs est moins
coûteuse si elles sont détectées assez tôt dans
le développement (dans la phase d’analyse)
6
 Introduction
[Chaos, 2000]

Distribution des défectuosités Distribution de l’effort pour

réparer les défectuosités
Code
Autres Conception
1%
Exigences 4% 13%
82%

7
 Introduction
Standish Group a recensé les causes principales des
échecs des projets SI:
- Manque de participation des utilisateurs
- Besoins incomplets et/ou mal exprimés
- Manque de documentation
- Inadéquation des services fournis par le système aux
besoins exprimés
- 67% des coûts dépensés en phase de maintenance
- Le client ne sait pas ce qu’il veut ou ne sait pas exprimer
ce qu’il veut
- L’analyste ne comprend pas le client
- …

8
 Introduction (2/2)
• Distribution des causes d’échecs selon l’étude du
Standish Group
6 0%
o b ejc tifs p e u c lairs

5 0%
b e so ins qu i m an q ue n t du
5% ré alis m e
4 0% 6% b e so ins ch a ng é s e ntre le
d é bu t e t la fin d u p roje t
3 0% 11 %
53% b e so ins m al e xp rim é s
2 0% 12 %
m a nq u e d e p articip a tio n d es
1 0% u tilis a te u rs
13 %
0
0%
c a u s es d 'é c h e cs lié s a u x b e s o in s au tres ca u s e d ' éc h e c s

9
 Introduction
• Pour minimiser le taux d’echec des projets SI,
l’étape d’IE doit être clairement identifiée dans le
processus de développement
• Nécessité de méthodologies et de technologies
d’IE
• Les étapes suivantes du cycle de
développement (conceptions globales et
détaillées, mise en œuvre) dépendent toutes de
l’étape d’IE

10
 Définitions
• Ingénierie des systèmes (IEEE, 99):
démarche méthodologique, coopérative et
interdisciplinaire qui englobe l’ensemble
des activités adéquates pour concevoir,
développer, faire évoluer et vérifier un
système apportant une solution optimisée
sur tout le cycle de vie aux besoins d’un
client tout en étant accepté par tous

11
 Définitions
• Partie prenante: entreprise, organisation ou individu
ayant un intérêt ou une partie dans le résultat de
l’ingénierie d’un système
(AFIS, 07): une partie prenante constitue une partie
intéressée par l’utilisation et l’exploitation du système,
mais aussi un agent participant à sa conception, sa
production, son déploiement, sa commercialisation, son
maintien en condition opérationnelle et son retrait de
service
• Besoin (AFNOR): une nécessité ou désir éprouvé par un
acteur exprimé en langage naturel. Il peut être un
manque ou une attente
(Essame, 02): la perception que l’utilisateur a du
système. Ce besoin s’exprime souvent sous forme de
problèmes que rencontrent les utilisateurs auxquels le
système est destiné
12
 Définitions
• Contrainte: restriction, limitation ou régulation
imposée sur un produit, un projet ou un
processus
• Exigence (IEEE): entité qui identifie un produit
ou un processus opérationnel, fonctionnel, ou
désigne une caractéristique ou une contrainte,
qui est non ambiguë, testable et mesurable, et
nécessaire pour l’acceptation du produit ou du
processus
(Essame, 02): l’exigence est la vision que le
concepteur ou le développeur a du système
13
 Définitions
• Besoin Vs Exigence:
– Les besoins représentent la vision du système
uniquement du point de vue utilisateur
– Les exigences représentent la vision du système du
point de vue des concepteurs
– Une exigence est un besoin qui est techniquement
satisfaisable ou dans la solution peut être
implémentée
– Le passage des besoins aux exigences est un
processus très critique

14
 Définitions
• Besoin Vs Exigence: [Essame, 02]

15
 Définitions
• Deux catégories d’exigences:
- Fonctionnelles: fonctions attendues du système
- Non Fonctionnelles:
- contraintes globales de qualité de service ou
d’aptitude du système (fiabilité, maintenabilité,
évolutivité, sécurité, etc.) ou
- des contraintes opérationnelles (conformité à des
normes d’utilisation), ou
- des contraintes de conception (réutilisation d’existant)

16
 SOMMAIRE
• Introduction
• Ingénierie des exigences
• Processus d’IE
• Techniques d’IE
• Outils d’IE
• Conclusion

17
 Ingénierie des Exigences (IE)
• Activité d’IE (IEEE): processus qui permet
de transformer une idée floue en
spécification précise des exigences
servant de support à la spécification du
système et de ses interfaces avec
l’environnement
• Produire un document des exigences de
qualité est difficile et crucial

18
 Ingénierie des Exigences (IE)
• (Loucopoulos, 95): l’IE est un processus systématique
de développer des besoins par un processus itératif et
coopératif afin d’analyser les problèmes, de documenter
les observations résultantes dans une variété de formats
de représentation et de vérifier l’exactitude de la
compréhension (aspects représentatifs, sociaux et
cognitifs de l’IE)
• (Zave, 97): l’IE est la branche de l’IS qui concerne:
– Les besoins réels du monde en termes de fonctions et
contraintes sur ce système
– La relation entre ces facteurs qui définit le comportement de ce
système et son évolution au cours du temps et ses versions

19
 Ingénierie des Exigences (IE)
Objectifs de l’IE
• L’IE doit poser la question POURQUOI développer un
système?
• Déterminer les fonctionnalités que le système doit mettre
en œuvre
• Identifier les contraintes qui restreignent la mise en
œuvre de ces fonctions.
• Ces buts, fonctions et contraintes: exigences converties
en une spécification permettant le développement du
système
• L’évolution des exigences doit aussi être prise en
compte
20
 Ingénierie des Exigences (IE)
• Enjeux de l’IE
– Enjeux majeurs: satisfaction du client ou l’utilisateur
et la réponse aux attentes et contraintes des parties
prenantes
 Deux espaces: problème et solution
- Espace problème concerné par l’utilisateur et les
parties prenantes
- Espace solution concerné par les parties prenantes
 naissance des exigences à partir des besoins
clients  analystes et experts métier

21
 SOMMAIRE
• Introduction
• Ingénierie des exigences
• Processus d’IE
• Techniques d’IE
• Outils d’IE
• Conclusion

22
 Processus d’IE
• Objectif: fournir un document de
spécification des exigences qui définit le
système à développer
• Processus d’IE termine quand on pourra
répondre à la question: quand et si les
exigences rassemblées sont assez
bonnes pour commencer le
développement? (Sommerville, 97)

23
 Processus d’IE
• Le processus couvre des activités qui
sont inter-reliées:
- Elicitation des exigences
- Analyse et négociation des exigences
- Spécification des exigences
- Validation des exigences
- Gestion des exigences

24
 Processus d’IE: Approches
(Kotonya,98): processus linéaire et activités
exécutées itérativement

25
 Processus d’IE: Approches
(Macaulay, 1996): processus purement linéaire

26
 Processus d’IE: Approches
• Classification des processus d’IE selon leurs architectures

Structure Linéaire Linéaire+ Itératif Hiérarchique

Processus itérations
Kotonya X
Macaulay X
Loucopoulos X
Pohl X
Sommerville X
Wiegers X
27
 Processus d’IE : Activités
• Elicitation des exigences:
- Rassembler les info concernant les besoins des utilisateurs  bien
comprendre le problème et le domaine d’application  implication
de toutes les parties prenantes
- Composée de plusieurs étapes:
 Comprendre le domaine d’application
 Comprendre le problème
 Comprendre l’activité métier et ses interactions avec le reste du
système
 Identifier les sources appropriées des besoins
 Poser les questions pertinentes
 Rechercher les implications, contradictions, issues non définies
 Confirmer la compréhension des exigences avec les utilisateurs
 É tablir un rapport de synthèse des exigences

28
 Processus d’IE : Activités
Techniques d’élicitation:
- Observation des utilisateurs sur le terrain
- interviews,
- brainstorming,
- focus groupe
- Questionnaires
- ….
Rq. Le choix des techniques dépend du temps et des
ressources dont disposent les ingénieurs des exigences
et dépend aussi du type d’information à éliciter

29
 Processus d’IE : Activités
• Analyse des exigences
L’analyse se focalise sur l’examen et la compréhension des résultats
issus de la phase d’élicitation pour clarifier les exigences, assurer la
complétude et la non redondance, établir un accord entre partenaires
sur les exigences
Si contradiction ou divergence d’une ou plusieurs exigences
 négociation
But Analyse:
- Détecter les problèmes, lacunes, incohérences dans les besoins
acquis
- Les communiquer aux intéressés pour les résoudre par négociation

Rq. Les conflits ne sont pas des échecs mais des divergences dans les
exigences (priorités des intéressés)

30
 Processus d’IE Activités
• Spécification des exigences (documentation
des exigences)
- Rassemble les exigences résultantes de la phase
d’analyse et négociation
- Une bonne spécification doit avoir les propriétés suivantes:
cohérence (absence de contradictions), complétude (ts
les élts utilisés sont définis), absence de comportements
indésirables (blocage, situations dangereuses)
- Une spécification peut être:
 Informelle: écrites en langage naturel
 Semi-formelle: modèles E/A, DFD, Use case, ..
 Formelle: spécifier formellement le comportement complet du
système + inférences (RdP, B; Z; …)

31
 Processus d’IE: Activités
Traduction des exigences en spécifications
- Spécif générales: ensemble d’objectifs,
contraintes, généralités à respecter
- Spécif fonctionnelles: description détaillée
des fonctionnalités du système
- Spécif d’interfaces: description des
interfaces du logiciel avec le monde
extérieur
- Spécif des besoins: définir ce que doit faire
le logiciel et non comment il est fait
32
 Processus d’IE: Activités
• Négociation
Trouver un compromis approuvé par toutes les parties prenantes en
discutant les conflits des exigences existants
Activités de négociation (Valtchev, 03):
- Discussion: les exigences identifiées comme problèmes sont
discutées et chaque partie concernée expose sa vision sur chaque
exigence
- É tablissement de priorités: chacune des exigences discutée reçoit
une priorité et donc reconnaître celles qui sont critiques
- Consensus sur les exigences: un ensemble de compromis
d’exigences consensuelles est établi. Ceci implique certains
changements sur certaines exigences

33
 Processus d’IE: Activités
• La tâche de négociation n’est pas un processus
simple mais un processus coopératif
• Difficultés rencontrées:
– Trop d’exigences
– Budgets, durée et ressources limités
– Une exigence: importante? Pour qui? Sur quels
critères la prioriser? À quelle phase sera-elle
associée? ..
– Les développeurs ne connaissent pas bien la valeur
des exigences demandées
– Les clients ne connaissent pas la complexité de leur
développement
34
 Processus d’IE: Activités
– Plusieurs intervenants avec différents buts,
différentes priorités, ..
– Attitudes! Pas besoins de priorités; parfois l’échéance
arrive alors que des exigences sont mises à côté pour
livrer le produit; ..
– Coordination entre analystes
– Difficile de satisfaire tout le monde, de prendre les
bonnes décisions et d’atteindre tous les buts fixés
Besoins de compromis, de priorités, de triage, …
 de négociation

35
 Processus d’IE: Activités
• Validation des exigences
- Confronter le cahier de charges aux acteurs
pour s’assurer de son adéquation avec leurs
exigences
- Les exigences doivent être complètes,
correctes et non ambiguës
- Les spécif consultées par les acteurs peuvent
être acceptées, commentées, amendées ou
refusées
- Les modèles graphiques se prêtent bien à la
validation
- En cas de modifications ou refus, un nouveau
cycle du processus d’IE est lancé
36
 Processus d’IE: Activités
• Norme EIA-632: la validation des exigences est focalisée
sur la vérification de la version finale du document des
exigences pour détecter les conflits, les omissions et les
déviations par rapport aux normes.

• Validation: vérifer que les exigenes satisfont les attentes

des parties prenantes et à assurer qu’elles décrivent les
fonctionnalités éspérées du système

37
 Processus d’IE: Activités
• Validation Vs Vérification
Boehm:
Vérification: « Am I building the product
right? » Est-ce que je construis le produit
correctement?
Validation: « Am I building the rigth
product? » Est-ce que je construis le bon
produit?
38
 Processus d’IE: Activités
Types de tâches de validation
- Spécification vérifiée pour consistance interne:
Activités basées sur
- les vérifications formelles
- Les validations qui utilisent les techniques d’inspection ou des
walkthrough
- Spécification validée avec l’utilisateur, le client, ..
- Prototypage
- Expériences et analyse des résultats
- Animation ou simulation
- …
Vérification des documents produits: Complétude; consistance;
conformité aux standards; conflits entre besoins; ambiguïté dans les
besoins; …
39
 Processus d’IE
• Gestion des exigences
- Partie intégrante du processus global de l’IE
- Pendant le processus, le système évolue  découverte de nouvelles
exigences et changement de celles existantes

- Les parties prenantes sont à l’origine de ces changements

- Pour une meilleure performance du système, la gestion doit inclure le
stockage de l’info, l’organisation, la traçabilité, l’analyse, la
visualisation et la documentation

- La traçabilité permet de poursuivre les origines de chaque exigence

- Contexte traçabilité: qui a suggéré les exigences; pourquoi elles snt

agréées; quelles autres exigences lui sont liées; comment sont reliées
aux autres documents de conception, ..
40
 Processus d’IE: Activités
Préoccupations de la gestion des exigences:
- Changements dans les besoins agréés
- Identification des exigences
- Relations entre les exigences
- Traçabilité des exigences
- Dépendances entre les documents décrivant les exigences et les
autres documents produits en cours de l’IE
- Planification de la gestion des exigences (lignes directrices qui sont
en rapport avec la planification des activités d’identification, de
traçabilité
- Dans 70% des systèmes, le coût du projet évolue de façon
exponentielle dans les travaux d’adaptabilité et de
correction du système
- Les coûts relatifs à la gestion des exigences sont
récompensés par une meilleure satisfaction de client et
minimise les coûts de développement du système global 41
 Conclusion
• L’IE prend en compte de manière systématique et
formalisée les exigences des acteurs d’un système
• L’IE indispensable pour la réussite du développement du
système
• L’IE décèle les erreurs assez tôt qui autrement
deviennent les erreurs les plus difficiles, les plus longues
et les plus coûteuses à corriger
• L’IE contribue à diminuer le coût de développement et
garantie un développement fluide (pas de modifications
fondamentales)
• Le résultat de l’IE est un document des exigences
complet et non ambigu
• Le développement du processus d’IE nécessite des
méthodologies, techniques et outils appropriés
42