-- Séance Exigences Non-Fonctionnelles

Transcription

1 -- Séance Exigences Non-Fonctionnelles Objectifs: Être en mesure de comprendre les exigences Non-Fonctionnelles (ENF) et leur importance sur les décisions architecturales. Identifier les problèmes de définition, classification et représentation des ENF. Explorer les différentes approches de caractérisation des ENF. Découvrir quelques exemples. Comprendre la gestion des ENF. 1

2 Types des exigences (classification générale des exigences) Type des exigences Exigences fonctionnelles Exigences non-fonctionnelles Les contraintes Rappel (séance 1): Une exigence fonctionnelleest une exigence définissant une fonction du système à développer. Ce que le système doit faire. Une exigence non-fonctionnelleest une exigence qui caractérise une propriété (qualité) désirée du système telle que sa performance, sa robustesse, sa convivialité, sa maintenabilité, etc. Une contrainteest une restriction sur une ou plusieurs valeurs d une partie du système ou de tout le système. 2

3 Exigences non-fonctionnelles L utilité d un système logiciel est déterminée par ses exigences fonctionnelles et ses caractéristiques non-fonctionnelles. L ensemble des fonctionnalités n est pas utilisable sans certaines caractéristiques non fonctionnelles. Doivent être vérifiables Sinon, elles ne sont que des buts Catégorie liée à l usage, l efficacité, la fiabilité, la maintenance et la réutilisation Temps de réponse Rendement, débit Utilisation des ressources Fiabilité Disponibilité Restauration après pannes Facilité de maintenance et d amélioration Facilité de réutilisation 3

4 Problème avec la définition du terme ENF Source Antón Davis IEEE IEEE Jacobson, Booch and Rumbaugh Definition Describe the non-behavioral aspects of a system, capturing the properties and constraints under which a system must operate. The required overall attributes of the system, including portability, reliability, efficiency, human engineering, testability, understandability, and modifiability. Term is not defined. The standard distinguishes design requirements, implementation requirements, interface requirements, performance requirements, and physical requirements. Term is not defined. The standard defines the categories functionality, external interfaces, performance, attributes (portability, security, etc.), and design constraints. Project requirements (such as schedule, cost, or development requirements) are explicitly excluded. A requirement that specifies system properties, such as environmental and implementation constraints, performance, platform dependencies, maintainability, extensibility, and reliability. A requirement that specifies physical constraints on a functional requirement. Kontonyaand Sommerville Requirements which are not specifically concerned with the functionality of a system. They place restrictions on the product being developed and the development process, and they specify external constraints that the product must meet. Mylopoulos, Chung & Nixon Ncube Robertson and Robertson SCREEN Glossary Wiegers Wikipedia: NFRs... global requirements on its development or operational cost, performance, reliability, maintainability, portability, robustness There is not a formal definition or a complete list of nonfunctional requirements. The behavioral properties that the specified functions must have, such as performance, usability. A property, or quality, that the product must have, such as an appearance, or a speed or accuracy property. A requirement on a service that does not have a bearing on its functionality, but describes attributes, constraints, performance considerations, design, quality of service, environmental considerations, failure and recovery. A description of a property or characteristic that a software system must exhibit or a constraint that it must respect, otherthan an observable system behavior. Requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. Wikipedia: Requits Requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or Analysis design constraints). 4

5 Problème avec la définition du terme ENF Toutes ces définitions convergent vers les termes: Propriétés, caractéristiques, attributs, qualité, contraintes et performance. Propriétés, caractéristiques: dénotent les choses que le système doit posséder. Ce qui inclut des caractéristiques spécifiques comme l utilisabilité et la fiabilité. Attributs: Dans IEEE 830 les attributs sont une collection de qualité spécifique excluant la performance et les contraintes. Qualité:ISO 9000:2000 définit la qualité comme : «degré auquel un ensemble de caractéristiques inhérentes rencontre les exigences». Contraintes: dans ce contexte des ENF, les contraintes doivent avoir un sens de restriction (design, physique, ). Performance:IEEE 830 ne considère pas la performance comme un attribut ou une qualité. C est une catégorie à part. 5

6 Si vous n arrivez pas à choisir une des définitions Les ENF sont des attributs qui caractérisent le système ou le contraignent. Il est clair que les ENF ont pour but d exprimer des attributs de qualité. 6

7 Problème de classification des ENF 1 Davis utilise l arbre de qualité de Boehm. 2 Sommerville: exigences du produit, organisationnelles et externes. RUP : avec le document de spécifications supplémentaires. 3 4 IEEE 830 : exigences des interfaces externes, performance, attributs (fiabilité, disponibilité, sécurité, ) et contrainte de conception. 5 ISO 9126: facette de qualité (maintenabilité, testabilité, utilisabilité, ). 6 Martin Glinz: une classification à base de facette (facettée). 7

8 1 L arbre des caractéristiques de qualité selon Boehm Device-independence portability reliability self-containedness accuracy completeness general utility as-is utility efficiency human engineering Robustness/integrity consistency accountability testability Device efficiency accessibility maintainability understandability communicativeness modifiability Self-descriptivness structurness conciseness legibility 8

9 2 Classification des ENF selon Sommerville Non-functional requirements Product requirements Organizational requirements External requirements Ef ficiency Reliability Portability Interoperability Ethical requirements requirements requirements requirements requirements Us ability requirements Delivery requirements Implementation requirements Standards requirements Legislative requirements Performance requirements Space requir ements Privacy requirements Safety requirements (Sommerville & Kontoya 1998) 9

10 Classification des ENF selon Sommerville (I) Attributs orientés-produit Performance Utilisabilité: effort requis pour apprendre, utiliser, fournir l entrée et interpréter les sorties d un programme. Efficacité: usage minimal de ressources: mémoire, processeur, etc. Fiabilité: des calculs, de la précision Sécurité Robustesse: en présence de données invalides Adaptabilité: à d autres environnements ou problèmes Passage à l échelle: pour grandes quantités ou données Coût: coût total de possession (TCO): achat, installation, usage 10

11 Classification des ENF selon Sommerville (II) Attributs orientés-famille (de produits) Portabilité: fonctionne sur plusieurs plateformes Modifiabilité: ajout de nouvelles fonctionnalités Réutilisabilité: de composantes, de code, de designs, et même d exigencesdans d autres systèmes 11

12 Classification des ENF selon Sommerville (III) Attributs orientés-processus Maintenabilité: modifications de fonctionnalités, corrections Lisibilité: code, documents Testabilité: facilité à tester Compréhensibilité: conception, architecture et code facile à comprendre/apprendre Intégrabilité: facilité à intégrer des composantes Complexité: degré d interaction entre modules 12

13 4 Classification IEEE 830: Exigences spécifiques 3.1 Exigences des interfaces externes Interfaces avec les utilisateurs Interfaces avec le matériel Interfaces avec les logiciels Interfaces de communication 3.2 Exigences fonctionnelles 3.3 Exigences de performance 3.4 Contraintes de conception 3.5 Attributs 3.6 Autres exigences Précise les exigences numériques statiques et dynamiques qui doivent être satisfaites par le système ou par l interaction entre l humain et le système. Ex: 95% des transactions doivent être traitées en moins de 1s. Précise les contraintes de conception qui peuvent être imposées par d autres normes, les limites du matériel, etc. Il est important de pouvoir spécifier les attributs exigés pour que leur matérialisation puisse être vérifiée objectivement. Ex: -Disponibilité (point de contrôle, récupération et redémarrage, ). -Sécurité (cryptographie, journaux d historiques, intégrité, etc.) - Maintenabilité - Transférabilité. 13

14 5 Modèle ISO Ce standard international a été instauré pour centrer principalement deux problèmes : 1. Les différents modèles causent une confusion concernant la définition de la qualité. 2. Les termes employés sont interprétés de façon différente par différents experts. La nouvelle version de ISO 9126 est divisée en quatre parties: ISO :2001 Partie 1: Qualitymodel. ISO :2002 Partie 2: Externalmetrics. ISO :2003 Partie 3: Internalmetrics. ISO :2004 Partie 4: Qualityin use metrics. 14

15 Modèle pour la qualité externe et interne 15

16 Exemple Le plus haut niveau de cette structure constitue les caractéristiquesde qualité et le niveau le plus bas constitue les attributs de qualité du logiciel. Exemples: Changeabilité: Capacité à permettre l implémentation des changements Testabilité : Capacité à supporter les différents types de tests 16

17 Définitions des caractéristiques 17

18 Définitions des caractéristiques -- Suite 18

19 3 Le sous processus des exigences (input / output) On peut aussi étendrele tableau des UCen ajoutant une ligne ENF pour expliciter les attributs de qualité. 19

20 Modèle du doc pour les spécifications supplémentaires 2. Assumptions and Dependencies 3. Usability 3.1 <Usability Requirement One> 4. Reliability 4.1 <Reliability Requirement One> 5. Performance 6. Supportability 6.1 <Supportability Requirement One> 7. Design Constraints 7.1<Design Constraint One> 8. Security 9. Online User Documentation and Help System Requirements 10. Interfaces 10.1 User Interfaces 10.2 Hardware Interfaces 10.3 Software Interfaces 10.4 Communications Interfaces 11. Applicable Standards 20

21 6 Classification à base de facette (facettée) de Martin Glinz Représentation Opérationnelle Quantitative Qualitative Déclarative Type Fonction Donnée Performance Qualité spécifique Contrainte Exigences Satisfaction Dure (Hard) Légère (Soft) Rôle Prescriptive Normative Hypothétique 21

22 Liste de vérification Général Les exigences sont-elles conformes à la norme de représentation des exigences? Les exigences sont-elles énoncées dans une forme spécifique et mesurable (par exemple 10 secs vs rapide) Fiabilité (Reliability) Les exigences de fiabilité sont-elles spécifiées? Les exigences de disponibilité sont-elles spécifiées? Les exigences de service sont-elles spécifiées? Les exigences de robustesse sont-elles spécifiées? Performance Les exigences pour le temps de réponse ou de latence sont-elles spécifiées? Les exigences pour le de débit sont-elles spécifiées? Les exigences pour le volume de données sont-elles spécifiées? Les exigences des besoins à court terme en montée de charge sont-elles spécifiées? 22

23 Liste de vérification : suite Danger / sécurité / sûreté Les exigences pour la sécurité sont-elles spécifiées? Les exigences pour la reprise après incident sont-elles spécifiées? Configurations Les configurations prises en charge sont-elles spécifiées? Les exigences de compatibilité sont-elles spécifiées? (ex. Versions précédentes) Utilisabilité/Convivialité (Usability) Les exigences des critères d utilisabilité sont-elles spécifiées? Les exigences de l'internationalisation / localisation sont-elles spécifiées? Les exigences de look and feel sont les elles spécifiées? Opérationnel Y a-t-il des contraintes opérationnelles? (Ex. L utilisateur doit être en mesure de faire fonctionner le système en utilisant des gants). 23

24 Exemple 1 La facilité d utilisation est sans doute le critère le plus attendu pour les applications commerciales. Toutefois, ce critère demeure subjectif aux yeux de l utilisateur. Comment spécifier une exigence liée à la facilité d utilisation? Ci-dessous quelques suggestions: Spécifier le temps minimal de formation nécessaire pour devenir productif. Spécifier des temps de tâche mesurables pour des tâches types ou des transactions que l utilisateur final doit réaliser. Comparer l utilisabilitédu nouveau système avec des systèmes existants que la communauté des utilisateurs approuve. Spécifier les exigences pour un support en ligne, outils, manuels ou toute forme de documentation et d assistance. Suivre les standards et les conventions quand elles existent. 24

25 Exemple 2 Fiabilité: Personne n aime les bogues, les erreurs système, les pertes de données, etc. Ci-dessous quelques suggestions: Spécifier la disponibilité du système de façon opérationnelle durant des pourcentages de temps spécifiques. Le temps moyen entre les pannes (MeanTime BetweenFailures: MTBF) Le temps moyen pour la réparation (MTTR) Spécifier la précision requise pour les calculs et les sorties numériques. Spécifier les types de bogues. Qu est qu un bogue critique (ex. perte de données, l inutilisation de certains parties du système) Performance: La performance traite généralement des catégories suivantes: Temps de réponse pour une transaction (moyen et maximum). Débit pour les données ou de transactions par seconde. La capacité en nombre d utilisateur simultanés ou de transaction que le système peut supporter. Les modes de dégradations quand le système manque de ressources. 25

26 Métriques et mesures Distinction entre mesure et métrique. Par exemple, pour la fiabilité Métrique: Temps moyen entre les pannes Mesure: Nombre de pannes dans une période de temps donnée 26

27 Mesures de fiabilité Le système va-t-il fonctionner de façon inattendue lors d une requête? Mesures Probabilité d un échec sur demande Taux d occurrence de fautes (observables) Précision des calculs 27

28 Mesures de disponibilité Proportion de temps pendant laquelle le système fonctionne correctement Probabilité qu il soit fonctionnel! Mesurée par la durée entre les pannes et par la rapidité de reprise de service Temps moyen entre pannes: MTTF (Mean Time To Failure) Temps moyen de réparation: MTTR (MeanTime To Repair) Disponibilité = MTTF/(MTTF+MTTR) Peut mener à des exigences architecturales: Composantes redondantes (abaisse MTTF). Modificabilité des composantes (abaisse MTTR). Types de composantes spéciales (e.g auto-diagnostiques) 28

29 Mesures de sécurité Mesure de la capacité du système à résister à des tentatives d'usage non-autorisées et refus de services Mesures: Taux de succès en authentification Résistance à des types d attaques connues Temps/efforts/ressources nécessaires pour trouver une clé de chiffrage (probabilité de trouver la clé) Probabilité/temps/ressources pour détecter une attaque Pourcentage de services encore disponibles pendant une attaque Pourcentage d attaques réussies Durée de vie d un mot de passe, d une session Niveau de chiffrement Nombre de copies de sûreté Peut mener à des exigences architecturales Authentification, autorisation, audit Mécanismes de détection Coupe-feu, canaux de communication chiffrés Peut aussi être modélisée (SDL, logique ) 29

30 Mesures d utilisabilité Comprend plusieurs facettes et mesures, incluant: Facilité d'apprentissage (learnability) Taux de fonctionnalités ou de tâches maîtrisées après une période de formation Efficacité Rapidité acceptable des réponses aux requêtes Nombre de tâches exécutés ou problèmes résolus par unité de temps Nombre de clicks requis pour atteindre une certaine information ou fonctionnalité Facilité de mémorisation (memorability) Nombre/taux de façons de faire retenues après une période de temps Prévention des erreurs l'usager Nombre d erreurs par période de temps par types d utilisateurs Quantité d appels au support aux usagers Reprise d'erreur Temps pour récupérer/refaire un travail après erreur Accessibilité Respects de normes pour personnes handicapées Satisfaction de l'usager Taux de satisfaction par types d utilisateurs, taux d utilisation 30

31 Mesures de maintenabilité Habilité à effectuer des changements rapidement et efficacement Mesures Couplage, dépendances, quantité d anti-patterns, complexité cyclomatique Temps moyen pour corriger une bogue, temps moyen pour ajouter une nouvelle fonctionnalité (par experts, par nouveaux développeurs) Présence, accessibilité, utilité de la documentation (design, code, guides de mise à jour) Quelques outils permettent de mesurer la maintenabilitédu code. Exemple: Structural Analysis for Java d IBM Utilisation de Borland Together 31

32 Mesures de testabilité Facilité avec laquelle peuvent être détectées, isolées, et corrigées les fautes Mesures Temps pour exécuter les tests Temps pour mettre en place un environnement de test (développement et exécution) Probabilité d échec visible si une faute existe Couverture des tests (exigences, code) Peut mener à des exigences architecturales: Mécanismes de monitorage Points d accès et de contrôle supplémentaires 32

33 Mesures de portabilité et d intégrabilité Portabilité Capacité d'exécution sur différentes plateformes (matériel, OS, langages, versions) Pourcentage du code ou des fonctionnalités indépendantes de la plateforme Temps moyen pour porter un produit vers une nouvelle plateforme Intégrabilité Capacité à faire fonctionner ensemble des composantes développées séparément Temps moyen pour intégrer avec un nouveau système adjacent 33

34 Mesures de réutilisabilité et de robustesse Réutilisabilité Capacité à réutiliser la structure du système ou ses composantes Utilisation de cadres de développement standards Couplage de composantes Réutilisation: pourcentage d exigences, d éléments de design, de tests, de code, de structures de données réutilisées Robustesse Capacité à répondre à l inattendu Pourcentage d échecs sur entrées invalides Spécification de dégradation de service Performance minimale sous charges extrêmes Services actifs en présence de fautes Durée pendant laquelle le produit doit gérer des conditions de stress 34

35 Mesures de qualité et domaines Les mesures de qualité les plus appropriées vont varier d un domaine d application à l autre Performance Système Web: Nombre de requêtes traitées / secondes Jeux vidéo Nombre d images 3D / secondes Accessibilité Système Web: Respect de normes pour les personnes aveugles Jeux vidéo: Manipulation par enfants de moins de 12 ans Aussi: pas de violence 35

36 Autres ENF Que dire de ENF telles que amusant ou cool ou beau? Comment les mesurer? Les listes d attributs de qualité préexistantes sont intéressantes, mais elles n incluent pas ce genre de qualificatifs. Il est parfois préférable de laisser les clients faire leur remue-méninge avant de proposer les catégories conventionnelles. Il faut aussi raffiner ces buts en exigences mesurables. 36

37 Obtenir des quantités mesurables Les quantités ne peuvent pas être arbitraires ou devinées. Elles doivent être bien comprises. Si une exigence demande de réduire le temps de réponse de 25%, ceci implique que Le temps de réponse actuel est connu et Qu il existe une raison pour laquelle on veut 25% et non 20%. Il est peu probable que ces nombres vous soient donnés directement par vos clients au début. Ne ralentissez pas votre processus d élicitationet d analyse d exigences pour autant. Prenez en note les attributs de qualité pertinents, et vous pourrez négocier des quantités mesurables plus tard. 37

38 Conclusions Les exigences non-fonctionnelles ENF sont aussi importantes que les exigences fonctionnelles. Il existe un problème de définition de classification et de représentation des ENF. Les ENF peuvent être liées et difficilement séparables. Les ENF ont une portée globale. Elles doivent être adressées, mesurées et testées. Toutefois, la classification ne doit pas causer de problème pour la spécification dans la mesure où vous comprenez que c est une exigenceàspécifieretàmesurerparlasuite. 38