5/20/2014 1 - 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 Centre de recherche LGI2P Ecoled’étéCA’NTI #20, 26 –30 mai2014, 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
31
Embed
-Ingénierie Système - Ingénierie des besoins des …acse.pub.ro/wp-content/uploads/2014/05/Ingénierie-des-besoins-des... · Document expression des besoins Enquêtes, interview
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
5/20/2014
1
- 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
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)
• 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 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.
16
5/20/2014
9
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?).
B.S.1 Le système protège des radiations obligatoire 3
17
Retour sur… l’importance des besoins et les
conséquences
Neutre
Satisfaction
Insatisfaction
Absent Complet
Satisfaction client
Degréd’implémentationDiagramme de Kano 18
5/20/2014
10
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
5/20/2014
11
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
5/20/2014
12
Le processus de définition des besoins des parties
prenantes
• Processus complexe
• 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
Subjectif Objectif
Le processus de définition des besoins des parties
prenantes (2)
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 24
5/20/2014
13
Plan type de documentation d’expression des
besoins1. Introduction
a) Objet
b) Documents (documents en référence, documents applicables)
c) Terminologie
2. Présentation du système
a) Finalité, mission, objectifs
b) Contexte organique et fonctionnel du système
c) Parties prenantes
3. Besoins des parties prenantes
a) Modes opérationnels et scénarios
b) Besoins opérationnels
o 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
c) 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
Développement retardé, validation conflictuelle
• Mauvaise classification des besoins
Perte de temps pour la maîtrise d’œuvre, coût de développement plus cher
source: MAP système 26
5/20/2014
14
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
27
Rappel et positionnement du processus
Fabriquer Réutiliser Acheter
Intégration Système
Ingénierie Système
Réalisation: Ingénierie Métiers
Réceptionner
Assembler
Vérifier
Qualifier
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
Rechercher
des concepts
pertinents
ou
innovants
28
5/20/2014
15
Rôles des exigences
• L’élaboration des exigences joue deux rôles
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
29
Définition
• 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
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.
30
5/20/2014
16
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
5/20/2014
17
Du besoin des parties prenantes aux exigences
• Exemple:
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 33
Langages des exigences
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
• Exemple:
� E<> t.Working and r.Active and T > t.timeMin and T < t.timeMax
34
Les langages semi-formelsAvantages: syntaxe graphique, facilité de manipulationInconvénients: risque d’ambiguïté
Le langage utilisé doit être précis, lisible et permettre de créer
• Exemple:
� UML, URN, GRL, KAOS…
5/20/2014
18
Expression d’une exigence: le langage naturel
• Une exigence est un élément d’ingénierie qui traduit un besoin.
Sujet
(le système à l’étude)Verbe
Complément (résultat,
critère de qualité…)
Exigence 1
Le système détecte les défaillances
C’est une expression qui doit s’exprimer par une phrase simple.
Le système de banque en ligne autorise l’accès de l’utilisateur à son compteen moins de 1 minute
35
Le SOI* Le verbe
* System of Interest
Le résultat Le critère
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
� 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.
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 »
42
5/20/2014
22
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
� …
Exigences non-
fonctionnelles
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
5/20/2014
23
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
• 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.
• 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.
46
5/20/2014
24
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
• 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.
• (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.
48
5/20/2014
25
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.
• Une exigence d’interface définit les conditions d’interactions entre
éléments.
• Interface requirement.
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
5/20/2014
26
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.
• 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.
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
5/20/2014
27
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
5/20/2014
28
Le processus de définition des exigences techniques
(2)
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
Etablir le référentiel des exigences
Vue
fonctionnelle
Vue
opérationnelle
Vue des
contraintes
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 55
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
c) Exigences d’interfaceso Interfaces fonctionnelles, Interfaces physiques
d) Exigences opérationnelleso 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
e) Contrainteso 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
f) Exigences de validation et de certification
56
5/20/2014
29
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
Validation conflictuelle, mise en service retardée, développement retardé
• Incomplétude, imprécision des exigences
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
source: MAP système 57
Vérifier
Conclusion
58
Processus d’ingénierie
Définir les
besoins des
parties
prenantes
Définir les
exigences
techniques
Concevoir
l’architectur
e
fonctionnell
e
Concevoir
l’architectur
e 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
5/20/2014
30
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, 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'exigences
• N. Sannier, Eliciting requirements – Specifying requirements60
5/20/2014
31
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).