Ingénierie des besoins des parties prenantes et des exigences

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

Download Report