Présentation

Article

1 - PHASE D’ACQUISITION DES EXIGENCES

2 - SPÉCIFICATION DES EXIGENCES

3 - RÉALISATION

4 - GESTION DES EXIGENCES

5 - CONCLUSION

Article de référence | Réf : S7305 v1

Réalisation
Management des exigences

Auteur(s) : Jean-Louis BOULANGER

Date de publication : 10 août 2015

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

Version en anglais 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’article

Auteur(s)

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.

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-s7305


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

ABONNEZ-VOUS

Lecture en cours
Présentation
Version en anglais English

3. Réalisation

3.1 Processus

La figure 1 montre qu’une fois la spécification technique réalisée il est possible de passer à la seconde phase qui concerne la réalisation d’un système respectant les exigences. La réalisation doit suivre un cycle qui doit permettre de démontrer que le système final réalise les exigences.

Il est à noter que nous parlons de réalisation d'un système ou d'une sous-partie (sous-système, équipement, plate-forme, application logicielle) et non pas de son simple développement : la réalisation d'un système ou d'une sous-partie contient les activités de développement, mais aussi les activités de vérification, de validation, de production, d'installation et de maintenance de l'application (figure 22).

Les activités de vérification et validation (V&V) sont importantes et seront plus ou moins développées en fonction du niveau de qualité et de sécurité requis pour le système. Concernant les activités de fabrication du produit et de son installation, elles sont cruciales et nécessitent la mise en place de processus spécifiques.

La maintenance d'un système démarre à partir du moment où le système a été mis en service. La maintenance reste une activité de projet : en effet, suite à une évolution, il faut maintenir un niveau de sécurité et de qualité tout en maîtrisant le coût de l'évolution et en minimisant l'impact sur le système en service.

La maintenance d'un système se confronte à une difficulté : la durée de vie. En effet, cette dernière peut être très longue ; il faut alors maintenir les équipes et les compétences nécessaires jusqu'au retrait. Pour les domaines du ferroviaire, de l'aéronautique ou du nucléaire par exemple, la durée de vie d'un système est de 40 à 50 années, alors que pour l'automobile elle est de 15 années. Au vu de ces durées de vie, il faut prendre des mesures pour garantir le maintien du service et la maintenance du système et de ses composantes.

Finalement, il faut définir un cycle de réalisation adapté au système (à titre d'exemple la figure ...

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

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

ABONNEZ-VOUS

Lecture en cours
Réalisation
Sommaire
Sommaire

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

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

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

ABONNEZ-VOUS