Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Ingénierie des exigences https://standards.ieee.org/standard/29148-2018.html ht

Ingénierie des exigences https://standards.ieee.org/standard/29148-2018.html https://meritis.fr/lingenierie-des-exigences-au-secours-de-la-gestion-des-user- stories/ http://membres-lig.imag.fr/dubousquet/docs/2.3_Exigences-2semaines.pdf Définition L’ingénierie des exigences est une discipline qui consiste à développer un référentiel d’exigences, mais aussi à le maintenir à jour en présence d’évolutions. Les exigences définissent le système à construire et à améliorer. Dans un sens plus large, les systèmes peuvent correspondre à n’importe quel logiciel, unité commerciale ou même à toute une organisation. De plus, les exigences sont des énoncés exprimant les besoins et les contraintes des clients, concernant le fonctionnement du système, de manière formalisée. Les exigences sont normalement écrites sur un ton impératif. La norme ISO / IEC / IEEE 29148 utilise l’expression ‘‘The system shall…’’ qui est la manière recommandée pour rédiger les exigences. Par exemple : « L’application doit être accessible via différentes plates-formes ». Les exigences peuvent également être affinées pour améliorer leur sémantique et pour énoncer explicitement les besoins et les désirs du client. En effet, les exigences peuvent être affinées en sous-exigences, ce qui clarifie les principales idées qui sous-tendent l’exigence parent. I. Processus Le processus d’ingénierie des exigences peut être décliné sous 6 étapes : • Étude de faisabilité • Analyse • Définition des exigences • Spécification • Vérification, validation • Gestion du changement I.1. Étude de faisabilité • Se fait via des études courtes et focalisées • Pour répondre aux questions : ➢Le système répond-t-il aux objectifs business ➢Le système peut-il être développé avec les techniques actuelles ? ➢Le nouveau système pourra-t-il être intégré aux systèmes existants ? ➢Peut-on utiliser les outils disponibles ? • Document en entrée : appel d’offre • Document en sortie : rapport avec recommandations I.2. Analyse • Pour collecter les données sur le logiciel ➢Comprendre le domaine de l’environnement ➢Identifier les objectifs et les conflits • L’analyse est une phase ouverte ➢Impliquer autant de stakeHolders que possible ➢Éviter les idées préconçues ➢Attention à l’autocensure ➢Attention à l’apparente simplicité des objectifs et des besoins I.3. Définition des exigences • But de confronter les stakeHolders avec les exigences possibles et établir une liste d’exigences valides. Elle se fait par la : ➢ Comparaison d’options alternatives ➢Résolution de conflits ➢Négociation des meilleurs compromis ➢Et doit permettre d’Obtenir un agrément partagé • C’est une phase de « fermeture » ➢Regroupement des stakeHolders ➢Réduction des exigences à un cœur faible I.4. Spécification des exigences • But de définir clairement le logiciel à produire ➢Via une Documentation compréhensible par toutes les parties → base contractuelle • Phase de synthèse ➢Écriture des exigences ➢Structuration des exigences (type, niveau d’abstraction) ➢Vérification de la consistance, complétude, … ➢Assignation de priorités possible ➢Validation I.5. Validation des exigences • Complétude • Consistance • Adéquation • Précision • Pertinence • Compréhensibilité • Bonne structuration • Modifiabilité • Traçabilité • Mesurabilité I.6. Gestion du changement • On ne peut pas empêcher l’évolution des exigences • Elle n’est Possible que si le travail initial de collecte, d’analyse et de validation a été fait de façon rigoureuse • II. Exigences fonctionnelles • Il s’agit des Services offerts ➢ca peut etre Description d’une fonction ou son comportement ➢ou alors Une propriété générale du système • Exemples ➢Le logiciel doit gérer le système de prêt de la bibliothèque ➢Un abonné doit payer 20 euros par an ➢Le logiciel doit afficher la liste des emprunts par abonné, … III. Exigences non-fonctionnelles • Ce sont les contraintes sous lesquelles un logiciel doit fonctionner ou être développé • contraintes sur la qualité : performance, fiabilité, utilisabilité et maintenabilité, ... • relatives au développement : os, méthodes, outils, standards, ... • relatives au domaine : usage, lois, ... III.1. Niveaux d’abstraction • Exigences relatives au domaine (besoins) ➢ Les propriétés d’un domaine influencent une large gamme de logiciels ➢ Écrits par les clients • Exigences relatives à l’utilisateur ➢ Services offerts et contraintes opérationnelles ➢ Décrites en langue naturelle et avec des diagrammes ➢ Écrites pour les clients • Exigences relatives au système ➢ Document structuré détaillant les descriptions des services systèmes offerts ➢ Contrat entre les parties IV. Outils pour l’ingénierie des exigences • Création des exigences • Traçabilité des exigences • Lien avec les outils de test (UML par exemple) • Génération de documents • Parmi les plus utilisés sont : ➢DOORS (Telegoric) ➢RequisitePro (IBM/Rationale) ➢AnalystPro (Goda Software) //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// • permet Évaluer les impacts des exigences ➢Grace a des Mécanismes de traçabilité • Outil nécessaire ➢Au moins d’automatisation de la gestion des liens de traçabilité • Problèmes liés à l’évolution des exigences ➢Évolution sans analyse d’impact ➢Modification par la hiérarchie ➢Nouveaux stakeHolders (très fréquent) ➢Pas de formalisme, de processus pour l’évolution ➢Faible traçabilité ➢Un bon processus initial ne suffit pas : besoin d’un processus de gestion d’évolution uploads/Management/ mouhamadou-lamine-gueye.pdf