Sie sind auf Seite 1von 5

Gnie Logiciel Avanc M1 II e e TD 1 : Analyse et spcication des charges e

Lanalyse des charges (ou besoins ou en anglais requirements) et leur spcication constie tuent la premi`re tape du processus de dveloppement dun syst`me (produit) logiciel. Son e e e e rle est tr`s important car elle dnit ce que le syst`me doit faire, ses proprits indispeno e e e ee sables ou dsires, les contraintes sur les fonctionalits du syst`me ou sur le processus de e e e e dveloppement. e Le but de ce TD est de rdiger le cahier des charges pour trois tudes de cas qui nous e e servirons comme exemples au long du semestre. Une description partielle de ces tudes de e cas se trouve dans les annexes. Vous devez utiliser votre connaissance des syst`mes proposs e e pour complter ces descriptions avec les charges manquants. e Pour rdiger un tel document, la norme IEEE/ANSI 830-1998 donne une recommandation e du plan du document (voir lannexe B.1). Cette recommandation sapplique ` tout type de a syst`me. Un plan plus spcique aux syst`mes logiciels se trouve dans lannexe B.2. e e e Pour lanalyse et la spcication des charges, nous allons suivre un processus itratif avec e e trois tapes : e 1. Lanalyse puis le choix des charges : (a) Indiquer quels sont les interlocuteurs (stakeholders) que vous devez contacter pour obtenir des informations sur lutilisation du produit. (b) Classier les charges collectes en groupes cohrents. e e (c) Donner une priorit ` chaque charge et rsoudre les ventuels conits. ea e e Le rsultat de cette tape sera une matrice de traabilit et de dpendance des charges. e e c e e 2. La spcication des charges en utilisant des ches de spcication en langage naturel e e (voir exemple en annexe) ou des notations semi-formelles (diagrammes dutilisation ou diagrammes de squence). e 3. La validation des charges : en regardant Validit : le produit fournit les fonctions demands par lutilisateur ? e e Consistance : les charges sont-elles en conit ? Compltude : toutes les fonctionalits demandes sont spcies ? e e e e e Vriabilit : peut-on vrier une demande/charge sur le produit ? e e e Le rsultat de cette tape sera un plan de test du produit. e e Annexes : Annexe Annexe Annexe Annexe Annexe Annexe A : Rappel de la classication des charges. B : Recommandations pour le plan du cahier de charges. C : Etude de cas ATM : borne de distribution dargent. D : Etude de cas EDT : emplois du temps en M1 II. E : Etude de cas LIBSYS : syst`me de gestion dune biblioth`que. e e F : Fiche de spcication informelle des charges. e

Classication des charges


La classication des charges en fonction de leur niveau de dtail : e Charges dutilisation (CU) : les services ` fournir et les contraintes de fonctionnement a exprims en langage naturel aid par des diagrammes (par exemple les diagrammes e e dutilisation dUML). Charges du syst`me (CS) : les fonctions du syst`me spcies en dtail ; cest un contrat e e e e e entre le client et le fournisseur du syst`me. Les charges du syst`me sont classies en e e e fonction de leur type comme suit : Charges fonctionnels (CSF) : les services que le syst`me doit fournir, comment le e syst`me doit ragir ` des entres ou des situations particuli`res. e e a e e Charges non-fonctionnels (CSNF) : contraintes qualitatives et quantitatives sur les services oerts comme les dlais de rponse, les standards ` respecter, le type de e e a processus de dveloppement ` adopter, les contraintes de scurit ou condentialit, e a e e e etc. Charges dus au domaine (CSD) : contraintes imposs par le domaine dutilisation du e syst`me et qui re`tent les caractristiques de ce domaine. e e e

B
B.1

Plan du document de description des besoins


Recommandation IEEE/ANSI 830-1998
(a) Purpose of the requirements document (b) Scope of the product (c) Denitions, acronyms and abbreviations (d) References (e) Overview of the remainder of the document 2. General description (a) Product perspective (b) Product functions (c) User characteristics (d) General constraints (e) Assumptions and dependencies 3. Specic requirements Cover functional, non-functional and interface requirements. This is obviously the most substantial part of the document but because of the wide variability in organisational practice, it is not appropriate to dene a standard structure for this section. The requirements may document external interfaces, describe system functionality and performance, specify logical database requirements, design constraints, emergent system properties and quality characteristics. 4. Appendices 5. Index 1. Introduction

B.2

Recommandation spcique au logiciel e

Ce plan est recommand dans le livre Software engineering par Ian Sommerville. e 1. Prface : Dcrire la structure du document, ses direntes versions, un rsum des e e e e e raisons pour lesquelles les direntes versions du document ont t conues. e ee c 2. Introduction : Indiquer ` quel besoin le produit rpond. Dcrire bri`vement les fonca e e e tionnalits du produit et ses interaction avec dautres syst`mes. Positionner le produit e e par rapport ` la stratgie ou les objectifs du client. a e 3. Glossaire : Dnir les termes techniques utiliss dans le document sans supposer un e e lecteur averti. 4. Charges dutilisation : Dcrire les fonctionnalits oertes ` lutilisateur ainsi que des e e a charges non fonctionnelles du syst`me. Cette description peut utiliser le langage naturel, e des diagrammes ou dautres notation comprhensibles par les clients. Les standards qui e doivent tre respects par le produit doivent tre spcis. e e e e e 5. Architecture du syst`me : Prsenter une vue de haut niveau de larchitecture e e prconise du syst`me et la distribution des fonctionnalits ` travers les modules du e e e e a syst`me. Les composantes rutilise de larchitecture doivent tre soulignes. e e e e e 6. Charges du syst`me : Dcrire les charges fonctionnelles en dtail et dautre charges e e e non fonctionnelles, par exemple donner des dtails sur les charges dinterface avec e dautres syst`mes. e 7. Mod`les du syst`me : Donner un ou plusieurs mod`les du syst`me et montrer la e e e e relation entre les composantes du syst`me et son environnement. e 8. Evolution du syst`me : Dcrire les hypoth`ses fondamentales sur lesquelles le syst`me e e e e a t construit et anticiper les changements dus ` lvolution du matriel, aux changeee a e e ments des besoins dutilisation, etc. 9. Annexes : Fournir des informations dtailles et spciques au produit dvelopp. e e e e e Exemples dannexes qui peuvent tre donnes : description du matriel et de la base e e e de donne utilise. Pour le matriel, dnir la conguration minimale et optimale pour e e e e utiliser le produit. Pour la base de donnes, dnir le mod`le relationnel. e e e 10. Index : Plusieurs indexations du document peuvent y para tre : lindex des termes utiliss, lindex des diagrammes, lindex des fonctions, etc. e

Distributeur dargent (ATM)

But du produit : Il sagit dassurer la distribution dargent pour les possesseurs dune carte bancaire valide.

Etude de cas EDT

But du produit : Il sagit dun logiciel permettant de gnrer des emplois du temps pour e e la formation M1 Ingnierie Informatique en tenant compte des enseignements ouverts, de la e disponibilit des salles et de la disponibilit des professeurs. e e

Etude de cas LIBSYS

But du produit : Il sagit dun syst`me de gestion utilis dans une biblioth`que pour e e e fournir aux utilisateurs lacc`s personnalis aux articles ou aux chapitres de livre tout en e e respectant la loi sur la proprit intellectuelle. Ainsi, si le contrat de distribution du document ee le demande, lutilisateur devra signer une notice de copyright et de payer larticle demand. e Pour cela, la biblioth`que doit disposer des contrats avec les diteurs des articles dont elle e e fait la diusion. Exemples de charges : [Charges dutilisation :] CU1 : Les utilisateurs peuvent chercher, tlcharger et imprimer ces articles pour une ee utilisation personnelle. [Charges fonctionnels du syst`me :] e CSF1 : Lutilisateur doit pouvoir chercher soit dans toutes les bases de donnes ou e dans une liste slectionne de bases. e e CSF2 : Le syst`me doit fournir des applications permettant de visualiser les direntes e e formats de chiers dans la base. [Charges non-fonctionnels du syst`me :] e CSNF1 : (Produit) Linterface du syst`me doit tre implmente comme une simple e e e e page HTML sans cadres (frames) ou applets Java. CSNF2 : (Organisation) Le processus de dveloppement et les documents remis e doivent respecter la norme ISO 9001. CSNF3 : (Externe) Le syst`me ne doit pas permettre la visualisation des informations e personnelles des clients autre que leur nom et leur numro de rfrence. e ee [Charges domaine du syst`me :] e CSD1 : Il doit avoir une interface normalis avec lutilisateur base sur le standard e e Z39.50. CSD2 : A cause du copyright, certains documents doivent tre eacs immdiatement e e e du disque du syst`me apr`s leur arrive. En fonction de la demande de lutilisateur, e e e ces documents doivent tre soit imprims localement puis envoys manuellement ` e e e a lutilisateur, soit transmis sur une imprimante rseau. e

Fiche de description de charges


Dans lexemple LIBSYS, la description de la fonction (CF1) de recherche dun article.

Fonction : Recherche un article. Description : Recherche un article selon des crit`res donnes par lutilisateur dans une liste e e de bases slectionnes par lutilisateur ou dans une liste par dfaut. e e e Entres : La liste de bases ` chercher et les crit`res de la recherche (auteur, mots-cls, titre). e a e e Source : La page de requte remplie par lutilisateur et la mmoire (pour la liste par dfaut e e e des bases). Sorties : La liste des articles correspondant aux crit`res. e Destination : Achage HTML sur cran. e Action : Le crit`re donn par lutilisateur est transform dans une requte qui est transmise e e e e a ` chaque bases dans la liste de bases slectionnes. La rponse de chaque base est e e e formate dans le format de sortie et ache au fur et ` mesure de larrive des rponses. e e a e e Lachage doit prvoir un moyen pour slectionner larticle en vue de sa consultation. e e Requis : Moyen pour slectionner la liste de bases par dfaut et pour rentrer le crit`re. e e e Pr-condition : La liste de bases est non vide et le crit`re est une cha non vide. e e ne Post-condition : Le log correspondant ` cet utilisateur est modi. a e Eets de bord : Enregistre la recherche dans le log du syst`me. e