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

  • 27
  • 0
  • 0
Afficher les détails des licences
Licence et utilisation
Gratuit pour un usage personnel Attribution requise
Partager
  • Détails
  • Publié le Dec 31, 2021
  • Catégorie Management
  • Langue French
  • Taille du fichier 0.4529MB