Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 4: Developing Requirements.

Présentation au sujet: "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 4: Developing Requirements."— Transcription de la présentation:

1 Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 4: Developing Requirements

2 © Lethbridge/Laganière 2001 2 4.1 Analyse de domaine Il sagit du processus par lequel un ingénieur logiciel peut faire lapprentissage du domaine de lapplication: Le domaine correspond au champs dapplication dans lequel le logiciel sera utilisé. Un expert de ce domaine est une personne ayant une connaissance approfondie de ce domaine Cette étude a pour but ultime de mieux comprendre le problème à résoudre Bénéfices découlant de lanalyse de domaine: Accélère le développement Permet le développement dun meilleur système Permet danticiper les possibles extensions

3 © Lethbridge/Laganière 2001 3 Document danalyse de domaine A.Introduction B.Glossaire C.Connaissances générales D.Les clients et utilisateurs E.Lenvironnement F.Tâches est procédures en usage G.Logiciel concurrent H.Similarités avec dautres domaines

4 © Lethbridge/Laganière 2001 4 Exigences à être determinées Le client a rédigé les exigences Nouveau produit Évolution dun Système existant AB CD 4.2 Le point de départ green field project

5 © Lethbridge/Laganière 2001 5 4.3 Définition du problème et de sa portée Un problème peut être exprimé comme: Une difficulté auquel se voit confronté le client ou les utilisateurs Ou une opportunité qui produira un certain bénéfice tel que une augmentation de productivité ou de ventes. La résolution du problème mène au développement dun logiciel Un bon énoncé de problème doit être clair et concis

6 © Lethbridge/Laganière 2001 6 Définir la portée Cerner la portée en définissant de façon plus précise le problème à résoudre Lister toutes les choses que le système devrait avoir à faire Exclure le plus de choses possibles pour réduire la complexité du problème Établir des buts plus généraux si le problème devient trop simple Exemple: un système automatisé dinscription universitaire

7 © Lethbridge/Laganière 2001 7 4.4 Quest-ce quune exigence? Un énoncé décrivant soit: 1)Ce que le système doit faire 2)Une contrainte concenant le développement du système Cet énoncé doit contribuer à résoudre le problème du client Et doit avoir été accepté par toutes le parties prenantes Un ensemble dexigences est un cahier des charges (requirements document).

8 8 Directives pour lécriture dexigences Chaque exigence doit être une phrase complète. Chaque exigence doit contenir un sujet et un prédicat: Sujet: système discuté, ou utilisateur (attention…) Prédicat: condition, action, ou résultat attendu Utilisation cohérente du verbe: doit (« shall ») pour exigences obligatoires peut (« should ») pour exigences optionnelles Lexigence doit contenir un critère de succès ou une autre indication mesurable de la qualité. Lexigence doit décrire ce qui doit être fait, et non comment le faire. © Lethbridge/Laganière 2001

9 9 Le système doit permettre à lutilisateur daccéder au solde de son compte en moins de 5 secondes. Définit le sujet Définit un résultat positifCritère de qualité Verbe doit ou peut Exemple dune bonne exigence utilisateur Cette exigence identifie un sujet spécifique ainsi quun résultat attendu dans un délai maximal donné et mesurable. Votre défi consiste à définir le sujet, le résultat attendu, et la mesure de succès pour chaque exigence! © Lethbridge/Laganière 2001

10 10 Lutilisateur Internet voit rapidement le solde de de son compte sur lécran du portable. Pas dexigence sur lutilisateur Critère de qualité vagueComment plutôt que Quoi Pas de verbe doit ou peut Exemple dune mauvaise exigence utilisateur © Lethbridge/Laganière 2001

11 11 Quelques lignes de conduite (1/4) Ne pas concevoir prématurément le système Indiquez plutôt ce que le système doit faire, et non comment le faire Signes de sur-spécification: utilisation de noms de composants, de matériaux, de champs du système… La conception prématurée peut mener à des coûts plus élevés en éliminant trop tôt des alternatives qui seraient plus efficaces. Ne pas mélanger différents types dexigences Évitez de mélanger exigences utilisateur, système, et de processus © Lethbridge/Laganière 2001

12 Exemple Test: quoi versus comment… Le système doit utiliser Microsoft Outlook pour envoyer un courriel au client qui contient la confirmation dachat. Le système doit informer le client que lachat est confirmé. X 12 © Lethbridge/Laganière 2001

13 13 Quelques lignes de conduite (2/4) Ne laissez pas de clauses échappatoires Pourraient mener à des problèmes de test Évitez si possible si, mais, sauf, excepté, à moins que/de, cependant Cependant, ces termes peuvent être utiles si dénumérer tous les cas spécifiques est difficile. Évitez les ambiguïtés Évitez les définitions pauvres (seulement des exemples) Lutilisation des mots ou/et car ils peuvent porter à confusion (en labsence de parenthèses)… Évitez les « etc. », « ainsi de suite », etc. © Lethbridge/Laganière 2001

14 Exemple Évitez les termes vagues Plusieurs mots utilisés informellement pour indiquer des qualités sont trop vagues pour être vérifiés Par exemple: convivial, hautement versatile, flexible, autant que possible, approximativement, impact minimal 14 Le système SimplEntrée doit être facile à utiliser et demander un minimum de formation sauf pour le mode professionnel X © Lethbridge/Laganière 2001

15 15 Quelques lignes de conduite (3/4) Nécrivez pas dexigences multiples Une exigence par phrase Évitez les conjonctions et, ou, avec, ainsi que Évitez les termes archaïques Évitez les références à des documents inaccessibles Le module de Navigation de SimplEntrée doit contenir la commande et les communications, le traitement, les résultats et les rapports. Le module de Commande doit être intégré au système Intranet et les résultats emmagasinés dans le dossier client. X © Lethbridge/Laganière 2001

16 16 Quelques lignes de conduites (4/4) Évitez les termes spéculatifs Les exigences ne sont pas une liste de souhaits! Évites les généralisations vagues Signes de dangers: habituellement, généralement, souvent, normalement, typiquement Éviter dinclure des suggestions ou possibilités. Des suggestions qui ne sont pas explicitement émises comme exigences sont invariablement ignorées par les développeurs Indiquées par des termes tels que: peut, pourrait, devrait, peut-être, probablement © Lethbridge/Laganière 2001

17 17 4.5 Types dexigences Exigences fonctionnelles Décrit ce que le système doit faire Exigences de qualité Contraintes sur le niveau de qualité que le design doit rencontrer Exigences de plate-forme Contraintes sur lenvironement et la technologie Exigences de processus Contraintes sur la gestion du projet et la méthodologie de développement

18 © Lethbridge/Laganière 2001 18 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 dautres systèmes Quels sont les calculs à effectuer La mise en marche et la synchronisation de tous ces éléments

19 © Lethbridge/Laganière 2001 19 Exigences de qualité Doivent être vérifiables Temps de réponse Rendement, débit Utilisation des ressources Fiabilité Disponibilité Restauration après pannes Facilité de maintenance et damélioration Facilité de réutilisation

20 20 Évaluez ces exigences 1.Le système dacquisition permet la saisie et le traitement rapide, convivial, et efficace des commandes. 2.Factures et reçus doivent être faxés automatiquement la nuit, afin que les clients puissent les recevoir dès le matin. 3.Le système doit pouvoir être mis à jour dun seul coup. Suggérez des améliorations lorsque nécessaire. © Lethbridge/Laganière 2001

21 21 Évaluez ces exigences 1.Le module dEntrée des Commande doit être entièrement intégré au Système Intranet et les résultats doivent être emmagasinés dans lenregistrement du client. 2.Linterface utilisateur doit être simple à utiliser. 3.Les données de lutilisateur doivent autant que possible être obtenues automatiquement de lestimé T&M. Suggérez des améliorations lorsque nécessaire. © Lethbridge/Laganière 2001

22 22 Cas type et scénarios © Lethbridge/Laganière 2001

23 23 4.6 Les cas-type dutilisation Un cas-type (use case) est une séquence typique dactions quentreprend un utilisateur afin daccomplir une tâche donnée Lobjectif dune analyse de cas est de modéliser le système … du point de vue de la façon par laquelle lutilisateur interagit avec le système … afin daccomplir ses objectifs Il sagit-là de lune des activités les plus importantes pour la cueillete et lanalyse des exigences du système Un modèle des cas-types consiste en un ensemble de cas-type une description ou un diagramme expliquant comment ils sont inter-reliés

24 © Lethbridge/Laganière 2001 24 Les cas types En général, un cas-type doit couvrir lensemble des étapes à suivre dans laccomplissement dune tâche donnée Le cas-type doit décrire linteraction de lutilisateur avec le système et non les opérations que doit réaliser le système. Le cas-type devrait être écrit, dans la mesure du possible, dune façon indépendante de toute interface utilisateur Un cas-type ne doit inclure que les interactions avec le système Synonymes: Cas dutilisation, cas-type dutilisation, use case…

25 25 Alternatives et exceptions Alternative: Sous-cas dusage qui satisfait le but visé mais à laide dune séquence détapes différente Exemple avec un consensus comme but: Cas dusage principal: vote en une session Cas dusage alternatif: vote en plusieurs sessions Exception: Sous-cas dusage qui traite les conditions du cas principal et des cas alternatifs qui diffèrent de la norme et des cas déjà couverts Exemple avec un consensus comme but: Cas dusage exceptionnel: quoi faire avec une personne non- inscrite qui veut voter © Lethbridge/Laganière 2001

26 26 Scénarios Un scénario est une instance dun cas-type Il exprime une occurrence spécifique dun cas-type un acteur spécifique... à un moment spécifique... avec des données spécifiques Il peut donc y avoir une multitude de scénarios générés à partir dun cas dusage Chacun deux pouvant mener à un ou plusieurs cas de tests

27 27 Rôle des scénarios dans le développement Application Domain Objects SubSystems class... Solution Domain Objects Source Code Test Cases ? Expressed in Terms Of Structured By Implemented By Realized By Verified By System Design Object Design Implemen- tation Testing class.... ? Requirements Elicitation Use Case Model Requirements Analysis [Tiré de Bruegge et Dutoit, OOSE] © Lethbridge/Laganière 2001

28 28 Comment décrire un cas-type? A. Nom: Une appellations courte et descriptive B. Acteurs: Énumérer les acteurs impliqués C. Buts: Expliquer ce que les acteurs veulent accomplir D. Préconditions: Décrire létat du système avant lexécution de ce cas-type E. Description: Une courte description informelle F. Référence: Autre cas-type apparentés G. Déroulement: Décrire chacune des étapes, sur 2 colonnes H. Postconditions: Décrire létat du système après lexécution de ce cas-type

29 29 Description des événements – Déroulement Plusieurs formes disponibles Narrative: paragraphe qui se concentre sur le scénario primaire ou quelques scénarios Forme préférée des partie prenantes lors des tous premiers contacts Colonne simple: séquence linéaire (séquence principales et alternatives) Colonnes multiples: une colonne par acteur Forme qui permet davoir une vue plus détaillée On utilise parfois des diagrammes de séquence © Lethbridge/Laganière 2001

30 30 Diagrammes de cas-type dutilisation

31 © Lethbridge/Laganière 2001 31 Extensions Utilisés afin de spécifier des interactions optionnelles tenant compte des cas exceptionnels En créant ainsi un cas-type dextension, la description principale peut demeurer simple Un cas-type dextension doit aussi énumérer toutes les étapes mentionnées dans le cas-type principal incluant le traitement de la situation exceptionnelle

32 © Lethbridge/Laganière 2001 32 Généralisations Similaire aux super-classes dans les diagrammes de classes Un cas-type généralisé représente plusieurs cas-types similaires La spécialisation dun cas-type fournit les détails spécifiques relatifs à un de ces cas-types similaires

33 © Lethbridge/Laganière 2001 33 Inclusions Sert à décrire les points communs contenus dans plusieurs cas-types différents Sont donc inclus dans dautres cas-types Même des cas-types très différents peuvent partager un certain nombre dactions identiques Permet déviter la répétition de ces détails dans chacun des cas-types Représente lexécution dune tâche de plus bas niveau pour accomplir un but aussi de plus bas niveau

34 © Lethbridge/Laganière 2001 34 Exemple de généralisation, dextension et dinclusion

35 © Lethbridge/Laganière 2001 35 Exemple de description dun cas-type

36 © Lethbridge/Laganière 2001 36 Exemple (suite)

37 © Lethbridge/Laganière 2001 37 Exemple (suite)

38 © Lethbridge/Laganière 2001 38 Exemple (suite)

39 © Lethbridge/Laganière 2001 39 Exemple (suite)

40 © Lethbridge/Laganière 2001 40 Exemple (suite)

41 41 Mésusage: Ne soyez pas négatifs, mais… Comme les scouts, soyez toujours prêts! En affaires, certaines personnes aimeraient vous voir échouer… Il y a plusieurs imprévus dans tout projet Les systèmes ouverts sont susceptibles aux menaces de toutes parts Les logiciels contiennent toutes sortes de bogues Rappelez-vous ce que dit la Loi de Murphy… © Lethbridge/Laganière 2001

42 42 Penser à des scénarios négatifs? Un scénario négatif est un scénario dont le but Est indésirable par lorganisation en question Est désiré par un agent hostile (pas nécessairement humain) Il peut être payant de les considérer Vous pouvez prévoir des solutions à lavance ou… Attendre quil soit trop tard pour réagir… © Lethbridge/Laganière 2001

43 43 Cas de mésusage Proposé par Sindre et Opdahl (2000) Décrit un cas dusage contre lequel un système devrait se protéger Son but est de menacer le système Il y a des applications évidentes du côté sécurité et analyse de risques Son més-acteur est un agent hostile Les couleurs de lellipse sont inversées Conduire lauto Voler lauto Voleur threatens © Lethbridge/Laganière 2001

44 44 Une approche MiniMax pour la sécurité Tel une partie déchecs… Le meilleur mouvement des Blancs est de trouver le meilleur mouvement des Noirs et de le contrer. Relations de menace (threatens) et datténuation mitigates) © Lethbridge/Laganière 2001

45 45 Le processus de modélisation: choisir le cas-type central Souvent lun des cas-type (ou quelques uns) peut être identifié comme central au système Le système peut alors être conçu autour de ce cas- type particulier Il existe dautre raisons de se concentrer sur un cas-type en particulier: Certains cas-types présentent un risque élevé dont la réalisation peut-être problématique Certain cas-types présentent une valeur commerciale ou politique importante

46 © Lethbridge/Laganière 2001 46 Les bénéfices liés à un développement fondé sur les cas-types Cela aide à mieux définir la portée du système Cela aide à mieux planifier le développement du logiciel Cela permet de définir et de valider les exigences Cela permet de définir les scénarios de tests Cela permet de mieux structurer les manuels dutilisation

47 © Lethbridge/Laganière 2001 47 Les cas-types ne sont pas une panacée Les cas-types doivent aussi être validés En utilisant les même méthodes que celles utilisées pour valider les exigences Certains aspects du logiciel ne sont pas couverts par une analyse de cas Des solutions innovatrices peuvent être ignorées

48 Édition de scénarios avec UCEd 48 Use Case model (use case, extend, include, actor…) Use Case model edition area Use Case description Use Case description edition area © Lethbridge/Laganière 2001

49 49 4.7 Quelques techniques pour la cueillette et lanalyse des exigences Observation Lire tous les documents disponibles et discuter avec les utilisateurs Observer des utilisateurs potentiel à leur travail leur demander en quoi consiste leur travail, ce quil sont en train de faire Filmer et enregistrer des sessions de travail Entrevues Mener une série dentrevues Demander des détails spécifiques Demander à chacun sa vision du problème et de sa solution Demander à chacun si ils ont des idées à proposer Demander à chacun de proposer des sources dinformation intéressantes Demander leur de faire des dessins et diagrammes

50 © Lethbridge/Laganière 2001 50 Cueillette et analyse des exigences... Séance de remue-méninge Recourir à un modérateur expérimenté Disposer lassistance autour dune table Lancer une question de départ Demander à chacun des participants décrire une réponse et de la passer à son voisin Développement conjoint dapplications (JAD) est une technique reposant sur des séances intensives de remue-méninge

51 © Lethbridge/Laganière 2001 51 Cueillette et analyse des exigences... Prototypage Sa forme la plus simple: un prototype sur papier. Un ensemble de schémas montrant le système en action Le plus commun: une maquette de linterface usager Écrit dans un langage permettant la conception rapide dinterface Neffectue aucun calcul, aucune réelle interaction Peut concerner un aspect particulier du système

52 © Lethbridge/Laganière 2001 52 Cueillette et analyse des exigences... Analyse de cas informelle Déterminer les différents types dutilisateur du système (acteurs) Déterminer les tâches que chacun de ces acteurs doivent accomplir avec le système

53 © Lethbridge/Laganière 2001 53 4.8 Types de document pour les exigences Dans le cas dun système de grande taille, plusieurs tels documents existent et sont organisés de façon hiérarchique Requirements Specification xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Requirements Definition xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Requirements Specification xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Requirements Definition xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Requirements Specification xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Les deux extrêmes: Un résumé informel des exigences utilisant le plus souvent quelques diagrammes accompagnés dun court texte On parle alors de la définition des exigences Une liste détaillée de spécifications décrivant le système en détail On parle alors de la spécification des exigences

54 © Lethbridge/Laganière 2001 54 Niveau de détail requis Le niveau de détail requis dépend de plusieurs facteurs: La taille du système Le fait que ce système doit sinterfacer avec dautres système Le public cible Létape où en est rendu le projet Le niveau dexpérience et de connaissance du domaine et de la technologie Le coût encouru par linclusion dexigences erronées ou ambiguës

55 © Lethbridge/Laganière 2001 55 4.9 Révision des exigences Chacune des exigences Doit avoir un bénéfice qui lemporte sur les coûts quelle engendre Doit être importante dans la solution du problème Doit être exprimée dune façon claire, concise et consistante Doit être non-ambiguë Doit être en concordance avec les standards et pratiques Doit mener à un système de qualité Doit être réaliste considérant les ressources disponibles Doit être vérifiable Doit être uniquement identifiable Ne doit pas sur-contraindre le système

56 © Lethbridge/Laganière 2001 56 Cahier des charges... Ce document doit être: Suffisamment complet Bien organisé clair Accepté par les différentes parties Retraçabilité:

57 © Lethbridge/Laganière 2001 57 Cahier des charges A.Problème B.Information de base C.Environnement et modèles D.Exigences fonctionnelles E.Exigences non-fonctionnelles

58 © Lethbridge/Laganière 2001 58 4.10 Faire face au changements Les exigences changent parce que: Les procédures évoluent La technologie change Le problème est mieux maîtrisé Lanalyse des exigences ne sarrête jamais Toujours continuer à interagir avec le client et les utilisateurs Tout changement doit être avantageux De petits changements cosmétiques sont souvent faciles et peu coûteux Des changement plus fondamentaux doivent être entrepris avec grande précaution -Effectuer des changements dans un système en cours de développement peut mener à une mauvaise conception et à des retard de livraison Certains changements sont en fait des ajouts au système Éviter de rendre le système plus gros, il doit simplement devenir meilleur

59 © Lethbridge/Laganière 2001 59 4.13 Difficultés et risques liés au domaine et aux exigences Mauvaise compréhension du domaine ou du problème Une bonne analyse de domaine et le prototypage sont la clé Les exigences changent rapidement Effectuer un développement incrémental, rendre le système flexible, procéder à des révision régulières Vouloir trop en faire Bien délimiter le problème, bien planifier le temps de travail Certaines exigences peuvent être difficiles à concilier Bien discuter des alternatives, faire des prototypes comparatifs Certaines exigences sont difficiles à saisir et à exprimer Subdiviser une exigence complexe en plus petite exigences, éviter les ambiguïtés, faire des prototypes