![Page 1: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/1.jpg)
«SEG 3501»
D. Amyot uOttawa
SEG 3601- Module 3
Analyse, modélisation et spécification des exigences
(introduction)Basé en partie sur du matériel de
K.E. Wiegers, D. Leffingwell & D. Widrig, P. Heymans, M. Jackson, I.K.
Bray, D. Berry, J. Atlee, B. Selic, G.
Mussbacher
![Page 2: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/2.jpg)
«SEG 3501»
D. Amyot uOttawa
Module 3 : Analyse et spécification des exigences 2
Analyse des exigences
• Le processus qui consiste à étudier et à analyser les besoins des parties prenantes pour en arriver à une définition des du domaine du problème et des exigences du système (ou logicielles)
• L’analyse va souvent de pair avec la modélisation
![Page 3: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/3.jpg)
«SEG 3501»
D. Amyot uOttawa
Objectifs de l’analyse
• Découvrir les frontières du système/logiciel et comment il doit interagir avec son environnement
• Détecter et résoudre les conflits entre exigences (des utilisateurs)
• Négocier les priorités des intervenants• Élaborer les exigences du système pour en dériver les exigences logicielles utiles pour les gestionnaires (estimés réalistes) et les développeurs (implémentation et test)
• Classifier les exigences• Évaluer les exigences par rapport aux qualités désirables
• S’assurer que rien n’est oublié
Module 3 : Analyse et spécification des exigences 3
![Page 4: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/4.jpg)
«SEG 3501»
D. Amyot uOttawa
Module 3 : Analyse et spécification des exigences 4
Analyse des exigences
Élicitation
Analyse
Notes d’élicitation
Questions et pointsà considérer
Documents d’exigences
![Page 5: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/5.jpg)
«SEG 3501»
D. Amyot uOttawa
Modélisation des exigences
• Aussi une tâche essentielle de la spécification des exigences― Mène à une forme plus précise des éléments recueillis lors de
l’élicitation― Aide à mieux comprendre le problème― Aide à trouver ce qui reste à discuter
• Différents langages de modélisation― Informels (langage naturel)― Orientés-buts (GRL)― Modélisation fonctionnelle
– UML (Unified Modeling Notation)– SDL (Specification and Description Language)– Logique (Z, CTL et autres logiques temporelles…)– UCM (Use Case Map)– …
Module 3 : Analyse et spécification des exigences 5
![Page 6: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/6.jpg)
«SEG 3501»
D. Amyot uOttawa
Validation et vérification des exigences
•Doivent être faites à toutes les étapes du processus d’ingénierie des exigences― Élicitation
– Vérifier auprès des sources d’élicitation– « Donc, vous dites que… ? »
― Analyse– Vérifier que la description du domaine et que celle
des exigences sont correctes― Spécification
– Vérifier que les exigences définies pour le système vont satisfaire les exigences des intervenant lorsque les hypothèses sur le domaine et l’environnement sont vraies
– Vérifier que les exigences et les documents soient bien formés (règles, gabarits…)
Module 3 : Analyse et spécification des exigences 6
![Page 7: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/7.jpg)
«SEG 3501»
D. Amyot uOttawa
L’utilisation des modèles
Module 3 : Analyse et spécification des exigences 7
![Page 8: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/8.jpg)
«SEG 3501»
D. Amyot uOttawa
Module 3 : Analyse et spécification des exigences 8
•Selon Bran Selic, un modèle est une représentation réduite (simplifiée, abstraite) d'un (aspect d'un) système qui sert à:―aider à comprendre un problème et/ou
une solution complexe(s)―communiquer des informations sur le
problème/la solution―diriger l'implémentation
•Qualités d’un bon modèle―Abstrait, compréhensible, précis, prédictif,
peu coûteux…
Modèles
![Page 9: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/9.jpg)
«SEG 3501»
D. Amyot uOttawa
Module 3 : Analyse et spécification des exigences 9
Représentations de modèles• Langue naturelle (français)
+ Pas d’apprentissage spécial nécessaire- Ambigüe, verbeuse, imprécise, obscure…- Pas d’automatisation
• Notation ad hoc (bubbles and arrows)+ Pas d’apprentissage spécial nécessaire- Pas de syntaxe formellement définie, ambigüe - Pas d’automatisation
• Notation semi-formelles (URN, UML…)+ Syntaxe (graphique) bien définie+ Interprétation commune partielle, raisonnablement simple
à apprendre+ Automatisation partielle- Sémantique incomplète, toujours un risque d’ambigüités
• Notation formelle (SDL, Réseaux de Pétri, LOTOS, …)+ Syntaxe et sémantique bien définies+ Grande automatisation (analyse et transformations)- Difficile à apprendre et à comprendre
![Page 10: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/10.jpg)
«SEG 3501»
D. Amyot uOttawa
•Les langages informels sont mieux compris par un vaste éventail d’intervenants― Bons pour les exigences utilisateurs, les contrats― Mais: manque de précision― Possibilité d’ambigüités― Manque d’outils d’analyse
•Les langages formels sont plus précis― Moins de problèmes d’ambigüités― Outils (p.ex., vérification et transformations)― Pour les spécialistes (développeurs, testeurs…)― Mais à portée limitée
Représentations de modèles (2)
Module 3 : Analyse et spécification des exigences 10
![Page 11: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/11.jpg)
«SEG 3501»
D. Amyot uOttawa
Module 3 : Analyse et spécification des exigences 11
Modélisation de la structure
•Concepts d’entités et de relations. Utilisez l’une des notations suivantes:― Diagrammes entités-relations (ERD)― Diagrammes de classe UML
•Peuvent être utilisés pour modéliser:― le domaine du problème (aussi appelé le
« modèle du domaine »)– Même les systèmes présents et futurs
― Les structures de données― Les données emmagasinées (bases de
données)― La conception architecturales du système futur
![Page 12: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/12.jpg)
«SEG 3501»
D. Amyot uOttawa
Modélisation des entrées et sorties
•Nature des entrées et sorties (E/S):― E/S reliées au problème (données du problème)― Données additionnelles reliées à la solution
– P.ex., options des utilisateurs, messages d’erreurs…
•Regroupées dans un dictionnaire de données― Texte simple (langage naturel)― EBNF― Pseudo-code― Logique (p.ex., Z, CTL…)― …
•Sorties graphiques (écrans, formulaires)― Dessins iconiques, écrans/formulaires prototypes,
affichages produits par prototype opérationnel…
Module 3 : Analyse et spécification des exigences 12
![Page 13: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/13.jpg)
«SEG 3501»
D. Amyot uOttawa
Modélisation du comportement dynamique
• Représentations― Texte (simple, description des fonctions, cas d’utilisation)― Tables de décision ― Diagrammes d’activités UML / Use Case Maps― Machines à états finis
– Machines à états simples (FSM) : diagrammes d’états ou tableau de transitions
– Machines à états étendus (EFSM): diagrammes d’états UML, SDL
– State Charts de Harel (intégrés dans UML)– Réseaux de Pétri
― Logique (p.ex. Z, B, CTL) , pour décrire des assertions due les entrées et sorties, et possiblement sur les états internes des objets modifiés par les opérations
• Il est important de choisir ce qui est le plus approprié pour le système― Pas de « one size fits all »!
Module 3 : Analyse et spécification des exigences 13
![Page 14: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/14.jpg)
«SEG 3501»
D. Amyot uOttawa
Module 3 : Analyse et spécification des exigences 14
Analyse de modèles
• Par construction― On apprend le système en s’interrogeant et en le
décrivant• Par inspection
― Exécution mentale― Fiable?
• Par analyse formelle― Nécessite une sémantique formelle (mathématique)― Fiable (en théorie), mais coûteux pour certaines
approches et certains problèmes• Par expérimentation
― Exécution, simulation, animation, test…― Requiert une sémantique définie er des outils de
simulation― Plus fiable que l'inspection pour certains aspects― Contact "direct", possible d’interagir (prototype)
![Page 15: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/15.jpg)
«SEG 3501»
D. Amyot uOttawa
Module 3 : Analyse et spécification des exigences 15
Analyse: Quelques approches typiques
•Analyse structurée (1970)•Analyse orientée-objet (1990)•Cadres de problèmes (Problem Frames, 1995)
•Analyse basée sur les machines à états•Analyse de conflits
― Avec cas de mésusage― Avec modèles GRL/UCM (en laboratoire)
• Il est important de distinguer:― La notation utiliser pour définir le modèle― Le processus par lequel le modèle est créé
![Page 16: «SEG 3501» D. Amyot uOttawa SEG 3601- Module 3 Analyse, modélisation et spécification des exigences (introduction) Basé en partie sur du matériel de K.E](https://reader036.vdocuments.pub/reader036/viewer/2022062404/551d9dd5497959293b8e5de5/html5/thumbnails/16.jpg)
«SEG 3501»
D. Amyot uOttawa
Module 3 : Analyse et spécification des exigences 16
Tous les modèles sont faux, mais quelques modèles sont
utiles...
George Edward Pelham Box (1919-)