Software Requirements. Cahier des Charges des Logiciels. LFI2, Automne 2008, Genie Logiciel

Transcription

1 Software Requirements المتطلبات البرمجية Cahier des Charges des Logiciels LFI2, Automne 2008, Genie Logiciel

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 (المتطلبات الوظيفية ( Fonctionnelles Clauses Specifie les services rendus, les fonctions calculees, reactions a des entrees ou des circonstances, etc. (المتطلبات اللاوظيفية ( Fonctionnelles Clauses Non Contraintes sur les services rendus, les fonctions calculees, les circonstances operatoires Contraintes sur le processus de developpement. (متطلبات الميدان ( Domaine Clauses du 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 الا آتمال Completeness/ Completude/ Representer toutes les exigences de l usager. التماسك Consistency/ Coherence/ Ne pas imposer de contraintes contradictoires. الا حتفاظ Minimality/ Minimalite/ 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 Clauses du produit Fonctionnelles 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 Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time M Bytes Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems

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 Understandability domaine Clauses exprimees dans le vocabulaire du domaine. (Interet des PLE: Product Line Engineering) 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 Insulin Pump/Control Software/SRS/3.3.2 Function Compute insulin dose: Safe sugar level Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units. Inputs Current sugar reading (r2), the previous two readings (r0 and r1) Source Current sugar reading from sensor. Other readings from memory. Outputs CompDose Ğ the dose in insulin to be delivered Destination Main control loop Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be delivered. Requires Pre-condition Post-condition Side-effects None Two previous readings so that the rate of change of sugar level can be computed. The insulin reservoir contains at least the maximum allowed single dose of insulin.. r0 is replaced by r1 then r1 is replaced by r2

20 Specification Tabulaire Condition Action Sugar level falling (r2 < r1) CompDose = 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of increase decreasing ((r2-r1)<(r1-r0)) Sugar level increasing and rate of increase stable or increasing. ((r2-r1) (r1-r0)) CompDose = 0 CompDose = round ((r2-r1)/4) If rounded result = 0 then CompDose = MinimumDose

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 interface PrintServer { // defines an abstract printer server // requires: interface Printer, interface PrintDoc // provides: initialize, print, displayprintqueue, cancelprintjob, switchprinter void initialize ( Printer p ) ; void print ( Printer p, PrintDoc d ) ; void displayprintqueue ( Printer p ) ; void cancelprintjob (Printer p, PrintDoc d) ; void switchprinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer

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