Exigences Logicielles une introduction

Transcription

1 Exigences Logicielles une introduction C est quoi? Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system Sommerville& Sawyer (1997) 1

2 Est-ce important? The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later Fred Brooks, No Silver Bullet: Essence and Accidents of Software Engineering Coût de l erreur Si uneerreurau niveaudes exigencescoute1 $ à corrigerau moment des exigences, elle coutera: 3 à 4 $, sidécouverteau moment de la conception 100 $ à corriger, après déploiement[boehm 1981, Grady 1999, Haskins 2004] 2

3 Types d exigences Terme Exigences d affaires Règle d affaires Contrainte Exigencesinterface externes Feature ou fonctionnalité Exigences fonctionnelles Exigences nonfonctionnelles Attribut de qualité Exigence système Exigence usager Définition Objectifs de haut niveau que l entreprise espère atteindre avec la réalisation du logiciel Politique, norme, contrainte, ou règlementation qui définit ou contraint un aspect (fonctionnel ounon) du système Unecontrainte externe imposée qui limite les choixde conception et d implantation du système Description de la connection entre lesystème et, a) sesusagers, b) le matériel, et c) d autres systèmes logiciels Une ou plusieurs capacités reliées du système qui apportent de la valeur à l usager pouvant être décrite par des exigences fonctionnelles (aussi cross-cutting) Unedescription d un comportement du système souscertaines conditions. Une relation <I,o> entre entrées/stiumulus, et sorties Une description d une propriété ou caractéristique que le système doit avoir ou une contrainte qu il doit respecter Un type d exigence nonfonctionnelle qui décritune caractéristique de service oude performance du logiciel Une exigence de haut niveau concernant un système possiblement composé par plusieurs sous-systèmes matériel ou logiciels Un objectif ou une tâche que certaines classes d utilisateurs doit être en mesure de réaliser avec le système; une caractéristique désirable du logiciel Rôles et liens entre les différents types Exigences d affaires Règles d affaires Document de vision & portée Exigences usager Attributs qualité Exigences système Document exigences usager Exigences fonctionnelles Interfaces externes contraintes Doc. Specs exigences logicielles(sel) 3

4 Exigences d affaires Pourquoiconstruire(oumettreà jour) le système en question (business case) Augmenter sa part de marché Améliorer la performance de ses opérations Améliorer la satisfaction (et rétention) de ses clients Développer de nouveaux marchés/produits Se conformer à une nouvelle règlementation Saisir une opportunité d affaires Exigences usagers Un objectif ou une tâche qu une classe d utilisateursdoitêtreen mesurede réaliseravec le système; unecaractéristiquedésirabledu logiciel Peuvent être exprimées par Cas d utilisation User stories Exemple: Inscription dans un cours Acheterun livresuramazon Obtenir une soumission d assurance auto 4

5 Exigences fonctionnelles Décrivent le comportement que le système doit avoir pour que les usagers puissent réaliser leurs tâches/objectifs Formulées sous formes d obligations/impératif sur le système(shall plutôt que should) Le système DOIT afficher/affichera un horaire modifié après l ajout d un cours Si la capacité d un groupe-cours est atteinte, le système DOIT proposer d autres groupes ayant de la place Le système DOIT proposer au client d autres livres reliés à ceux inclus dans son panier d achat Exigences système Cesontdes exigencesau niveaud un système comprenantplusieurssous-systèmes, possiblement logiciels et matériels Par exemple, unecaissede magasin, avec scanners, balance, imprimante, calculateur, dispenseur de monnaie, etc. 5

6 Alignement d exigences Nous devons avoir un alignement entre Exigences d affaires Exigences usagers Exigences fonctionnelles Alignement exigences usagers <-> exigences fonctionnelles Facile à vérifier: une question de couverture Alignement exigences d affaires <-> exigences usagers Plus compliqué Intervenants dans les trois niveaux 6

7 Règles d affaires Toute une approche The Business Rules Approach Des méthodesexistent pour la créationet la gestion de livrables autour des règles d affaires durant le cycle de vie Élicitation Analyse Conception Implémentation Exemple Développer un nouveau système de souscription d assurances en ligne: Exigencesd affaires: accroitrenotrepart de marchéde 15% Atteindrele clientèlede la générationy ouz Exigences usager Offrir une soumission en ligne à partir de données vérifiables fournies pour l usager Exigences fonctionnelles Calculerle facteurde risqueà partirde données sociologiques, dossier de conduite, et usage du véhicule 7

8 Exemple de domaine que vous connaissez? Exigences d affaires Exigences usager Exigences fonctionnelles Exigences suite Exigences interfaces externes Accèsà un service web de la SAAQ pour le dossier de conduite Accèsà un régistrede véhiculesaccidentésmaintenupar les compagnies d assurance Accèsà un bureau de crédit(equifax, etc.) Accès au système de gestion de polices courantes Contraintes Compatibilité au niveau des données avec le système backoffice + des applications desktop des agents/souscripteurs Intégrabilité dans la plateforme d intégration de l entreprise (e.g. ESB, etc.) 8

9 Exigences- suite Attributs de qualité Fiabilité Durée moyenne entre pannes Pourcentage de temps de fonctionnement Maintenabilité Par exemple, l introductionde nouveaux produitsdoitse faire en moinsde X temps oux% du temps de Changement d interfaces doit nécessiter moins de Migration de donnéesne doitpas affecter couchex et Y Etc. Disponibilité 24/7 Exigences- suite Règles d affaires: L assurédoitêtreagéde 18 ans L assuré(e) doit détenir un permis du Québec Si l assuréa plus de deuxréclamations at-fault durantles 18 derniersmois, alorscote de risque= C Règlementrations gouvernementales dans le domaine Assurance Sécurité et confidentialité de données personnelles Codes de pratiques de l industrie American Insurance Association 9

10 Exigences Votre exemple? Exigences produit vs. exigences projet Exigences projet Ressourcespour l équipede développement: machines, logiciels, outils, locaux, etc. Formation Documentation Exigenceset procédurespour le déploiementde logiciels Exigenceset procédurespour la transition entre ancien système et nouveau système Acquisition de logiciels Etc. 10

11 Ingénierie des exigences Différentes définitions Ingénierie des exigences: Développement des exigences Élicitation Analyse Spécification Validation Gestion des exigences Élicitation Activités principales: Identifier les intervenants(stakeholders) et les classes d usagers du système cible Comprendreles tâcheset les objectifsdes usagers, et les objectifs d affaires correspondants Se renseignersurle contexted utilisationdu nouveau produit Travailler avec des représentants de chaque classe d usagers pour mieux cerner leurs besoins fonctionnels, et leurs attentes en terme de qualité 11

12 Analyse Analyser l information receuillie auprès des utilisateurs potentiels pour faire le tri entre les différentes catégories d exigences (objectifs/tâches, fonctions, régles, etc.) Décomposer les exigences de haut niveau à un niveau de détail approprié Identifier les exigences fonctionnelles à partir des autres informations Comprendre l importance relative des divers critères de qualité Associer des exigences aux différentes composantes/ soussystèmes du système global Négocier les priorités d implantation Identifier des exigencesmanquantesoubiendes exigences hors contexte (out of scope) Spécification Mise en forme des diverses exigences élicitées et analysées sous une forme permettant sa compréhension, sarévision, et son utilisation par les usagers cibles Documents Diagrammes Etc. 12

13 Validation Réviserles exigencesdocumentées pour identifier et corrigerles problèmeséventuels, avantde transmettreà l équipede développement Développer des tests et critères d acceptation du logicielpour vérifierqu ilrépondaux exigences documentées Gestion des exigences Ingénierie des exigences: Développement des exigences Élicitation Analyse Spécification Validation Gestion des exigences 13

14 Gestion des exigences Définirun document d exigencesservant de baseline représentantun consensus atteint à un moment donné Gérerla traceabilitédes exigencesdurantle projet Relier les exigences à la conception, code, et tests Faire le suividu statutdes exigencesdurantle projet Gérer l évolution des exigences Gestion vs. développement d exigences Développement: développementde la première version signéepar tout le monde Gestion: Suivi des exigences (traceabilité) Gestiondu changement 14

15 Gestion de l évolution des exigences Préalable: conception de processus de changements d exigences Miseen oeuvre de cesprocessusde gestionde changement, impliquant: L étude d impact des changements proposés Définir les relations et dépendances entre exigences Negotiation des nouveaux engagements en se basant sur une estimation de l impact de ses changements sur le projet L incorporation des changements retenus/ approuvés de façon controlée Miseà jour des plans de projeten fonctiondes changements Facteurs de risques Conséquences de Mauvaises exigences : Refaireunepartiedu travail (coût, retard, dégradation de la qualité) Développeursfrustrés Clients pas content Promoteursfachés 15

16 Causes de mauvaises exigences Faible implication des usagers Fautepartagéeentre analystes, clients, et gestionnaires Requirements creep : Bien baliser la portéedu systèmeau départ, pour savoir quoi inclure et exclure Exigences ambigues Peu détaillées/ développées Utilisation de termes ambigus Causes de mauvaisesexigences (suite) Gold-plating : les développeurs en rajoutent L usager veut faire la tâche X, l analyste généralise à une famille de tâches paramétrables Intervenant négligé: Une classe d usagers non-présente Un détenteurde contenu d exigences(e.g. expert en taxation ou en comptabilité) 16

17 Gérer le client Parties prenantes et usagers Droits et obligations des clients S accorder sur les exigences Parties prenantes Étantdonnéles différentstypes d exigences, s assurerde ne pas en manquer Distinction claireentre client(exigencesd affaires) et usager(exigences usagers) 17

18 Parties prenantes Parties prenantesau seinde l équipe project Gestionnaire projet Analyste d affaires Architecte d application Concepteur Développeur Architecte données Analyste processus Testeur Gestionnaireproduit(product manager) Personnel de QA Administrateur BD Rédacteur de documentation Parties prenantesau seinde l organisation qui développe Gestionnairede développement Marketing Personnel de support opérationnel aux applications Services juridiques/contentieux Architecte d information Ventes Subject Matter Expert Bureau de Gestion de Projets (PMO) Expert utilisability/ergonomie Gestionnaire de programme etc Parties prenantesexternesà l organisation Utilisateur directs et indirects Acheteurs Sous-traitants Agence gouvernementale Spécialistes(subject matter expert) Auditeurde conformance (compliance auditor) Agence reglementaire Investisseur(venture capitalist) Testeur beta certificateur Droitset obligations des usagerset clients L ingénieriedes exigencesnécessitela collaboration entre ceux qui développement le logiciel, et ceux qui vont l utiliser Pour quecettecollaboration fonctionne, les clients ontun certain nombrede droitset responsabilitésreprésentantun contratentre les deux. 18

19 Droits des clients Un(e) analyste d affaires qui parle leur langage Un(e) analyste d affaires qui en apprend sur votre métier et sur vos objectifs Un(e) analyste d affaires qui enregistre vos exigences sous le bon format Avoiruneexplication surles pratiqueset livrablesde l eingénierie des exigences Changer vos exigences Une ambiance de respect mutuel D être informé d idées et de différentes façons de satisfaire vos exigences De décrire les caractéristiques qui rendraient le produit facile à utiliser D être informéde façonsd ajustervosexigences pour accélérer le développement Et. De recevoir un système qui répondà vosbesoinsfonctionnelset à vos exigences de qualité! Obligations des clients / usagers Apprendre votre métier aux AA et aux développeurs Prendre le temps qu il faut pour fournir et clarifier vos exigences Être clair et précis sur quand vous donnez de l information sur vos exigences Prendre des décisions concernant les exigences de façon rapide(timely) Respecter l évaluationqueles développeursferontdu coûtet de la faisabilité de vos exigences Mettredes prioritésréalistes survosexigences, en concertation avec les développeurs Prendrele temps de faire unerevue des documents d exigenceset d évaluer les prototypes Établir des critères d acceptation du logiciel Communiquer les changements à faire aux exigences le plus rapidement possible Respecter le processus de développement des exigences 19

20 Deux défis: Une culture d exigences Convaincretout le mondede l importancedu processus d exigences Leur montrer comment ce faire Solutions Formation Prêche Engagement / soutien des gestionnaires Résolutionde conflitsconcernantles exigences Le processusd élicitationd exigencesimpliquedes centaines de décisions à prendre où les avis peuvent être partagés C est important de: Identifier les décideurs Personneougroupeayantla compétence et l autoritépour trancher une question Identifier leur processus de décision Consensus Majorité Véto Le boss consulte et décide seul etc 20

21 Sign-off des exigences Queveutdire le sign-off des exigences? Les clients attestent que les exigences telles que documentées répondent à leurs besoins Les développeursattestentqu ilscomprennentles exigences et que les exigences sont faisables Les testeurs attestent que les exigences sont vérifiables Les gestionnaires/décideursattestentqueles exigences répondent à leurs objectifs d affaires Et après? Le sign-off se fait surla base d un basline Celane veutpas dire queles exigencesne vont pas changer Il fautmettreen place un processusde gestionde changements dans les exigences suivant le sign-off 21

22 Sign-off des exigences I agree that this set of requirements represents our best understanding of the requirements for the next portion of this project and that the solution described will meet our needs as we understand them today I agree to make future changes in this baseline through the project s defined change process. I realize that changes might require us to renegotiate cost, resource, and schedule commitments Sign-off dans le cas de projets agiles Voirchapitre20 Signification du sign-off: Pas de contradiction avec le motto des projets agiles embrace change Au moinsse mettred accordsurune compréhension partagée des exigences à ce moment-ci du projet/pour la prochaine itération Les nouvelles exigences ou exigences modifiées (ou qui débordent) iront dans le product backlog 22