GL - 2 2.3 Ingénierie des Exigences Lydie du Bousquet Lydie.du-bousquet@imag.fr
GL - 2 2.3 Ingénierie des Exigences Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda, Y. Ledru 2 Plan Introduction Exigences Fonctionnelles Non-fonctionnelles Traçabilité des exigences Ingénierie des exigences Phase d’analyse et techniques Spécification d’exigences Conclusion 3 Exigences Objectifs Établir ce que souhaite le client Spécifier ces exigences Analyse Modèles du système Modèles du système Exigences Exigences Stakeholders Appel d’offre Appel d’offre 4 Différentes exigences Les exigences ont une double fonction Pour une réponse à un appel d’offre – doit être ouvert à une interprétation Pour le contrat lui-même – doivent être définies en détail Appel d’offre et cahier des charges : exigences Appel d’offre Appel d’offre Cahier des charges Cahier des charges 5 L’origine des exigences Les exigences proviennent du côté client Utilisateur, experts du domaine, managers, marketing,… Reformulées par la maîtrise d’œuvre Analyste Appel d’offre Appel d’offre Analyste Spécifications Spécifications Utilisateur Marketing Manager 6 Acteurs Plusieurs parties, différents besoins managers et preneurs de décision experts du domaine clients et utilisateurs analystes architecte et développeurs Points de vue divergents 7 Impact des exigences Impact légal Base pour le contrat entre client et maîtrise d’œuvre Impact économique Coût de correction dues des exigences incorrectes Impact social Des exigences incorrectes peuvent conduire à des désastres Impact du point vue de l’usage Acceptation ou rejet d’un logiciel 8 De l’importance des exigences Les exigences influent toutes les phases de développement Architecture Conception (design) Définition des tests Acceptation (recette), … Les use cases (cas d’utilisation UML) peuvent être utilisés pour dériver des tests 9 Très difficile de formuler un ensemble complet et consistent d’exigences Les clients ne savent pas toujours ce qu’ils veulent Les souhaits des clients évoluent Il existe des conflits internes Certains problèmes ne peuvent être complètement capturés/compris. La compréhension évolue avec le développement Clients et maîtrise d’œuvre parlent différents langages Il faut gérer une grande masse d’information 10 Problèmes possibles incomplétude inconsistance inadéquation ambiguïté non intelligibilité faible structure sur spécification 11 Plan Introduction Exigences Fonctionnelles Non-fonctionnelles Traçabilité des exigences Ingénierie des exigences Phase d’analyse et techniques Spécification d’exigences Conclusion 12 Qu’est-ce qu’une exigence ? Description d’une capacité ou d’une contrainte un service offert par le logiciel une contrainte sous laquelle il doit opérer ou doit être développé Exprime Tout ce que le client veut Tout ce qui est nécessaire pour le développement du logiciel 13 Attention Ne pas confondre le « quoi » et le « comment » 14 Exigences fonctionnelles Services offerts Description d’une fonction ou son comportement Une propriété générale du système IHM attendue, … Exemples Le logiciel doit gérer le système de prêt de la bibliothèque Un abonné doit payer 20 euros par ans Le logiciel doit afficher la liste des emprunts pour un abonné, … 15 Contraintes (exigences non fonctionnelles) Une contrainte sous laquelle un logiciel doit fonctionner ou être développé Qualité Performance Fiabilité Utilisabilité Maintenabilité Développement COTS (OS, middleware, …) Méthodes Outils Standards Domaine Usage Lois 16 Plusieurs niveaux d’abstraction Exprimables sous la forme d’expression de haut niveau à l’expression sous la forme de spécification formelle détaillée Trois niveaux abstraction Exigences relatives au domaine (besoins) Exigences relatives à l’utilisateur Exigences relatives au système 17 Exigences domaine/utilisateur/système Les besoins (exigences relatives au domaine) Les propriétés d’un domaine influencent une large gamme de logiciels Écrits par les clients Exigences utilisateur Services offerts et contraintes opérationnelles Décrites en langue naturelle et avec des diagrammes Écrites pour les clients Exigence système Document structuré détaillant les descriptions des services systèmes offerts Contrat entre les parties 18 Exemples Besoins (Exigences relatives au domaine) 1. Le système doit gérer les accords de "copyright" Exigences relatives à l’utilisateur 1. Le système devra garder trace de toutes les données nécessaires à la gestion du "copyright" 19 Exemples Exigences système 1.1. pour toute requête, l’utilisateur doit remplir un formulaire avec son nom et sa demande 1.2. les formulaires doivent être sauvegardés 5 ans 1.3. Les formulaires doivent être indexés par utilisateur, par document demandé et par fournisseur 1.4. Le système doit maintenir un log de toutes les requêtes 1.5. Pour les documents avec droit d'auteur, un détail des sommes dues sera envoyé chaque mois 20 Exigences système Exigences utilisateur Besoins Manager Utilisateur Développeurs Niveaux d’abstraction 21 Propriétés des exigences : Une exigence doit être Concise Non ambiguë Compréhensible par l’utilisateur et la maîtrise d’œuvre Structurée Vérifiable Les exigences doivent être écrites de telle sorte qu’elles doivent être compatibles avec les méthodes de vérification qui peuvent être utilisées 22 Plan Introduction Exigences Fonctionnelles Non-fonctionnelles Traçabilité des exigences Ingénierie des exigences Phase d’analyse et techniques Spécification d’exigences Conclusion 23 Objet, fonction et état – Davis, 93 Une exigence fonctionnelle concerne … un objet Un abonné est identifié par son nom et sa date de naissance ou une fonction liée au logiciel Un abonné peut emprunter 5 livres ou un état Un livre est disponible, emprunté ou perdu ou plusieurs de ces éléments en même temps 24 Objets – Davis, 93 Un objet est une entité clairement définie dans le domaine considéré Correspond à un concept du métier, pas à un concept d’implantation Seulement les concepts ayant un sens pour le logiciel ≠ d’une analyse du domaine Les exigences spécifient des objets et limitent leurs portées « Le système doit afficher le nom de l’abonné » « Un abonné peut emprunter 5 livres et 2 revues » « les livres ont un titre et un ou plusieurs auteurs » 25 Fonctions – Davis, 93 Activités clairement définies dans le domaine Tâches, services, processus On se limite aux fonctions réalisées par le logiciel (suite à une action utilisateur ou à un événement) Les exigences spécifient des fonctions et les détaillent « Le système peut afficher le nom des abonnés » « Le système effectue les emprunts des abonnés ayant droit » « Le système autorise les emprunts pour 5 semaines » 26 États – Davis, 93 Caractérise une situation d’une entité Peut s’exprimer sous la forme d’un prédicat Qui influence le comportement de cette entité Aspect temporel important L’état peut être transitoire Il peut capturer un certain historique Certaines exigences spécifient des états et les détaillent Un livre peut être disponible, emprunté ou perdu Un client est caractérisé par le nombre de livres empruntés Un client est caractérisé par sa situation vis à vis du paiement de l’abonnement 27 Objets, fonctions, états Certaines exigences établissent des relations entre les objets, les fonctions et les états Un client peut emprunter un livre quand il a payé son abonnement et s’il a moins de 5 prêts en cours Les méthodes d’analyse se concentrent sur un aspect Objet Fonction État 28 Questions à poser – Pfleeger Fonctionnalités Qu’est-ce que le système va faire ? Quand le système devra-t-il le faire ? Existe-t-il plusieurs modes de fonctionnement ? Quelles sont les bonnes réactions aux stimuli possibles ? Données Quel doit être le format des données ? Combien de temps les données doivent-elles être conservées ? 29 Plan Introduction Exigences Fonctionnelles Non-fonctionnelles Traçabilité des exigences Ingénierie des exigences Phase d’analyse et techniques Spécification d’exigences Conclusion 30 Quantification Exigences NF sont liées aux propriétés globales qui sont difficiles à vérifier (dans leur première formulation) Non précises, plusieurs interprétations possibles “Le système doit être facile à utiliser” Source de conflits “Le système doit être robuste et performant” Il est nécessaire de quantifier ces exigences Avec des métriques qui peuvent être mesurées, testées 31 Exemple Première formulation Le système doit être facile à utiliser pour un contrôleur expérimenté et doit être organisé pour limiter le nombre d’erreur. Reformulation Un contrôleur avec plus de 5 ans d’expérience doit être capable d’utiliser le système après une formation de 2 heures. A l'issue de cette formation, le nombre moyen d'erreurs ne doit pas dépasser deux par jour. 32 Performance Questions à poser Quelles sont les contraintes sur la vitesse d’exécution, le temps de réponse, ou le uploads/Management/ 2-3-exigences-2semaines-pdf.pdf
Documents similaires










-
27
-
0
-
0
Licence et utilisation
Gratuit pour un usage personnel Attribution requise- Détails
- Publié le Dec 31, 2021
- Catégorie Management
- Langue French
- Taille du fichier 0.4529MB