Ingénierie des Exigences pour les Processus Inter-organisationnels

(1)

THESE EN CO

THESE EN CO-

-

-TUTELLE

TUTELLE

Soutenue en vue de l'obtention du titre de :

DOCTEUR EN INFORMATIQUE

De l'Université Mentouri de Constantine (Lab. LIRE)

et de l'Université de Toulouse (EDMITT, Lab. IRIT)

Intitulée

Ingénierie des Exigences pour les Processus

Inter-organisationnels

Présentée et soutenue publiquement par

Hakim BENDJENNA

Le 21/11/2010 à l'Université Mentouri de Constantine

Devant le jury composé des membres suivants :

Président de jury : Pr. Zizette Boufaida (Université Mentouri - Constantine, Algérie) Rapporteurs : Pr. Colette Rolland (Université Paris I- Sorbonne, France)

Dr. Djamel Meslati (Université Baji Mokhtar d'Annaba, Algérie) Examinateur : Pr. Chihab Hanachi (Université de Toulouse 1, France)

Directeurs de thèse : Pr. Nacer eddine Zarour (Université Mentouri - Constantine, Algérie) Pr. Pierre-Jean Charrel (Université de Toulouse, France)

(2)

ةدحاو نم ةطشنلأا ةمساحلا هذھل ةلحرملا . هذھ ةبوعصلا دادزت يف ةئيب ةعزوم يتلا لثمت ةئيب انثحب ثيح كانھ مظن تامولعم ةينواعت نيب تاسسؤملا . ببسلا عجري ىلإ اوح زج لصاوتلا نيب رصانعلا ةلعافلا ةطبترملا مھتتشتب نيب عقاوم ةديعب يف نامزلا ،ناكملاو قرفلاو يف ،ةفاقثلا تاغلا صئاصخلاو نيب تاھجلا ،ةلعافلا امو ىلإ كلذ . انسرد ةثلاث ميھافم ةيسيئر يتلاو موقت ىلع جھنلا ةمئاقلا راھظتسلا تاجايتحلاا : ،فدھلا ويرانيس و تاھجو رظنلا . انمق دقنب هذھ بيلاسلأا يف قايس نواعتلا كرتشملا نيب مظنلا ةيتامولعملا و اضيأ رصانعلا يتلا اھيلارقتفت لامعلأا ةدوجوملا ايلاح . سكعني اذھ داقتنلاا يف نيلاغشنا . لولأا وھ حارتقا لبس بلغتلل ىلع قئاوعلا يتلا مت اھديدحت يف قيبطت راھظتسا تاجايتحلاا و يناثلا وھ رظنلل يف لماوعلا يتلا رثؤت يف ةيلمع راھظتسا تاجايتحلاا لثم قراف تيقوتلا نيب عقاوملا ، تافلاتخلااو يف ةغللا نيب فارطلأا ةلعافلا ، امو ىلإ كلذ . نوكيو اھل ريثأت رايتخاٮلع تاينقت راھظتسلإا . لحلا يذلا دمتعا يف هذھ ةساردلا وھ حارتقا ةيجھنم ىعدت cro level from MAcro to MI ( MAMIE ) requirements Elicitation . يف MAMIE ، جمدن لك ميھافملا ةثلاثلا ،فدھلا ويرانيسلا و تاھجو رظنلا . مدختستو فادھلأ ريبعتلل نع فادھلأا ايلعلا ، تاھويرانيسلا مدقت افصو ايصن هذھل فادھلأا تاھجوو رظنلا يوحت تابلطتم ماظنلا يلبقتسملا . ةفاضلإابو ىلإ كلذ ، خا ةينقترايت راھظتسا تاجايتحلاا لا دمتعي ىلع تارايتخلإا ةيصخشلا للحملل ، نكلو وھ ةجيتن مييقتل ةيعضولا ةيلاحلا يتلا متي اھفصو عيمجب لماوعلا يتلا رثؤت ىلع اذھ رايتخلاا . ةدعاسمل للحملا مادختسلا MAMIE ، انمق ريوطتب ةادأ حمست كل ديدحتب فادھأ ةصاخ ، تاھويرانيسلاو ، تاھجو رظنلا تابلطتمو ماظنلا يف لبقتسملا . حاتفملا تاملكلا : تاجايتحلاا راھظتسا , ةيتامولعملا مظنلا نيب كرتشملا نواعتلا , ويرانيسلا ،فدھلا , رظنلا تاھجو

RESUME

Le processus d'ingénierie des exigences constitue la phase amont du cycle de développement d'un système d'information. L'élicitation des exigences est l'une des activités critiques de cette phase. Cette criticité augmente dans l'environnement distribué où se situent les systèmes coopératifs inter-organisationnels qui représentent notre contexte de travail. La cause est due aux obstacles de communication entre les acteurs, liés à la dispersion des acteurs entre les sites distants dans le temps et l'espace, la différence de culture, de langues et de caractéristiques entre les acteurs, etc.

Nous avons étudié trois des concepts principaux sur lesquels sont fondées les approches existantes d'élicitation des exigences : but, scénario et point de vue. Nous critiquons ces méthodes dans le contexte des systèmes coopératifs inter organisationnels, en établissant leurs intérêts mais aussi les éléments qui leur font défaut. De cette critique ressortent deux préoccupations. La première consiste à proposer des moyens pour remédier aux inconvénients recensés lors de l'application des approches d'élicitation existantes. La deuxième invite à considérer les facteurs qui influent sur le processus d'élicitation tels que le décalage horaire

(3)

entre les sites, la différence de langues entre les acteurs, etc., et qui ont un impact sur le choix des techniques d'élicitation. La solution adoptée dans ce mémoire de thèse est la proposition d'une méthodologie nommée MAMIE (from MAcro to MIcro level requirements Elicitation). Dans MAMIE, nous intégrons à la fois les trois concepts de but, scénario et point de vue. Les buts sont utilisés pour exprimer les objectifs de haut niveau dits de métier, les scénarios fournissent une description textuelle à ces objectifs et les points de vue permettent d'encapsuler les exigences du futur système. De plus, MAMIE fait appel de manière récurrente au choix d'une technique d'élicitation : ce choix ne dépend pas des préférences personnelles de l'analyste, mais il est le résultat d'une évaluation d'une situation décrite par l'ensemble des facteurs qui influent sur ce choix. Pour aider l'analyste à utiliser MAMIE, nous avons développé un outil, MAMIE-Tool, qui permet notamment de spécifier les buts, les scénarios, les points de vue et les exigences du futur système. MAMIE-Tool est présenté sur une étude de cas issue de l'industrie textile.

Mots clés : L’élicitation des exigences, Système d’information coopératif inter-organisationnel, But, Scénario, Point de vue, choix d’une technique d’élicitation.

ABSTRACT

Requirements Engineering (RE) process constitutes the earliest phase of the information system development life-cycle. Requirements elicitation is considered as one of the most critical activities of this phase. Moreover, requirements elicitation is still a challenge, especially in the distributed environment of so-called inter-company cooperative information system, where more issues are created by inadequate communication, time difference between sites, cultural and characteristics diversity of stakeholders. Even though existing requirements elicitation approaches based either on goal, scenario or viewpoint are effective techniques, however, it is well known that they present some difficulties in the practice.

In this thesis, we propose a methodology called MAMIE (from MAcro to MIcro level requirements Elicitation) which integrates the three notions of goal, scenario and viewpoint to elicit requirements for an inter-company cooperative information system. We argue that these concepts may be used simultaneously and in a complementary way to improve the requirements elicitation process. Moreover, in order to increase the quality of the elicited requirements and thus the system-to-be quality, selecting an elicitation technique in MAMIE is not based on personal preferences but on situation assessment. A tool has been developed to facilitate the operation of our methodology and an example from textile industry is used to illustrate its applicability.

Key-words: Requirements elicitation, Inter-company cooperative information system, Goals, Scenarios, Viewpoints, Elicitation technique selection.

(4)

A ma famille

A ma femme

A mes filles Sirine et Maram

(5)

REMERCIEMENTS

Tout d’abord, je tiens à exprimer mes plus vifs remerciements et ma gratitude à mes directeurs de thèse M. Nacer eddine Zarour et M. Pierre-Jean Charrel pour les encadrements continus et pour les remarques constructives qu’ils m’ont fournies. Je les remercies également pour la confiance q’ils m’ont accordée et pour la grande liberté d’idées et de travail qu’ils m’ont donnée. En dehors de leurs apports scientifiques, je n’oublierai pas à les remercier pour leurs qualités humaines, leur hospitalité et leur soutien qui m’ont permis de mener à bien ma thèse de doctorat. Je voudrais adresser ma profonde reconnaissance à M. Pierre-Jean Charrel qui m’a accueilli au sein de son équipe de recherche (IC3) à l’IRIT.

Je suis très reconnaissant au Pr. Mahmoud Boufaida, directeur du laboratoire LIRE de Constantine et Mme. Zizette Boufaida, professeur à l’université de Mentouri -Constantine pour leurs précieux conseils et encouragements.

Je remercie sincèrement Mme. Colette Rolland professeur à l’université de Paris I-Sorbonne, M. Djamel Meslati, maître de conférence à l’université Baji Mokhtar d'Annaba et qui ont eu la gentillesse d’accepter les rôles de rapporteurs. Je remercie également M. Chihab Hanachi, professeur à l’université de Toulouse 1, pour avoir accepté de faire partie du jury. Un grand merci aussi à Mme. Zizette Boufaida qui m’a fait l’honneur de présider ce jury.

Je remercie les membres des laboratoire LIRE et IRIT que j’ai pu côtoyer durant la période de ma thèse et qui ont su rendre mon travail agréable à travers leur simple présence et l’ambiance qu’ils ont su créer et plus particulièrement Mohamed Amroune, Louardi Bradji, Adil Anwar, Younes Lakhrissi, Toufik Dkaki, Rahma Bouaziz et Adel Ziani.

Je remercie du plus profond de mon cœur mes chers parents et ma femme pour leur soutien, leur patience et leur amour. Je suis très reconnaissant pour les sacrifices qu’ils ont dû faire pendant mes longues années d’études et d’absence.

(6)

LISTE DES FIGURES ... 09

LISTE DES TABLES ... 10

INTRODUCTION GENERALE ... 11

1. CONTEXTE DU TRAVAIL ... 11

2. PROBLEMATIQUE... 13

3. OBJECTIFS ET DEMARCHE ... 14

4. PLAN DE MEMOIRE ... 15

CHAPITRE I L’INGENIERIE DES EXIGENCES ... 17

1. INTRODUCTION ... 18

2. L’INGENIERIE DES EXIGENCES : DEFINITIONS... 18

3. MOTIVATIONS POUR L’INGENIERIE DES EXIGENCES... 20

4. MISSIONS ET OBJECTIFS DE L’INGENIERIE DES EXIGENCES... 21

5. L'INGENIERIE DES EXIGENCES ET LES APPROCHES D’ANALYSE ET DE CONCEPTION TRADITIONNELLES ... 22

6. LE PROCESSUS D’INGENIERIE DES EXIGENCES ... 25

7. L’ELICITATION DES EXIGENCES ... 27

7.1 Comprendre le domaine ... 28

7.2 IDENTIFIER LES PARTIES PRENANTES... 29

7.3 SELECTIONNER LES METHODES... 30

7.4 IDENTIFIER LES BESOINS... 32

8. LES TECHNIQUES D’ELICITATION DES EXIGENCES... 33

8.1 L’OBSERVATION... 34

8.2 L’INTERVIEW... 35

8.3 Le brainstorming ... 36

8.4 Le focus group... 37

9. CONCLUSION ... 37

CHAPITRE II LES APPROCHES D'INGENIERIE DES EXIGENCES ... 39

2. APPROCHES DIRIGEES PAR LES BUTS ... 41

2.1 La méthode i* pour l’élicitation des exigences ... 43

2.1.1 Les exigences préliminaires... 44

2.1.2 Les exigences finales... 45

3. APPROCHES A BASE DE SCENARIOS ... 47

3.1 Propos et rôles des scénarios ... 47

3.2 Les formats d’un scénario ... 48

4. APPROCHES COUPLANT LES BUTS ET LES SCENARIOS : LA METHODE CREWS... 48

4.1 La notion de but dans la méthode CREWS ... 49

4.2 La notion de scénario dans la méthode CREWS ... 50

(7)

T

TAABBLLEEDDEESSMMAATTIIEERREESS

7

5. LES APPROCHES PAR POINTS DE VUE ... 52

5.1 Point de vue et exigence ... 52

5.2 La méthode PREview ... 54

6. VERS UNE APPROCHE HYBRIDE D’INGENIERIE DES EXIGENCES... 57

6.1 Évaluation des approches actuelles d’ingénierie des exigences ... 57

6.2 UNE APPROCHE D’ELICITATION DES EXIGENCES INTEGRANT BUT, SCENARIO ET POINT DE VUE... 60

CHAPITRE III LA COOPERATION INTER-ORGANISATIONNELLE... 63

2. LA COOPERATION INTER-ORGANISATIONNELLE : CONCEPTS DE BASE... 64

2.1 COOPERER ? ... 64

2.2 LA COOPERATION INTER-ORGANISATIONNELLE : DEFINITIONS... 65

2.3 MOTIVATIONS POUR LA COOPERATION INTER-ORGANISATIONNELLE... 66

2.4 LA MISE EN ŒUVRE DE LA COOPERATION INTER-ORGANISATIONNELLE... 67

2.5 LE PROCESSUS INTER-ORGANISATIONNEL... 68

3. LES SYSTEMES D’INFORMATION COOPERATIFS INTER-ORGANISATIONNELS... 69

3.1 DEFINITION D’UN SYSTEME D’INFORMATION COOPERATIF INTER-ORGANSIATIONNEL... 69

3.2 POURQUOI DES SICIS ? ... 71

4. LES OUTILS INFORMATIQUES D’AIDE AU TRAVAIL COOPERATIF : LES COLLECTICIELS (GROUPWARE) ... 71

4.1 OBJECTIFS ET FONCTIONS D’UN COLLECTICIEL... 72

4.2 TAXONOMIES DES COLLECTICIELS... 72

4.3 CLASSIFICATION ESPACE-TEMPS... 75

5. LA COOPERATION INTER-ORGANISATIONNELLE : PROBLEMES ... 75

5.1 PROBLEMES LIES AU SYSTEME D'INFORMATION DE L'ORGANISATION... 75

5.1.1 Le manque d'agilité... 75

5.1.2 Problème concernant l'ouverture du système d’information à l'extérieur... 77

5.2 LES PROBLEMES LIES A L'INTERCONNEXION DE PROCESSUS... 77

6. ELICITATION DES EXIGENCES POUR UN SICI : FACTEURS A PRENDRE EN COMPTE ET QUELQUES TRAVAUX ... 78

CHAPITRE IV MAMIE : UNE METHODOLOGIE D’ELICITATION DES EXIGENCES D’UN SYSTEME D’INFORMATION COOPERATIF INTER-ORGANISATIONNEL... 82

2. MOTIVATIONS POUR UNE NOUVELLE METHODOLOGIE D’ELICITATION DES EXIGENCES D’UN SICI ... 84

3. PRESENTATION DES CONCEPTS DE BASE DE MAMIE... 84

3.1 LES CAS D’UTILISATION COOPERATIFS... 84

3.2 LES PROCESSUS COOPERATIFS INTER-ORGANISATIONNELS... 85

3.3 BUT, SCENARIO , POINT DE VUE : UN META-MODELE D’INTEGRATION... 85

3.4 L’IDENTIFICATION ET LA MODELISATION DES RELATIONS ENTRE LES PREOCCUPATIONS NON -FONCTIONNELLES... 86

3.4.1 Identification des PNFs ... 87

3.4.2 Elaboration d'une carte cognitive des relations entre les PNFs ... 88

3.4.3 Identification des poids flous des relations et élaboration de la carte cognitive floue ... 89

3.5 LE CHOIX D’UNE TECHNIQUE D’ELICITATION... 90

3.5.1 Evaluation de la situation actuelle ... 90

(8)

3.5.3 La sélection d’une technique d’élicitation ... 93

4. PRESENTATION DE MAMIE ... 95

4.1 CHOIX D’UNE TECHNIQUE D’ELICITATION... 95

4.2 ELICITATION DES EXIGENCES AU NIVEAU MACRO... 95

4.3 ELICITATION DES EXIGENCES AU NIVEAU MICRO... 97

4.4 LE PROCESSUS DE LA METHODOLOGIE MAMIE ... 98

5. MAMIE-TOOL : UN OUTIL POUR SUPPORTER MAMIE ... 100

CHAPITRE V ETUDE DE CAS ... 103

2. INTRODUCTION DU CAS D’ETUDE... 104

2.1 DOMAINE D’APPLICATION : L’INDISTRIE TEXTILES... 104

2.2 CAS D’ETUDE... 105

3. APPLICATION DE I*... 106

3.1 LES EXIGENCES PRELIMINAIRES... 106

3.2 LES EXIGENCES FINALES... 106

4. APPLICATION DE MAMIE ... 108

4.1 ELICITATION DES EXIGENCES AU NIVEAU MACRO... 108

4.1.1 Identification et spécification des cas d’utilisation coopératifs... 108

4.1.2 Identification et spécification des interactions inter- organisationnelles ... 113

4.2 ELICITATION DES EXIGENCES AU NIVEAU MICRO... 114

4.2.1 Identification des questions ... 114

4.2.2 Identification et spécification des préoccupations non-fonctionnelles ... 114

4.2.3 Identification et spécification des points de vue ... 116

5. DISCUSSION ... 117 6. CONCLUSION ... 119 CONCLUSION GENERALE ... 120 1. CONTRIBUTION ... 120 2. PERSPECTIVES ... 122 BIBLIOGRAPHIE ……….123

(9)

LISTE DES FIGURES

FIGURE 1.PLAN DE MEMOIRE...……….16

FIGURE I.1.LES PHASES D'INGENIERIE DES SYSTEMES.……O...19

FIGURE I.2.DISTRIBUTION DES CAUSES D’ECHECS SELON L’ETUDE DU STANDISH GROUP (2003)....…………20

FIGURE I.3.LE FONDEMENT DE L’INGENIERIE DES EXIGENCES D’APRES LAMSWEERDE (2000)...….………….22

FIGURE I.4.LE CYCLE <ACQUISITION, ABSTRACTION, VALIDATION>[TARDIEU & AL.1983]..….….…………23

FIGURE I.5.LES PHASES DE L'INGENIERIE DES EXIGENCES [KOTONYA &SOMMERVILLE 1998,NUSEIBEH & EASTERBROOK 2000,COULIN 2007]……...…....…….…....……….………...25

FIGURE I.6.LE PROCESSUS D’IE- VUE DETAILLEE..………...………27

FIGURE I.7.VUE DETAILLEE DE L’ELICITATION DES EXIGENCES ..………..29

FIGURE II.1.LES TROIS MONDES ET LEURS INTERACTIONS [JARKE 1993]…..………..40

FIGURE II.2.UN DIAGRAMME DE DEPENDANCE DU PROJET ECULTURE [BRESCIANI & AL.2004]…...………45

FIGURE II.3.EXEMPLE D’UN FRAGMENT DES DIAGRAMMES DE DEPENDANCES ET DE RAISONNEMENT [BRESCIANI & AL.2004]………...46

FIGURE II.4.LA STRUCTURE DU BUT EN NOTATION UML[PRAT 1997]…………..………...50

FIGURE II.5.LA STRUCTURE DE SCENARIO [ROLLAND & AL.1998B]……….………51

FIGURE II.6.LA NOTION DE FRAGMENT D’EXIGENCE [ROLLAND & AL.1998B]……...……….52

FIGURE II.7.COMPOSANTS D’UN POINT DE VUE D’APRES CHARREL (2004)…………..………53

FIGURE II.8.LE PROCESSUS DE LA METHODE PREVIEW D’APRES [SOMMERVILLE &SAWYER 1998]…….…..…….55

FIGURE II.9.INTERACTION ENTRE POINTS DE VUE ………..……...56

FIGURE II.10.UN META-MODELE POUR COUPLER BUT, SCENARIO ET POINT DE VUE……...………..……..61

FIGURE III.1.ETAPES DE MISE EN ŒUVRE D’UNE RELATION DE COOPERATION………...…..……….67

FIGURE III.2. PROCESSUS DE PRISE DE COMMANDE [BENOIT &AYMERIC 2002]………..70

FIGURE III.3.LES DEMANDES DE CHANGEMENT REDUISENT L'AGILITE DU SYSTEME D'INFORMATION AU COURS DU TEMPS (KRAFZIG & AL.2004)……….76

FIGURE III.4.LES PRINCIPAUX FACTEURS QUI INFLUENT SUR L’ELICITATION DES EXIGENCES POUR UN SICI…...80

FIGURE IV.1.UN DIAGRAMME DE CAS D’UTILISATION COOPERATIFS………84

FIGURE IV.2.L’INTERACTION INTER-ORGANISATIONNELLE………..85

FIGURE IV.3.INTERACTION ENTRE BUT, SCENARIO ET POINT DE VUE DANS MAMIE………....86

FIGURE IV.4.UN EXEMPLE D’UNE CARTE COGNITIVE ………...87

FIGURE IV.5UNE APPROCHE D’IDENTIFICATION ET DE MODELISATION DES RELATIONS ENTRE PNFS…………..89

FIGURE IV.6.RENSEIGNEMENTS PERSONNELS………...91

FIGURE IV.7RENSEIGNEMENTS PROFESSIONNELS ………92

FIGURE IV.8.DESCRIPTION DUNE SITUATION ET SPECIFICATION DES TECHNIQUES SUGGEREES………93

FIGURE IV.9.LES ETAPES DE MAMIE………...99

FIGURE IV.10.PASSAGE DES PREOCCUPATIONS DE HAUT NIVEAU VERS LES EXIGENCES FINALES………...100

FIGURE IV.11.COPIE ECRAN DE MAMIE-TOOL ……….101

FIGURE V.1. LE DIAGRAMME DE DEPENDANCE STRATEGIQUE……….107

FIGURE V.2.LE DIAGRAMME DE RAISONNEMENT……….107

FIGURE V.3.RENSEIGNEMENTS PERSONNELS D’UNE PARTIE PRENANTE………...109

FIGURE V.4.RENSEIGNEMENTS PROFESSIONNELS D’UNE PARTIE PRENANTE………109

FIGURE V.5.SITUATION ACTUELLE ET TECHNIQUE (S) UTILISEE (S)……… 111

FIGURE V.6.LE DIAGRAMME DE CAS D’UTILISATION COOPERATIFS……… 111

FIGURE V.7.COPIE ECRAN DE MAMIE-TOOL LORS DE LA CREATION D’UN NOUVEAU CAS D’UTILISATION COOPERATIF……….. 112

FIGURE V.8.DESCRIPTION DU SCENARIO DU PROCESSUS DE COOPERATION INTER-ENTREPRISE ………..113

FIGURE V.9.MODELISATION DES PNFS ET LEURS RELATIONS ……….115

FIGURE V.10.COPIE ECRAN DE MAMIE-TOOL LORS DE LA CREATION D’UNE NOUVELLE PNF………...116

(10)

TABLEAU II.1.LES CONTRIBUTIONS DES APPROCHES ORIENTEES BUT………46

TABLEAU II.2.VERIFICATION DE CONSISTANCE MUTUELLE ENTRE VP1 ET VP2...57

TABLEAU III.1.CLASSIFICATION ESPACE-TEMPS DES COLLECTICIELS………75

TABLEAU IV.1.NIVEAU D’APPLICABILITE DES CATEGORIES DE TECHNIQUES D’ELICITATION………94

TABLEAU IV.2TEMPLATE POUR UN CAS D’UTILISATION COOPERATIF ………96

TABLEAU IV.3.TEMPLATE POUR UNE PNF………...97

TABLEAU IV.4. TEMPLATE POUR UN POINT DE VUE ……….98

TABLEAU V.1.EVALUATION DE LA SITUATION ACTUELLE ………...108

TABLEAU V.2.DESCRIPTION DU CAS D’UTILISATION COOPERATIF FABRICATION DU PRODUIT ………112

TABLEAU V.3.DESCRIPTION DE LA PNFCOUT DU PRODUIT ………...115

(11)

I

NTRODUCTION GENERALE

1. Contexte du travail

Le contexte économique des dernières décennies a été marqué par de multiples mutations qui ne cessent de remettre en cause les stratégies d'organisations. En effet, on assiste à une mondialisation des marchés, à une sévère concurrence en termes de prix, de délai, de qualité et de flexibilité. De plus, la variabilité importante des demandes des clients et la difficulté de répondre à leurs besoins avec des coûts de production acceptables ont poussé les organisations à revoir en profondeur leurs processus et à devenir plus flexibles et plus agiles. Cette conséquence qui est aussi le résultat de l'expansion des technologies d'information et de communication et le raccourcissement du cycle de vie des produits, explique l'effort des organisations à orienter leurs réflexions sur le niveau inter-organisationnel et à tisser des relations de collaboration et de coopération. Ceci a donné naissance à un nouveau mode de travail notamment la coopération inter-organisationnelle. Dans le cadre de ce travail, nous nous intéressons plus particulièrement à la sous-traitance comme forme de coopération.

Cette grande dynamicité introduite par le contexte économique actuel exige des différents acteurs, participant à un scénario de collaboration, une forte capacité d'adaptation et de réactivité. Ces deux derniers facteurs reflètent la capacité de l'organisation à interagir d'une manière efficace avec l'ensemble des acteurs constituant son environnement. Il est indispensable par conséquent que les organisations fassent tomber les barrières culturelles, fonctionnelles, organisationnelles et technologiques pour que l'ensemble des organisations coopérantes soit perçu comme un tout homogène et cohérent. Les systèmes d’information coopératifs organisationnels permettent de supporter la coopération inter-organisationnelle.

Cependant, un grand nombre d'études [Lubars 1993; McGraw & Harbison 1997; Standish 2003] a montré que les échecs dans la mise en œuvre et l'utilisation des systèmes informatiques sont dus à une mauvaise compréhension des besoins auxquels ces systèmes tentent de satisfaire. Un exemple édifiant est celui de la refonte du système d'information du SAM londonien (gestion des ambulances d'urgence) qui, à cause d'une mauvaise compréhension des besoins, a abouti à plusieurs décès.

Les efforts lesquels requis pour corriger les erreurs découlant de cette mauvaise compréhension des besoins sont très importants [Jackson 1995]. Afin de corriger cette situation, il est nécessaire de définir des méthodes, des techniques et des outils pour éliciter, valider et représenter de manière adéquate et structurée les besoins relatifs aux systèmes à développer. Ce travail devrait permettre, dans le futur, de développer des systèmes plus adaptés. C'est l'objectif que s'est fixé l'ingénierie des exigences.

Traditionnellement, le développement d'un système d'information débute par la construction d'une représentation abstraite des données et des traitements en suivant une approche de modélisation conceptuelle. Ce type de modélisation a pour objectif de décrire ce que le système doit faire, c'est à dire ses fonctionnalités. Parmi les hypothèses (le plus souvent

(12)

implicites) sur lesquelles est basée la modélisation conceptuelle, il y en a trois qui paraissent essentielles :

• Les fonctionnalités d'un système sont stables, elles n'évoluent pas avec le temps. En conséquence, le schéma conceptuel d'un système est lui aussi stable.

• Les besoins relatifs à un système sont donnés au départ. Les utilisateurs expriment leurs besoins, le problème se réduit à construire le système qui répond à ces besoins ; et ce sont les analystes systèmes qui sont les personnes les plus adaptées pour faire ce travail.

• La validation des besoins peut se faire en référence aux fonctionnalités du système. En d'autres termes, le schéma conceptuel est le support privilégié pour communiquer, négocier et aboutir au consensus nécessaire entre les différentes parties impliquées dans le développement.

Aujourd'hui, il est clair que ces hypothèses ne sont plus valides. En réponse aux pressions économiques et à l'émergence constante de nouvelles technologies, les organisations changent plus rapidement que par le passé. En conséquence, ce que les utilisateurs attendent du système évolue bien plus rapidement qu'auparavant. Leurs besoins ne sont donc pas stables [Harker 1993].

Comprendre les impacts d'un changement organisationnel sur les systèmes informatiques existants est un problème très ouvert [Lubars 1993]. La prise en compte de l'évolution des besoins durant la phase de développement d'un système est aussi une problématique [Curtis & al. 1992]. Comme les besoins évoluant, il n'est donc plus possible de les considérer comme donnés a priori.

Il est plutôt nécessaire de déterminer les nouveaux besoins pour les systèmes existants et développer des modèles représentants fidèlement les besoins et leurs évolutions, durant tout le cycle de développement. De plus, le rôle central de l'analyste système doit être reconsidéré, l'ingénierie des exigences requière la participation d'un grand nombre d'acteurs de l'organisation, chacun apportant sa vision sur ce le système devrait faire [Finkelstein & Savigni 2001]. Enfin, la validation des besoins doit être basée sur les besoins réels de l'organisation plutôt que sur les fonctionnalités du système. C'est seulement à cette condition que les systèmes informatiques seront capables de s'adapter aux changements organisationnels.

En s'attaquant à ces problèmes, l'ingénierie des exigences tente de surpasser la vue fonctionnelle de la modélisation conceptuelle. Nous mettons en avant deux dimensions autour desquelles cette tentative est faite :

• L'ingénierie des exigences ne se limite plus à prendre en compte ce que doit faire le système mais cherche à comprendre le "pourquoi" du système. On répond à la question du "pourquoi" dans des termes d'objectifs organisationnels et de l'impact de ces objectifs sur le système de l'organisation. En d'autres termes, les systèmes ont un propos vis-à-vis de l'organisation et l'ingénierie des exigences aide à la conceptualisation de ce propos. Ceci a deux implications. En premier lieu, l'élucidation et la validation des besoins d'un système doivent être réalisées en fonction de leur propos dans l'organisation. Ensuite, seuls les systèmes ayant un propos organisationnel pertinent doivent être étudiés.

• L'ingénierie des exigences ne s'intéresse pas directement aux fonctionnalités d'un système, ni à ce qui doit être réalisé par le système tel que cela a été conceptualisé par un analyste

(13)

I

INNTTRROODDUUCCTTIIOONNGGEENNAARRAALLEE

13 en partant d'un ensemble de besoins donnés. Au contraire, ce sont les utilisateurs potentiels du futur système qui sont les plus à même de fournir des points de vue utiles et réalistes sur le système à développer. En conséquence, il faut effectuer une exploration détaillée des différentes manières dont le système sera utilisé ainsi que les activités qu'il doit supporter. Ceci peut être fait, par exemple, en étudiant les interactions attendues entre le système et ses utilisateurs à l'aide de "cas d'utilisation" [Jacobson 1992]. Cette exploration aboutie à l'identification d'activités normales et d'activités exceptionnelles dont l'intégration modélise le comportement global du système. Dans ce sens, déterminer ce que le système doit faire est une question intéressante pour l'ingénierie des exigences.

Selon Nuseibeh & Easterbrook (2000), un processus d'ingénierie des exigences inclut les phases d'élicitation, de modélisation, d'analyse, de spécification, de validation et de gestion des exigences. Dans notre travail on s’intéresse à la phase d’élicitation, la première phase du processus. L’objectif de cette phase consiste en la collecte, la capture, la découverte et le développement des exigences à partir d'une variété de sources y compris les parties prenantes humaines.

En premier lieu, l'évolution permanente des besoins implique que les hypothèses faites, les décisions prises et les alternatives explorées doivent être mémorisées et disponibles pour un usage futur. En second lieu, l'élicitation des exigences est connue pour être une tâche complexe et nécessite d'être guidée. Ce guidage doit permettre de déterminer quelle activité mener et dans quel contexte ainsi que comment mener une activité. Enfin, une liberté importante doit être donnée à l'ingénieur des exigences pour déterminer l'ordre dans lequel les activités doivent s'enchaîner. Afin de répondre à tous ces objectifs, une méthode d'élicitation des exigences, comprenant une démarche, un ensemble de modèles et des outils logiciels, doit être développée. Les approches d’élicitation des exigences existantes sont souvent basées sur un des trois concepts suivants : but, scénario ou point de vue.

2. Problématique

L’élicitation des exigences est un élément fondamental du processus de développement des systèmes, mais souvent considéré comme étant le problème majeur en recherche et en pratique, et largement considéré comme l’une des activités les plus difficiles du processus d’ingénierie des exigences.

Parmi les effets ultérieurs d’une mauvaise conduite du processus d’élicitation des exigences on peut citer les dépassements du délai et de coût, l’insatisfaction des parties prenantes et l’échec du projet [Hickey & Davis 2002]. Malgré la nécessité évidente d’avoir un processus d’élicitation avec un niveau de structuration et de rigueur approprié, cette critique, complexe et potentiellement coûteuse activité est souvent effectuée d’une manière ad-hoc, sans un processus défini ou méthodologie [Coulin 2007].

A ce problème s’ajoute le fait que la plupart des techniques, des approches et outils actuels pour l’élicitation des exigences sont inconnus ou trop complexes pour les novices. De plus, il y a une réticence générale à les adapter dans l’industrie, résultant en un écart important entre l’élicitation des exigences en pratique et en réalité [Hickey 2003].

Tout aussi important est l’écart actuel entre expert et novices analystes, qui peut être dû à plusieurs facteurs, pas moins de ce qui est l’ensemble de compétences et d’expérience qui est souvent nécessaire pour réussir cette activité, difficile mais cruciale [Hickey & Davis 2003a].

(14)

Le manque de méthodologies systématiques et un processus qui fournit des lignes directives pouvant être appliquées à des situations réelles sont des raisons supplémentaires pour l’écart actuel entre l’élicitation des exigences dans la recherche et en pratique [Coulin 2007].

L’utilisation des approches d’élicitation des exigences actuelles basées sur l’un des concepts : but, scénario ou point de vue a montrée leurs limites, et des travaux ont été menés pour leur intégration dans une même approche d’élicitation. Rolland & al. (1998b) par exemple ont proposé une approche nommée CREWS pour l’élicitation des exigences dans laquelle les auteurs utilisent à la fois but et scénario.

Pour l’élicitation des exigences d’un système d’information coopératif inter-organisationnel d’autres facteurs sont à considérer. D’abord, il faut prendre en compte le processus coopératif inter-organisationnel en élicitant “qui“ fait “quoi“, “quand“ et “comment“, etc. Cela n’exclut pas l’intérêt d’avoir ces informations dans les autres systèmes.

De plus, la distance entre les sites et le décalage horaire entraînent des problèmes de communication [Damian & Zowghi 2002]. En ajoutant à cela, les différences de langues et de cultures entre les parties prenantes. Par conséquent le choix d’une technique d’élicitation devient un problème crucial [Hickey & Davis 2002]. Tout cela va rendre le processus d’élicitation dans cet environnement de plus en plus difficile.

3. Objectifs et démarche

L’hypothèse générale de notre recherche est que le processus d’élicitation des exigences d’un système d’information coopératif inter-organisationnel peut être amélioré en terme d’efficacité et d’utilisabilité.

En particulier, pour augmenter l’efficacité de ce processus nous proposons d’intégrer à la fois but, scénario et point de vue dans une même méthode, en l’associant à un outil qui supporte les concepts utilisés dans cette méthode.

L’utilisabilité du processus peut être améliorée en : • Se basant sur des concepts et modèles existants.

• Proposant certaines lignes directrices qui permettent de choisir une technique d’élicitation adéquate en prenant en compte le décalage horaire entre les sites, le niveau d’abstraction des exigences à éliciter, la différence de langues entre les parties prenantes et leurs préférences en techniques d’élicitation.

Pour valider notre hypothèse initiale, nous avons établi et examiné en séquence les objectifs suivant :

Objectif 1 : Etudier dans la littérature l’état de l’art sur l’ingénierie des exigences.

(15)

I

INNTTRROODDUUCCTTIIOONNGGEENNAARRAALLEE

15

4. Plan de mémoire

Comme décrit dans la Figure 1, la structure en cinq chapitres de ce mémoire reflète notre démarche de travail.

Chapitre I : L’ingénierie des exigences

Dans ce chapitre nous introduisons le domaine d’ingénierie des exigences en détaillant le processus d’élicitation. Nous présentons également quelques techniques d’élicitation et leur classification. En particulier nous présentons :

• Quelques définitions, objectifs ainsi que le processus d’ingénierie des exigences. • Détails de la phase d’élicitation.

Chapitre II : Les approches d’ingénierie des exigences

Dans ce chapitre nous focalisons sur l’état de l’art des approches d’ingénierie des exigences. L’objectif de ce chapitre est de fournir une base théorique pour notre recherche en analysant les approches existantes d’ingénierie des exigences. Nous introduisons également dans ce chapitre les principes de base d’une nouvelle approche hybride d’élicitation des exigences.

Chapitre III : La coopération inter-organisationnelle

Dans ce chapitre nous présentons la coopération inter-organisationnelle et les problèmes que cette pratique peut engendrer à l’organisation. Nous présentons aussi les facteurs à prendre en compte pour minimiser ces problèmes lors de la phase d’élicitation considérée parmi les phases les plus critiques du processus de développement. Nous discutons également quelques travaux réalisés dans ce contexte. Nous présentons ainsi :

• Définitions et motivations de la coopération inter-organisationnelle.

• Les systèmes d’information coopératifs inter-organisationnels et les problèmes de leurs mises en œuvre.

• Les facteurs à prendre en compte pour l’élicitation des exigences d’un système d’information coopératif inter-organisationnel.

• Analyse de quelques travaux existants.

Objectif 5: Montrer l’utilisabilité et la faisabilité de la méthode et l’outil proposés par une étude de cas.

Objectif 4: Proposer une méthode et développer un outil pour aider l’analyste à effectuer l’élicitation des exigences pour un système d’information coopératif.

(16)

L’ingénierie des exigences

Les approches d’ingénierie des exigences La coopération inter-organsiationnelle Conclusion générale Introduction générale

MAMIE: une méthode d’élicitation des exigences d’un système d’information

coopératif inter-organisationnel

Etude de cas

Analyse et synthèse de l’état de l’art

Proposition

Chapitre IV : MAMIE : une méthode d’élicitation des exigences d’un système d’information coopératif inter-organisationnel

Dans ce chapitre nous présentons MAMIE : la méthode que nous proposons pour l’élicitation des exigences d’un système d’information coopératif inter-organisationnel. Avant cela, nous commençons par introduire d’abord les concepts de base de cette méthode.

Chapitre V : Etude de cas

Dans ce chapitre nous montrons l’utilisabilité et la faisabilité de MAMIE à travers une étude de cas dans le domaine de l’industrie textile. Avant cela, nous appliquons la méthode orientée but i* au même exemple pour montrer la différence entre les concepts utilisés pour modéliser les activités coopératives et la dépendance entre les organisations dans cette méthode et dans MAMIE.

Ce mémoire de thèse se termine par le bilan des différents travaux réalisés dans la thèse et les travaux que nous envisageons dans le futur.

(17)

Chapitre I

L’

INGENIERIE DES EXIGENCES

“Le début est la partie la plus importante du travail“

Platon, 4 avant JC

SOMMAIRE

2. L’INGENIERIE DES EXIGENCES : DEFINITIONS... 18

3. MOTIVATIONS POUR L’INGENIERIE DES EXIGENCES... 20

4. MISSIONS ET OBJECTIFS DE L’INGENIERIE DES EXIGENCES... 21

5. L'INGENIERIE DES EXIGENCES ET LES APPROCHES D’ANALYSE ET DE CONCEPTION TRADITIONNELLES ... 22

6. LE PROCESSUS D’INGENIERIE DES EXIGENCES ... 25

7. L’ELICITATION DES EXIGENCES ... 27

8. LES TECHNIQUES D’ELICITATION DES EXIGENCES... 33

(18)

1. Introduction

La réussite d'un projet de développement d'un système dépend d'une identification réelle des besoins que le système est censé satisfaire. Dans les années 70 à 80, les systèmes étaient développés selon la vision des concepteurs et des ingénieurs, sans l'implication effective des utilisateurs et autres parties prenantes. Cela a abouti à l'abandon de nombreux systèmes qui étaient très bien construits d'un point de vue technologique, mais qui ont été considérés comme des échecs car ils ne correspondaient pas aux besoins des utilisateurs. Plus tard, le marketing a trouvé plus de succès parce qu'il a réalisé que les clients et les utilisateurs finaux devaient être impliqués dans le processus de développement et spécialement durant la définition des fonctionnalités du système. De nombreux éléments doivent être pris en compte tels que : les besoins des utilisateurs, le budget, l'économie, les aspects politiques et finalement la définition des solutions du problème. Afin de minimiser le taux d’échec de l’utilisation des systèmes informatiques dû à ce genre de lacunes, une étape dite d’ingénierie des exigences doit être clairement identifiée dans le processus de développement des systèmes d'information, et l’application des méthodologies et des technologies d’ingénierie des exigences s’avère nécessaire.

Ce chapitre vise à faire une présentation succincte permettant de comprendre le cadre général de note travail à savoir l’ingénierie des exigences. Il est organisé comme suit. Dans la section 2 nous présentons quelques définitions de l’ingénierie des exigences. Les motivations pour l’ingénierie des exigences sont ensuite présentées dans la section 3. La section 4 détaille les missions et objectifs de l’ingénierie des exigences. Ensuite, nous situons le processus d’ingénierie des exigences dans les approches traditionnelles de développement des systèmes d’information dans la section 5 avant de présenter les étapes de ce processus dans la section 6. Nous détaillons ensuite le processus d’élicitation des exigences dans la section 7. Avant de conclure nous présentons dans la section 8 quelques techniques fréquemment utilisées durant ce processus.

2. L’ingénierie des exigences : définitions

L’ingénierie des systèmes est le domaine d’informatique concerné par le développement des systèmes informatiques, ainsi que les processus, méthodes et outils utilisés lors du développement [Finkelstein & Kramer 2000]. Un système résulte d’un cycle de développement dont l’Ingénierie des Exigences (IE) est une phase initiale du projet qui précède la conception du système. Cette phase est généralement suivie des phases de conception, spécification, test, implémentation et maintenance, comme le montre la Figure I.1. Cependant, la phase d’IE peut également être effectuée de manière itérative et incrémentale tout au long du cycle de développement, et les résultats de cette phase peuvent également être utilisés pour des fins de planification et de déterminer si un projet devrait se poursuivre (une étude de faisabilité).

Ainsi, l’IE est la première étape fondamentale de n’importe quel projet de développement de système. Selon le GTIE (Groupe de Travail sur l’Ingénierie des Exigences) de l’AFIS (Association Française de l‘Ingénierie des Systèmes) [AFIS 2007], l’IE désigne l’ensemble des activités destinées à découvrir, analyser, valider et faire évoluer un ensemble d’exigences relatives à un système. Elle permet de montrer la satisfaction des besoins et des engagements durant tout le cycle de vie d’un système [GTIE 2007].

(19)

C

CHHAAPPIITTRREEI I: :LL’I’INNGGEENNIIEERRIIEEDDEESSEEXXIIGGEENNCCEESS

19 Figure I. 1. Les phases d'ingénierie des systèmes

Les éléments de base de l’IE sont :

• Les parties prenantes : une partie prenante est une entreprise, une organisation ou un individu ayant un intérêt ou une partie dans le résultat de l’ingénierie d’un système. Selon l’AFIS, une partie prenante constitue une partie intéressée par l’utilisation et l’exploitation du système (voire par ses impacts sur son environnement), mais aussi un agent participant à sa conception, sa production, son déploiement, sa commercialisation, son maintien en condition opérationnelle et son retrait de service [AFIS 2007].

• Les besoins : c’est la perception que l’utilisateur a du système [Essame 2002]. Ce besoin s’exprime souvent sous forme de problèmes que rencontrent les utilisateurs auxquels le système est destiné.

• Les exigences : il n’existe pas une définition unique de l’exigence, mais plusieurs telle que celle donnée par Davis qui considère l’exigence comme étant une caractéristique visible, vue de l’extérieur de système [Davis 2000]. Selon l’IEEE, une exigence est une condition ou une capacité qui doit être satisfaite par un système ou composant d’un système pour satisfaire un contrat, une norme, une spécification, ou autres documents formellement imposés [IEEE 1990]. Comparativement au besoin, qui est lié à l’utilisateur, l’exigence est la vision que le concepteur ou le développeur a du système [Essam 2002]. La traçabilité des exigences se rapporte à la capacité de décrire et suivre la vie d'une exigence dans les différentes phases de développement du système.

Une exigence est dite traçable si on sait répondre aux questions suivantes: - Qui a suggéré cette exigence ?

- Pourquoi est-ce qu’elle a été agréée ? - Quelles autres exigences sont liées ?

- Comment elle est reliée aux autres informations comme les documents de la conception, l’implantation, l’usager, etc. ?

Souvent, les exigences peuvent être classées dans deux catégories : • Les exigences fonctionnelles : expriment les fonctions attendues du système.

• Les exigences non fonctionnelles : traduisent les contraintes globales de qualité de service ou d’aptitude du système (fiabilité, maintenabilité, opérabilité, évolutivité, convivialité,

Ingénierie des exigences Conception Spécification Test Implémentation G es ti o n d u p ro je t Maintenance

(20)

sécurité, performance, etc.), ou des contraintes opérationnelles (conformité à des normes d’utilisation), ou des contraintes de conception (réutilisation d’existant).

3. Motivations pour l’ingénierie des exigences

Les motivations pour l’ingénierie des exigences sont multiples. En 1976 déjà, Bell & Tayer ont fait observer que l’inadéquation des fonctionnalités du système aux besoins des usagers, l’incohérence, l’incomplétude et l’ambiguïté des documents des exigences avaient une influence majeure sur la qualité du logiciel final [Bell & Tayer 1976]. Brooks énonce « the hardest single part of building a software system is deciding precisely what to build… Therefore, the most important function that the system builder performs for the client is the iterative extraction and refinement of the product requirements » [Brooks 1987]. Dans son étude sur les erreurs du programme Voyager & Galileo de la NASA, Lutz (1993) rapporte que la principale cause vient des erreurs d’expression des exigences fonctionnelles et d’interface.

Plusieurs enquêtes ont confirmé l’ampleur des dégâts causés par l’insuffisance de qualité des documents des exigences. Une enquête menée auprès de 800 projets conduits dans 350 compagnies américaines par le Standish Group (2003) et présentée dans deux rapports, intitulés “Chaos“ et “Unfinished Voyages“, a révélé que 31% des projets sont annulés avant même d’être terminés. En 1995, cela a coûté 81 milliards de dollars aux compagnies américaines. Ce même rapport montre que 50% d’entre eux n’avaient que partiellement réussi dans le sens où ils avaient nécessité des budgets et des délais très fortement majorés. Comme l’indique la Figure I.2 la mauvaise qualité des documents des exigences constitue 47% des causes d’échecs citées. Ce pourcentage est distribué de la façon suivante : manque de participation des utilisateurs (13%), besoins mal exprimés (ou incomplets) (12%), besoins changés entre le début et la fin du projet (11%), besoins qui manquent de réalisme (6%), et objectifs peu clairs (5%).

autres cause d' échecs

13% 0 53% 12% 11% 6% 5% 0% 10% 20% 30% 40% 50% 60%

causes d'échecs liés aux besoins

obejctifs peu clairs

besoins qui manquent du réalisme

besoins changés entre le début et la fin du projet besoins mal exprimés

manque de participation des utilisateurs

Figure I.2. Distribution des causes d’échecs selon l’étude du Standish Group (2003)

De plus, parmi les projets menés à terme, près de 67% des coûts de maintenance résultent de l’incomplétude des documents de spécification des exigences : “La plupart des efforts de maintenance consistent à fournir des fonctionnalités nécessaires mais manquantes“ [Mc Graw & Harbison 1997].

(21)

C

21 En Europe, une enquête de grande envergure effectuée auprès de 3800 organisations dans 17 pays différents [ESI 1996] a conclu dans le même sens : les principaux problèmes sont liés à la spécification des exigences (>50% des réponses) et à la documentation des exigences (50%).

Christel & kang (1992) ont classé les problèmes qui se posent lors de l’élicitation des exigences en dix points, appartenant à trois classes différentes :

• Problèmes d’étendue du système étudié

- Les frontières du système sont mal définies. - Des informations non nécessaires sont fournies. • Problèmes de compréhension

- Les utilisateurs ont une idée incomplète de leurs besoins.

- Les utilisateurs connaissent mal les possibilités et contraintes des systèmes proposés. - Les analystes ont une faible connaissance du domaine.

- L’utilisateur et l’analyste parlent des langages différents. - Il est facile d’omettre des informations.

- Il peut exister des conflits de points de vue entre différents utilisateurs. - Les besoins sont souvent vagues et non mesurables.

• Problèmes de volatilité des exigences

- Les exigences évoluent au cours du temps.

On comprend à travers ces faits et chiffres, l’importance de l’IE et son caractère crucial pour la production de systèmes de qualité. Pour remédier à cette situation d’insuccès il semble nécessaire de s’interroger sur la mission de l’IE et aussi, de comprendre pourquoi les approches d’IE pratiquées traditionnellement n’ont pas encore totalement atteint leurs objectifs. C’est ce que nous tentons de faire dans les sections suivantes.

4. Missions et objectifs de l’ingénierie des exigences

L’IE doit d’abord s’intéresser aux buts du contexte organisationnel du système à développer parce qu’ils permettent de comprendre les raisons justifiant son développement. Ainsi, l’IE doit poser la question POURQUOI développer un système et aider les acteurs du projet à y répondre. Le rôle de l’IE est ensuite de déterminer les fonctionnalités que le système doit mettre en œuvre pour aider à la satisfaction de ces buts et identifier les contraintes qui restreignent la mise en œuvre de ces fonctions. Ces buts, fonctions et contraintes, constituent les exigences qui doivent ultérieurement être converties en une spécification précise permettant le développement du système. L’évolution des exigences au cours du temps et la répercussion de leur évolution sur la spécification du système doivent aussi être prises en compte [Zave 1997].

La Figure I.3 empruntée à Axel van Lamsweerde (2000) schématise cette vue de l’IE centrée sur les questions POURQUOI et QUOI ainsi que la mise en correspondance des réponses inhérentes à l’une et à l’autre.

(22)

Figure I.3. Le fondement de l’ingénierie des exigences d’après Lamsweerde (2000)

Se centrer sur le POURQUOI doit permettre de découvrir les exigences correspondantes à la mission et aux objectifs de l’organisation. Si l’on veut éviter de développer des systèmes techniquement parfaits mais inutilisés parce qu’inadaptés aux besoins réels de leurs utilisateurs, il faut se donner les moyens de comprendre à quoi le système va servir dans son contexte organisationnel. C’est la mission de l’IE. Mais ce n’est pas la pratique courante comme nous tentons de le montrer dans la section suivante.

5. L'ingénierie des exigences et les approches d’analyse et de

conception traditionnelles

Dans les méthodes héritées des années 80 telles que MERISE, l’IE est partie intégrante de l’étape "d’analyse" aboutissant à la construction d’une représentation des données, des traitements et des interfaces en suivant une approche de modélisation conceptuelle. L’objectif principal est de décrire ce que le système doit faire, c’est à dire ses fonctionnalités, dans un schéma conceptuel. Comme le montre la Figure I.4, l’IE fondée sur la modélisation conceptuelle est centrée sur la question QUOI à laquelle on répond par le cycle <acquisition, abstraction, validation>. La tâche d’acquisition de connaissances de domaine et des exigences s’appuie sur un cahier des charges et des interviews. Elle permet d’abstraire à partir de la connaissance acquise, la spécification des fonctionnalités attendues du système. Le schéma conceptuel résultant sert de support à la validation des exigences par des techniques telles que le maquettage et le prototypage [Rolland & al. 1998a].

L’IE fondée sur la modélisation conceptuelle n’est pas réellement conforme à la définition que nous en avons donnée. Un centrage exclusif sur le QUOI inhibe les vraies questions du POURQUOI et risque d’aboutir à la production d’une spécification conceptuelle d’un système inadapté aux réelles attentes de ses usagers. Par ailleurs, le schéma conceptuel est l’expression d’une solution fonctionnelle des besoins à l’égard du système. L’absence d’une expression des besoins eux-mêmes ne peut que rendre difficile la validation par les parties concernées [Rolland & al. 1998a].

Pourquoi ? Quoi Buts Opérationnalisation Connaissances du domaine Besoins

(23)

C

23 Figure I.4. Le cycle <acquisition, abstraction, validation> [Tardieu & al. 1983]

En outre la pratique du cycle précédent repose sur trois hypothèses [Rolland & al. 1997] :

• Les fonctionnalités d’un système sont stables, elles évoluent peu dans le temps. En conséquence, le schéma conceptuel d’un système est lui aussi stable.

• Les exigences relatives à un système sont données au départ. Les utilisateurs expriment leurs besoins dans un cahier des charges, le problème est donc de construire le système qui répond à ce cahier des charges. Ce sont les analystes (la maîtrise d’œuvre) qui sont en charge de ce travail.

• La validation des exigences peut se faire en référence aux fonctionnalités du système. En d’autres termes, le schéma conceptuel est le support privilégié pour communiquer, négocier et aboutir au consensus nécessaire entre les différentes parties impliquées dans le développement du système.

Si dans les années 1980/1990, ces hypothèses étaient valides, elles ne le sont plus aujourd’hui. En réponse aux pressions économiques et à l’émergence constante de nouvelles technologies, les organisations changent plus rapidement que par le passé. En conséquence, ce que les utilisateurs attendent du système évolue bien plus rapidement qu’auparavant. Leurs besoins ne sont donc pas stables [Harker & al. 1993]. Aussi, ils évoluent eux-mêmes au cours du projet [Lubars & al. 1993] et il est donc nécessaire de se doter de moyens permettant d’établir un lien conceptuel entre les buts et objectifs de l’organisation (réponse au POURQUOI), les besoins qui en résultent (réponse au QUOI) et les spécifications fonctionnelles du système qui les supportent.

Dans les projets actuels, le rôle central de l’analyste système est reconsidéré et la maîtrise d’ouvrage vient contrebalancer le rôle de la maîtrise d’œuvre. Ainsi, il est clair comme le suggérait déjà Finkelstein & al. (1990) que l’IE requiert la participation d’un grand nombre d’acteurs de l’organisation, chacun apportant sa vision sur ce que le système devrait faire. On distingue par exemple, les utilisateurs finaux du système – ceux qui utiliseront le système

Univers de discours

Schéma interne

Ingénierie des exigences

Acquisition et abstraction Validation Conception Correction Schéma conceptuel

(24)

pour mener à bien leurs activités au sein de l’organisation –, les responsables de l’organisation qui ont décidé de la mise en place du système, les personnes responsables de la mise en place et de la maintenance du système, etc.; en fait tous ceux pour qui le développement du système constitue un enjeu (les « stakeholders » dans la terminologie anglo-saxonne) [Rolland & al. 1998a].

Enfin, l’expérience a montré que la validation des exigences sur la base du schéma conceptuel n’est pas satisfaisante. On peut accepter l’idée que cette validation soit bien plus efficiente si elle est basée sur l’expression des besoins eux-mêmes et non sur la spécification abstraite et difficile à comprendre des spécifications fonctionnelles du système qui en résulte. Ceci justifie l’introduction d’un document des exigences dans lequel les exigences spécifiées peuvent être discutées, négociées et validées [Rolland & al. 1998a].

En résumé l’IE :

• N’a pas vocation à se centrer sur le QUOI mais sur le POURQUOI pour en dériver un QUOI motivé.

• Doit décrire le QUOI en termes d’exigences que le système doit satisfaire et non de spécification des fonctionnalités du système.

L’IE cherche à répondre à la question POURQUOI et à associer un QUOI compatible et motivé par le POURQUOI. Elle fait appel à des modèles aussi bien pour exprimer la dimension POURQUOI que pour la description du QUOI et préconise d’établir et de tracer le lien entre les éléments du premier modèle et ceux du second. Ce lien doit faciliter la répercussion d’un changement organisationnel sur les exigences.

Cette vision de l’IE laisse éclairer les raisons pour lesquelles le processus d’IE est si complexe et encore mal maîtrisé [Rolland & al. 1998a] :

• Le champ est large puisqu’il s’étend du domaine social des organisations à celui des lois de la physique aux artefacts qui doivent y être intégrés; des objectifs stratégiques aux prescriptions logicielles fines; de l’informel au formel. Le système cible n’est pas seulement un logiciel mais comprend l’environnement organisationnel dans lequel il doit opérer. Celui-ci est complexe car il est constitué d’êtres humains, de machines et/ou de logiciels. Le système doit être considéré selon de multiples points de vue : socio-économiques, physiques, opérationnels, évolutifs, etc.

• Il y a d’autres aspects à prendre en compte en plus des aspects fonctionnels du système qui viennent à l’esprit, en premier lieu : la sécurité, la performance, la robustesse, la facilité d’utilisation, l’interopérabilité, etc. Tous ces aspects sont appelés non fonctionnels et ont la particularité d’être souvent en conflit les uns avec les autres.

• Il y a de nombreux acteurs. Citons, les ingénieurs des exigences, les clients, les experts du domaine, les utilisateurs, les commanditaires, les ingénieurs de maintenance et les ingénieurs d’applications. Chacun ayant son champ de compétences et de connaissances, sa propre culture, ses propres points de vue et intérêts. Ces différents acteurs ont des points de vue différents, voire conflictuels.

• Les spécifications des exigences peuvent être entachées de nombreuses erreurs. Certaines d’entre elles peuvent être terriblement pénalisantes et avoir des effets désastreux sur les étapes suivantes du développement et/ou sur la qualité du futur système. Ce sont par

(25)

C

25 exemple les incomplétudes et incohérences, ambiguïtés, inadaptations aux exigences réels; d’autres sont des faiblesses de la spécification qui peuvent aboutir à des pertes de temps ou la génération de nouvelles erreurs.

6. Le processus d’ingénierie des exigences

Selon Nuseibeh & Easterbrook (2000), un processus d'IE inclut les phases d'élicitation, de modélisation, d'analyse, de spécification, de validation et de gestion des exigences comme le montre la Figure I.5. D'autres auteurs proposent des découpages différents du processus d'IE comme Kotonya & Sommerville (1998) qui ont mis en évidence toutes les phases précitées sauf celle de la modélisation. Ces différences ne s'expliquent pas forcément par une omission de phases, mais peuvent être considérées comme différentes façons de voir le processus comme par exemple Kotonya & Sommerville qui incluent la modélisation dans la phase d'analyse.

Figure I.5. Les phases de l'ingénierie des exigences [Kotonya & Sommerville 1998, Nuseibeh & Easterbrook 2000, Coulin 2007]

De ce fait, nous proposons les définitions ci-après provenant de l'une ou l'autre des deux visions sachant qu'au delà de ces différences apparentes, elles partagent un fond commun (voir la Figure I.6) :

• L'Elicitation des exigences consiste en la collecte, la capture, la découverte et le développement des exigences à partir d'une variété de sources y compris les parties prenantes humaines. Nous détaillons cette phase qui fait l’objet de notre étude dans la section suivante.

• La Modélisation est une abstraction du problème par des représentations parfois graphiques. c'est la construction d'une description et d'une représentation abstraite d'un système pour les besoins de l'interprétation [Nuseibeh & Easterbrook 2000]. Divers aspects d'un système peuvent être modélisés pour avoir une compréhension approfondie du contexte ou de l'environnement. Par exemple, quand la modélisation porte sur les données utilisées et générées par le système, pour avoir plus de compréhension par rapport à la structure des informations sur le système, la modélisation de données peut être utilisée. Un exemple de modèle de données est le modèle entité-relation. Lorsque la modélisation est utilisée pour comprendre les parties prenantes ou la dynamique du système, ou encore le

Ingénierie des exigences Elicitation Modélisation Analyse Spécification G es ti on d es e x ige n ce s Validation

(26)

comportement fonctionnel, nous parlons de modélisation comportementale dont un exemple connu est la modélisation de cas d'utilisation [Kulak & Guiney 2000]. La modélisation peut aussi concerner le processus. Par exemple la modélisation de processus de collaboration [Briggs & Grünbacher 2002] et la modélisation de workflow [Yuhong & Bejan 2000]. Nous pouvons aussi citer la modélisation orientée objet [SINTEF 2008]. • L'Analyse se focalise sur l'examen, la compréhension des exigences élicitées et leur

vérification pour la qualité en termes d'exactitude, de complétude, de clarté et de consistance. C'est l'examen et l'interprétation des résultats issus de la phase de modélisation dans le but de clarifier les exigences, de supprimer les incohérences, et d'assurer la complétude et la non redondance. Les méthodes d'analyse sont entre autres la critique des connaissances [Watson 1997] et les techniques d'élicitation des exigences [De Antonellis & Vandoni 1993].

• La Spécification n'est autre que l'enregistrement et la documentation des exigences de sorte que celles-ci soient utilisables par les parties prenantes, et en particulier, par les développeurs qui doivent concevoir et construire le système. Elle consiste à établir la liste finale des exigences en les organisant suivant des catégories. Les exigences selon différentes perspectives doivent être intégrées dans le but d'avoir une vision commune du système. Un exemple d'approche pour la spécification est la fiche Volere [J. Robertson & S. Robertson 2007]. L'organisation des exigences peut être faite sur la base de méthodes orientées aspects [Rashid & Chitchyan 2003]. Des exemples d'intégration des exigences sont la gestion de l'intégration conjointe des exigences et l'intégration horizontale [Briggs & Grünbacher 2002].

• La Validation est la confirmation de la qualité des exigences et de leur conformité aux besoins et désirs des parties prenantes. Selon la norme EIA-632, la validation est focalisée sur la vérification de la version finale du document des exigences pour détecter les conflits, les omissions et les déviations par rapport aux normes [EIA 1999]. La validation cherche à certifier que les exigences satisfont les attentes des parties prenantes et à assurer qu'elles définissent les fonctionnalités attendues du système. En cas de conflits, une négociation est envisagée pour amener les gens à un accord. D'après l'EIA-632, un accord est un arrangement, non nécessairement contractuel, entre deux parties (un acquéreur et un fournisseur) qui définit les tâches à exécuter, les parties à délivrer, les critères d'acceptation à appliquer aux parties délivrées et d'autres exigences affectant le développement ou l'acquisition d'un produit. Quand il n'y a pas de conflits, les participants acceptent et valident tout simplement la spécification.

• La Gestion des exigences est exécutée tout au long du processus d'IE. Cette étape consiste à suivre l'évolution ou le changement des exigences, à faire la traçabilité et le contrôle des différentes versions de ces exigences [Wiegers 2006] durant tout leur cycle de vie de l'exigence, c'est-à-dire durant tout le processus d'IE [Fiksel & Dunkle 1991].

(27)

C

27 Figure I.6. Le processus d’IE- vue détaillée

Dans la section suivante, on s’intéresse à la phase d’élicitation des exigences.

7. L’élicitation des exigences

Comme décrit dans le paragraphe précédent, l’élicitation des exigences est la première phase du processus d’IE. Il peut donc être soutenu que l’élicitation des exigences est en fait la première phase du cycle de développement d’un système d’information, et par conséquent une condition préalable pour toutes les autres activités de développement. Actuellement, il y a très peu d'uniformité dans la recherche et la pratique d’IE concernant une définition standard pour l’élicitation des exigences. Hickey & Davis (2003c) définissent l’élicitation des exigences par “learning, uncovering, extracting, surfacing, and/or discovering needs of customers, users, and other potential stakeholders”. Une définition alternative proposée pour l’élicitation des exigences est “the process of identifying software or system requirements

5- Validation

Comportement

2- Modélisation

Entreprise Données Exigences non fonctionnelles ……...

3- Analyse

− analyse des modèles d’exigences − assurer la clarté et la non ambiguïté − assurer la cohérence

− assurer la non redondance − assurer la complétude 4- Spécification − organisation et catégorisation − intégration − documentation 6- Gestion − changement − traçabilité

− contrôle des versions