View
9
Download
0
Category
Preview:
Citation preview
‐ Ingénierie Système ‐Ingénierie des besoins des parties
prenantes et des exigences techniquesNicolas Daclin
Ecole Nationale Supérieure des Mines d’AlèsLaboratoire de Génie Informatique et d’Ingénierie de la Production
Qui suis‐je?
• Nicolas DaclinMaî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)
tel. +33 466 387 039, nicolas.daclin@mines‐ales.fr
• Thème de rechercheVérification par preuve formelle d’exigences et de propriétés
Interopérabilité: modélisation des exigences d’interopérabilité pour les processus collaboratifs
• Domaines d’applicationGestion de crise
Entreprises
Système de santé
2
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 andactivities – 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.
3
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, INCOSE‐TP‐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'exigencestechniques, 2001
4
Quelques exemples…
• Programme navette spatiale Américaine (1981 – 2011)Extrait du CdC initial:
o 10 m$/vol à raison d’un vol habité par semaineBilan:
o Deux accidents majeurs avec perte d’équipage et destruction du matérielo ~1,5 à 100 M$ (!) chaque vol avec 8 vols par an en moyenne depuis le début du programme
Problèmes:
o Techniques : moteurs de la navette participant au décollage (manque de sécurité)
o Organisationnelso Conceptuels
5
Quelques exemples…
• Therac 25 (1985 ‐ 1987)Extrait du CdC initial:
o Traitement de tumeurs cancéreuses par rayon XBilan:
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 Mauvais développement logiciel/ techniqueo Pauvreté du processus d’ingénierieo Manque de spécificationso Défauts de procédure de test
6Source: http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html
Quelques exemples…
• The ∅resund bridge (1996 – 2000)Extrait du CdC initial:
o Pont reliant la Suède au Danemarko 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! »
7Source: INCOSE Systems Engineering Handbook v. 3.2.2, 2011
Importance de l’utilisation d’une démarche
• Ingénierie système
8http://www.levasseur.im
Importance de l’ingénierie des exigences
• Selon, le Standish Group:
9www.standishgroup.com, the Chaos report
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…
L’ingénierie des besoins et des exigences est également la principale cause du succès d’un projet!
mais…
Processus de définition des besoins des parties prenantes
1. Principes et concepts relatifs aux besoins
2. Processus de définition des besoins des parties prenantes
10
Rappel et positionnement du processus
11Processus de réalisation
Fabriquer Réutiliser Acheter
Processus d’ingénierie
Définir les besoins des parties
prenantes
Définir les exigences techniques
Concevoir l’architecture fonctionnelle
Concevoir l’architecture organique
Evaluer Optimiser
Vérifier
Valider
Processus d’intégration
Réceptionner
Assembler
Vérifier
Valider
Les enjeux
12
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. Nécessité de collecter les besoins2. 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…
Définition
• 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 reconnu 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.
13
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.• Need and expectation, stakeholder requirement, user requirement,
initial requirement.
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.
14
Provenance des erreurs et coûts de correction
15
Coût relatif de correction
Production des erreurs
Source des erreurs
Nombre d’erreurs produites àun instant donné
Coût relatif de correction d’une erreur au même instant
exigences conception réalisation essais maintenance
source: MAP système
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é.
16
Expression des besoins: difficultés
• Identification: le besoin est mal identifié, défini ou exprimé.• Incompréhension: mauvaise compréhension de la relation client‐fournisseur.• 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.
17
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?).
18
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…
19
• 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…
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
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.
Déterminer le niveau d’abstraction des besoins.
21
Vérification et validation des besoins
• VérificationMaturité: 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?
• ValidationPourquoi ces besoins?
Quel est le risque qu’ils disparaissent? Pour quelle(s) cause(s)?
22
Le processus de définition des besoins des parties prenantes
• Processus complexe puisque l’on part de quelque chose de subjectif pour aller vers quelque chose d’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)
24
Définir la finalité et la mission du système
Identifier les situations de vie et les parties prenantes
Définir les limites fonctionnelles du
système
Définir les limites physiques du système
(interfaces)
Analyse et définition des besoins
Document expression des besoins
Enquêtes, interview
Définir les concepts d’opérations ou technologiques
Définir les scénarios opérationnels
Définir les besoins opérationnels
Définir les objectifsExprimer les besoins
unitairement
Quantifier et classer les besoins et les
contraintes
Vérifier la cohérence, l’exhaustivité et la
traçabilité
source: MAP système
Plan type de documentation d’expression des besoins
1. Introductiona) Objet
b) Documents (documents en référence, documents applicables)
c) Terminologie
2. Présentation du systèmea) Finalité, mission, objectifs
b) Contexte organique et fonctionnel du système
c) Parties prenantes
25
Plan type de documentation d’expression des besoins (2)3. Besoins des parties prenantes
a) Modes opérationnels et scénariosb) Besoins opérationnels
o Services attenduso Performances, autonomie, durée de vieo Interactions et connexions physique avec les éléments du contexteo Facteurs humain et ergonomieo Sûreté de fonctionnemento Sécurité de l’informationo Moyenso Transport, stockage
c) Contraintes des systèmes contributeurso Réalisationo Mise en serviceo Retrait de serviceo Soutien logistique et maintenanceo Productiono Réglementationo Couts, délaiso Validation 26
Risques majeurs au stade de l’élaboration des besoins
• Mauvaise identification du systèmeNiveau 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èmeProduit inadapté ou refus du produit par les utilisateurs
Oubli d’interfaces
Oubli de connexions physiquesProduit non interopérable
• Absence ou insuffisance de modes et scénarios opérationnelsValidation conflictuelle, mise en service retardée, développement retardé
• Incomplétude des besoins, oubli des parties prenantesDéveloppement retardé, validation conflictuelle
• Mauvaise classification des besoinsPerte de temps pour la maîtrise d’œuvre, coût de développement plus cher
27source: MAP système
28
Processus de définition des exigences techniques
1. Principes et concepts relatifs aux exigences techniques
2. Gestion des exigences techniques
3. Processus de définition des exigences techniques
Rappel et positionnement du processus
29Processus de réalisation
Fabriquer Réutiliser Acheter
Processus d’ingénierie
Définir les besoins des parties
prenantes
Définir les exigences techniques
Concevoir l’architecture fonctionnelle
Concevoir l’architecture organique
Evaluer Optimiser
Vérifier
Valider
Processus d’intégration
Réceptionner
Assembler
Vérifier
Valider
Rôles des exigences
• L’élaboration des exigences joue deux rôles
30
1. Identifier le travail de conception à réaliser2. Servir de référence à la justification et à la validation
Elaboration des exigences
Justification
Conception
Que faut‐il faire?
Pourquoi cela est nécessaire?
1
2
Définition
• Caractéristiques de base d’une exigence:Unicité: elle ne traite que d’un sujetPrécision: elle est rigoureuse dans son expressionNon‐ambiguïté: il n’existe qu’une seule interprétation de celle‐ciVérifiable: elle peut être mesuréeRéalisable: elle doit pouvoir être satisfaite
• Caractéristiques de base d’un ensemble d’exigences:Cohérence: les exigences ne sont pas contradictoires entre ellesComplétude: pas de manque, l’ensemble du problème est considéré.
• 200 à 300 exigences techniques de haut niveau 31
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.• Requirement.
Caractéristiques: précisions sur…
• … les exigences :Nécessaire
Indépendante des solutions
Non ambiguïté
Complète
Unicité
Faisable
Vérifiable
Correcte
(Conforme)
32
• … le référentiel :Complet
Cohérent
Faisable
Délimité
Structuré
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 prenantesCela évite des dérives de coûts et/ou de délais, les exigences fixent contractuellement l’engagement de la maîtrise d’œuvre.
33
Du besoin des parties prenantes aux exigences
• Exemple:
34
Besoins des parties
prenantes
Exigences techniques systèmes
Exigences techniques détaillées
Exigences systèmes
Traduits en Traduites en
Besoins, désirs, attentes…Termes non techniques
Non ambiguës, vérifiables…Termes techniques
Arrangements logiques des exigences
Complet/cohérent avec Complet/cohérent avec
« La peinture ne coûte pas chère »
Traduits en quelque chose de vérifiable…
???
source: MAP système
Langages des exigences
• Le langage utilisé doit:Être précis et lisible
Permettre de créer
35
Le langage naturelAvantages: bonne lisibilité, grande richesse, extensibilitéInconvénients: faible cohérence, précision
Les langages formelsAvantages: grande précision, cohérence, outillageInconvénients: faible lisibilité, constructibilité
• Exemple:La machine lave le linge
Le véhicule se déplace
• Exemple:E t.Working and r.Active and T > t.timeMin and T
Expression d’une exigence
• Une exigence est un élément d’ingénierie qui traduit un besoin.
36
Sujet Verbe Complément
Exigence 1
La machine lave le linge
Le système détecte les défaillances
C’est une expression qui doit s’exprimer par une phrase simple.
Expression d’une exigence : moyens mnémotechniques
37
• Une exigence doit être un MUST:
• Une exigence doit être SMART:
MesurableUtileSimpleTraçable
Spécifique (specific)Mesurable (measurable)Atteignable (achievable)Réaliste (relevant)Traçable (traceable)
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 d’un calculateur.• 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.
38
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 supra‐neutronique 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. »
40
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.
42
Le véhicule roule
Le véhicule protège les personnes
roule
protège
Exigences fonctionnelles
Le véhicule roule à la vitesse maximum de 200 km/h
Le véhicule protège jusqu’à 10 occupants
vitesse maximum de 200 km/h
jusqu’à 10 occupants
Quelle motorisation?
Quel volume pour l’habitacle?
Exigences non fonctionnelles
Fonction « rouler »
Fonction « protéger »
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
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
Exigences non‐fonctionnelles
Classification des exigences: lecture
44
Classification des exigences pour la justification
45
Les exigences fonctionnelles
• 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
• 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.
Les exigences de performance
47
• 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
Les contraintes
• 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
• (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 exigences d’interfaces
• 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
• Une exigence d’interface définit les conditions d’interactions entre éléments.
• Interface requirement.
Scénarios, mode et exigence opérationnelle
50
• Les scénarios et modes décrivent le comportement attendu du système dans toutes les phases de son cycle de vie.
• Scenario, mode.• Functional requirement.• 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’ergonomieLes facteurs humainsLa sureté de fonctionnementLa logistiqueL’environnementLes 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.
Les exigences de justification et de validation
• 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
• 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.
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.
52
• 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…
Vérification et validation d’une exigence technique
• VérificationNon ambiguïté: 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 .
• ValidationLes 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
Le processus de définition des exigences techniques (2)
55
Analyser les scénarios et modes
opérationnels
Analyser le périmètre et les interactions avec le contexte
Identifier les exigences
dimensionnantes
Vérifier la faisabilitédes concepts
Définir les exigences
fonctionnelles
Définir les performances
Définir les exigences d’interface
Définir les exigences
opérationnelles
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
Définition des exigences techniques
Document expression des besoins
Document exigences techniques
Enquêtes, interview
source: MAP système
Plan type de document d’exigences techniques
1. Introductiona) Objet
b) Documents (documents en référence, documents applicables)
c) Terminologie
2. Présentation du systèmea) Finalité, mission, objectifs
b) Contexte organique et fonctionnel du système
c) Parties prenantes
56
Plan type de document d’exigences techniques (2)3. Exigences techniques
a) Exigences fonctionnellesb) Exigences de performancec) Exigences d’interfaces
o Interfaces fonctionnelleso Interfaces physiques
d) Exigences opérationnelleso Modes et scénarios opérationnelso Exigences d’ergonomie et de facteurs humainso Exigences de SdFo Exigences de sécurité de l’informationo Exigence d’environnemento Exigences de moyens
e) Contrainteso Contraintes physiqueso Contraintes de conception et de réalisationo Contraintes de réserve et d’extensiono Contraintes de mise en serviceo Contraintes de retrait de serviceo Contraintes de soutien / maintenance et de documentationo Contraintes de productiono Contraintes de réglementationo Contraintes de coûts et de délai
f) Exigences de validation et de certification 57
Risques majeurs au stade d’élaboration des exigences
• Ne pas s’assurer que les besoins sont suffisamment maturesLe maître d’œuvre joue le rôle du maître d’ouvrage
• Insuffisance des modes et scénarios opérationnelsValidation conflictuelle, mise en service retardée, développement retardé
• Incomplétude, imprécision des exigencesConception réalisée sans tenir compte des exigences
Développement retardé, validation conflictuelle
• Mauvaise classification ou rédaction des exigencesExigences 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 besoinsDifficultés de gestion des évolutions client
58source: MAP système
Vérifier
Synthèse
59
Processus d’ingénierie
Définir les besoins des parties
prenantes
Définir les exigences techniques
Concevoir l’architecture fonctionnelle
Concevoir l’architecture organique
Evaluer Optimiser
Valider
Définir les besoins des parties
prenantesDéfinir les exigences techniques
Arch. Fonct.
Arch. Org.Arch. Fonct.Arch. Org.Arch. Fonct.
Doc. expression des besoins
PP1
Doc. expression des besoins
PP2
Doc. Expression des besoins consolidés
Doc. Exigences techniques
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).
60
61
Merci pour votre attention
Nicolas Daclinnicolas.daclin@mines‐ales.fr
- Ingénierie Système -Ingénierie des besoins des parties prenantes et des exigences techniquesQui suis-je?Références utilisées dans ce cours et quelques lectures pour approfondir (Ingénierie Système)Références utilisées dans ce cours et quelques lectures pour approfondir (ingénierie des exigences)Quelques exemples…Quelques exemples…Quelques exemples…Importance de l’utilisation d’une démarcheImportance de l’ingénierie des exigencesProcessus de définition des besoins des parties prenantesRappel et positionnement du processusLes enjeuxDéfinitionDe l’utilité de la définition des besoins des parties prenantesProvenance des erreurs et coûts de correctionExpression des besoins : une opération complexeExpression des besoins: difficultésExpression des besoins: attributsClassification des besoins: typologieApproches et outils méthodologiques pour la définition des besoinsDéfinition des besoins: principes pour la collecteVérification et validation des besoinsLe processus de définition des besoins des parties prenantesLe processus de définition des besoins des parties prenantes (2)Plan type de documentation d’expression des besoinsPlan type de documentation d’expression des besoins (2)Risques majeurs au stade de l’élaboration des besoinsProcessus de définition des exigences techniquesRappel et positionnement du processusRôles des exigencesDéfinitionCaractéristiques: précisions sur…De l’utilité de la définition des exigences techniquesDu besoin des parties prenantes aux exigencesLangages des exigencesExpression d’une exigenceExpression d’une exigence : moyens mnémotechniquesExemples d’exigencesExpression des exigences: défauts à éviterExpression des exigences: exemple illustratifExpression des exigences: attributsClassification des exigences: première typologieClassification des exigences: typologie classiqueClassification des exigences: lectureClassification des exigences pour la justificationLes exigences fonctionnellesLes exigences de performanceLes contraintesLes exigences d’interfacesScénarios, mode et exigence opérationnelleLes exigences de justification et de validationClassification des exigences: exemple illustratifVérification et validation d’une exigence techniqueLe processus de définition des exigences techniquesLe processus de définition des exigences techniques (2)Plan type de document d’exigences techniquesPlan type de document d’exigences techniques (2)Risques majeurs au stade d’élaboration des exigencesSynthèseGlossaire
Recommended