SEG Module 1 Fondements de l'ingénierie des exigences

Présentation au sujet: "SEG Module 1 Fondements de l'ingénierie des exigences"— Transcription de la présentation:

1 SEG 3501- Module 1 Fondements de l'ingénierie des exigences
Objectifs: Définition(s) et importance Types d'exigences Place dans le processus de développement Activités principales

2 Le début est la partie la plus importante du travail.
Platon, 4 avant J.C. Partie 1 : Introduction à l'ingénierie des exigences

3 Partie 1 : Introduction à l'ingénierie des exigences
Mars Climate Orbiter En 1999 le « Mars Climate Orbiter » disparait alors qu’il débute son orbite autour de Mars. Coût: environ 125 millions de dollars US. Problème causé par une erreur de transfert d’information entre une équipe au Colorado et une en Californie. Une équipe utilisait le système de mesure anglais (pouces, pieds, livres…) alors que l’autre utilisait le système métrique pour une fonction clé de l’appareil… Partie 1 : Introduction à l'ingénierie des exigences

4 GIRES (Gestion intégrée des ressources)
GIRES touchera : plus de 1000 systèmes ministériels existants plus de employés de l’État près de 140 ministères et organismes Projet de 8 ans du gouvernement du Québec, commencé en 1998. Budget: 80 millions de dollars. Difficultés à gérer le changement. Après 5 ans, les coûts avoisinent les 400 millions de dollars et les retards s'accumulent.. Le projet est abandonné en 2003 Partie 1 : Introduction à l'ingénierie des exigences

5 Programme canadien de contrôle des armes à feux
But: Réduire le crime en suivant la circulation des armes Ce fameux programme devait coûter 2 millions de dollars. (119M$ de coûts, 117M$ de revenus) C’est ce qu’on disait aux contribuables, lors de l’adoption de la loi C-68 en 1995. Partie 1 : Introduction à l'ingénierie des exigences

6 Partie 1 : Introduction à l'ingénierie des exigences
Quelque dérapages… 85 M$ en 1995, 327 M$ en 2000, 699 M$ en 2002, 1000 M$ en 2005… Pressions politiques des lobbyistes, payeurs de taxes, propriétaires d’armes, corps policiers… Plusieurs imprévus sans relation à l’informatique: Frais de bataille juridique Scandales au niveau des achats de matériel Frais de voyage indécents et autres frais obscurs... Et plusieurs reliés à l’informatique! 30 permis différents, long formulaires (jusqu'à huit pages) qui changent souvent. 90 % d'erreurs ou d'omissions sur les demandes de permis… Utilisabilité? Le client, le Centre des armes à feu, a demandé 2000 changements informatiques Partie 1 : Introduction à l'ingénierie des exigences

7 Partie 1 : Introduction à l'ingénierie des exigences
Et ça dérape encore Après la tentative de EDS (qui avait déjà échoué avec GIRES), les firmes CGI et BDP doivent tout recommencer! Un contrat de 300 millions de dollars pour le créer, l'installer et le faire fonctionner. À la surprise de plusieurs, EDS a un nouveau contrat de 115 millions de dollars. Elle aura reçu, au total, 410 millions de dollars. La deuxième version du système (SCIRAF II), commencée en 2003, voit ses coûts passer de 32M$ à 90M$. Près d’un milliard de dollars ont été dépensés (mars 2005), comme l'a révélé la vérificatrice générale, avec les coûts informatiques, les dépenses occultes et les frais courants. Partie 1 : Introduction à l'ingénierie des exigences

8 Partie 1 : Introduction à l'ingénierie des exigences
Résultats Dans son rapport de mai 2006, la vérificatrice générale (Mme Sheila Fraser) déclare: Les exigences de projet n'ont pas été bien définies Les modifications législatives approuvées ont nécessité des modifications plus substantielles des exigences du système et de l'étendue du projet que celles qui avaient été communiquées au départ à l'entrepreneur. La demande de proposition pour le SCIRAF II (2e version), qui a été envoyée à l'automne 2001, ne comprenait pas d'exigences détaillées. L'entrepreneur choisi n'a reçu le cahier des charges qu'après avoir reçu la déclaration d'intention l'avisant qu'il était le soumissionnaire gagnant. Le Centre a dit que la direction avait adopté cette approche afin de susciter des propositions créatives… Tout est mis sur la glace en 2006 avec la venue d’un nouveau gouvernement… 5 années d’amnistie pour les proprios non enregistrés Bill C-391 accepté en avril 2012… Partie 1 : Introduction à l'ingénierie des exigences

9 Module 1 : Fondements de l'ingénierie des exigences

10 Sources principales pour ce module
Jeremy Dick, Elizabeth Hull, Ken Jackson: Requirements Engineering, Springer-Verlag, 2004 Soren Lauesen: Software Requirements - Styles and Techniques, Addison Wesley, 2002 Ian K. Bray: An Introduction to Requirements Engineering, Addison Wesley, 2002 Gerald Kotonya and Ian Sommerville: Requirements Engineering – Processes and Techniques, Wiley, 1998 Roger S. Pressman: Software Engineering A practitioner's Approach Tim Lethbridge and Robert Laganière: Object Oriented Software Engineering: Practical Software Developement using UML and Java, 2nd edition, McGraw-Hill, 2005 Ivy F. Hooks and Kristin A. Farry: Customer-Centered Products – Creating Successful Products Through Smart Requirements Management, Amacom, 2001 CHAOS report, Standish Group SWEBOK 2013 Divers articles des conférences Requirements Engineering et autres sources du Web. Module 1 : Fondements de l'ingénierie des exigences

11 Module 1 Définition(s) et importance
Types d'exigences et place dans le processus de développement Aperçu des activités principales

12 Vous avez dit « exigence »?
Les exigences (parfois appelés requis) décrivent la raison d’être d’un système Les exigences expriment les idées à être incarnées dans un système ou une application en développement Module 1 : Fondements de l'ingénierie des exigences

13 Module 1 : Fondements de l'ingénierie des exigences
Selon la norme IEEE Une exigence (ou requis) est définie comme: une condition ou capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif; une condition ou capacité qui doit être satisfaite ou possédée par un système … pour satisfaire un contrat, une norme, une spécification, ou tout autre document formellement imposé … Module 1 : Fondements de l'ingénierie des exigences

14 Module 1 : Fondements de l'ingénierie des exigences
Selon la norme IEEE 29148 Une exigence est une phrase qui traduit ou exprime un besoin de même que les contraintes et conditions qui y sont associées. Module 1 : Fondements de l'ingénierie des exigences

15 Module 1 : Fondements de l'ingénierie des exigences
Une autre définition Une exigence est un énoncé à propos du système à concevoir avec lequel tous les intervenants impliqués sont en accord et qui doit devenir vrai afin de résoudre adéquatement le problème du client. Information claire et concise Concerne le système Toutes les parties prenantes ont confirmé sa validité Aide à résoudre le problème Un ensemble d’exigences est un cahier des charges ou une spécification des exigences (requirements document). Module 1 : Fondements de l'ingénierie des exigences

16 Vous avez dit «ingénierie des exigences»?
« Activité de développement, élicitation, spécification, analyse, et gestion des exigences des parties prenantes (intervenants, ou stakeholders), qui devront être rencontrées par des systèmes. » L’ingénierie des exigences englobe toutes les activités interdisciplinaires reliées à la détermination, la documentation et le maintien d'un ensemble convenu d'exigences pour un système, et pour les retracer jusqu’à l’implémentation. Module 1 : Fondements de l'ingénierie des exigences

17 Module 1 : Fondements de l'ingénierie des exigences
Selon la norme IEEE 29148 RE is the interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software or service of interest. RE is concerned with discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting, and managing requirements Module 1 : Fondements de l'ingénierie des exigences

18 Ingénierie des exigences
L’I.E. peut être vue comme un ensemble d’activités Pas nécessairement une phase séparée Applicable aux nouveaux systèmes et à ceux en évolution Pas limitée à la partie logicielle Prend en considération le contexte Comment/où le système sera-t-il utilisé La vue d’ensemble est importante Demande d’interagir avec les parties prenantes Qui sont-ils? Comment communiquer et négocier? Traduction entre plusieurs mondes/domaines Y a-t-il une perte de sens/information lors de la traduction? Passerelle vers la conception et les autres étapes. Module 1 : Fondements de l'ingénierie des exigences

19 Ingénierie des exigences
Création Développement des exigences Gestion des exigences Élicitation Analyse Vérification Spécification Larry Boldt, Trends in Requirements Engineering People-Process-Technology, Technology Builders, Inc., 2001 Module 1 : Fondements de l'ingénierie des exigences

20 Plus de détails sur ces activités…
Phase de création Débute le processus (besoin ou opportunité d’affaire, bonne idée…). Dossier commercial, étude de faisabilité, étendue du système, risques, etc. Élicitation des exigences Les exigences sont découvertes en consultant (et parfois même en provoquant) les diverses parties prenantes. Analyse des exigences et négociation Les exigences sont analysées et les conflits résolus, souvent par négociation. Spécification des exigences Un document précis décrivant les exigences est produit. Validation des exigences La spécification des exigences est vérifiée en termes de cohérence et de complétude. Gestion des exigences Les besoins évoluent, les exigences aussi! Module 1 : Fondements de l'ingénierie des exigences

21 Module 1 : Fondements de l'ingénierie des exigences
Vue du SWEBOK ( ) Module 1 : Fondements de l'ingénierie des exigences

22 Problèmes généraux de l’ingénierie des exigences
Manque d’expertise disponible (ingénieurs logiciels, experts de domaines, etc.) Idées initiales trop souvent incomplètes, trop optimistes, et fermement présentes dans les têtes des personnes gérant le processus d’acquisition Les difficultés à utiliser les outils et méthodes complexes et variées associées à la cueillette d’exigences peuvent effacer les bénéfices escomptés d’une approche complète et détaillée Gestion du changement Module 1 : Fondements de l'ingénierie des exigences

23 Statistiques du rapport NIST
En mai 2002, le NIST (National Institute of Standards and Technology) a publié un rapport intéressant sur des statistiques et des expériences basées sur des données provenant d’un grand nombre de projets logiciels 70 % des défectuosités sont introduites lors de la phase de spécification, et 30% plus tard lors de la solution technique Seulement 5% des problèmes de spécification sont corrigés dans la phase de spécification. 95% sont détectés plus tard dans le projet alors que le coût pour les résoudre est en moyenne 22 fois supérieur. Ce rapport conclut que le test exhaustif est essentiel, mais que le test ne permettait de détecter les erreurs de spécification que tard dans le processus de développement. Module 1 : Fondements de l'ingénierie des exigences

24 Pourquoi faire la gestion des exigences?
Distribution des défectuosités Distribution de l’effort pour réparer les défectuosités Code 7% Autres 10% Conception 27% Exigences 56% Code 1% Autres 4% Conception 13% Exigences 82% (Martin & Leffinwell) Module 1 : Fondements de l'ingénierie des exigences

25 Vue du Software Engineering Institute
Le SEI offre une vue alternative sur l’amélioration du processus de développement de logiciels avec le modèle CMM/CMMI. Leur vision est: Le bon logiciel, livré sans défectuosité dans le temps et le budget requis, à chaque fois. « Bon logiciel » implique que le logiciel satisfasse les exigences fonctionnelles et non-fonctionnelles (performance, coût…) tout au long de sa vie. « Sans défectuosité » implique soit du test exhaustif après le codage, soit de développer le logiciel correctement dès la première fois. Module 1 : Fondements de l'ingénierie des exigences

26 Module 1 : Fondements de l'ingénierie des exigences
CHAOS Report, 2004 Module 1 : Fondements de l'ingénierie des exigences

27 Progression depuis 1994 En % (Standish Group Inc., 1994-2009)
Environ projets, sur 14 ans… Note: ces nombres sont cependant critiqués dans: J.L. Eveleens and C. Verhoef, “The Rise and Fall of the Chaos Report Figures”. IEEE Software, 27(1), Jan/Feb 2010, pp Module 1 : Fondements de l'ingénierie des exigences

28 Module 1 : Fondements de l'ingénierie des exigences
Facteurs de succès Standish Group Inc., 2000 Module 1 : Fondements de l'ingénierie des exigences

29 Module 1 : Fondements de l'ingénierie des exigences
Causes des problèmes Module 1 : Fondements de l'ingénierie des exigences

30 Évolution des facteurs de succès
Voir aussi le rapport 2012: Module 1 : Fondements de l'ingénierie des exigences

31 Module 1 : Fondements de l'ingénierie des exigences
Chaos Report, 2012 Module 1 : Fondements de l'ingénierie des exigences

32 Module 1 : Fondements de l'ingénierie des exigences
Facteurs de succès, 2012 Module 1 : Fondements de l'ingénierie des exigences

33 Module 1 : Fondements de l'ingénierie des exigences
Agilité vs. Cascade Module 1 : Fondements de l'ingénierie des exigences

34 Implication des intervenants?
Partie 1 : Introduction à l'ingénierie des exigences

35 Gestion des exigences en évolution
“Changing requirements is as certain as death and taxes” Source: Module 1 : Fondements de l'ingénierie des exigences

36 Module 1 Définition(s) et importance
Types d'exigences et place dans le processus de développement Aperçu des activités principales

37 Tellement d’« exigences » …
Un but est un objectif ou une préoccupation utilisé pour découvrir et évaluer des exigences fonctionnelles et non-fonctionnelles Un but n’est pas encore une exigence.. Une exigence fonctionnelle est une exigence définissant une fonction du système en développement Décrit le quoi, c.-à-d. ce que le système doit faire Une exigence non-fonctionnelle (ou extra-fonctionnelle) est une exigence qui caractérise une propriété ou une qualité désirée du système telle que sa performances, sa robustesse, sa convivialité, sa maintenabilité, etc. Une contrainte qui doit être prise en compte lors du développement Module 1 : Fondements de l'ingénierie des exigences

38 Tellement d’« exigences »… (2)
Une exigence utilisateur est une fonctionnalité ou un but désiré par un utilisateur ou une autre partie prenante Elle ne devient pas nécessairement une exigence du système… Une exigence du domaine d’application (incluant les règles d’affaires) est une exigence dérivée de contraintes physiques ou encore de pratiques d’affaires dans un secteur industriel donné, dans une compagnie donnée, ou définie par des règles et des normes gouvernementales. Peuvent être fonctionnelles ou non-fonctionnelle Module 1 : Fondements de l'ingénierie des exigences

39 Exigences: système vs logiciel
Ensemble de composants inter-reliés collaborant vers un objectif commun Peut inclure des composants mécaniques, électriques, électroniques, logiciels, etc. Ingénierie des systèmes Approche multidisciplinaire pour le développement de systèmes Le logiciel n’est souvent qu’un partie du système, mais souvent une partie problématique! Nous pouvons donc distinguer les exigences du système des exigences des composants logiciels. Module 1 : Fondements de l'ingénierie des exigences

40 Module 1 : Fondements de l'ingénierie des exigences
Note importante L’ingénierie des exigences logicielles est un cas particulier de l’ingénierie des exigences. Plusieurs des sujets vus dans ce cours sont aussi applicables à des systèmes sans logiciels. Dans un système contenant du logiciel, les exigences logicielles sont dérivées des exigences du système. Le matériel (et le système d’exploitation) font partie de l’environnement où le logiciel est utilisé. Module 1 : Fondements de l'ingénierie des exigences

41 Exigences fonctionnelles
Quelles doivent être les entrées du système Quelles sorties le système doit-il produire Quelle sont les données qui devront être stockées pour usage par d’autres systèmes Quels sont les calculs à effectuer La mise en marche et la synchronisation de tous ces éléments Module 1 : Fondements de l'ingénierie des exigences

42 Exemples d’exigences fonctionnelles
Le système doit offrir à l’utilisateur l’opportunité de chercher l’ensemble des bases de données. Le système doit offrir les visionneuses appropriées pour afficher les documents emmagasinés. Chaque commande doit avoir un identifiant unique (ORDER_ID). Module 1 : Fondements de l'ingénierie des exigences

43 Exigences non-fonctionnelles (NFR)
Si elles ne sont pas satisfaites, le système est inutile. Elles peuvent être difficile à décrire, et des exigences imprécises sont difficiles à vérifier à leur tour. Plusieurs taxonomies existent… Module 1 : Fondements de l'ingénierie des exigences

44 Types d’exigences non-fonctionnelles
(Sommerville & Kontoya 1998) Module 1 : Fondements de l'ingénierie des exigences

45 Exigences non-fonctionnelles
Doivent être vérifiables Sinon, elles ne sont que des buts Trois grandes catégories (Lethbridge et Laganière) 1. Catégorie liée à l’usage, l’efficacité, la fiabilité, la maintenance et la réutilisation Temps de réponse Rendement, débit Utilisation des ressources Fiabilité Disponibilité Restauration après pannes Facilité de maintenance et d’amélioration Facilité de réutilisation Module 1 : Fondements de l'ingénierie des exigences

46 Exigences non-fonctionnelles
2. Catégorie liée à l’environnement et à la technologie Plateforme (exigences minimales, matériel, S.E.) Technologie à utiliser (langage, BD, …) 3. Catégorie liée à la planification et à la méthode de développement du projet Processus de développement à utiliser Coût et date de livraison (ces derniers éléments se retrouvent souvent dans le contrat signé par les parties) Module 1 : Fondements de l'ingénierie des exigences

47 Exemples d’exigences non-fonctionnelles
Exigence de sécurité Le système ne doit pas révéler l’information personnelle des clients, à part les noms et numéros de référence aux gestionnaires du système. Exigence de technologie Le système doit supporter l’encodage ISO/CEI (jeu universel de caractères). Exigence de processus Le processus de développement du système aéronautique et les livrables doivent être conforme à la norme DO-178B. Module 1 : Fondements de l'ingénierie des exigences

48 Exigences mesurables (Sommerville & Kontoya 1998)
Module 1 : Fondements de l'ingénierie des exigences

49 Module 1 : Fondements de l'ingénierie des exigences
Buts Les exigences non-fonctionnelles peuvent être difficiles à spécifier précisément, et ces exigences ambigües deviennent difficiles à vérifier. Un but offre une intention ou un objectif général tel que la convivialité de l’application. Les buts peuvent guider la découverte d’exigences non-fonctionnelles vérifiables, qui peuvent être testées objectivement. Module 1 : Fondements de l'ingénierie des exigences

50 Module 1 : Fondements de l'ingénierie des exigences
Exemple de but Un but du système Le système doit être facile à utiliser par des utilisateurs expérimentés et devrait être organisé de façon à minimiser les erreurs d’utilisation. Exigences non-fonctionnelles vérifiables, inférées de ce but (Un utilisateur expérimenté a au moins 2 années d’expérience sur le vieux système) Les utilisateurs expérimentés doivent être capables d’utiliser les fonctions du système après une formation de 3 heures. Le nombre moyen d’erreurs faites par les utilisateurs expérimentés ne doit pas excéder 2 par jour. Module 1 : Fondements de l'ingénierie des exigences

51 Exigences du domaine d’application
Dérivées du domaine d’application Décrivent les caractéristiques du système qui reflètent le domaine Peuvent être de nouvelles exigences fonctionnelles, ou des contraintes sur des exigences existantes Si les exigences du domaine ne sont pas satisfaites, alors le système pourrait être inutilisable. Module 1 : Fondements de l'ingénierie des exigences

52 Exemple d’exigences du domaine d’application
Système de bibliothèque L’interface du système vers les bases de données doit se conformer à la norme Z39.50. À cause de restrictions et de droits d’auteurs, certains documents électroniques devront être détruits immédiatement après réception. Selon les exigences de certains utilisateurs, ces documents pourront d’abord être soit imprimés localement, soit imprimés à une imprimante réseau et récupérés par l’utilisateur. Module 1 : Fondements de l'ingénierie des exigences

53 Autre exemple de domaine d’application
Surveillance de population de phoques Transmetteurs attachés à quelques phoques, pour déterminer leur position Difficile d’attacher un transmetteur (et dangereux!) Projet sur quelques années Problème: la durée de vie des piles est de quelques semaines, alors que le projet dure plusieurs années Options proposées pour le transmetteur: Toutes les 40 minutes pendant 9 mois (4500$) Toutes les 60 minutes pendant 1 an (4500$) Toutes les 40 minutes pendant 2 ans (5500$) Contraintes du domaine… Les transmetteurs sont attachés à la fourrure La fourrure d’un phoque change à tous les 9 mois!!! Module 1 : Fondements de l'ingénierie des exigences

54 Problèmes courants liés au domaine
Compréhension Les exigences sont exprimées dans le langage du domaine d’application. Elles sont souvent incompréhensibles à l’ingénieur logiciel qui développe le système. Exigences implicites Les spécialistes du domaine le comprennent si bien qu’ils ne pensent pas mettre sur papier certaines exigences du domaine. C’est évident! « Assume » Module 1 : Fondements de l'ingénierie des exigences

55 Propriétés émergentes
Propriétés du système tout entier Exigences qui ne s’appliquent pas à un seul composant, mais qui dépendent de la façon dont les composants vont collaborer N’émergent souvent que lorsque les sous-systèmes individuels sont intégrés Dépendent de l’architecture du système Exemples Fiabilité, maintenance, performance, convivialité, sécurité. Module 1 : Fondements de l'ingénierie des exigences

56 Module 1 Définition(s) et importance
Types d'exigences et place dans le processus de développement Aperçu des activités principales

57 Une approche pour l’ingénierie des exigences (Wiegers)

58 Approche par couche typique
Hull, Jackson, Dick: requirements Engineering, 2004 Module 1 : Fondements de l'ingénierie des exigences

59 Exigences et modélisation
Le sandwich de l’ingénierie des systèmes! Module 1 : Fondements de l'ingénierie des exigences

60 De retour au sandwich Hull, Jackson, Dick: Requirements Engineering, 2004 Module 1 : Fondements de l'ingénierie des exigences

61 Avantages des niveaux d’exigences (sandwich)
Concentre l’attention sur la vue d’ensemble avant les détails Réduit le nombre de changements en spécifiant à un niveau plus bas les exigences qui n’affectent rien sauf les exigences à un niveau plus bas Promeut la division du travail Module 1 : Fondements de l'ingénierie des exigences

62 Processus d’I.E. et activités reliées
Pourquoi? Quoi? Comment? Qui? Si-Alors Vraiment? Où? Identifier les besoins et objectifs d’affaires Dériver exigences utilisateur et fonctionnelles Time Concevoir les solutions Temps Processus de gestion de projet Processus de gestion du risque Processus de gestion de la qualité Processus de gestion des composants & configs. Module 1 : Fondements de l'ingénierie des exigences

63 Module 1 : Fondements de l'ingénierie des exigences
I.E. et processus… L’I.E. est un ensemble d’activités mais pas nécessairement une phase séparée. Source: Donald C. Gause, Risk Focused Requirements Management, Tutorial at RE’09, September 2009 Module 1 : Fondements de l'ingénierie des exigences

64 Module 1 Définition(s) et importance
Types d'exigences et place dans le processus de développement Aperçu des activités principales

65 Module 1 : Fondements de l'ingénierie des exigences
Selon la norme IEEE 29148 Requirements elicitation process through which the acquirer and the suppliers of a system discover, review, articulate, understand, and document the requirements on the system and the life cycle processes Requirements validation: confirmation by examination that requirements (individually and as a set) define the right system as intended by the stakeholders. Requirements verification: confirmation by examination that requirements (individually and as a set) are well formed Requirements management: activities that ensure requirements are identified, documented, maintained, communicated and traced throughout the life cycle of a system, product, or service. Software requirements specification: structured collection of the requirements (functions, performance, design constraints, and attributes) of the software and its external interfaces. Module 1 : Fondements de l'ingénierie des exigences

66 Création des exigences (inception)
Débute le processus Identification des besoins d’affaires Nouvelles opportunités de marché Nécessité Idée géniale Implique Création d’un plan d’affaires Étude de faisabilité préliminaire Définition préliminaire de la portée du projet Intervenants Hauts gestionnaires, marketing, gestionnaires de produits, etc. Module 1 : Fondements de l'ingénierie des exigences

67 Élicitation des exigences (1)
Sur le domaine du problème demandant une solution Plus qu’une simple demande ou collecte d’information; il faut évoquer et provoquer Questions devant être posées et répondues Quel est le système? Quels sont ses buts? Comment le travail se fait-il actuellement? Qui sont les intervenants? Quels sont les problèmes? Comment le système résoudra-t-il ces problèmes? Comment le système sera-t-il utilisé dans le quotidien? Qu’est-ce qui ne fera pas partie du système (portée)? Les performances et autres contraintes (p.ex., légales) affecteront-elles la façon dont la solution est approchée? Module 1 : Fondements de l'ingénierie des exigences

68 Élicitation des exigences (2)
Aperçu de différentes sources Clients et autres intervenants Systèmes existants Documentation Experts du domaine Autres… Aperçu de différentes techniques Remue-méninge Entrevues Observations de tâches Cas d’usage et scénarios Prototypage Module 1 : Fondements de l'ingénierie des exigences

69 Élicitation des exigences (3)
[ISO/IEC/IEEE 29148:2011] Module 1 : Fondements de l'ingénierie des exigences

70 Élicitation des exigences (4)
Module 1 : Fondements de l'ingénierie des exigences

71 Module 1 : Fondements de l'ingénierie des exigences
Analyse des exigences Le processus qui consiste à étudier et à analyser les besoins des parties prenantes pour en arriver à une définition des exigences (logicielles). Mène à une solution pouvant impliquer: Une nouvelle structure des flux de travaux Un nouveau système (to-be, domaine de la solution) Objectifs Découvrir les frontières du système/logiciel et comment il doit interagir avec son environnement Détecter et résoudre les conflits (par négociation) Élaborer les exigences du système pour en dériver les exigences logicielles. L’analyse va souvent de pair avec la modélisation Module 1 : Fondements de l'ingénierie des exigences

72 Spécification des exigences
L’invention et la définition du comportement d’un nouveau système (domaine de la solution) qui va produire les effets désirés dans le domaine du problème. L’analyse des exigences a déjà défini le domaine du problème et les effets requis. Plusieurs formats et gabarits pour les documents de spécification Module 1 : Fondements de l'ingénierie des exigences

73 Validation et vérification des exigences
Techniques variées Vérifications simples Exigences bien formées, checklists Révision formelle Inspection de Fagan, révision active Analyse logique Simulation/test, model checking, preuves Prototypes Jetables ou évolutifs Conception de tests fonctionnels (TDD) Développement du manuel de l’utilisateur Module 1 : Fondements de l'ingénierie des exigences

74 Validation vs Vérification
Module 1 : Fondements de l'ingénierie des exigences

75 Module 1 : Fondements de l'ingénierie des exigences
Gestion des exigences Nécessaire pour faire face aux changements dans les exigences causés par: Changements aux processus d’affaires Changements dans les technologies, le marché, les lois Meilleure compréhension du problème La traçabilité est essentielle pour une bonne gestion Module 1 : Fondements de l'ingénierie des exigences

76 Types de documents pour les exigences
Les deux extrêmes Un résumé informel des exigences utilisant le plus souvent quelques diagrammes accompagnés d’un court texte Une liste détaillée de spécifications décrivant le système en détail Dans le cas d’un système de grande taille, plusieurs tels documents existent et sont organisés de façon hiérarchique Requirements xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxxxxxxxxxx subsystem 1 subsystem 2 Definition Specification sub-subsystems Module 1 : Fondements de l'ingénierie des exigences

77 L’analyste en exigences
Joue un rôle de communication essentiel! Parle aux utilisateurs: domaine de l’application Parle aux développeurs: domaine technique/solution Traduits les exigences utilisateur en exigences fonctionnelles et en critères de qualité A besoin de plusieurs compétences Entrevues et écoute Relations interpersonnelles Facilitation et psychologie Rédaction et modélisation Sens de l’organisation L’ingénierie des exigences, c’est plus que de la modélisation… C’est une activité sociale! Karl Wiegers – In Search of Excellent Requirements Module 1 : Fondements de l'ingénierie des exigences

78 Pour plus d’informations
B. A. Nuseibeh and S. M. Easterbrook, Requirements Engineering: A Roadmap. In A. C. W. Finkelstein (ed) The Future of Software Engineering, ACM Press, 2000 INCOSE Requirements Working Group Tools Survey: Requirements Management (RM) Tools See also IEEE (1995) Guide for Developing System Requirements Specifications. IEEE Std P1233/D3, NY, USA. IEEE (1998) Recommended Practice for Software Requirements Specifications. IEEE Std , NY, USA. Requirements Engineering Conference Module 1 : Fondements de l'ingénierie des exigences

79 Module 1 : Fondements de l'ingénierie des exigences
Conférences en IE International Requirements Engineering Conference (RE; since 1993): Int. Working Conf. on Requirements Engineering Foundation for Software Quality (REFSQ; since 1995): Workshop on Requirements Engineering (WER; since 1998): Asia Pacific Requirements Engineering Symposium (APRES; since 2014): Dozens of satellite workshops and special tracks elsewhere. Module 1 : Fondements de l'ingénierie des exigences