Présentation

Article

1 - POSITION DE L'INGÉNIERIE DES EXIGENCES

2 - DE LA MODÉLISATION CONCEPTUELLE À L'INGÉNIERIE DES EXIGENCES

3 - EXIGENCES ET DOCUMENTATION

4 - APPROCHE D'ÉLUCIDATION DES EXIGENCES DIRIGÉE PAR LES BUTS

5 - CAS DES RÉSERVATIONS DE CHAMBRES D'HÔTELS

6 - CONCLUSION

Article de référence | Réf : H3250 v2

De la modélisation conceptuelle à l'ingénierie des exigences
De la modélisation conceptuelle à l'ingénierie des exigences

Auteur(s) : Colette ROLLAND

Date de publication : 10 févr. 2011

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

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

Sommaire

Présentation

Auteur(s)

  • Colette ROLLAND : Université Paris 1 Panthéon Sorbonne, Centre de recherche en informatique

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

INTRODUCTION

L'impact critique de l'analyse des exigences sur la qualité du logiciel a été reconnu de longue date et à maintes reprises. Des enquêtes récentes en Europe et aux États-Unis ont confirmé le problème à une plus grande échelle. Les échecs de projets SI sont imputables dans un cas sur deux au manque de qualité du document d'exigences.

Améliorer la qualité de ce document, ainsi que la pratique de l'Ingénierie des Exigences (IE) est donc un objectif primordial. Cet objectif n'est pas facile à atteindre, au vu du large spectre de considérations à couvrir, de la multitude de processus et produits concernés, de la multitude d'acteurs à impliquer, et de la variété d'écueils à éviter. L'IE est une discipline aux confins du génie logiciel et de l'ingénierie des systèmes, qui vise à offrir des modèles, méthodes et outils pour développer et faire évoluer des documents d'exigences de qualité. Cet article se propose de donner un aperçu des développements récents dans cette discipline relativement jeune et d'en approfondir certains. L'IE élargit l'approche classique où l'on cherche à comprendre, ce qui doit être réalisé par le système en essayant de comprendre le « pourquoi » du système, sa raison d'être.

L'expression du « pourquoi » est faite en termes de buts organisationnels et de leur impact sur les exigences imposées au système d'information. L'article insiste sur cette dimension, propose et illustre, par une étude de cas, une démarche d'ingénierie des exigences dirigée par les buts.

Cet article est réservé aux abonnés.
Il vous reste 92% à 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.

VERSIONS

Il existe d'autres versions de cet article :

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v2-h3250


Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(239 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

2. De la modélisation conceptuelle à l'ingénierie des exigences

2.1 Conceptualisation et cycle de développement d'un SI

Toutes les activités d'ingénierie quelles qu'elles soient, ont pour objectif la réalisation d'un produit. Le génie civil vise par exemple, à construire des ponts, l'ingénierie automobile fabrique des voitures etc. L'ingénierie des SI a pour objectif la construction de produits que sont les systèmes d'information. Le produit SI, comme les ponts et les automobiles peuvent se décrire à différents niveaux de détail et d'abstraction. On en reconnaît deux principaux en ingénierie des SI : le produit conceptuel et le produit réalisé. On admet en effet universellement, que l'ensemble des activités d'ingénierie conduisant au produit SI s'organise en deux groupes (figure 1) :

  • activités de conceptualisation ;

  • activités de transformation.

Les premières visent à représenter certaines parties d'intérêt de la réalité par des structures d'information et des règles de comportement afin d'obtenir une description conceptuelle de ce que le SI sera capable de faire. Elles aboutissent au produit conceptuel. Les secondes sont des transformations successives de la représentation conceptuelle aboutissant à un système en fonctionnement. Elles conduisent au produit final, réalisé qui prend la forme d'un ensemble de logiciels. Il est important de noter que cette classification des activités de production d'un SI, aujourd'hui admise par tous, repose sur une analyse de leur nature profonde : les activités de conceptualisation sont de nature abstraite et donc difficiles à automatiser ; elles sont aujourd'hui majoritairement conduites par les hommes. Au contraire, les activités de transformation se systématisent et s'automatisent. Les approches IDM (Ingénierie dirigée par les modèles) sont l'expression la plus récente de cette recherche d'automatisation. Dans ce paragraphe, l'accent est mis sur le produit conceptuel et sur les activités de sa production.

Le produit conceptuel ou schéma conceptuel est une représentation d'une certaine partie de la réalité, « l'Univers du Discours ». Sa production est donc le résultat d'un travail de modélisation conceptuelle qui s'appuie sur des modèles, les modèles conceptuels. Un modèle propose un ensemble de concepts et de règles pour les utiliser qui indiquent au modeleur les entités de la réalité sur lesquelles l'effort de représentation doit être concentré....

Cet article est réservé aux abonnés.
Il vous reste 93% à 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

Technologies logicielles Architectures des systèmes

(239 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
De la modélisation conceptuelle à l'ingénierie des exigences
Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - AMOROSO (E.J.) -   Fundamentals of computer security.  -  Prentice-Hall (1994).

  • (2) - ANTÒN (A.I.), POTTS (C.), TAKAHANSHI (K.) -   Inquiry based requirements analysis.  -  IEEE Conference on Requirements Engineering (1994).

  • (3) - ANTÒN (A.I.) -   Goal based requirements analysis.  -  2nd International Conference on Requirements Engineering (ICRE'96), p. 136-144 (1996).

  • (4) - ANTÒN (A.I.), EARP (J.B.), POTTS (C.), ALSPAUGH (T.A.) -   The role of policy and stakeholder privacy values in requirements engineering.  -  5th IEEE International Symposium on Requirements Engineering (RE'01), Toronto, Canada, 27-31, p. 138-145 (2001).

  • (5) - BELL (T.E.), THAYER (T.A.) -   Software requirements : are they really a problem ?  -  ICSE-2 : 2nd International Conference on Software Engineering, San Francisco, p. 61-68 (1976).

  • (6) - BOEHM (B.W.) -   Software...

Cet article est réservé aux abonnés.
Il vous reste 94% à 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

Technologies logicielles Architectures des systèmes

(239 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