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

Module 3 : Analyse et spécification des exigences 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 Module 3 : Analyse et spécification des exigences

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

Analyse des exigences Élicitation Analyse Notes d’élicitation Questions et points à considérer Analyse Documents d’exigences Module 3 : Analyse et spécification des exigences

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

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

L’utilisation des modèles Module 3 : Analyse et spécification des exigences

Module 3 : Analyse et spécification des exigences Modèles 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… Module 3 : Analyse et spécification des exigences

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 de syntaxe formellement définie, ambigüe 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 Module 3 : Analyse et spécification des exigences

Représentations de modèles (2) 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 Module 3 : Analyse et spécification des exigences

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 Module 3 : Analyse et spécification des exigences

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

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

Module 3 : Analyse et spécification des exigences 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) Module 3 : Analyse et spécification des exigences

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éé Module 3 : Analyse et spécification des exigences

Tous les modèles sont faux, mais quelques modèles sont utiles... George Edward Pelham Box (1919-) Module 3 : Analyse et spécification des exigences