5/20/2014 Centre de recherche LGI2P - Ingénierie Système Ingénierie des besoins des parties prenantes et des exigences techniques Nicolas Daclin Ecole Nationale Supérieure des Mines d’Alès Laboratoire de Génie Informatique et d’Ingénierie de la Production Ecole d’été CA’NTI #20, 26 – 30 mai 2014, Bucarest, Roumanie Présentation • Nicolas Daclin, Dr Maître assistant Ecole Nationale Supérieure des Mines d’Alès LGI2P (Laboratoire de Génie Informatique et d’Ingénierie de Production) Equipe ISOE (Interoperable System and Organisation Engineering) +33 466 387 039 [email protected] www.mines-ales.fr / lgi2p.mines-ales.fr 2 1 5/20/2014 Ingénierie des exigences (Requirements Engineering): pourquoi? • Mars Climate Orbiter (1999) Extrait du CdC initial: o Etude météorologique de la planète Mars o Etude de l’atmosphère de la planète Mars Bilan: o Destruction du matériel o 125 millions de $ partis… en fumée o 1 cliché de la planète Mars Problème: o Erreur de transfert d’informations entre deux logiciels (un logiciel calcule des paramètres avec le système de mesure anglo-saxon (pouces, pieds…), l’autre attend les informations dans le système métrique) Source: http://www.jpl.nasa.gov 3 Ingénierie des exigences: pourquoi? • Therac 25 (1985 - 1987) Extrait du CdC initial: o Traitement de tumeurs cancéreuses par rayon X Bilan: o Surexposition des patients aux radiations (~100 x dose normale) o 3 blessés graves (pertes de fonctions motrices, brûlures) o 3 morts Problèmes: o o o o Mauvais développement logiciel/ technique Pauvreté du processus d’ingénierie Manque de spécifications Défauts de procédure de test Source: http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html 4 2 5/20/2014 Ingénierie des exigences: pourquoi? The ∅ resund bridge (1996 – 2000) • Extrait du CdC initial: o Pont reliant la Suède au Danemark o Transport ferroviaire et routier Bilan: o Planification (temps, budget, qualité, + 4000 schémas) o Définition des exigences – Durée de vie : 100 ans – Vitesse train/véhicule : 200km/h, 120 km/h – Environnement : vent (61 m/s), vague (2,5 m) température (+/- 27° C) – Évaluation des solutions par rapport aux exigences – Application des principes de l’IS : « an award-winning bridge! » 5 Problématique de l’ingénierie des exigences • L’ingénierie des exigences est souvent négligée parce que… Les acteurs ne savent pas quoi faire o Comment écrire une exigence? o Quel est le processus? Les acteurs ne comprennent pas pourquoi les exigences sont nécessaires o Ils ne comprennent pas l’impact o Les exigences sont justes des évidences o C’est un document de plus à rédiger… Les acteurs préfèrent faire autre chose o Ils n’ont pas de temps à perdre o Ils verront plus tard… pendant la phase opérationnelle Source: G.V. Bochmann, Writing better requirements, université d’Ottawa, 2010 Willis J., Systems Engineering and the forgotten ‘-Illities, 2011 6 3 5/20/2014 Importance de l’ingénierie des exigences • Selon, le Standish Group: L’ingénierie des besoins et des exigences est la principale cause de l’échec (annulation avant la fin) ou de difficultés (hors budget/délais, moins de fonctionnalités) d’un projet… mais… L’ingénierie des besoins et des exigences est également la principale cause du succès d’un projet! Source: www.standishgroup.com, the Chaos report 7 Ingénierie des exigences « Activité méthodique collaborative et pluridisciplinaire - fondée sur la science et l’expérience – permettant de recueillir, de spécifier, d’affiner, de qualifier des exigences relatives à un système à positionner dans son environnement et de maîtriser les évolutions de ces exigences dans le temps pour apporter une solution globalement optimisée à des besoins identifiés. » 8 4 5/20/2014 Processus de définition des besoins des parties prenantes 1. 2. Principes et concepts relatifs aux besoins Processus de définition des besoins des parties prenantes 9 Positionnement du processus Rechercher des concepts pertinents ou innovants Ingénierie Système Définir les besoins des parties prenantes Définir les exigences techniques Vérifier Evaluer Optimiser Qualifier Valider Concevoir l’architecture organique Vérifier Concevoir l’architecture fonctionnelle Assembler Réceptionner Intégration Système Réalisation: Ingénierie Métiers Fabriquer Réutiliser Acheter 10 5 5/20/2014 Les enjeux Quelle est la première perception que nous avons de la qualité d’un produit ou d’un service? L’aptitude à satisfaire les besoins exprimés ou non. 1. 2. • Nécessité de collecter les besoins Nécessité d’exprimer les besoins Deux principes fondamentaux : Il n’y a pas de besoin s’il n’y a pas de problème à résoudre! Il faut dans un premier temps préciser le problème pour fournir un premier cadrage. Il faut penser le besoin et non la solution. Généralement nous avons tendance à définir les besoins au travers des solutions que nous entrevoyons… 11 Définition Besoin (exigence initiale) : • • • • • • • Nécessité ou désir exprimé par un utilisateur, ou par toute partie prenante intéressée par l’utilisation ou l’exploitation du système. Exprimé dans le langage de la maîtrise d’ouvrage (MOA). Need and expectation, stakeholder requirement, user requirement, initial requirement. Un besoin naît d’un manque, d’une insatisfaction, d’une attente. La réponse à un besoin est un ensemble d’action. Le besoin est valide lorsque son utilité est reconnue par les parties prenantes et qu’il est possible de le justifier auprès de ces mêmes parties prenantes. 50 à 80 besoins de haut niveau. 12 6 5/20/2014 De l’utilité de la définition des besoins des parties prenantes • La définition des besoins permet d’avoir une compréhension commune du problème qui doit être résolu. • Pour la maîtrise d’ouvrage: Définir clairement ses besoins et ses attentes. Etre compris par la maîtrise d’œuvre. • Pour la maîtrise d’œuvre: Comprendre clairement ce qu’il y a à faire et pourquoi. Etre compris par la maîtrise d’ouvrage. 13 Provenance des erreurs et coûts de correction Production des erreurs Coût relatif de correction Nombre d’erreurs produites à un instant donné exigences source: MAP système conception Coût relatif de correction d’une erreur au même instant réalisation essais maintenance Source des erreurs 14 7 5/20/2014 Expression des besoins : une opération complexe • Aspects relationnels avec de multiples parties prenantes pour exprimer les besoins et contraintes et rechercher des consensus. • Aspects d’analyse et de recadrage des besoins pour identifier les incohérences ou antagonismes entre besoins. • Aspects d’analyse de l’existant avec la prise en compte de l’environnement d’exploitation dans lequel opérera le système. • Aspects d’analyse de missions, de validation et de simulation de scénarii. • Aspects d’analyse de l’impact du système sur son environnement et vice versa. • Etudes de marché, sondages, études prospectives. • Analyse de faisabilité. 15 Expression des besoins: difficultés • • • • • Identification: le besoin est mal identifié, défini ou exprimé. Incompréhension: mauvaise compréhension de la relation clientfournisseur. Séparation: il n’existe pas de séparation claire entre le problème et la solution. Communication: difficulté de communication entre les parties prenantes. Perception négative: perception négative du problème à résoudre. 16 8 5/20/2014 Expression des besoins: attributs • Les attributs sont des caractéristiques pour compléter les besoins en vue de leur gestion: Identificateur: symbole alphanumérique pour repérer les besoins parmi les autres. Il est unique. Importance: importance du besoin pour les parties prenantes (essentiel, obligatoire, optionnel). Criticité: importance du besoin pour la sécurité ou la fiabilité du système. Flexibilité: o Niveau impératif: la non satisfaction entraine l’incapacité à réaliser la mission ou des risques non acceptables pour le système ou l’environnement. o Niveau souhaité (taux d’échange): prise en compte des moyens complémentaires pour obtenir la satisfaction (e.g. coût – quel complément de prix pour tel besoin?). Identificateur Expression B.S.1 Le système protège des radiations Importance Criticité (0,1,2,3) obligatoire 3 17 Retour sur… l’importance des besoins et les conséquences Satisfaction Satisfaction client Neutre Insatisfaction Absent Diagramme de Kano Complet Degré d’implémentation 18 9 5/20/2014 Classification des besoins: typologie Services attendus: les actions à effectuer pour réaliser la mission du système. Performances (efficacité): ensemble des performances liées aux services attendus. Interfaces: flux échangés et connexions physiques du système avec le contexte. Opérationnels: conditions dans lesquelles le service est rendu: • • • • Sécurité, Ergonomie, Facteurs humains, Sûreté de Fonctionnement (SdF), Environnement… Contraintes: limitations engendrées par les systèmes contributeurs, dimensions physiques, règlements… • • La classification des besoins peut permettre une meilleure traçabilité de ceux-ci. Cependant, mieux vaut avoir tous les besoins pêle-mêle que d’en oublier… 19 Approches et outils méthodologiques pour la définition des besoins • • Définition d’un langage commun (thésaurus) Technique d’interview Interview non directive centrée Interview de groupe non directive centrée • • • • • Technique de recherche de consensus Technique de recueil d’expertise Technique de maquettage Technique d’analyse fonctionnelle Sensibilisation à la valeur des besoins et contraintes exprimés 20 10 5/20/2014 Définition des besoins: principes pour la collecte Quelques principes pour la collecte des besoins des parties prenantes: • Ecoute organisée des parties prenantes (identification des personnes, organisation de réunion de groupe). Recueil des faits uniquement, sans opinion ni interprétation. Reformulation par hypothèses des faits avec validation de ces hypothèses auprès des parties prenantes. Focalisation sur l’essentiel. Travail en groupe. 21 Vérification et validation des besoins • Vérification Maturité: le besoin exprimé n’est-il pas trop éloigné du besoin perçu? Exhaustivité: tous les besoins des parties prenantes sont-ils exprimés? Justesse: les parties prenantes reconnaissent-elles une formulation fidèle de l’expression de leurs besoins? Faisabilité: des concepts d’opérations peuvent-ils être identifiés pour estimer la faisabilité à résoudre le problème exposé? Traduisible: le besoin exprimé peut-il être traduit en exigence technique? Cohérence: existe-t-il des contradictions entre les besoins exprimés? Pertinence: le besoin exprimé permet-il de définir la pertinence d’une réponse au problème? • Validation Pourquoi ces besoins? Quel est le risque qu’ils disparaissent? Pour quelle(s) cause(s)? 22 11 5/20/2014 Le processus de définition des besoins des parties prenantes • Processus complexe Subjectif • Objectif Résultats attendus: Ensemble des attentes, désirs, exigences représentant les besoins des clients, des utilisateurs / opérateurs. Les contextes d’utilisation des utilisateurs / opérateurs. Une base pour établir les exigences techniques. Une base pour établir l’acceptation opérationnelle des produits et services à fournir. 23 Le processus de définition des besoins des parties prenantes (2) Enquêtes, interview Analyse et définition des besoins Identifier les situations de vie et les parties prenantes Définir la finalité et la mission du système Définir les limites fonctionnelles du système Définir les scénarios opérationnels Définir les limites physiques du système (interfaces) Définir les besoins opérationnels Quantifier et classer les besoins et les contraintes Définir les concepts d’opérations ou technologiques Exprimer les besoins unitairement Définir les objectifs Vérifier la cohérence, l’exhaustivité et la traçabilité Document expression des besoins source: MAP système 24 12 5/20/2014 Plan type de documentation d’expression des besoins 1. Introduction a) b) c) 2. Présentation du système a) b) c) 3. Objet Documents (documents en référence, documents applicables) Terminologie Finalité, mission, objectifs Contexte organique et fonctionnel du système Parties prenantes Besoins des parties prenantes a) b) Modes opérationnels et scénarios Besoins opérationnels o c) Services attendus, performances, autonomie, durée de vie, interactions et connexions physique avec les éléments du contexte, facteurs humains et ergonomie, sûreté de fonctionnement, sécurité de l’information, moyens, transport, stockage Contraintes des systèmes contributeurs o Réalisation, mise en service, retrait de service, soutien logistique et maintenance, production, réglementation, coûts, délais, validation 25 Risques majeurs au stade de l’élaboration des besoins • Mauvaise identification du système Niveau d’abstraction trop haut (sur-système) ou trop bas (sous-système) Arrêt du développement et retour au bon niveau • Mauvais ciblage du périmètre Éléments ajoutés ou oubliés dans le système Produit inadapté ou refus du produit par les utilisateurs Oubli d’interfaces Oubli de connexions physiques Produit non interopérable • Absence ou insuffisance de modes et scénarios opérationnels Validation conflictuelle, mise en service retardée, développement retardé • Incomplétude des besoins, oubli des parties prenantes • Mauvaise classification des besoins Développement retardé, validation conflictuelle Perte de temps pour la maîtrise d’œuvre, coût de développement plus cher source: MAP système 26 13 5/20/2014 Processus de définition des exigences techniques 1. 2. 3. Principes et concepts relatifs aux exigences techniques Gestion des exigences techniques Processus de définition des exigences techniques 27 Rappel et positionnement du processus Rechercher des concepts pertinents ou innovants Ingénierie Système Définir les besoins des parties prenantes Définir les exigences techniques Vérifier Evaluer Optimiser Qualifier Valider Concevoir l’architecture organique Vérifier Concevoir l’architecture fonctionnelle Assembler Réceptionner Intégration Système Réalisation: Ingénierie Métiers Fabriquer Réutiliser Acheter 28 14 5/20/2014 Rôles des exigences L’élaboration des exigences joue deux rôles • 1. 2. Identifier le travail de conception à réaliser Servir de référence à la justification et à la validation Elaboration des exigences 1 Que faut-il faire? Conception Justification Pourquoi cela est nécessaire? 2 29 Définition Exigence: • Enoncé qui spécifie une aptitude, une caractéristique ou une limitation d’un système, d’un produit ou d’un processus, pour contribuer, dans des conditions d’environnement données, à la satisfaction d’un but. • Exprimée dans le langage de la maîtrise d’œuvre (MOE). • Requirement. • Caractéristiques de base d’une exigence: • Unicité: elle ne traite que d’un sujet Précision: elle est rigoureuse dans son expression Non-ambiguïté: il n’existe qu’une seule interprétation de celle-ci Vérifiable: elle peut être mesurée Réalisable: elle doit pouvoir être satisfaite Caractéristiques de base d’un ensemble d’exigences: Cohérence: les exigences ne sont pas contradictoires entre elles Complétude: pas de manque, l’ensemble du problème est considéré. • 200 à 300 exigences techniques de haut niveau 30 15 5/20/2014 Caractéristiques: précisions sur… • … l’exigence: Nécessaire Indépendante des solutions Non ambiguïté Complète Unicité Faisable Vérifiable Correcte (Conforme) • … le référentiel : Complet Cohérent Faisable Délimité Structuré 31 De l’utilité de la définition des exigences techniques • Assurer la qualité de communication entre les différentes communautés techniques qui travaillent ensemble pour réaliser le système à faire. Plus les interlocuteurs sont nombreux, plus les risques de mécompréhension le sont aussi… • Vérifier la satisfaction des besoins des parties prenantes tout au long du développement Cela évite aux concepteurs de faire des interprétations et des choix de solutions qui peuvent ne pas satisfaire le besoin des parties prenantes • Prendre en compte tous les besoins des parties prenantes Cela évite des dérives de coûts et/ou de délais, les exigences fixent contractuellement l’engagement de la maîtrise d’œuvre. 32 16 5/20/2014 Du besoin des parties prenantes aux exigences Exigences systèmes Besoins des parties prenantes Traduits en Exigences techniques systèmes • Traduites en Complet/cohérent avec Complet/cohérent avec Besoins, désirs, attentes… Termes non techniques Exigences techniques détaillées Non ambiguës, vérifiables… Termes techniques Arrangements logiques des exigences Exemple: « La peinture ne coûte pas chère » ??? Traduits en quelque chose de vérifiable… Source: MAP système 33 Langages des exigences Le langage utilisé doit être précis, lisible et permettre de créer Le langage naturel Avantages: bonne lisibilité, grande richesse, extensibilité Inconvénients: faible cohérence, précision Exemple: • La machine lave le linge Les langages semi-formels Avantages: syntaxe graphique, facilité de manipulation Inconvénients: risque d’ambiguïté • Exemple: UML, URN, GRL, KAOS… Les langages formels Avantages: grande précision, cohérence, outillage Inconvénients: faible lisibilité, constructibilité • Exemple: E<> t.Working and r.Active and T > t.timeMin and T < t.timeMax 34 17 5/20/2014 Expression d’une exigence: le langage naturel • Une exigence est un élément d’ingénierie qui traduit un besoin. C’est une expression qui doit s’exprimer par une phrase simple. Exigence 1 Sujet (le système à l’étude) Verbe Complément (résultat, critère de qualité…) Le système détecte les défaillances Le système de banque en ligne autorise Le SOI* Le verbe l’accès de l’utilisateur à son compte en moins de 1 minute Le résultat Le critère * System of Interest 35 Expression d’une exigence • • Une exigence est rédigée au présent. On évite l’utilisation: Des structures négatives Des termes vident de sens (buzzword) o beaucoup, peu, gérer, facilement, convivial… Des conjonctions o et, ou, ainsi que, avec… Des clauses échappatoires o si, mais, quand, sauf, à moins que… Des spéculations o normalement, souvent, généralement… Des suggestions o peut, pourrait, devrait, peut-être, probablement… Normalement, le système devrait détecter les défaillances à moins qu’il soit en dehors de son domaine de travail. 36 18 5/20/2014 Expression d’une exigence : moyens mnémotechniques • Une exigence doit être MUST: Mesurable Utile Simple Traçable • Une exigence doit être SMART: Spécifique (specific) Mesurable (measurable) Atteignable (achievable) Réaliste (relevant) Traçable (traceable) 37 Exemples d’exigences • • • • • • Le véhicule X atteint la vitesse de 200 km/h. Le coût de la peinture du véhicule X est inférieur à 1000 €. Un voyant informe le pilote en cas de défaillance. Le système enregistre les pannes en temps réel. La probabilité d’interruption des fonctions du système électronique qui entraîne la perte d’une mission est inférieur à 5x 10-6 par heure de vol. Le rayon de braquage permet un créneau en ville. Parmi ces exigences, laquelle vous interpelle? 38 19 5/20/2014 Expression des exigences: défauts à éviter • • • • • • • • Bruit: l’exigence contient des éléments inutiles. Redondance: l’exigence apparait plusieurs fois. Sous-spécification: l’exigence est implicite, imprécise, omise. Sur-spécification: l’exigence contient des éléments de solution. Contradiction: plusieurs exigences présentent une même caractéristique qui est contradictoire. Ambiguïté: l’exigence peut être comprise de plusieurs façons. Référence non vérifiée: l’exigence fait référence à d’autres documents dont la pertinence et/ ou l’exactitude n’est pas vérifiée. Option: l’exigence est « ouverte » ou incomplète. 39 Expression des exigences: exemple illustratif • Quels sont les problèmes liés à ces exigences? « La régulation sera efficace dans tous les cas. » « Qualité des capteurs de température: adaptabilité et mesure infra-rouge. » « L’actionneur pourrait être automatiquement asservi avec un relais supraneutronique branché en shunt sur l’alterno-démarreur. » « Toutes les informations inutiles ne sont pas affichées. » « La fixation du système utilise le procédé R-00-XXX-125. » « L’âge du pilote est de 35 ans. » « L’interface est simple d’utilisation. » « Les données sont sauvegardées autant que possible. » « L’application n’a pas de bugs » 40 20 5/20/2014 Expression des exigences: attributs Les attributs sont des caractéristiques pour compléter les exigences en vue de leur gestion: • Identificateur: symbole alphanumérique pour repérer les exigences parmi les autres. Il est unique. Criticité: importance de l’exigence pour la sécurité ou la fiabilité du système. Priorité: indication pour que le concepteur puisse décider de l’ordre du développement. Pondération: état d’évolution de l’exigence (identifiée, analysée, vérifiée, allouée, satisfaite). Historique: repère pour identifier les modifications subies par l’exigence (date, auteur, modification, suppression, justification de la modification). 41 Classification des exigences: première typologie • Pour le concepteur, le classement des exigences permet d’identifier la nature des travaux à effectuer. Exigences fonctionnelles : exigences qui décrivent ce que doit faire le système (fonction) Exigences non fonctionnelles : exigences non attribuables à une fonction. Elles traduisent généralement une contrainte, une aptitude attendue, une performance…. Elles peuvent avoir un impact sur les choix techniques. Fonction « rouler » Le véhicule roule roule Le véhicule protège les personnes Fonction « protéger » Exigences fonctionnelles Quelle motorisation? Le véhicule roule à la vitesse vitesse maximum maximum de de 200 200 km/h km/h Le véhicule protège jusqu’à jusqu’à10 10occupants occupants Quel volume pour l’habitacle? Exigences non fonctionnelles 42 21 5/20/2014 Classification des exigences: typologie classique • Pour le concepteur, le classement des exigences permet d’identifier la nature des travaux à effectuer: Exigence fonctionnelle Performance Contrainte Exigence d’interface Exigences nonfonctionnelles Scénarios, modes et exigences opérationnelles Exigence de justification et de validation • La typologie des exigences peut varier, notamment en fonction du secteur d’activité: Environnemental Soutien … 43 Classification des exigences: lecture Type Lecture Connaitre les différentes transformations à réaliser (ce que le système doit faire) Définir le domaine d’utilisation des transformations à réaliser Identifier les contraintes qui seront imposées aux architectures organiques et constituants Interfaces entre les différents ensembles (internes et externes au système) Identifier les situations de vie à prendre en charge ainsi que les conditions opérationnelles correspondantes Prendre en compte les différents essais et situations de justification 44 22 5/20/2014 Classification des exigences pour la justification Type Justification de l’exigence Le système exécute toutes les fonctions à réaliser Les fonctions atteignent les performances définies Les architectures organiques et constituants ne dépassent pas les limites imposées. Toutes les interfaces sont réalisées Toutes les situations de vie du système sont identifiées Toutes les situations de justification et de validation sont identifiées 45 Les exigences fonctionnelles • • Les exigences fonctionnelles décrivent ce que doit faire le système en termes d’action, de comportement et de résultat attendu ou de service rendu. Functional requirement. • Ces exigences sont uniquement liées aux transformations (ou actions) que doit effectuer le système pour fournir les services correspondant à ses missions opérationnelles. • Exemples: Le système X se déplace. Le système X collecte les informations. Le système X mémorise les informations collectées. 46 23 5/20/2014 Les exigences de performance • • Exigence associée à une fonction ou un produit, indiquant un critère d’appréciation mesurable d’un attribut de qualité de cette fonction ou de ce produit. Performance requirement. Les exigences de performance sont généralement quantitatives (évaluation plus aisée). Les performances sont utilisées pour effectuer un choix dans le cas ou différentes solutions existent. • • Exemples: • Le système est opérationnel en moins de 2 minutes Le système surveille un espace aérien de 30 km de rayon. Le système est étanche jusqu’à 100 mètres 47 Les contraintes • • • (1) restriction, limitation ou une conformité à un règlement imposé à un produit, un projet ou un processus. (2) type d’exigence ou de caractéristique de conception qui ne peut faire l’objet d’un compromis. Constraint. • Les contraintes sont très souvent dimensionnantes: reconduction de constituants, solutions imposées. • Exemples: Le système respecte les normes environnementales en vigueur. Le volume du système est de 1 m3. Le système assure toutes les opérations de maintenance de ses équipements. 48 24 5/20/2014 Les exigences d’interfaces • • Une exigence d’interface définit les conditions d’interactions entre éléments. Interface requirement. • Les exigences d’interfaces considèrent les interfaces entre le système et son environnement (externes) et les interfaces entre les éléments du système (internes). Les interfaces peuvent être fonctionnelles ou physiques. • Exemples: • Le système X échange des informations avec le système Y Les bouchons de réservoir du système X sont compatibles avec les pistolets A612. Le système X reçoit des ordres du système Z. 49 Scénarios, mode et exigence opérationnelle • • • • Les scénarios et modes décrivent le comportement attendu du système dans toutes les phases de son cycle de vie. Scenario, mode. Une exigence opérationnelle exprime les conditions d ’exécution et d’opération du système durant son cycle de vie. Ces exigences intègrent: • L’ergonomie Les facteurs humains La sureté de fonctionnement La logistique L’environnement Les moyens Exemples: Le taux de disponibilité du système X est de 80%. Le système X est aérotransportable. 1 opérateur est suffisant pour effectuer les actions de conduite du système X. 50 25 5/20/2014 Les exigences de justification et de validation • Les exigences de justification et de validation permettent au concepteur de connaître les différentes situations de validation et de justification qui seront rencontrées. • Ces exigences expriment les justifications à apporter au donneur d’ordre afin qu’il soit sûr que le système livré correspond à celui dont il a besoin. Ces exigences expriment la méthode à employer pour parvenir à cette assurance (analyse, inspection, essais, simulation…). Ces exigences considèrent le niveau auquel la justification s’applique (constituant, assemblage, système complet). • • • Exemples: Le respect des exigences de performance est démontré par essais. Le matériel de transmission est testé tel que définit par la norme XX-250-EF. Le respect des exigences fonctionnelles est démontré pour toutes les conditions d’emploi définies dans les scénarios. 51 Classification des exigences: exemple illustratif • A quelle classe appartiennent les exigences suivantes? Le système X approvisionne le système Y en carburant. Le système X est opérationnel par temps de brouillard. Le système X utilise un châssis industriel existant. Les coûts de développement du système X sont minimisés. Le système X est aérotransportable. Le système de transmission est compatible RX-32. En mode veille le système diagnostique l’état de fonctionnement de ses équipements. Le respect de la tenue au brouillard est démontré par essais en air ambiant. Le système X échange des informations avec le centre de contrôle. Le système X réalise une mission en moins de 24 heures. • De la même manière que pour les besoins, la classification permet une meilleure traçabilité et une meilleure lecture des exigences. • Le positionnement d’une exigence dans une classe peut être soumis à discussion, cependant, mieux vaut l’avoir dans une classe que de l’omettre… 52 26 5/20/2014 Vérification et validation d’une exigence technique • Vérification Non ambiguë: l’exigence n’a qu’une seule interprétation possible Exhaustive: le concepteur dispose-t-il de tous les éléments pour travailler? Vérifiable: chaque exigence est-elle vérifiable? Cohérente: il n’y a aucun conflit entre les exigences. Modifiable: le document des exigences est-il aisément modifiable? Identifiable: les exigences sont clairement identifiées pour faciliter leur mise en référence dans le document des exigences techniques . • Validation Les exigences traduisent-elles correctement le besoin exprimé par les parties prenantes? 53 Le processus de définition des exigences techniques • Processus qui vise à transformer les besoins en exigences techniques pour guider, ultérieurement, la conception du système et sa validation. • Résultats attendus: Ensemble d’exigences du système Description complète du problème à résoudre Base pour établir la conception de l’architecture Base pour valider la solution 54 27 5/20/2014 Le processus de définition des exigences techniques (2) Document expression des besoins Enquêtes, interview Définition des exigences techniques Analyser les scénarios et modes opérationnels Définir les exigences fonctionnelles Analyser le périmètre et les interactions avec le contexte Définir les performances Définir les exigences d’interface Identifier les exigences dimensionnantes Définir les exigences opérationnelles Etablir le référentiel des exigences Vue fonctionnelle Vue opérationnelle Vue des contraintes Vérifier la faisabilité des concepts Définir les contraintes du cycle de vie Définir les contraintes physiques Vérifier l’exhaustivité, la cohérence, la traçabilité du référentiel source: MAP système Document exigences techniques 55 Plan type de document d’exigences techniques 1. Introduction a) b) c) 2. Présentation du système a) b) c) 3. Objet Documents (documents en référence, documents applicables) Terminologie Finalité, mission, objectifs Contexte organique et fonctionnel du système Parties prenantes Exigences techniques a) b) c) Exigences fonctionnelles Exigences de performance Exigences d’interfaces o d) o e) Modes et scénarios opérationnels, exigences d’ergonomie et de facteurs humains, exigences de SdF, exigences de sécurité de l’information, exigences d’environnement, exigences de moyens Contraintes o f) Interfaces fonctionnelles, Interfaces physiques Exigences opérationnelles Contraintes physiques, contraintes de conception et de réalisation, contraintes de réserve et d’extension, contraintes de mise en service, contraintes de retrait de service, contraintes de soutien / maintenance et de documentation, contraintes de production, contraintes de réglementation, contraintes de coûts et de délais Exigences de validation et de certification 56 28 5/20/2014 Risques majeurs au stade d’élaboration des exigences • Ne pas s’assurer que les besoins sont suffisamment matures Le maître d’œuvre joue le rôle du maître d’ouvrage • Insuffisance des modes et scénarios opérationnels • Incomplétude, imprécision des exigences Validation conflictuelle, mise en service retardée, développement retardé Conception réalisée sans tenir compte des exigences Développement retardé, validation conflictuelle • Mauvaise classification ou rédaction des exigences Exigences non utilisées par la conception Perte de temps pour la maîtrise d’œuvre, coût de développement plus élevé Validation difficile • Pas de traçabilité avec les besoins Difficultés de gestion des évolutions client 57 source: MAP système Conclusion Définir les besoins des parties prenantes Définir les exigences techniques Vérifier Evaluer Optimiser Valider Concevoir l’architectur e organique Concevoir l’architectur e fonctionnell e Processus d’ingénierie Doc. expression des besoins PP1 Doc. expression des besoins PP2 Définir les besoins des parties prenantes 58 Arch. Fonct. Arch. Org. Doc. Expression des besoins consolidés Définir les exigences techniques Doc. Exigences techniques Arch. Fonct. Arch. Fonct. Arch. Org. 29 5/20/2014 Références utilisées dans ce cours et quelques lectures pour approfondir (Ingénierie Système) • • • • S. Fiorèse, J.-P. Ménadier, Découvrir et comprendre l’Ingénierie Système, Collection AFIS, Cépaduès Ed., 2012. NASA, Systems Enginering Handbook, NASA/SP-2007-6105 Rev1, available online at: ntrs.nasa.gov, december 2007. INCOSE, Systems Engineering Handbook – A guide for system life cycle processes and activities – v. 3.2.1, INCOSE-TP-2003-002-03.2.1, january 2011. AFIS, Glossaire de base de l’Ingénierie de Systèmes – Version Expérimentale 1.2, disponible en ligne à : http://homepages.laas.fr/kader/Glossaire_IS.pdf, octobre 2011. 59 Références utilisées dans ce cours et quelques lectures pour approfondir (ingénierie des exigences) • • • • • • • • • A. Faisandier, Ingénierie des systèmes complexes – démarche et méthode d’élaboration des besoins des parties prenantes, MAP système, avril 2010. A. Faisandier, Ingénierie des systèmes complexes – démarche et méthode d’élaboration des exigences techniques – MAP système, avril 2010. Requirements WG-INCOSE, Guide for Writing Requirements, v1.0, INCOSETP-2010-006-01, avril 2012 AFIS, Guide des bonnes pratiques en ingénierie des exigences, Collection AFIS, Cépaduès Ed., 2012 AFIS, Recommandations pour l’élaboration d'un référentiel d'exigences techniques, 2001 AFIS, Glossaire GT « Ingénierie des exigences », fiche n°14, 2013 IEEE, Guide de l’IEEE pour la spécification d’exigences de système, Norme IEEE 1233, 1998 G.V. Bochmann, Writing better requirements, univerité d’Ottawa, 2010 N. Sannier, Eliciting requirements – Specifying requirements 60 30 5/20/2014 Glossaire • • • • • • • Ingénierie système (System engineering): démarche méthodologique générale qui englobe l’ensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une solution économique et performante aux besoins d’un client tout en satisfaisant l’ensemble des parties prenantes (AFIS) Finalité (purpose): expression et caractérisation du but final du système étudié (pourquoi créer ce système?). Mission: tâche, service ou fonction spécifique, définie pour être fournie par le système (que doit faire le système?). Objectif: performance attendue du système (quantifié ou qualifié). Partie prenante (stakeholder): partie ayant un droit, une part ou une prérogative qui fait que le système ou certaines de ses propriétés doivent satisfaire les besoins ou les attentes de cette partie (ISO 15288). Maitre d’œuvre (prime contractor): personne physique ou morale qui reçoit mission du maître d’ouvrage de concevoir le système et de contrôler sa réalisation. Maitre d’ouvrage (acquirer, purchaser): personne physique ou morale pour le compte de laquelle le système est réalisé (synonymes: donneur d’ordre, acquéreur, client). 61 Merci pour votre attention Nicolas Daclin [email protected] 62 31
© Copyright 2025 ExpyDoc