Syllabus REQB Professionnels Certifiés pour l Ingénierie des Exigences Version 1.2 1 er Juillet 2008 Le copyright de cette édition du syllabus dans toutes les langues est détenu par le Gasq Global Association for Software Quality.
Historique des modifications Version Date Commentaire 0.1 17 avril 2006 Première version du syllabus; création de la structure de base pour le syllabus 0.2 20 juillet 2006 Complément à la Version 0.1 0.3 4 septembre 2006 Autre complément et révision de la Version 0.1 0.4 10 octobre 2006 Version 0.3 révisée 0.5 15 décembre 2006 Version 0.4 révisée 0.6 7 février 2007 Version 0.5 complètement revisée 0.7 10 avril 2007 Version revisée pour revue 0.8 15 juin 2007 Version alpha 0.9 1 er septembre 2007 Version beta 1.0 15 janvier 2008 Version 1.0 diffusée 1.1 29 mai 2008 Mise à jour : version 1.1 1.2 1 er juillet 2008 Mise à jour : version 1.2 1.2 FR 15 décembre 2010 Version 1.2 en français Le copyright de cette édition du syllabus dans toutes les langues est détenu par le Gasq Global Association for Software Quality. 2
Idée principale Le thème central pour ce syllabus était que la complexité du logiciel et notre dépendance au logiciel ne cessent de croître. Ceci engendre un haut niveau de dépendance à l égard de l absence d erreurs dans le logiciel. Le «Requirements Engineering Qualifications Board» (REQB) a donc décidé de créer des standards internationaux uniformes dans le domaine de l Ingénierie des Exigences. Pour des standards comme les langages c est uniquement si vous les comprenez que vous pourrez travailler efficacement. Pour créer un tel langage uniforme dans ce domaine important qu est l Ingénierie des Exigences, des experts internationaux se sont réunis au sein du REQB et ont développé ce syllabus. 3
Sommaire Introduction... 5 1. Fondamentaux... 7 1.1 Exigence... 7 1.2 Normes et standards... 11 2. Procedure et Processus... 13 2.1 Les modèles de processus... 13 2.2 Processus d Ingénierie des Exigences (K 2)... 15 3. Gestion de projet et de risque... 16 3.1 Gestion de projet... 16 3.2 Gestion de risque... 17 4. Rôles et Responsabilités... 18 4.1 Rôles élémentaires... 18 4.2 Tâches de l Ingénierie des Exigences... 19 5. Identification des Exigences... 20 5.1 Client... 20 5.2 Visions du projet et objectifs... 21 5.3 Identification des parties prenantes... 21 5.4 Techniques pour identifier les exigences... 22 5.5 Exigences fonctionnelles et non fonctionnelles... 23 5.6 Descriptions des Exigences... 23 6 Specification des exigences... 25 6.1 Spécification... 25 6.2 Procédure... 26 6.3 Formalisation... 26 6.4 Qualité des Exigences... 27 7. Analyse des exigences... 28 7.1 Exigences et Solutions... 28 7.2 Méthodes et Techniques... 28 7.3 Analyse orientée objet... 29 7.4 Estimations du coût... 30 7.5 Prioritisation... 30 7.6 Entente sur les exigences... 31 8. Suivi des exigences... 32 8.1 Suivi au sein du projet... 32 8.2 Gestion du Changement... 33 8.3 Métriques... 34 9. Assurance Qualité... 35 9.1 Facteurs d influence... 35 9.2 Assurance qualité via testabilité... 35 10. Outils... 37 10.1 Avantages des outils... 37 10.2 Catégories d outils... 37 11. Littérature... 39 4
Introduction Objectif de ce syllabus Ce syllabus définit le niveau élémentaire (niveau Fondation) du programme de formation pour devenir un Professionnel Certifié REQB pour l Ingénierie des Exigences (REQB Certified Professional for Requirements Engineering - CPRE). REQB a développé ce syllabus en collaboration avec le Gasq - Global Association for Software Quality. Le syllabus a pour but de servir de base pour les organismes de formation qui sont à la recherche d une accrédation en tant que formateur. Toutes les parties de ce syllabus doivent par conséquent être incluses dans les documents de formation. Cependant, le syllabus devrait également servir au stagiaire dans sa préparation à la certification. Toutes les parties énumérées ici sont donc utiles pour l examen qui peut être passé après des cours accrédités ou en candidat libre. Examen L examen pour devenir un Professionnel Certifié REQB pour l Ingénierie des Exigences est basé sur ce syllabus. Toutes les sections de ce syllabus peuvent ainsi être examinées. Les questions d examen ne sont pas nécessairement divisées en différentes sections. Une question peut se référer à plusieurs sections. Le format de l examen est un Questionnaire à Choix Multiples. Les examens peuvent être passés après avoir suivi des cours accrédités ou en candidat libre (sans cours préliminaire). Vous trouverez des informations détaillées concernant les durées des examens sur le site du Gasq (www.gasq.org),sur le site du REQB (www.reqb.org), ou sur le site du CFTL (www.cftl.fr) Accreditation Les organismes fournissant des cours Professionnels Certifiés REQB pour l Ingénierie des Exigences doivent être accrédités par le Gasq - Global Association for Software Quality. Les experts du Gasq revoient l exactitude de la documentation 5
des organismes de formation. Un cours accrédité est considéré comme conforme au syllabus. A la fin d un tel cours, un examen officiel Professionels Certifiés REQB pour l Ingénierie des Exigences (examen CPRE) peut être réalisé par l organisme de certification indépendant (selon les règles de l ISO 17024). Les organismes de formation accrédités peuvent être identifiés par le logo officiel REQB Organisme de Formation Accrédité. Internationalité Ce syllabus a été développé en collaboration entre plusieurs experts internationaux. Le contenu de ce syllabus peut donc être considéré comme un standard international. Le syllabus permet ainsi de former et de faire passer des examens internationalement au même niveau. Niveaux K Le syllabus a été divisé en différents niveaux K. Cela permet au candidat de reconnaitre le «niveau de connaissance» de chaque point. Il y a 3 niveaux K dans ce syllabus : K1 se rappeler, reconnaitre, rappeler K2 - comprendre, expliquer, donner des raisons, comparer, classifier, résumer K3 appliquer dans un contexte spécifique 6
1. Fondamentaux Objectifs d apprentissage Qu est ce qu une exigence? Quels sont la signification et le but des exigences? Comment peuvent être classées les exigences? Qu y a-t-il comme types d exigences? Quels sont les problèmes concernant les exigences? Quels sont les concepts importants en rapport avec les exigences? Quelle est la différence entre GE (Gestion des Exigences) et IE (Ingénierie des Exigences)? Quels sont les normes et standards importants qui existent? Pourquoi l Ingénierie des Exigences est-elle importante? 1.1 Exigence Définition de ce qu on entend par le terme exigence (K 1) Glossaire IEEE 610.12: Une exigence est une condition ou une aptitude requise par un utilisateur pour résoudre un problème ou atteindre un objectif. Quels sont la signification et le but des exigences? (K 2) Fondement pour l évaluation, la planification, l exécution et le suivi de l activité de projet Attentes client Composante d accords, de commandes, de plans projet, Définition des limites d un système, du perimètre d une livraison, de services contractuels 7
Classification des exigences (selon [Ebert05]) (K 2) Les exigences comprennent des exigences processus et des exigences produit. Exigences processus : les coûts, le marketing, le temps de traitement, les ventes et la distribution, l organisation, la documentation. Décrit les besoins et les limites des processus métier. Les exigences produit comprennent les exigences produit fonctionnelles et non fonctionnelles. Ces deux types d exigences peuvent être considérés du point de vue de l utilisateur (externe) ou du client et du point de vue du développeur (interne). Exigences produit fonctionnelles du point de vue de l utilisateur : interface utilisateur, applications, services Exigences produit fonctionnelles du point de vue du client : interface utilisateur, applications, services Note : l utilisateur et le client peuvent être différents! Exigences produit fonctionnelles d un point de vue du développeur : architecture, alimentation électrique, répartition de charge Les exigences fonctionnelles décrivent la fonction du système Exigences produit non-fonctionnelles du point de vue de l utilisateur : fiabilité, performance, utilisabilité (facilité d emploi) Exigences produit non-fonctionnelles du point de vue du développeur : testabilité, services offerts, outils Les exigences non-fonctionnelles décrivent les attributs qualité du système. 8
Types d exigences : exigences clients, exigences solution/système, exigences produit/composant (K 1) Problèmes avec les exigences (K 2) Objectifs imprécis Problèmes de communication Barrières de la langue Barrières de connaissance Formulation vague Formulations trop formelles Exigences ambigues, trop spécifiées, peu claires, impossibles, contradictoires Instabilité des exigences Mauvaise qualité des exigences Placage doré Implication insuffisante des utilisateurs Classes utilisateur oubliées Planning inadapté Spécification minimale Critère de qualité des exigences (d après Wiegers05): (K 2) 1. Chaque exigence doit être complete, correcte, possible, nécessaire, priorisée, non ambigue et vérifiable 2. La spécification des exigences doit être complète, cohérente, modifiable et traçable. Pour les organismes de formation : explication de chaque critère qualité Solution (K1) Une solution est l implémentation d une exigence. Engagement (K1) 9
L engagement est le degré d obligation. Définition de l engagement à travers les mots-clés. Pour les organismes de formation : explication des mots-clés Observer les responsabilités légales, notamment en cas de fautes Faute (K 1) Ecart de l état actuel par rapport à l état cible Priorité des exigences (K 1) Evaluation de l importance / urgence Criticité des exigences (K 1) Evaluation du risque d une exigence en évaluant le dommage en cas de non-respect d une exigence Validation (K1) Processus de confirmation que la spécification d une phase ou du système complet satisfait les exigences client. Verification (K 1) Comparaison d un produit intermédiaire avec ses spécifications. Il s agit donc de déterminer si le logiciel a été développé correctement et si les spécifications qui ont été déterminées au cours de la phase précédente ont été remplies Délimitation entre gestion et ingénierie des exigences (K 2) La gestion des exigences (GE) inclut les processus pour l identification et la gestion des exigences L ingénierie des exigences inclut les compétences de base de l ingénierie Pour les organismes de formation : approfondir les différents domaines 10
1.2 Normes et standards ISO 9000 : Exigences d un système de management de la qualité : Concepts et fondements définis d un SMQ Indépendant d un domaine ou de l industrie ISO 9126 : Définit un modèle qualité en six catégories : Fonctionnalité, fiabilité, utilisabilité (facilité d utilisation), efficacité, maintenabilité, portabilité IEEE 610 : Glossaire standard de la terminologie de l ingénierie logicielle IEEE 830 : Pratique recommandée pour les spécifications d exigences logicielles IEEE 1233 : Guide pour développer des spécifications d exigences logicielles IEEE 1362: Guide pour la technologie de l information Définition Système Normes processus : ISO 12207 : Standard pour le processus du cycle de vie logiciel ISO 15288 : Processus de cycle de vie système 11
ISO 15504: Software Process Improvement and Capability Determination (SPICE) Capability Maturity Model Integrated (CMMI) Pour passer l examen, il n est pas nécessaire de connaître le contenu de toutes les normes. Il est néanmoins important (K 1) de connnaitre quelles normes sont importantes pour l Ingénierie des Exigences. L Ingénierie des Exigences est d une importance vitale. Et pourtant, elle est maintes fois négligée. Pour les organismes de formation : mettre en avant l importance de l Ingénierie des Exigences et les raisons pour lesquelles elle est souvent négligée (K 2) : Négligée à cause d une pression importante des délais Négligée à cause d une orientation exclusive vers des résultats rapides Négligée à cause d une fixation exclusive sur les coûts Négligée à cause de mauvaises interprétations (beaucoup de choses sont considérées comme connues) Conséquences possibles causées par la négligence de l Ingénierie des Exigences (K 2) : Les exigences deviennent imprécises Les exigences sont ambigues Les exigences sont contradictoires Les exigences qui changent Les exigences qui ne remplissent pas les critères Les exigences qui peuvent être interprétées différemment Des exigences manquantes 12
2. Procedure et Processus Objectifs d apprentissage Quels sont les différents modèles de processus? Quelles sont les différences entre les différents modèles de processus? Qu est-ce qui caractérise le processus d Ingénierie des Exigences? Quelles sont les phases de ce processus? 2.1 Les modèles de processus Modèles procéduraux (K 2) Processus indépendant de méthodes de description des processus de développement Les rôles, activités, phases et documents sont ainsi pris en compte Cycle de Vie Produit (PLC Product Life Cycle) (K 2) Phases élémentaires : planification, développement, maintenance, fin de vie La phase de planification inclut : la vision, la stratégie, le business plan et l analyse de bénéfices La phase de développement inclut : la spécification, le maquettage et l implémentation Définit les différentes phases du développement d un produit Cycle en V général (K 2) Etapes de développement : Définition des exigences, détermination des exigences (spécifications de ce qui doit être développé) 13
Maquettage fonctionnel du système, analyses systèmes (spécifications fonctionnelles) Maquettage technique du système, maquettage de l architecture (conception logicielle) Spécification des composants Implémentation Pour les organismes de formation : représentation graphique du modèle de cycle en V général ; description approfondie du modèle de cycle en V général Rational Unified Process (RUP ) (K 2) Modèle procédural défini par IBM Rational On y trouve un processus de développement itératif avec : 4 phases (création, élaboration, construction, transition) 9 disciplines (parmi lesquelles, la discipline relative aux exigences) Pour les organismes de formation : approfondissement de RUP avec une représentation graphique, étude approfondie de la discipline relative aux exigences Extreme Programming (K 2) Modèle procédural défini par Kent Beck et al Gestion des exigences comme composant principal Sans la moindre étape d ellicitation des exigences Pour les organismes de formation : expliquer aussi au moins trois autres modèles agiles incluant Scrum et Crystal Niveaux de modèles de maturité (K 2) 14
Pour l identification et l amélioration de la maturité de processus (évaluation de processus et amélioration de processus) Définition des niveaux de maturité et spécifications correspondantes des processus Pour les organismes de formation : approfondissement en utilisant l exemple de l ISO 15504/SPICE, avec une description des exigences typiques pour l Ingénierie des Exigences 2.2 Processus d Ingénierie des Exigences (K 2) Processus non fondamental, qui concerne toutes les phases de développement de systèmes : Identification des exigences Analyse des exigences Spécification des exigences Changements des exigences Vérification Assurance Qualité Description des facteurs qui ont une influence négative sur les processus Description des différents points de vue (point de vue client, fournisseur) Méthode du processus d Ingénierie des Exigences centrée sur le client 15
3. Gestion de projet et de risque Objectifs d apprentissage Pourquoi l Ingénierie des Exigences est-elle importante dans les projets? Quelles erreurs peuvent survenir dans l Ingénierie des Exigences? Quels risques y a-t-il avec les exigences? 3.1 Gestion de projet Description de la nécessité de l IE dans les projets (K 2) L IE doit contribuer aux domaines suivants : (K 1) Conception de projet Négociations de contrat Définition de projet Exécution de projet Pour les organismes de formation : description plus détaillée de l IE dans ces domaines Quelles erreurs peuvent survenir dans l Ingénierie des Exigences? (K 2) Manque de clarté des exigences Changement des exigences Instabilité du produit et des bases de conception pour les commandes soustraitées Manque de clarté dans les responsabilités Ecart entre les attentes client et les contenus projet Gestion client insuffisante Définition projet avec des jalons qui ne peuvent pas être atteints 16
Estimation imprécise des dépenses Estimation imprécise des impacts 3.2 Gestion de risque Expliquer la nécessité de la gestion de risque (K 3) Gestion de risque efficace comme clé pour réduire les risques projet Pour les organismes de formation : description détaillée du développement de contre-mesures et de techniques de gestion de risque (comme l Analyse des Modes de Défaillances et des Effets) 17
4. Rôles et Responsabilités Objectifs d apprentissage Quels sont les rôles élémentaires dans l Ingénierie des Exigences? Qu est-ce qu une partie prenante? Quelles sont les tâches relatives à l Ingénierie des Exigences? Quelle est la tâche d un Professionel pour l Ingénierie des Exigences? Qu est-ce qui caractérise un Professionnel pour l Ingénierie des Exigences? 4.1 Rôles élémentaires Rôles élémentaires (K 2) Client (= commanditaire) Contractant (= fournisseur) Le client formule ses besoins Le contractant fournit des solutions Partie prenante Une partie prenante est une personne ou un rôle qui a un intérêt Les parties prenantes peuvent être des personnes physiques, des sociétés ou des personnes morales. Les parties prenantes ont souvent des conflits d intérêt entre elles. Pour les organismes de formation : description d une partie prenante typique (e.g. Directeur Général, Chef de projet, Client) Important : Identification de toutes les parties prenantes afin de prendre en considération tous les points de vue sans exception 18
4.2 Tâches de l Ingénierie des Exigences Tâches (K 2) Analyse des processus métier Identification et analyse des exigences Assurance Qualité des exigences et spécifications Création de la spécification des exigences Analyse de risque Le Professionnel pour l Ingénierie des Exigences identifie les souhaits et les objectifs Connaissance d un Professionnel pour l Ingénierie des Exigences (K 1) Compétence de mesure Confiance en soi Capacité à convaincre Compétences linguistiques Capacité à communiquer Précision Capacité d analyse, pensée réfléchie Capacité à agir de façon structurée Compétence méthodologique Résistance au stress 19
5. Identification des Exigences Objectifs d apprentissage Que devrait contenir un contrat? Qu est-ce qui devrait être considéré lors de l évaluation des exigences? Qu est ce qui caractérise une vision typique de projet? Comment les parties prenantes peuvent-elles être identifiées? Quels sont les objectifs de l identification des exigences? Quelles sont les techniques pour identifier les exigences? Qu est-ce qui caractérise les exigences fonctionnelles et non fonctionnelles? Comment diffèrent-elles? Quels contenus devraient-être couverts par un document d exigences? Qu est-ce qui caractérise de bonnes exigences? Quels sont les contenus standards d un document d exigences? Comment peut-on construire une exigence? 5.1 Client Le client doit toujours être impliqué. Le but est de comprendre le client et que tout le monde ait une compréhension commune. Le contractant devrait ainsi se mettre toujours dans la position du client. Contrat : (K 2) Ce que veut le client devrait être formellement spécifié et décrit dans l accord Il faut s assurer que l intérêt du client est au centre des préoccupations Il est important de fixer des prix et des délais réalistes et de faire des plans projet réalistes Pendant l évaluation des exigences, différents points de vue doivent être pris en considération. 20
5.2 Visions du projet et objectifs Au début, nous avons le développement des visions du projet. C est la première étape de l Ingénierie des Exigences. Il est crucial d avoir une définition claire des visions d un projet. Pour les organismes de formation : présentation des visions typiques d un projet Questions importantes à propos des visions d un projet (K 2) Que va changer le projet? Pourquoi le projet est-il nécessaire? Que se passe-t-il une fois le projet terminé? Qui profitera du projet? Quels sont les coûts prêts à être assumés? Quels sont les risques prêts à être assumés? Pour les organismes de formation : présentation des influences typiques sur les visions d un projet (clients, stratégie, etc.) Pour chaque projet, la vision doit être réestimé. 5.3 Identification des parties prenantes Toutes les parties prenantes côté client et côté fournisseur doivent être identifiées. Les groupes d intérêt doivent être définis. Pour les organismes de formation : explication de l identification et de l évaluation des parties prenantes 21
5.4 Techniques pour identifier les exigences But de l identification des exigences (K 2) Identifier toutes les fonctions, caractéristiques, limitations et attentes désirées Orienter les exigences vers la vision du projet Les fonctions doivent être décrites clairement Les fonctions que le client ne veut pas doivent être exclues Techniques (K 1) Questionnaires Entretiens Auto-enregistrement Représentants du client sur site Identification sur la base de documents existants Réutilisation (Réutiliser la spécification d un certain projet) Brainstorming Observation terrain Apprentissage Ateliers après chaque processus spécifié Pour les organismes de formation : les techniques, incluant la description des avantages et des inconvénients Pour les organismes de formation : description des méthodes de questionnaire pour les entretiens 22
5.5 Exigences fonctionnelles et non fonctionnelles Exigences fonctionnelles (K 2) Description des fonctions du système Déclencher un processus Exigences non fonctionnelles (K 2) Décrire les attributs des fonctions ou leurs caractéristiques qualité Difficile à décrire, donc souvent formulées en termes vagues Souvent difficile à suivre et à tester Description claire et précise nécessaire pour la validation Pour les organismes de formation : exemples d exigences fonctionnelles et non fonctionnelles Caractéristiques qualité selon l ISO 9126: (K 2) Fonctionnalité, fiabilité, facilité d utilisation, efficacité, maintenabilité, portabilité Pour les organismes de formation : détailler les caractéristiques qualité Pour les organismes de formation : description des limitations (par exemple les spécifications techniques) 5.6 Descriptions des Exigences Contenu du texte d une exigence : Qui? Quoi? Comment? Quand? Avec qui? Touchés par quoi? Aides importantes pour la création du document d exigences (K 2) Les exigences doivent être non ambigues, précises et compréhensibles Les informations superflues doivent être évitées 23
Des modèles peuvent être utilisés comme une aide pour restreindre le langage Contenu standard d un document d exigences (K 1) Introduction Clause de confidentialité Réglements Standards Parties prenantes Objet du produit Description du système Exigences fonctionnelles Exigences non fonctionnelles Hypothèses Dépendances Risques Exigences de sureté de fonctionnement Attributs de qualité logicielle Acceptation Construction d une exigence (K 2) 1. Determination du processus 2. Classification de l activité du système 3. Determination de l engagement juridique 4. Rafinement du processus 5. Contraintes de logique et de temps Pour les organismes de formation : description des étapes particulières de la construction d une exigence 24
6 Specification des exigences Objectifs d apprentissage Qu est-ce que la spécification d une exigence? Qu est-ce qui caractérise la spécification d une exigence? Qu est-ce qu une spécification de solution? Qu est-ce qui caractérise une spécification de solution? Quels standards sont importants pour les spécifications d exigence et les spécifications de solution? Quelle est la procédure typique lorsqu il s agit de la spécification des exigences? Quels sont les différents niveaux de formalisation pour la spécification d exigences? Quelles peuvent être les conséquences des erreurs dans les exigences? Quelles sont les possibilités pour éviter les erreurs dans les exigences? 6.1 Spécification Dans la spécification, les exigences sont spécifiées de manière structurée et sont modélisées séparément. La spécification sert pour suivre et gérer les exigences. Spécification d exigences (K 2) Comprend la spécification de ce qui doit être développé La création devrait être une tâche client Spécification de la solution (K 2) Comprend les spécifications fonctionnelles La base du développement futur du système Standards importants (K 1) 25
IEEE 1362 (spécifications de performance système), IEEE 830 (spécification d exigences logicielles) - IEEE 1233 (spécifications fonctionnelles système) Pour les organismes de formation : description détaillée des spécifications de performance et des spécifications fonctionnelles 6.2 Procédure Spécification comme une activité pour formaliser les résultats d une analyse des exigences (K 2) Pour les organismes de formation : description des étapes pour la spécification de problèmes et de solutions (déterminer l espace de la solution, décrire les contacts clients, etc.) La phase d identification est terminée quand tous les accords nécessaires au projet ont été signés 6.3 Formalisation Different niveaux de formalisation Non-formel Semi-formel Formel Pour les organismes de formation : description et différentiation des niveaux de formalisation (K 2) 26
6.4 Qualité des Exigences Les erreurs d exigences comme la cause de coûts élevés (K 2) Plus les erreurs sont découvertes tard, plus elles coûtent cher Par conséquent, utilisation de la vérification manuelle (le produit est-il développé correctement?) et de la validation manuelle (le produit développé est-il le bon?) Pour les organismes de formation : description de mesures pour l amélioration de la qualité et pour l assurance qualité 27
7. Analyse des exigences Objectifs d apprentissage Quel est le but de l analyse des exigences? Quelles est la procédure lors de l analyse des exigences? Quels sont les différents modèles d analyse d exigences? Qu est-ce qui caractérise UML? Qu est-ce qui caractérise SysML? Quelle est la raison de l estimation du coût? Quels sont les facteurs importants pour l estimation des coûts? Quelle est la procédure lors de la priorisation? Qu est-ce qui devrait être considéré lors de l accord sur les exigences? 7.1 Exigences et Solutions But de l analyse des exigences : solution pour l implémentation des exigences (K 2) Procédure: 1. Analyse des besoins 2. Description de la solution 3. Estimation du coût et priorisation 7.2 Méthodes et Techniques Différents aspects du système sont représentés par différentes vues Les modèles sont développés par des méthodes appropriées d analyse Différentiation entre les types de modèles (K 2) 28
Modèles d exigences Modèles de solution Pour les organismes de formation : description détaillée des deux types de modèles et de leurs vues Différents modèles (K 1) Modèle de contexte Décomposition fonctionnelle Modèle de flot de données Modèle état-transition Réseau de pétri Modèle entité-relation Pour les prestataires de formation : description détaillée des différents modèles 7.3 Analyse orientée objet UML (Unified Modeling Language) UML fournit des diagrammes pour les différentes vues d un système Diagrammes de cas d utilisation, diagrammes de classe, diagrammes d activité, diagrammes d état, diagrammes d objet, diagrammes de composant, diagrammes de paquetage, etc. Pour les organismes de formation : exemples de diagrammes (au moins pour les diagrammes de cas d utilisation, les diagrammes de classe, les diagrammes d activité et les diagrammes d état) SysML (System Modeling Language) comme une extension d UML 29
7.4 Estimations du coût Les estimations de coût relient l Ingénierie des Exigences à la gestion de projet Types d estimations (K 2) Coûts Temps Exigences Qualité Les estimations de coût aident pour reconnaitre le coût du changement Pour les organismes de formation : description des facteurs déterminants pour les coûts de développement Procédure d estimation (K 1) Conclusions par analogie Procédure algorithmique Procédure des points de fonction Modèle de coût par déduction Méthode Delphi Pour les organismes de formation : explication de ces procédures d estimation Les procédures d estimation sont toujours basées sur des données historiques et des conditions prédéfinies 7.5 Prioritisation Procédure 1. Regroupement des exigences 30
2. Analyse des exigences 3. Création du plan projet 4. Test des incréments 7.6 Entente sur les exigences Accords (K 2) Accord formel comme base de projet La liste des exigences doit faire partie d un engagement Une revue continue de la liste des exigences est nécessaire Pour les organismes de formation : description des avantages des allocations des exigences sur engagement 31
8. Suivi des exigences Objectifs d apprentissage Qu est-ce que la traçabilité? Pourquoi les exigences continuent-elles à se développer? Quel est le but de la traçabilité? Quels sont les types de traçabilité? Qu est-ce qui caractérise la gestion du changement? Comment est constitué le comité de contrôle du changement? Que sont les métriques? Qu est-ce qui rend les métriques possibles? 8.1 Suivi au sein du projet Traçabilité (K 2) Les exigences ne sont pas stables et elles continuent de se développer Les raisons d un développement continu Nouvelles idées Nouveaux besoins client Travail en continu Nouvelles connexions au sein du projet Traçabilité comme une solution : Permet de vérifier que toutes les étapes du processus de développement ont été réalisées Buts : analyse d impact, analyse de couverture, analyse de la nécessité des exigences, preuve d implémentation, utilisation des exigences, etc. 32
Afin d assurer une bonne traçabilité, il est important d identifier les exigences de façon précise. Types de traçabilité Traçabilité horizontale et verticale Pour les organismes de formation : décrire ce qu est une traçabilité horizontale et verticale 8.2 Gestion du Changement Changements des exigences (Gestion du changement) (K 2) Les changements sont vérifiés et décidés par un comité de contrôle du changement Prise de décision concernant les demandes de changement Le comité de contrôle du changement est constitué de (K 1) La gestion de projet Le développement L assurance qualité La gestion métier, si nécessaire Le client, si applicable etc. Pour les organismes de formation : tâches du comité de contrôle du changement Un processus structuré est nécessaire pour les changements des exigences L analyse de la signification de chaque changement est importante. Des solutions hatives sont problématiques. Des changements conséquents d exigences peuvent être si importants qu ils nécessitent des modifications contractuelles. 33
Pour les organismes de formation : description du cycle de vie d une exigence Pour les organismes de formation : expliquer l impact des changements d exigences Pour les organismes de formation : distinction entre la gestion d erreur et la gestion du changement 8.3 Métriques Les métriques permettent de présenter de façon quantifiable l état d un projet ainsi que la qualité Les résultats de classification doivent toujours être comparés aux données de référence Métriques pour les exigences : (K 1) Coûts du projet Suivi du projet Stabilité du projet Amélioration de processus Qualité de la spécification Nombre d erreurs Type d erreur Mesure de la qualité des exigences : (K 2) Les exigences sont-elles correctes? Les exigences sont-elles compréhensibles? Plus le changement est important, plus le projet est risqué 34
9. Assurance Qualité Objectifs d apprentissage Quels facteurs influencent l Ingénierie des Exigences? Comment l assurance qualité peut-elle être améliorée? Quels sont les critères d acceptation? Quelles méthodes existent pour l assurance qualité? 9.1 Facteurs d influence Certains facteurs influencent le succès de l Ingénierie des Exigences : (K 2) Le produit en cours de développement L environnement dans lequel le produit est réalisé L industrie La pression du délai La pression du coût Les facteurs sociaux De tels facteurs doivent être pris en compte quand ils concernent l assurance qualité 9.2 Assurance qualité via testabilité L ingénierie des Exigences est présente sur tout le cycle de vie L ingénierie des Exigences est fortement couplée au test. De bons cas de tests nécessitent de bonnes exigences à tester (L implication des testeurs dans la spécification est donc très importante) (K 2) Critères d Acceptation Chaque exigence a au moins un critère d acceptation 35
C est la base du test d acceptation Méthodes: Couverture fonctionnelle Classes d équivalence Pour les organismes de formation : description des méthodes 36
10. Outils Objectifs d apprentissage Comment les outils peuvent-ils supporter l Ingénierie des Exigences? Quelles activités de l Ingénierie des Exigences peuvent être prises en charge par les outils? Quelles sont les exigences sur les outils utilisés pour l Ingénierie des Exigences? Qu est-ce qui doit être pris en compte dans le coût des outils? 10.1 Avantages des outils Les outils pour le stockage et la gestion des exigences facilitent l Ingénierie des Exigences. Ils peuvent offrir des activités automatiques et assurer une vue d ensemble. Il est ainsi possible de garder des documents statiques complexes cohérents et actuels. La sélection d un outil doit intervenir avant que le produit ne soit développé. Sinon, cela peut causer des problèmes importants. (K 2) Pour les organismes de formation: description des exigences imposées sur les outils associés au domaine de l Ingénierie des Exigences Pour les organismes de formation : description des activités de l Ingénierie des Exigences qui peuvent être prises en charge par l utilisation d outils 10.2 Catégories d outils Traitements de texte, tableurs MS Excel, MS Word, etc. Outils de modélisation Outils de gestion des exigences Outils de gestion des erreurs 37
Outils Open Source Le coût des outils peut varier considérablement. Le choix d un outil doit donc être fait avec précaution. Un choix hatif peut entrainer des coûts élevés. (K 2) 38
11. Littérature Beck, Kent: Extreme Programming. Munich 2003 Beck, Kent: Extreme Programming Explained: Embrace Change. Boston 2000 Beck, Kent: Test Driven Development. By Example. Amsterdam 2002 Beck, Kent: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman 1999 Boehm, Barry: Software Engineering Economics. Englewoods Cliffs, NJ 1981 Bundschuh, Manfred; Fabry, Axel: Aufwandschätzung von IT-Projekten. Bonn 2004 Cockburn, Alistair: Agile Software Development. Addison Wesley 2002 Cockburn, Alistair: Writing Effective Use Cases. Amsterdam 2000 DeMarco, Tom et al.: Adrenalin-Junkies und Formular-Zombies Typisches Verhalten in Projekten. Munich 2007 DeMarco, Tom: Controlling Software Projects: Management, Measurement and Estimates. Prentice Hall 1986 DeMarco, Tom: The Deadline: A Novel About Project Management. New York 1997 Ebert, Christof: Systematisches Requirements Management. Anforderungen ermitteln, spezifizieren, analysieren und verfolgen. Heidelberg 2005 Evans, Eric J: Domain-Driven Design: Tackling Complexity in the Heart of Software. Amsterdam 2003 Graham, Dorothy et al: Foundations of Software Testing. London 2007 Gilb, Tom; Graham, Dorothy: Software Inspection. Reading, MA 1993 Hull, Elizabeth et. All: Requirements Engineering. Oxford 2005 IEEE Standard 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology IEEE Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications IEEE Standard 829-1998 IEEE Standard for Siftware Test Documentation 39
IEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements Specifications IEEE Standard 1362-1998 IEEE Guide for Information Technology-System Definition Concept of Operations (ConOps) Document IEEE Standard 1220-1998: IEEE Standard for Application and Management of Systems Engineering Process ISO 9000 ISO 9126 ISO 12207 ISO 15288 ISO 15504 Jacobsen, Ivar et al.: The Unified Software Development Process. Reading 1999 Lauesen, Soren: Software Requirements: Styles and Techniques. London 2002 Mangold, Pascal: IT-Projektmanagement kompakt. Munich 2004 McConnell, Steve: Aufwandschätzung für Softwareprojekte. Unterschleißheim 2006 Paulk, Mark, et al: The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA 1995 Pfleeger, Shari Lawrence: Software Engineering: Theory and Practice, 2 nd edition. Englewood Cliffs, NJ 2001 Pohl, Klaus: Requirements Engineering. Grundlagen, Prinzipien, Techniken. Heidelberg 2007 Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide). PMI 2004 Robertson. Suzanne; Robertson, James: Mastering the Requirements Process, Harlow 1999 Rupp, Chris: Requirements-Engineering und Management. Professionelle, Iterative Anforderungsanalyse in der Praxis. Munich 2007 Sommerville, Ian: Requirements Engineering. West Sussex 2004 40
Sommerville, Ian: Software Engineering 8. Harlow 2007 Sommerville, Ian; Sawyer, Pete: Requirements Engineering: A Good Practice Guide. Chichester 1997 Sommerville, Ian; Kotonya, Gerald: Requirements Engineering: Processes and Techniques. Chichester 1998 Spillner, Andreas et all: Software Testing Foundations. Santa Barbara, CA 2007 Thayer, Richard H.; Dorfman, Merlin: Software Requirements Engineering, 2 nd edition. Los Alamitos, CA 1997 V-Modell XT: http://www.vmodellxt.de/ Wiegers, Karl E.: Software Requirements. Redmond 2005 Wiegers, Karl E.: More About Software Requirements: Thorny Issues and Practical Advice. Redmond, Washington 2006 41