Embed Size (px)
Citation preview
Master 2 GLREMaster 2 IT-SIGL
Ingénierie des exigences :les phases amonts d'ingénierie
système / logicielle
– Partie 1 – Pierre-Jean Charrel
UTM – [email protected]
http://www.univ-tlse2.fr/grimm/isycom/pjcharrel.html
M2 GLRE - IT-SIGL 2008 2009 2
PlanPartie 1 Généralités
1. Pourquoi des exigences ?2. Que sont les exigences et pourquoi une ingénierie des
exigences ?3. Qualité des exigences
Partie 2 Développement des exigences1. Vision du produit et portée du projet2. Elicitation3. Vérification et validation4. Documentation5. Analyse et négociation
Partie 3 Gestion des exigences1. Contrôle du changement2. Contrôle de version3. Trace de l'état des exigences4. Traçage des exigences
M2 GLRE - IT-SIGL 2008 2009 3
BibliographieKarl E. Wiegers, Software Requirements, Microsoft Press, 2nd ed., 2003 (1st ed. - 1999)Gerald Kotonya, Ian Sommerville, Requirements Engineering: Processes and Techniques, John Wiley &
Sons, 1998
Mark Bergman, John Leslie King, Kalle Lyytinen Large-Scale Requirements Analysis Revisited: The need for Understanding the Political Ecology of Requirements Engineering, Requirements Engineering journal 7(3): 152-171, 2002
Marjo Kauppinen, Sari Kujala, Tapani Aaltio, Laura Lehtola Introducing Requirements Engineering: How to Make a Cultural Change Happen in Practice, Proceedings of IEEE Requirements Engineering conference, pp. 43-51, 2002
Boehm, B. . A spiral model for software development and enhancement. IEEE Computer, pages 61–72,
1988Carson, R. S. Requirements completeness: A deterministic approach, Proc. 8th Annual International
Symposium of the INCOSE, 1998Glass, R. L. Facts and Fallacies of Software Engineering, Addison-Wesley, 2003Jackson, M. Software Requirements and Specifications : a Lexicon of Practice, Principles and Prejudices.
ACM Press / Addison-Wesley, 1995Jackson, M. Seeing More of the World, IEEE Software 21(6): 83-85, 2004Pohl, K. Process-Centered Requirements Engineering, Research Studies Press / Wiley, 1996Preiss, O. and Wegmann, A. Stakeholder discovery and classification based on systems science principles,
Proc. 2nd APQSC Asia-Pacific Conference on Quality Software, pp. 194-198, IEEE, 2001Sage, A. P. Systems Management for Information Technology and Software Engineering, John Wiley and
Sons, 1995Royce, W. Managing the development of large software systems. In Proc. IEEE Western Computer Conf.,
Los Alamitos, CA. IEEE Computer Society Press, 1970Schwalbe, K. Information Technology Project Management, Course Technology; 3rd ed., 2003
Partie 1 Généralités
1. Pourquoi des exigences ?
M2 GLRE - IT-SIGL 2008 2009 5
1. Pourquoi des exigences ?Petit malentendu entre amis• Allô Bill ? Ici Marie des RH. On a un problème avec ton
système de gestion de personnel. Le fils d'une employée vient de changer de nom, et on ne peut pas le dire au système.
• Dis plutôt que c'est sa fille et qu'elle s'est mariée !• Non, c'est son fils et il est adopté. Il prend maintenant le
nom de ses parents adoptifs. C'est légal, tu sais !• Je savais pas qu'on pouvait changer comme ça. C'est pour
ça qu'on ne peut atteindre le menu "changer de nom" que via l'écran "changement de situation maritale"
• Bon, tu peux corriger le bug pour vendredi ? Autrement, les allocations familiales et la Sécu vont lui causer des ennuis
• C'es pas un bug ! Tu ne m'as jamais dit que tu avais besoin de ça
• Ouais, bon! c'est le genre de truc qui me fait haïr l'informatique !
M2 GLRE - IT-SIGL 2008 2009 6
Idée de base : ajouter une étape au processus de développement
Conception
Implémentation
Test de satisfactionalpha, beta, conformité
Test unitaire et d'intégration
Attentes des utilisateurs du système
validation de la conceptionc
M2 GLRE - IT-SIGL 2008 2009 7
Idée de base : ajouter une étape au processus de développement
Exigences
Conception
Implémentation
Test de satisfactionalpha, beta, conformité
Test du système
Test unitaire et d'intégration
Validation des exigences
validation de la conceptionc
Attentes des Acteurs du système
M2 GLRE - IT-SIGL 2008 2009 8
Ajouter une étape : Avantages et inconvénients
Avantages• Pouvoir commencer le contrôle qualité plus tôt• Augmenter les niveaux de contrôle• Résoudre vite des conflits d'intérêt entre acteurs
Amélioration :• conformité aux attentes des acteurs • efficacité (coût, délai, ressources humaines) du
développement du système
Inconvénient• une étape de plus des bugs possibles en plus
M2 GLRE - IT-SIGL 2008 2009 9
Quelques définitions (1)
Acteur (stakeholder)personne, groupe, organisation
• impliqué dans la conception et le développement du système
• affecté par le système ou affectant le système
Attentebesoin, vœu, réclamation de l'acteur, même
inconscientExigence Système
ensemble d'attentes explicité et négocié entre les acteurs
M2 GLRE - IT-SIGL 2008 2009 10
Quelques définitions (2)Exigence IEEE 1990 Standard Glossary of Software Engineering2. Condition ou moyen dont un utilisateur a besoin pour résoudre un
problème ou atteindre un but3. Condition ou moyen à acquérir par un composant du système pour
satisfaire un contrat, une spécification ou tout document formel imposé
4. Une représentation documentée d'une condition ou d'un moyen relevant du point 1. ou du point 2.
Ingénierie des exigences (IE) Requirements Engineering (RE) Domaine des activités de • développement • gestiond'exigences systèmes tout au long • du processus de développement • de la vie du système
M2 GLRE - IT-SIGL 2008 2009 11
Erreurs d'exigences
Exigences 0,2
Conception 0,5
Codage 1
Test unitaire 2
Tests d'acceptation
5
Maintenance 20
0,1
1
10
100
les plus chères à corriger dans les phases de production
les moins chères à corriger dans les phases de développement
M2 GLRE - IT-SIGL 2008 2009 12
Erreurs d'exigences
Exigences41%
Conception28%
Données6%
Interface6%
Autres7%
Humaine5%
Documentation2%
Environnement5%
Source la plus fréquente de problèmes
M2 GLRE - IT-SIGL 2008 2009 13
Standish group CHAOShttp://wwwstandishgroup.com9.236 projets
• 58% réponses US • 27% européennes• 15% reste du monde
• 45% grandes sociétés• 35% moyennes• 20% petites
Taux de succès des projets (2004)
Projets "handicapés"
53
Projets abandonnés
18
Projets réussis
29
Projets "handicapés" challenged- en retard- en dépassement de budget- avec moins de fonctionnalités
que prévu
M2 GLRE - IT-SIGL 2008 2009 14
Projets "handicapés" (en 2000)Sous-estimation du temps %
Dépassement du budget %
moyenne 63%
moyenne 86%
En moyenne temps : 86% de plus que prévu coût : 63% de plus que prévu
M2 GLRE - IT-SIGL 2008 2009 15
Projets "handicapés" (en 2000)
Fonctionnalités planifiées à l'origine %
moyenne 75%
En moyennefonctionnalités : 75%
M2 GLRE - IT-SIGL 2008 2009 16
Propriétés des projets abandonnés, en 2000
13,1 12,410,6 9,9 9,3 8,7 8,1 7,5
6,34,3
9,9
02468
101214
Exigenc
es in
complè
tes
Manque
d'im
plicati
on utili
sateurs
Manque
de re
ssourc
es
Attente
s irré
aliste
Manque
de su
pport
Modif e
xigen
ces e
t Spéc
Défaut d
e palnific
ation
Produit i
nutile
Défaut d
'encadre
ment
"illétr
isme" te
chno
logique
Autre
Pourcents
M2 GLRE - IT-SIGL 2008 2009 17
Facteurs de succès
15,913,9 13
9,68,2 7,7 7,2
5,32,9 2,4
13,9
02468
1012141618
Implica
tion des
utilisa
teurs
Encad
rement p
résent
Exigenc
es cl
airem
ent én
oncée
s
Planning
juste
Attente
s réali
stes
Etapes d
e proje
t court
es
Personn
el co
mpétent
Ownersh
ip
Objecti
f clair
Equipe i
mpliqu
ée et "t
ravaille
urse"
Autre
Im plIm plicati
Pourcents
M2 GLRE - IT-SIGL 2008 2009 18
Risques d'un processus d'exigences inadéquat(Wiegers, 2003)
• implication insuffisante des utilisateurs produit inacceptable
• ignorer certains utilisateurs clients insatisfaits
• spécifications minimales passer à côté d'exigences clés
• exigences incomplètement définies problèmes de planification du projet
• exigences ambiguës gaspillage de temps
• "gold-plated" propriétés inutiles
M2 GLRE - IT-SIGL 2008 2009 19
Profits essentiels d'un bon processus d'exigences
• qualités du système et satisfaction du client améliorées
• mise en conformité facile avec les standards et les règles
• réduction des coûts et délais• contrôle accru sur des projets complexes• meilleure communication d'équipe
M2 GLRE - IT-SIGL 2008 2009 20
5 obstacles / réticences à l'IE (des développeurs)(1)1. "Cela ne vaut pas la peine de découvrir directement les
exigences des utilisateurs"Arguments• Cela fait longtemps qu'on développe ce genre de produit
et on connaît les besoins• Nos développeurs utilisent aussi nos propres produits
donc nous pouvons jouer le rôle d'utilisateurs• Nous développons un nouveau produit donc les
utilisateurs ne peuvent pas avoir d'exigences dessusRéponses• Mieux les utilisateurs sont compris, plus les produits sont
utiles• Les utilisateurs sont les experts de leur activité, ils sont
donc la source première d'exigences• Les utilisateurs d'un nouveau produit savent rarement
dire ce qu'ils veulent, mais sauront vite voir ce qu'ils ne veulent pas
M2 GLRE - IT-SIGL 2008 2009 21
5 obstacles / réticences à l'IE (des développeurs) (2)
2. "Excès de confiance en soi mais peu de connaissance du domaine"
M2 GLRE - IT-SIGL 2008 2009 22
5 obstacles / réticences à l'IE (des développeurs) (3)
3. "C'est difficile de découvrir directement les exigences des utilisateurs"
Arguments• "Ils" ne savent pas dire ce qu'ils veulent• Il y a trop d'utilisateurs pour qu'on puisse les interroger
tous
Réponses• Techniques d'élicitation (interviews, observations…)
faciles à utiliser par les développeurs obtenir une représentation des besoins des
utilisateurs sans leur demander de les expliciter• C'est mieux d'interroger un petit groupe d'utilisateurs que
de ne rien faire
M2 GLRE - IT-SIGL 2008 2009 23
5 obstacles / réticences à l'IE (des développeurs) (4)
4. "C'est risqué de découvrir les exigences directement auprès des utilisateurs"
Arguments• On ne peut pas montrer à nos clients qu'on ne connaît
rien à leur domaine• Les développeurs peuvent gâcher les relations avec les
clients en posant des questions stupides
Réponses• Des visites bien préparées
améliorer l'image d'une entreprise• Exigence découverte trop tard,
conséquences pires
M2 GLRE - IT-SIGL 2008 2009 24
5 obstacles / réticences à l'IE (des développeurs) (5)
5. "Cela ne vaut pas la peine d'expliciter les exigences des utilisateurs"
Arguments• Nos clients veulent les docs techniques du logiciel, pas
des docs qui racontent ce qu'ils savent • on n'a pas le tempsRéponses• Les exigences documentent un accord sur le système,
pas seulement ce que les utilisateurs ont en tête• Exigences utilisateurs bien documentées utiles à
beaucoup d'équipes : concepteurs, testeurs, rédacteurs de manuels, marketing, gestion
• Documenter les exigences en début de développement
Gain de temps Diminution des reprises en cours de projet
M2 GLRE - IT-SIGL 2008 2009 25
… et un 6ème obstacle
Le client6. "Je suis trop occupé pour perdre mon
temps avec les exigences"
Se rappeler • des projets abandonnés et "handicapés"• des coûts des changements dans les
phases aval
Partie 1 Généralités
1. Pourquoi des exigences ?2. Que sont les exigences et pourquoi une ingénierie des exigences ?
M2 GLRE - IT-SIGL 2008 2009 27
2. Que sont les exigences ?
Acteur (stakeholder)personne, groupe, organisation
• impliquée dans la conception du système• affectée par le système ou affectant le système
Attentebesoin, vœu, réclamation de l'acteur, même inconscient
Exigence Systèmeensemble d'attentes explicité et négocié entre les
acteurs
Comment distinguer exigences et conception?
M2 GLRE - IT-SIGL 2008 2009 28
Que sont les exigences ?Vue classique• les exigences définissent le problème• la conception et le développement définissent
la solution… simpliste !
En pratique, les systèmes • ne sont pas développés comme un problème
pour lequel il faut une solution• mais sont développés pour répondre à une
sollicitation "une solution qui cherche un problème"
M2 GLRE - IT-SIGL 2008 2009 29
Le Système et son Environnement
Distinguer entre• Connaissances du domaine• Exigences externes• Exigences internes• Information de conception
Exemple• Un système informatique qui vérifie
l'orthographe d'un texte
M2 GLRE - IT-SIGL 2008 2009 30
Le Système et son Environnement
• Connaissances du domaine (Domain knowledge)– phénomènes d'environnements indépendants du
système– Ex 1 : vérifier l'orthographe d'un texte à la main prend 5
pages à l'heure– Ex 2 : les nombres de mots et de citations du Grand
Robert sont respectivement de 100 000 et 160 000• Exigences externes (Outer requirements )
– effets souhaitables du système sur l'environnement– Ex : l'orthographe d'un texte doit être vérifiée vite et
bien
M2 GLRE - IT-SIGL 2008 2009 31
Le Système et son Environnement
• Exigences internes (Inner requirements)– phénomènes partagés par le système et
l'environnement– Ex 1 : un système informatisé doit être développé pour
vérifier l'orthographe d'un document électronique– Ex 2 : si on trouve un mot en dehors du dictionnaire,
l'utilisateur sera invité à choisir parmi plusieurs mots corrects
• Information de conception (Design information)– structure interne et comportement interne du système– Ex : l'algorithme de vérification orthographique
M2 GLRE - IT-SIGL 2008 2009 32
Le Système et son Environnement
Phénomènes de l'environnementindépendants du système
Analyse du domaine, règles de gestion
Phénomènes du systèmeConception
Phénomènes de l'environnementà effet sur le systèmeExigences externes
Phénomènes partagés, interface Système /
EnvironnementExigences internes
Exigences
d'après Jackson 1995, 2004
M2 GLRE - IT-SIGL 2008 2009 33
Que sont les exigences ?• Description de la frontière et des effets
Où est la frontière entre système et environnement?• Exemple
– le client : "Utilisez Oracle, car nous avons une licence et un savoir-faire"
– Exigence ou conséquence de conception ?
C'est une exigence. Le type de SGBD n'est pas du côté "utilisateur" de la frontière. Mais les utilisateurs ne sont pas les seuls acteurs.Le type de SGBD est du côté "équipe de maintenance" (savoir-faire),
et du côté "client" (licence) de la frontière
Etablir une classification des exigences
M2 GLRE - IT-SIGL 2008 2009 34
Exigences fonctionnelles et non fonctionnelles• Exigences fonctionnelles EF :
– ce que le système devra faire• Exigences non fonctionnelles ENF - attributs de qualité
– comment il devra le faire et à quel niveau il devra respecter les caractéristiques générales.
M2 GLRE - IT-SIGL 2008 2009 35
Exigences non fonctionnelles• Souvent oubliées, les acteurs se concentrent sur
les fonctionnalités qu'ils attendent• La perception de bon ou mauvais
fonctionnement d'un systèmes se traduit par la satisfaction ou non d'exigences non fonctionnelles
• Traitées classiquement dans la 1ère phase de conception, dite phase de conception d'architecture– Ex : décision d'une solution centralisée ou distribuée
• Le coût du changement dû à une ENF non satisfaite peut être énorme voire … infini !
M2 GLRE - IT-SIGL 2008 2009 36
4 ENF• Effectivité (effectivity): exactitude et complétude
de la réussite du système à atteindre ses objectifs – Mesurée en %
• Efficacité (efficiency): relation entre l'effectivité et les ressources mises en œuvre pour l'atteindre; bon usage de : processeur, mémoire, bande passante…
– Mesurée en %, MO, MO/s,…• Consommation de ressources (resource
consumption): – Mesure absolue
• Performances (performance) : rapidité d'exécution des fonctions.
– Mesurées comme un temps de réponse, un débit, une capacité
M2 GLRE - IT-SIGL 2008 2009 37
5 ENF de plus• Disponibilité (availability): prêt pour rendre un service
correct, – Mesuré en % de temps où le système est opérationnel
• Fiabilité (reliability): continuité de service – Mesuré en temps moyen entre 2 pannes (MTTF Mean Time To
Failure)• Sûreté (safety) : absence de conséquences
catastrophiques pour les utilisateurs et l'environnement, i.e. fiabilité vis-à-vis d'une liste de pannes catastrophiques
– Mesuré en MTTF• Intégrité (integrity) : absence d'altération dans le système
– Difficilement mesurable… probabilité ?• Confidentialité (confidentiality) : absence de divulgation
non autorisée d'information– Difficilement mesurable… probabilité ?
M2 GLRE - IT-SIGL 2008 2009 38
3 de plus
• Confiance (dependability) : aptitude à rendre un service dont la sécurité peut être justifiée
• Robustesse – tolérance aux pannes (robustness – fault tolerance) : aptitude à maintenir sa "confiance" en présence de données incorrectes, de défauts de composants logiciels et matériels connexes, ou de conditions opératoires inattendues
• "tankness" (Wiegers 2003)
• Sécurité (security) : aptitude à éviter les utilisations ou les modifications non autorisées
M2 GLRE - IT-SIGL 2008 2009 39
et 4 dernières
• Utilisabilité (utilisability): étendue des usages possibles du système avec garantie d'effectivité, d'efficacité, et de satisfaction
• Maintenabilité (maintenability): aptitude à corriger des défauts ou faire des modifications, avec effectivité et efficacité
• Flexibilité (flexibility) : aptitude à intégrer de nouvelles caractéristiques
• Portabilité (portability) : aptitude à faire migrer le logiciel d'un environnement opérationnel à un autre
M2 GLRE - IT-SIGL 2008 2009 40
Compromis
• Des décisions de conception différentes peuvent avoir un effet similaire sur une ENF
• Une décision de conception qui améliore une ENF peut avoir un effet négatif sur une autre
• Ex : Portabilité et efficacité
M2 GLRE - IT-SIGL 2008 2009 41
Dépendances entre ENF
Confiance
Maintenabilité
Intégrité
Confidentialité
Sûreté
Fiabilité
Disponibilité
Sécurité
M2 GLRE - IT-SIGL 2008 2009 42
d'après Wiegers, 2003
M2 GLRE - IT-SIGL 2008 2009 43
7 Problèmes liés aux ENF• Certaines ENF décrivent les performances du système,• Certaines ENF décrivent un système englobant (supra-
système)– utilisabilité = système + utilisateur– maintenabilité = système + équipe de maintenance– sécurité = système + une partie de son environnement
• La plupart des ENF difficiles à mesurer en pratique• Certaines ENF difficiles à quantifier • Beaucoup d'ENF sont subjectives• Pour assurer une ENF, le système doit souvent
implémenter une exigence fonctionnalitéEx : ENF de confidentialité protection par un mot de passe attaché
à des données sensibles. • L'IE devient un processus itératif, et des exigences de
niveau différent se mélangent dans un même document.
M2 GLRE - IT-SIGL 2008 2009 44
Exigences de projet
3 ENF se rapportent au processus de développement et non au système
• le Temps• le Coût• la nécessité de développer des produits
connexes, p. ex. un manuel d'utilisation
M2 GLRE - IT-SIGL 2008 2009 45
Catégories d'informations liées aux exigences (1)
• Exigences "métier" Business requirements : objectifs de haut niveau
• Propriétés Features : ébauches de solution aux exigences "métier", élaborées plus tard en exigences spécifiques.
• Exigences utilisateur User requirements : activités que les utilisateurs devront être capables d'accomplir dans le futur système
• Exigences fonctionnelles Functional requirements : fonctionnalités du système qui permettront aux utilisateurs d'accomplir leurs activités, satisfaisant les exigences "métier"
M2 GLRE - IT-SIGL 2008 2009 46
Catégories d'informations liées aux exigences (2)• Exigences non fonctionnelles Non functional requirements
– quality attributes : améliorent la description des fonctionnalités du produit en décrivant ses caractéristiques selon des dimensions importantes pour les acteurs
• Contraintes Constraints : restrictions imposées aux concepteurs pour l'implémentation du système
• Interfaces externes External interfaces : interface système - environnement
• Règles de gestion Business rules : politique de l'entreprise, règles de gouvernance, standards industriels, pratiques comptables, algorithmes de calcul connaissance du domaine, pas des exigences
• Exigences système System requirements : pour les logiciels, exigences pour le système informatisé
• Exigences de projet Project requirements : contraintes sur le processus de développement, p.ex. budget, planning
M2 GLRE - IT-SIGL 2008 2009 47
Fonctionnel Non fonctionnelExigences métier
Exigences utilisateur
Règles de gestion
ENF
Interfaces externes
ContraintesExigences
systèmeExigences
fonctionnelles
Cas d'utilisations, Scénarios …
Document de Spécification d'exigences
Document vision et portée
d'après Wiegers 1999, 2OO3
Catégories d'informations liées aux exigences (3)
Propriétés
Exigences projet
1 25/09/08 13h30-15h30 Fin
M2 GLRE - IT-SIGL 2008 2009 48
Exigences dans les modèles de génie logiciel : Modèle en cascade
d'après Royce 1970
M2 GLRE - IT-SIGL 2008 2009 49
Cycle en V temps
détails
M2 GLRE - IT-SIGL 2008 2009 50
Modèle en spirale
d'après Boehm (1988)
M2 GLRE - IT-SIGL 2008 2009 51
Modèle par prototypage (incrémental)d'après Huet (2006)
M2 GLRE - IT-SIGL 2008 2009 52
Processus unifié (RUP)Inception Elaboration Construction TransitionActivité \ Phase
• Implémentation
• Test• Déploiement
• Gestion du changementet de configuration• Gestion de projet
• Environnement
• Modélisation métier• Exigences
• Analyse-conception
ItérationsPréliminaire Elab 1 Elab 2 Tr 1Const 3Const 2Const 1 Tr 2
Quantités de
travail
• Exigences = capture ce que le système devrait faire (élicitation)• Analyse-conception = raffinement et structuration des exigences
M2 GLRE - IT-SIGL 2008 2009 53
Activités de base en Ingénierie des exigences
Développement des exigences1. Elicitation2. Analyse3. Négociation4. Documentation5. Vérification et validation
Gestion des exigences1. Contrôle du changement 2. Contrôle de version3. Historisation des états4. Traçabilité
M2 GLRE - IT-SIGL 2008 2009 54
Que doit-on signer ?Geler des exigences
irréaliste et imprudent, les changements sont inévitablesUn document d'exigences signé par un client• concrétise un accord• ne signifie pas que les exigences ont été finalisées
Toute signature d'un document d'exigences devrait être accompagné d'un texte du genre :"J'accepte que ce document représente nos exigences de projet
aujourd'hui. J'accepte d'effectuer les futurs changements selon le processus
défini de changement de projet. Je réalise que les changements approuvés devront requérir une
renégociation des accords de coûts, ressources et plannings pour ce projet". (Wiegers, 2003)
M2 GLRE - IT-SIGL 2008 2009 55
Exigences de basecourantes
Frontière entre définition et gestion des exigencesExigences Marketing, Client, Direction
AnalyseDocumentation
NégociationValidation
Exigences de base
Marketing Client
Direction
Processusde changementdes exigences
Développement
Gestion
Environnementde
projetChangement(exigences)
Changement(projet)
Exigences de baserévisées
M2 GLRE - IT-SIGL 2008 2009 56
Développement des exigencesEtablit un accord entre tous les acteurs (y compris l'équipe
de développement) sur les exigences systèmeInduit• Elicitation : processus d'identification des exigences à
partir de : interviews, réunions, séminaires, analyse de documents, analyse de tâches, workflow, etc.
• Validation & vérification : processus de test de non contradiction entre– exigences entre elles, – exigences et attentes des acteurs
• Analyse : processus – d'évaluation du coût et de la valeur des exigences,– d'identification de dépendances entre exigences, etc.
• Négociation : processus de résolution de conflits entre exigences, choix et priorités
• Documentation (spécification) : processus de documentation sous une forme partageable et gérable
M2 GLRE - IT-SIGL 2008 2009 57
Gestion des exigencesMaintient l'accordInduit• Contrôle du changement : gestion des changements par
rapport à l'accord initial, – contrôlée, – évaluant l'impact probable de chaque changement avant
approbation,– incorporant les changements approuvés
• Contrôle de version : gestion des versions de documentation et des révisions d'exigences
• Contrôle de l'état des exigences : définit un ensemble de valeurs d'état pour chaque exigence, et contrôle de ces états pendant le projet
• Traçage des exigences : gestion des dépendances entre exigences, et trace des traductions des exigences depuis leur origine jusqu'à la conception, codage, jeu de test
M2 GLRE - IT-SIGL 2008 2009 58
Processus de développement des exigences
Kotonya, Somerville, 1998
M2 GLRE - IT-SIGL 2008 2009 59
Processus de développement des exigencesKotonya, Somerville, 1998
M2 GLRE - IT-SIGL 2008 2009 60
Processus de développement des exigences
Wiegers, 2003
M2 GLRE - IT-SIGL 2008 2009 61
Processus de développement des exigences
Pohl, 1996
M2 GLRE - IT-SIGL 2008 2009 62
Processus de développement des exigencesProcessus unifiéSimilarité entre :Ingénierie logicielle• définition d'exigences• conception• implémentation• TestIngénierie des exigences• élicitation• analyse, négociation• documentation• validation
M2 GLRE - IT-SIGL 2008 2009 63
Processus de développement des exigences
Représentation
trace du processus
Accord
vues personnelles
vue commune
informel formel
complète
opaque
Spécification
Activités indépendantesElicitation : spécification Négociation : accordDocumentation : représentation Validation : toutes les dimensions
convenable
semi-formel
M2 GLRE - IT-SIGL 2008 2009 64
L'analyste des exigencesUn rôle, pas un travailRequiert des compétences spécifiques• savoir écouter• savoir interviewer et poser des questions• savoir organiser un travail en groupe• savoir observer• qualités relationnelles (modérateur…)en plus de• compétences en analyse et organisations• savoir "rédiger"• savoir modéliser• créativitéInterface entre clients et développeurs
Partie 1 Généralités
1. Pourquoi des exigences ?2. Que sont les exigences et pourquoi une ingénierie des exigences ?3. Qualité des exigences
M2 GLRE - IT-SIGL 2008 2009 66
3. Qualité des exigences L'IE tente de répondre aux 2 questions :• quels sont les effets que les acteurs souhaitent avoir sur
l'environnement ?• quel pourrait être le comportement du système qui
permettrait d'obtenir ces effets sur l'environnement ?
L'IE tente d'élaborer de "bonnes" exigences, i.e. des exigences de "bonne qualité"
Les bonnes exigences répondent aux questions 1 et 2
2 niveaux de qualité :• qualités d'un système / logiciel – ce qui fait qu'un système
est "bon" – spécifié par les "exigences système"• qualités des exigences – ce qui fait que les exigences
sont "bonnes" = exigences sur les exigences
M2 GLRE - IT-SIGL 2008 2009 67
3 Moyens pour la qualitéExemple2. chercher s'il y a des cafards dans la
soupe. S'il y en a, les retirer ou jeter le contenu de la marmite
3. laisser le couvercle sur la marmite le plus possible, pour minimiser les occasions de chute de cafards
4. nettoyer la cuisine
situation
moyen 1 : qualité réactive avec le contrôle qualité
moyen 2 : qualité intégrée avec l'assurance qualité
moyen 3 : qualité proactive avec la gestion de la qualité stratégique
M2 GLRE - IT-SIGL 2008 2009 68
Moyens pour la qualitéDans l'histoire de l'ingénierie, 4 niveaux de qualité
• "inspection" (1940) : inspection de tous les produits, avec rejet ou réparation des défauts
• "statistique" (1940 -1960) : utiliser des mesures de performance sur des échantillons représentatifs
Moyens réactifs, contrôle qualité, contrôle de production
• "opérationnel" (1960 – 1970) : chaque étape de production est contrôlée, au moyen de mesures contrôlables; le produit n'est plus seul contrôlé
Moyen intégré, assurance qualité, contrôle du processus de production
• "gestion de qualité stratégique" (1970 -) : toute l'organisation (structure, processus de production, culture) impliquée pour aboutir à l'amélioration de la qualité des produits
Moyen proactif, gestion de la qualité, contrôle de l'environnement de production
M2 GLRE - IT-SIGL 2008 2009 69
Moyens pour la qualité
3 moyens complémentairesLes 2 derniers = contrôles actifs de la qualité
plus d'améliorations, TQM (Total Quality Management) = les 3
moyens rassemblés :Processus de contrôle de gestion total et intégré qui se préoccupe de tous les aspects liés à la qualité du système et des produits pendant toutes les phases du cycle de vie
M2 GLRE - IT-SIGL 2008 2009 70
Moyens pour la qualité des exigences• Contrôle qualité en IE : validation & vérification
des exigences (contrôle du produit de l'IE)• Assurance qualité en IE : utiliser de bonnes
techniques et de bons outils pour éliciter, analyser, contrôler les changements… (contrôle du processus d'IE)
• Gestion stratégique de la qualité en IE : éduquer les analystes, les développeurs, les clients, surmonter les croyances sur les exigences (contrôle de l'environnement d'IE, au-delà des processus)
M2 GLRE - IT-SIGL 2008 2009 71
Gestion stratégique de la qualité en IEd'après Wiegers, 2003
Bonnes pratiques en IE = formation• des analystes d'exigences – tous les membres
de l'équipe ayant un rôle d'analyste doivent être formés à l'IE
• des représentants des utilisateurs et des gestionnaires aux exigences logicielles (software requirements) – les utilisateurs qui vont participer au développement devraient recevoir une formation de 2 jours à l'IE
• des développeurs aux concepts du domaine – pour aider les développeurs à atteindre un niveau de compréhension minimal, organiser un séminaire sur les activités du client, sa terminologie, et les objectifs du produit à concevoir
M2 GLRE - IT-SIGL 2008 2009 72
Qualité des exigences (1)
Niveau de satisfaction des acteurs lorsque les exigences sont respectées par le système
• Difficile à évaluer avant que le système existe
• Différents acteurs ont des vues différentes, voire contradictoires, sur le système situation encore plus délicate
• On se focalise sur quelques aspects de la qualité des exigences : les facteurs de qualité
M2 GLRE - IT-SIGL 2008 2009 73
Qualité des exigences (2)Les exigences ne doivent pas être mélangées avec
d'autres types d'information. Un mélange n'est pas un défaut, mais peut déclencher des défauts.
Séparer exigences et connaissance du domaine : séparer la description
• de la partie de l'environnement indépendante du logiciel • de la partie sur laquelle il a un effetSéparer les exigences et la conception• éviter de présenter comme exigences ce qui relève de la
conception ou du développement• étudier comme exigences tout ce qui traite des effets sur
l'environnement, pour ne pas les traiter dans les phases de conception et développement
M2 GLRE - IT-SIGL 2008 2009 74
Facteurs de qualité des exigences
La spécification globale des exigences doit être
• complète• cohérente• traçable• non redondante• organisée• conforme aux standards
L'énoncé d'une exigence particulière doit être• complet• correct• non ambigu• faisable• nécessaire• priorisé• vérifiable• concis
M2 GLRE - IT-SIGL 2008 2009 75
Pas d'ambiguïtéTous les lecteurs de
l'expression d'une exigence doivent parvenir à une interprétation unique et cohérente.
Ambiguïtés usage incontrôlé des quantificateurs "tous" et "chaque"Ex : toutes les lumières de chaque pièce doivent avoir un seul interrupteur• chaque lumière doit avoir son interrupteur• toutes les lumières de chaque pièce doivent partager le même
interrupteurAmbiguïté interférence entre énoncés de plusieurs exigences
M2 GLRE - IT-SIGL 2008 2009 76
ComplétudePour les énoncés individuels• chaque exigence fonctionnelle doit décrire complètement
la fonctionnalité à laquelle elle est associéePour la spécification• il ne doit manquer aucune exigence
M2 GLRE - IT-SIGL 2008 2009 77
Correction - NécessitéCorrectionchaque exigence fonctionnelle doit
décrire précisément la fonctionnalité qu'elle induit et doit correspondre aux intentions de l'acteur qui en est le détenteur
Nécessitéchaque exigence doit décrire une
capacité dont les clients ont vraiment besoin ou qui est requise par souci de conformité à une norme ou un système extérieur.
M2 GLRE - IT-SIGL 2008 2009 78
CohérenceLes exigences ne doivent pas entrer en conflit
avec d'autres exigences de même type, ou avec des exigences de plus haut niveau, système ou utilisateur
M2 GLRE - IT-SIGL 2008 2009 79
FaisabilitéIl doit être possible d'implémenter les exigences avec
les moyens connus les limitations du système et de l'environnement connus, dans le cadre du budget et du temps impartis au projet
M2 GLRE - IT-SIGL 2008 2009 80
… et les autres …Chaque exigence• priorisée• vérifiable : il faudrait élaborer des tests ou utiliser des
approches de vérification pour déterminer si le produit implémente correctement chaque exigence
• concise
L'ensemble des exigences• traçable : de leur source jusqu'au code et aux tests• non redondant : pas de répétition d'exigence• organisé : la structure doit être "sensée"• conforme aux standards
M2 GLRE - IT-SIGL 2008 2009 81
les 3 dimensions du modèle de Pohl (1996)
Représentation
trace du processus
Accord
vues personnelles
vue commune
informel formel
complète
opaque
Spécification
convenable
semi-formel
3 qualités de base : 2. complète3. acceptée, 4. bien représentée3 Dimensions6. Spécification
– complète7. Accord
– correcte– cohérente– faisable– nécessaire– priorisée
8. Représentation– non ambiguë– concise– traçable– non redondante– organisée– conforme aux
standards– vérifiable
M2 GLRE - IT-SIGL 2008 2009 82
Complétude : le plus grand facteur de risque"les manquants" • les plus durs à corriger (Glass, 2003)• les plus durs à détecterSpécification d'une exigence
= interface système – environnement= combinaison des interfaces système – acteur (Carson)
complétude =• toutes les interfaces avec les acteurs ont été identifiées et
sont quantifiables pour toutes les phases pertinentes du cycle de vie et leur modes d'exploitation associés
identifier d'abord tous les acteurs• toutes les conditions d'interface avec tous leurs paramètres
ont été analysées et collectées pour toutes les exigences système
identifier toutes les combinaisons possibles de conditions pour toutes les interfaces avec les acteurs
M2 GLRE - IT-SIGL 2008 2009 83
Identifier tous les acteursLes 4 mondes de Pohl, (Pohl,1996)• le monde du sujet : acteurs du domaine à
propos duquel le système traite de l'information• le monde de l'usage : acteurs qui possèdent ou
utilisent le système, directement ou indirectement
• le monde du système comprend le système logiciel et matériel et les responsables de son entretien
• le monde du développement est le lieu du processus de développement du système d'information
Mondes de Pohl = cadre pour démarrer l'identification des acteurs
Certains peuvent facilement échapper à la liste
M2 GLRE - IT-SIGL 2008 2009 84
Un cadre pour classifier les acteursClassification à 3 dimensions (Preiss et Wegmann, 2001)
• Domaine d'enquête : phases du cycle de vie du système - au minimum– domaine du développement – domaine de l'exploitation
• Niveau du système : système en jeu ou un des systèmes englobants (supra-système)– Domaine du "développement"
• système = "le projet de développement"• supra-système = société de développement ou environnement de
développement, inclut tous les facteurs externes affectant le projet– Domaine de l'"exploitation"
• système = logiciel proprement dit, • supra-systèmes = organisation qui l'utilise
• Objectifs ou Moyens– acteurs "d'objectifs" comportement perceptif du système– acteurs "de moyens" moyens pour le système d'atteindre ses
objectifs
M2 GLRE - IT-SIGL 2008 2009 85
Un cadre pour classifier les acteurs
•Gouvernement•Police…
DirectionEquipe de maintenanceMoyens
CitoyensPropriétairesUtilisateursObjectifs
Supra-système 2 :la société
Supra-système 1 :l'organisation
Système :le logiciel
Dirigeants de la sociétéDéveloppeursMoyensPropriétaires de la sociétéCommanditaireObjectifs
Supra-système :la société de développement
Système :le projet
Domaine du développement
Domaine de l'exploitation
Exemple
M2 GLRE - IT-SIGL 2008 2009 86
Couvrir toutes les combinaisons de conditions
Difficile de recommander une démarche…2 problèmes fréquents :• une des occasions les plus courantes de
manquer une condition est d'utiliser les quantificateurs "tous", "toujours", "aucun", "jamais" dans une exigence
• les exigences exclusives ou négatives, ce que le système ne doit pas faire, sont rarement spécifiées
