Bibliographie & annexes
Présentation
English
RÉSUMÉ
La réalisation d'un système ou d'un élément de système passe par la définition du besoin et par la démonstration que le système satisfait au besoin et aux exigences des utilisateurs. L'identification des acteurs et de leurs interactions avec le système ou l'élément à réaliser, ainsi que la formulation du besoin, sont des étapes clés lors de la mise en place du processus d'acquisition du besoin. Plusieurs approches ont été développées pour y répondre, permettant d'exprimer la notion de besoins sous forme d'exigences. Cet article décrit l'ensemble du processus d'ingénierie des exigences permettant d'acquérir, de formaliser et de démontrer que le besoin est satisfait.
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleAuteur(s)
-
Jean-Louis BOULANGER : Évaluateur-Certificateur - Certifer (Anzin, France)
INTRODUCTION
L’ingénierie des exigences est une nécessité qui apparaît dans l’ensemble des normes métiers (aéronautique, automobile, ferroviaire, nucléaire, équipements électriques, spatial et défense). Une difficulté vient du fait qu’aucune norme métier (DO 178, CENELEC, IEC 61508, etc.) n’introduit de manière non ambiguë et partagée ce qu’est une exigence, bien qu’il existe des normes dédiées comme la norme ISO/IEC 29148. Les normes métiers introduisent la notion de traçabilité (lien entre différents éléments) et la notion de niveau (en aéronautique on a la notion de HLR et LLR pour High Level Requirement et Low Level Requirement).
Cet article présente les activités liées à l’ingénierie des exigences et leur mise en œuvre. Les activités identifiées permettent de couvrir le champ allant de l’analyse du besoin utilisateur à sa réalisation. Le terme « réalisation » couvre l’ensemble des activités depuis l’acquisition du besoin jusqu’à la mise à disposition du système y répondant.
L’ingénierie des exigences est la discipline qui consiste à établir et à documenter les exigences. Les différentes activités associées sont l’élucidation (traduction du mot elicitation), la spécification, l’analyse, la vérification et la validation, et la gestion.
En règle générale, un projet démarre par une phase de définition des exigences qui vise à construire une spécification technique avec des niveaux de performance associés. À partir de la spécification technique, la seconde phase consiste à réaliser un système qui satisfait l’ensemble des exigences.
Il est à noter que certains projets démarrent avec, en entrée, un cahier des charges fonctionnel ou des spécifications techniques fournis par le donneur d’ordre (qui peut être un maître d’œuvre de premier rang dans le cas d’une organisation s’appuyant sur plusieurs entreprises pour réaliser le système final). Cela ne veut pas dire qu’il n’y a pas eu d’analyse préalable des exigences : en réalité, celle-ci aura alors été réalisée par le donneur d’ordre, et seules les spécifications techniques auront été fournies et elles servent à maîtriser la cohérence de l’ensemble.
L'expertise technique et scientifique de référence
MOTS-CLÉS
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Automatique et ingénierie système
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
Réalisation
English
2. Spécification des exigences
2.1 Caractérisation des exigences
La spécification des exigences est un document qui contient l’ensemble des exigences que le produit à réaliser doit respecter. Nous avons vu précédemment dans le tableau 2 les attributs de base d’une exigence. Revenons sur le premier d’entre eux, à savoir l’identification.
HAUT DE PAGE
Une exigence doit être identifiable de façon unique ; c’est pourquoi en général on associe à chaque exigence un identificateur qui se doit d’être unique. Afin de ne pas le confondre avec d’autres éléments pouvant être numérotés (éléments de liste, etc.), l’identificateur est construit en utilisant une étiquette (par exemple EXI) et un numéro unique (par exemple 0001) : on a alors un identificateur de la forme EXI_0001.
En fait, une exigence est associée à un projet et à un document au sein du référentiel documentaire du projet : il est ainsi possible d’avoir un identificateur de la forme EXI_AAAA_DDDD_xxxx avec AAAA qui représente le numéro de projet, DDDD la référence du document et xxxx le numéro de l’exigence.
La gestion de la référence projet et de la référence documentaire peut ainsi être intégrée à l’identificateur ou être vue comme un attribut.
Si l’on veut rendre l’identificateur unique, il est nécessaire de ne pas réattribuer les numéros d’exigence en cas de suppression d’exigence. Pour la même raison, on évitera de mettre en place un mécanisme d’identification automatique (comme la numérotation automatique fournie par certains logiciels d’édition de textes).
Concernant l’identification d’une exigence, il peut être difficile de détecter la fin d’une exigence ; c’est pourquoi il peut être utile de mettre en place une identification sous forme de balises.
[EXI_AAAA_DDDD_0001]
Un cycle du logiciel doit être exécuté en 100 ms.
[FIN_EXI]
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Automatique et ingénierie système
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Spécification des exigences
BIBLIOGRAPHIE
-
(1) - The Standish Group - The chaos report. - Technical report (1994).
-
(2) - HULL (E.), JACKSON (K.), DICK (J.) - Requirements Engineering. - Springer, Berlin (2005).
-
(3) - BOULANGER (J.L.) - * - . – Expression et validation des propriétés de sécurité logique et physique pour les systèmes informatiques critiques, thèse, Université de Technologie de Compiègne (2006).
-
(4) - De la BRETESCHE (B.) - La méthode APTE : Analyse de la valeur, analyse fonctionnelle. - Pétrelle, Paris (2000).
-
(5) - OMG (Object Management Group), Unified Modeling Language TM (OMG UML). - Infrastructure, OMG (2011).
-
(6) - ROQUES (P.) - UML 2 par la pratique – Études de cas et exercices...
DANS NOS BASES DOCUMENTAIRES
-
Composantes et applications électriques du système ferroviaire.
-
Traction ferroviaire – Équipements d’exploitation et sécurité.
-
Maîtrise du SIL et gestion des certificats – Domaine ferroviaire.
-
Qualification des outils au sens de la norme CENELEC EN 50128 :2011.
-
Mise en œuvre de la norme CENELEC EN 50128 :2011.
-
*
-
...
ANNEXES
CENELEC
COFRAC
EPSF
http://www.securite-ferroviaire.fr
ERA
ERTMS
IEC
ISO
http://www.iso.org/iso/home.html
MODUrban
OMG
STRMTG
http://www.strmtg.equipement.gouv.fr
UGTMS
HAUT DE PAGE
ERTSS...
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Automatique et ingénierie système
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
