Ingénierie des Exigences Enjeux, Principes et Bonnes Pratiques FANMUY Gauthier gauthier.fanmuy@adn.fr Conférence AFIS, 23-25 septembre 2009 06 10 76 29 06
Sommaire Du rapport Chaos à la réalité du terrain La mise en œuvre de bonnes pratiques d Ingénierie des Exigences 2
Du rapport CHAOS, 3
à la réalité du terrain Maturité Aéronautique & Défense Automobile Dispositifs médicaux Pharmaceutique Temps 4
Mais quelle est la réalité de la réalité terrain? des situations très variables! Les exigences sont validées. Les échéances projet sont respectées les exigences sont déclinées dans la conception. Elles sont la référence pour la conception des s/ensembles Les exigences sont de qualité et respectent le MUST J ai pour consigne de ne pas faire évoluer le CdC. Je fais mes modifications (sans en informer le chef de projet). J ai bien fait ma spécification comme on me l a demandé. Je ne sais pas bien ce que les autres Métiers ont demandé, de toutes façon je n ai pas le temps de faire mieux J ai défini des templates. J ai confié l écriture des exigences aux utilisateurs. Mes exigences sont inhomogènes et de qualité variable. 5
Facteurs influents Changement de culture Compréhension ou de non assimilation des fondamentaux, Fonctionnement dans l urgence empêchant une mise en application, Problèmes politiques pouvant conduire à masquer des situations réelles, Peur d aller de l avant ne sachant par quel bout traiter le problème etc. Conséquence : Ralentissement voire inefficacité de la mise en place d un processus d Ingénierie des Exigences 6
L Ingénierie des exigences Produit attendu Données d entrée : attentes parties prenantes, réglementations, contraintes Expertise et référentiels des métiers Conception du Produit Optimisation, fluidification du processus pour: limiter la Non Valeur Ajoutée converger plus rapidement Collecte des données d entrée Mise en cohérence, équilibrage Déclinaison progressive des objectifs CDC FNR* Réponse FNR Δ Améliorer la collecte des besoins et des exigences définition des objectifs et contraintes des parties prenantes définition des objectifs par l analyse des risques Assurer la traçabilité de la déclinaison des exigences convergence des objectifs ciblage des tests Mieux maîtriser l interface avec les fournisseurs (FNR) pour: limiter les écarts entre le produit attendu et le produit réalisé. maîtriser la conformité du produit réalisé à partir d un contrat de référence Bons directs et juste à temps Produit réalisé La mise en œuvre de ces principes peut apparaître comme complexe. *Fournisseurs externes et internes L application de pratiques très simples peut avoir un effet de levier important 7
Cas d utilisation: «Aidez-moi, je suis perdu» Vous avez lu une spécification de 125 pages Arrivé à la fin du document vous avez perdu le fil Que faire? Check list 1. Quel est le type de système? 2. Quelle est la nature de la spécification? 3. La spécification est-elle équilibrée? 4. Y-a-t-il un diagramme de contexte? 5. Y-a-t-il une description de comment le système sera utilisé? 6. Comment sont organisées les exigences dans le document? 7. Est-ce que les exigences sont identifiées? 8. Les exigences sont-elles au même niveau d importance? 9. Est-ce que les exigences d interface sont spécifiées? 10. Est-ce que les exigences sont conformes au MUST (Mesurable, Utile, Simple, Traçable)? 8
Q1: Quel est le type de Système? Catégorie 3 Produit sur étagère User Requirements Specification Catégorie 4 Produit configuré User Requirements Specification Functional Specification Configuration Specification Catégorie 5 Produit sur mesure User Requirements Specification Functional Specification Design Specification Source: ISPE GAMP 5 - Good Automated Manufacturing Practices 9
Q2: Nature de la spécification? Besoins Spécification URS FS Validation Utilisation Vérification Conception Spécification DS Réalisation Intégration Réception URS contient les besoins des parties prenantes, les processus Métiers, les cas d utilisation FS définit les exigences techniques du système, les interfaces externes : le «quoi» DS définit les contributions des sous-systèmes sous forme d exigences, les interfaces internes, contient l architecture fonctionnelle et physique du système: le «comment» Selon la nature du document, les informations y figurant peuvent être de nature ou de degré de précision différent Omissions Détail inapproprié / niveau d abstraction 10
Q3: Equilibrage de la spécification??? URS/CdC d une ligne d étiquetage C est évident! Moins d une page sur le fonctionnement De la solution (conception) dans les exigences Des parties prenantes oubliées: maintenance, logistique Idem pour la réglementation (audit trail ) Pas de documents de référence Omissions Engagement sur la solution 11
Q4: Diagramme de contexte? user Pressure sensor Temperature sensor Graphical views Reports Identification Selections Commands Pressure data Temperature data System Supervision SCSE environnement Alarms TOR Audio Alarm Viusal Alarm Centralised Supervision System Audio System Traduit la maturité du spécificateur, donc de la qualité de la spécification Le périmètre de la spécification est connu Les systèmes en interface sont identifiés Les interfaces sont identifiées Humidity data Humidity sensor Périmètre du système Flash Lamp Interfaces avec le système Inclusions / exclusions involontaires Omissions, Ajouts hors périmètre 12
Q5: Description de l utilisation du système? {21 CFR Part 11 11.10 (e)(i) BPF-EU 2.7} Système SCSE Supervision Sécuriser Environnement: le système Sécurisation {Contrainte} <<includes>> Paramétrer le système Sécuriser le système <<includes>> Gérer les profils Administrateur <<includes>> {Contrainte} {Contrainte} {21 CFR Part 11 300 } Gérer les accès {21 CFR Part 11 11.10 (d) } Un cas d utilisation représente un service global fourni par le système à un acteur. Il décrit le système du point de vue de son utilisation: ne constitue pas une spécification, permet de comprendre le besoin et d enrichir les exigences de la spécification Mauvaise compréhension du besoin 13
Q6: Organisation des exigences? La compréhension du problème posé nécessite d expliquer : L objectif du système: «à quoi ça sert» Dans quel contexte: «pourquoi, dans quelles conditions, pour quel scénario» Avec quelles fonctionnalités : «quels services / fonctions» Avec quelles caractéristiques : «quelles performances» Avec quels systèmes: «quelles interfaces» Sous quelles contraintes: «quelles réglementations, règles Métiers, contraintes industrielles» Le tout sans tomber dans le piège de description de la solution technique! Cette compréhension doit être progressive Du global vers le détaillé 14
Q6: Organisation des exigences? 15
Q6: Organisation des exigences? Contexte Références Scénarios Fonctions Interfaces Mauvaise compréhension du besoin Omissions 16
Q7: Exigences identifiées? Les exigences sont identifiées, mais l identifiant est basé sur un numéro de paragraphe: non robuste Un identifiant doit être neutre. Exemple Bat1-SENV-URS.015 Instabilité des références d exigences dans le temps 17
Parties prenantes identifiées. Exigences collectées. Q8: Niveau d importance? PERSONNES Priorisation des exigences: rangs d exigences = f(besoins, conception, contraintes) Diversité d information et de structure Objectif du système défini. Exigences sélectionnées. Problème posé (réglementaire, priorité des parties prenantes, impact conception, ) Déclinaison des exigences. Se perdre face à la quantité d information INGENIERIE Concept «Hour Glass» (source J. Dick) Information formalisée et structurée Conception de la solution 18
Q9: Exigences d Interfaces? Les interfaces sont les risques les plus élevés de tout projet ou programme Identifier toutes les interfaces : cf. diagramme de contexte Pas seulement lié au logiciel Fonctionnel Mécanique Electrique Protocole Messages / données Spécifier au bon niveau de détail selon la nature des documents et leur position dans le projet Intégration du système dans son environnement impossible 19
Mesurable Utile Simple Traçable Q10: Conformité au MUST? Il existe une méthode de test du produit par rapport à l exigence (inspection, analyse, démonstration, test physique ou numérique ) Information unique et explicitement identifiée Information strictement nécessaire Information précise Pas d information inutile ou superflue, formulation claire et précise. Comprise de la même façon par les parties prenantes et acceptée Permettre de retrouver la source de l exigence, retrouver la transformation du besoin à tous les niveaux du développement (allocations y compris). Permettre de retrouver la justification de l exigence Permettre de retrouver les tests mis en œuvre vis-à-vis de l exigence L'ensemble des exigences doit être : Complet Cohérent Structuré Besoins totalement exprimé et couvert par les exigences système Pas de contradictions entre les exigences Informations structurées pour faciliter la lecture / l analyse et les mises à jour 20
Le MUST: Simple Etre le plus synthétique possible Les aspects techniques sont présentés dans un langage ne comportant pas de termes vagues ou ambigus. On utilise les mots les plus précis mais simples. On évite : les termes génériques, vide de sens (exemple : gérer), les adjectifs non mesurables et non quantifiables (ex. certains, plusieurs, rapide, correcte, quelques, divers ) les adverbes non mesurables et non quantifiables (ex. peu, beaucoup, assez, moins, plus, souvent, parfois, longtemps, aussitôt, rapidement ) le recours aux synonymes et utiliser le terme «déposé» (cf. glossaire) les phrases sont simples, concises, courtes. Elles doivent : traiter un seul aspect, ne pas contenir d'ellipse (suppression d'un des éléments nécessaire à une construction sémantique complète), ne pas contenir des clauses multiples. Les phrases comportant des clauses multiples seront converties en phrases séparées. Des exigences ambigües source d anomalies sur le produit 21
Conclusion Les exigences sont au cœur de la gouvernance des projets Elles formalisent à tous les niveaux de décomposition d un système : l'expression des besoins et des engagements des parties prenantes les attendus d un système vis à vis de ses sous-systèmes les interfaces entre sous-systèmes les contraintes induites par les sous-systèmes sur le système Un déploiement efficace est un déploiement progressif du processus outillé Déploiement en YU Processus d IE Outils intégrés Amendement du Processus Définition du processus outillé Consolidation par l expérimentation Paramétrage et évolution des outils 22
Très prochainement QUESTIONS? Contact: gauthier.fanmuy@adn.fr, 0610762906 23