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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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 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 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 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 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

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 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

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 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 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

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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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 É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 É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 Cas type et scénarios © Lethbridge/Laganière 2001

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

© Lethbridge/Laganière 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 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 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 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 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 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 Diagrammes de cas-type dutilisation

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

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

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

© Lethbridge/Laganière Exemple (suite)

© Lethbridge/Laganière Exemple (suite)

© Lethbridge/Laganière Exemple (suite)

© Lethbridge/Laganière Exemple (suite)

© Lethbridge/Laganière Exemple (suite)

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 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 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 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 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

É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

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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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

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

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

© Lethbridge/Laganière 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

© Lethbridge/Laganière 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