Software Requirements المتطلبات البرمجية Cahier des Charges des Logiciels IF5, Automne 2008, Semaine 2.

Présentation au sujet: "Software Requirements المتطلبات البرمجية Cahier des Charges des Logiciels IF5, Automne 2008, Semaine 2."— Transcription de la présentation:

1 Software Requirements المتطلبات البرمجية Cahier des Charges des Logiciels IF5, Automne 2008, Semaine 2

2 Cahier des Charges Document qui stipule  Services rendus par le systeme envisage.  Contraintes d’exploitation.  Contraintes de developpement.

3 Cahier des Charges Ensemble de clauses  Chaque clause represente une contrainte/ un service/ une condition  Divers Niveaux d’abstraction/ Degres de precision.  Clause promotionnelle.  Clause de contrat.  Clause logique.

4 Trois Niveaux de Clauses Trois niveaux d’abstraction/ de detail  User requirements  System Requirements  Software specification

5 Trois Niveaux de Clauses

6 Clauses Fonctionnelles et non Fonctionnelles  Clauses Fonctionnelles (المتطلبات الوظيفية) Specifie les services rendus, les fonctions calculees, reactions a des entrees ou des circonstances, etc.  Clauses Fonctionnelles (المتطلبات اللاوظيفية) Contraintes sur les services rendus, les fonctions calculees, les circonstances operatoires… Contraintes sur le processus de developpement.  Clauses du Domaine (متطلبات الميدان) Contraintes qui emanent du domaine (contraintes physiques, dispositions legales, etc)..

7 Precision des Clauses  Problemes quand les clauses ne sont pas enoncees avec precision.  Des clauses ambigues peuvent etre interpretees differemment par les usagers, et les developpeurs.  Suffisemment non ambigues pour permettre a un parti impartial (juge) de determiner si une implementation satisfait la clause ou pas.

8 Proprietes des Clauses  Completude/ Completeness/ الإكتمال Representer toutes les exigences de l’usager.  Coherence/ Consistency/ التماسك Ne pas imposer de contraintes contradictoires.  Minimalite/ Minimality/ الإحتفاظ Ne pas imposer de contraintes autres que celles requises par l’usager ou le domaine.  Abstraction/ Abstraction/ التجرد WHAT vs HOW.

9 Clauses Non Fonctionnelles  Clauses Produit: Proprietes et contraintes du systeme, t.q. fiabilite, temps de reponse, limites d’espace memoire, capacite E/S, etc.  Clauses Processus: Specifier un langage, une methode, un outil, un standard, etc.  Clauses non fonctionnelles peuvent etre plus critiques que les clauses fonctionnelles (fiabilite, surete, temps de reponse, etc).

10 Classification de Clauses Non Fonctionnelles  Clauses du produit  Clauses de l’organisation Standards de processus, de langage, de methode, etc.  Clauses externes Externes au systeme et a son processus de developpement.

11 Classification de Clauses Non Fonctionnelles

12 Clauses Mesurables

13 Clauses du domaine  Derivees du domaine d’application.  Nouvelles clauses fonctionnelles, contraintes sur des clauses existantes ou calculs specifiques.  Si les clauses du domaine ne sont pas satisfaites, le systeme peut etre inoperable.

14 Difficultes des clauses du domaine  Understandability Clauses exprimees dans le vocabulaire du domaine. (Interet des PLE)  Implicitness Les experts du domaine ne pensent pas a formuler la connaissance implicite du domaine.

15 User Requirements  Formulees en termes comprehensibles par des non specialistes.  Representees en langage naturel, tables et diagrammes. Problemes du langage naturel: Informel/ qualitatif. Ambigu Confusion: plusieurs clauses

16 Recommendations pour representer des clauses  Inventer un format standard.  Utiliser le langage de maniere uniforme/ coherente.  Mettre en relief les clauses importantes du cagier des charges.

17 System requirements  Description detaillee des fonctions, services et contraintes du systemes.  Plus de detail que user requirements.  Base de conception.  Base de contract entre fournisseur et utilisateur.  Utilisent des modeles de systemes.

18 Cahier des Charges et Conception  En principe: CC  WHAT. Conception  HOW.  En pratique, le CC et la conception sont inseparable Une architecture du systeme peut etre concue pour structurer le CC. Le systeme peut interagir avec d’autres systemes qui generent des exigences de conception. L’utilisation d’une conception specifique peut etre une exigence du domaine.

19 Specification par formulaire

20 Specification Tabulaire

21 Digrammes de Sequence

22 Specification d’Interfaces  Interfaces entre systemes cooperatifs doivent etre specifiees.  Trois types d’interfaces peuvent etre specifees Interfaces Procedurales; Structures de donnees echangees; Representations de donnees.  Notations formelles, un moyen efficace a cet effet.

23 Exemple de Specification d’Interface

24 Document du Cahier des Charges  Charge des developpeurs du systeme.  User requirements + System requirements.  Pas un document de conception: what vs how.

25 Usagers du Cahier des Charges

26 Structure du Document  Preface  Introduction  Lexique  User requirements  Architecture du Systeme  Modeles du Systeme  System requirements  Evolution du Systeme  Appendices  Index