Vers une m´ethodologie pour l’Elicitation Collaborative des Exigences 

L’ingenierie des systemes concerne la recherche d’une solution satisfaisant au mieux aux innombrales attentes et contraintes. Ces contraintes ont besoin d’^etre formalisees et suivies en termes d’impacts tout au long de la de nition de la solution en prenant en compte les contraintes complementaires. Celles-ci resultent des choix techniques ou organisationnels suc-cessifs. En n, il faut se donner les moyens de veri er la conformite de la solution. Tout cela constitue le r^ole de l’Ingenierie des Exigences. Elle est donc la premiere etape fondamentale de n’importe quel projet de developpement de systeme.

Selon le GTIE (Groupe de Travail sur l’Ingenierie des Exigences) de l’AFIS (Association Francaise de l’Ingenierie des Exigences), l’Ingenierie des Exigences designe l’ensemble des activites destinees a decouvrir, analyser, valider et faire evoluer un ensemble d’exigences relatives a un systeme. Elle permet de montrer la satisfaction des besoins et des engagements durant tout le cycle de vie [dTIdE07].

Les elements de base de cette discipline sont les besoins et les exigences precedemment de nis dans la section 1.2.1. Les exigences representent la vision du systeme du point vue des concepteurs (point de vue technique) ; les besoins representent la vision du systeme uniquement d’un point de vue utilisateur. Une exigence est un besoin qui est techniquement satisfaisable ou dont la solution peut ^etre implementee. Les exigences formalisent l’expression des besoins et des engagements des parties prenantes comme le montre la gure I.2. Une exigence bien de nie permet d’assurer la reussite du projet de construction d’un systeme. Cependant, le passage des besoins aux exigences est une phase tres critique ce qui fait de l’IE un processus assez complexe a executer. En e et, l’IE s’occupe de la de nition des exigences depuis la phase d’emission des besoins et durant tout le cycle de vie du systeme.

Les exigences expriment des carateristiques du systeme que les utilisateurs doivent ap-precier. Par exemple, un besoin exprime que « la machine a cafe doit accepter au moins deux modes de paiement ». L’analyse des exigences obtenues conduit a distinguer les exigences de reference des exigences induites [Ess02]. Les premieres apparaissent a partir des besoins en termes techniques et prennent en compte l’expertise metier. Par exemple, « la machine a cafe doit ^etre equipee d’un lecteur de carte pour le paiement par carte bancaire ». Les secondes apparaissent a partir de l’analyse des exigences et incluent tous les details techniques que donnent les concepteurs pour repondre aux besoins exprimes a travers les exigences de ref – rence. Par exemple, en plus de l’exigence de reference, les concepteurs rajouteront un numero d’exigences, une justi cation, un niveau de priorite, une categorie, etc. Pour des exemples bien detailles, se referer au chapitre IV. Comme indique sur la gure I.2, l’ingenierie des exigences assure le processus de transfor-mation des besoins exprimes par les clients en exigences systemes qui seront techniquement exploitables. Cette transformation constitue une etape assez critique de l’ensemble du pro-cessus de l’ingenierie des exigences car la reussite d’un produit depend de la satisfaction de ses utilisateurs. Dans le domaine des systemes qui doivent s’integrer dans des environnements complexes, l’enjeu est d’abord de satisfaire tous les besoins et contraintes des parties inte-ressees de pres ou de loin par l’utilisation et l’exploitation du produit. Cette satisfaction des besoins vise a repondre aux attentes et contraintes des parties prenantes impliquees dans tout le cycle de vie du produit. Elle a egalement comme but de conferer au systeme une acceptabilit et de repondre aux attentes ou aux inquietudes de tous ceux qui sont ou seront concernes par ses impacts.

Les enjeux majeurs etant la satistaction du client ou de l’utilisateur et la reponse aux attentes et contraintes des parties prenantes, deux espaces respectivement appeles espace du probleme et espace de la solution sont de nis. L’utilisateur n’est concern que par la partie du processus de nie dans l’espace du probleme car son r^ole est central dans la de nition du probleme. Les autres parties prenantes interviennent egalement dans cette phase et pour-suivent le processus jusqu’a l’etape de la de nition de la solution. Ce dernier espace voit la naissance des exigences a partir des besoins clients ainsi que tout le processus de transfor-mation jusqu’a leur a nement en exigences techniques implementables. Ce travail est men par les concepteurs et experts metier qui ont les competences requises pour l’assurer.

Puisque l’IE couvre tout le cycle de vie d’un produit, elle s’applique non seulement dans le cadre de la de nition des fonctionnalites d’un nouveau systeme [KG04, KABC93], mais aussi aux cas d’evolution des systemes existants vers de nouveaux systemes. Par exemple, pour la resolution des questions d’interoperabilit des systemes, l’IE est egalement appliquee [GBB07, BP08]. Dans la problematique de la maintenance des systemes [SAS01, LSADG07], l’IE rev^et une grande importance, notamment pour accro^tre la abilite et la performance des systemes.

Il est un paradygme dans l’Ingenierie Systeme appel Processus-Methodes-Outils selon lequel toute demarche d’ingenierie doit commencer par la de nition de processus, suivie des methodes qui s’appuient sur ces processus et en n le developpement d’outils qui supportent ces methodes. L’Ingenierie des Exigences s’est developpee suivant cette demarche et les sec-tions suivantes en presentent les di erentes etapes.

Selon Nuseibeh et Easterbrook [NE00], un processus d’Ingenierie des Exigences inclut les phases d’elicitation, de Modelisation, d’Analyse, de Speci cation, de Validation et de Gestion comme le montre la gure I.4. D’autres auteurs proposent des decoupages di erents du processus d’IE comme Kotonya et Sommerville [KS98] qui ont mis en evidence toutes les phases precitees sauf celle de la modelisation. Ces di erences ne s’expliquent pas forcement par une omission de phases, mais peuvent ^etre considerees comme di erentes facons de voir le processus comme par exemple Kotonya et Sommerville qui incluent la modelisation dans la phase d’analyse. De ce fait, nous proposons les de nitions ci-apres provenant de l’une ou l’autre des deux visions sachant qu’au dela de ces di erences apparentes, elles partagent un fond commun.

L’Elicitation des exigences consiste en la collecte, la capture, la decouverte et le deve-loppement des exigences a partir d’une variet de sources y compris les parties prenantes humaines.

La Modelisation est une abstraction du probleme par des representations parfois gra-phiques. L’Analyse se focalise sur l’examen, la comprehension des exigences elicitees et leur veri-cation pour la qualite en termes d’exactitude, de completude, de clarte et de consistance.

La Speci cation 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 developpeurs qui doivent concevoir et construire le systeme.

La Validation est la con rmation de la qualite des exigences et de leur conformite aux besoins et desirs des parties prenantes. Quant a la gestion, elle est executee tout au long du processus d’ingenierie des exigences. Elle inclut les activites de contr^ole de l’evolution et de changement des exigences, de contr^ole de version, de tracabilite des exigences et les statuts des exigences.

Apres cette presentation du processus d’ingenierie des exigences et de ses di erentes etapes, nous abordons ici les methodes et techniques utilisees pour executer ces etapes.
Comme nous avons vu dans la section precedente, il existe di erentes methodes et tech-niques pour executer les etapes de l’Ingenierie des Exigences. Dans cette section, nous pre-sentons certaines d’entre elles et des outils qui les supportent.
Les methodes et les techniques pour l’ingenierie des exigences sont inspirees des sciences de la psychologie cognitive, l’anthropologie, la sociologie et la linguistique [NE00]. De facon generale, une methode est de nie comme « une facon de considerer quelque chose » et, une technique comme « une facon d’executer une actitivite avec habilete, ou les quali cations ne-cessaires pour la faire » [Cam08].
Pour les besoins de l’ingenierie des exigences, nous de nissons une methode comme une facon de considerer les processus d’ingenierie des exigences, et une technique comme une procedure ou une facon d’executer les processus de l’Ingenierie des Exigences. De ce fait, nous considerons que les methodes pour l’Ingenierie des Exigences utilisent les techniques pour l’Ingenierie des Exigences, et chaque technique est supportee par des outils.
Dans cette section, nous presentons d’abord les methodes a travers une categorisation, puis nous presentons les di erentes classes de techniques avec des exemples et nalement quelques outils. Methodes collaboratives
Il existe selon la litterature [Cou07] des methodes de Modelisation, de type Methodologique et des methodes Collaboratives pour l’Ingenierie des Exigences. Compte tenu du contexte de notre etude, nous choisissons de presenter ici seulement quelques methodes collaboratives.
Dans les methodes collaboratives, un groupe de participants travaille de maniere conjointe. La di erence entre les methodes collaboratives et les methodes de groupes est que les me-thodes collaboratives sont plus structurees et organisees avec des r^oles et des t^aches speci-ques. Cela presente l’avantage de faciliter le contr^ole et la gestion du processus. En voici quelques exemples:
Developpement Conjoint d’Application (JAD) [LC93] – est une methodologie de deve-loppement de systemes pour supporter la collaboration parmi les membres d’une equipe de projet dans le processus de developpement d’applications, specialement pour la de nition des exigences. JAD implique les utilisateurs naux dans un atelier structure et intensif avec le personnel des systemes d’information et un leader de session experiment . Les participants sont capables de faire ressortir des connaissances tacites. Le r^ole du leader est de de nir, avec les managers et les utilisateurs, la portee et les objectifs du projet et de determiner les participants d’un atelier JAD. Durant les sessions, le leader presente les informations et capture les exigences qu’un scribe documente sous une forme standardisee. En cas de con its entre les exigences, le leader doit jouer le r^ole de mediateur. Donc, les qualites du leader determinent grandement la reussite des sessions JAD. Deploiement de la Fonction Qualite (QFD) [Aka90] – qui est aussi appelee « Maison de la Qualite » est une approche visant a accro^tre la satisfaction des clients. Les besoins des clients (le quoi) sont collectes et transformes en speci cations techniques ou solutions (le comment) qui repondent aux besoins. Une matrice de correlation est creee pour montrer les relations entre les besoins et les vues techniques (quoi-comment) et aussi entre les solutions (comment1-comment2). Ces relations sont ponderees pour determiner si une solution satisfait ou pas un besoin. Les solutions non pertinentes, incoherentes et redondantes sont identi ees en vue de faciliter la prise de decision tout en considerant le co^ut du developpement [PK98]. Cette methode est vue comme la voix du client en entreprise parce qu’elle est centree sur la satisfaction de l’utilisateur.
Conception Centree sur l’Utilisateur (UCD) [Gul99] – est une approche qui vise a assurer l’unite entre le systeme technique et le systeme social en impliquant activement les utilisateurs comme une partie d’une equipe interdisciplinaire du projet. Les utilisateurs sont consultes, mais les decisions nales reviennent aux developpeurs. Participatory design [Com90] est un type d’approche UCD pour l’evaluation, la conception, et le developpement des systemes technologiques et organisationels qui met l’accent sur l’implication active des utilisateurs potentiels ou actuels du systeme dans les processus de conception et de prise de decision. Cette approche est basee sur l’idee selon laquelle, l’implication des utilisateurs dans le processus de conception contribue a rendre le systeme plus adapte aux besoins et aux procedures de travail des utilisateurs. Un avantage majeur de l’approche est qu’elle aide les participants, et specialement les utilisateurs, a prendre part personnellement au projet. Ils sont susceptibles de travailler pour la reussite du projet [MS00].
WinWin [GB01] – cette methode est axee sur la negociation des exigences en groupe. Elle a et introduite par Barry boehm [BBHL94]. Il y a quatre concepts essentiels dans cette approche :
{ les win-conditions qui representent les objectifs des parties prenantes, { les problemes qui sont les con its entre les parties prenantes,
{ les options qui sont des alternatives pour resoudre les problemes,
{ et les accords qui capturent les engagements partages des parties prenantes par rapport aux win-conditions ou les options adoptees.
WinWin utilise ces concepts pour engager les gens dans un processus de prise de decision a partir d’une situation con ictuelle vers une situation de consensus.
Techniques
On trouve dans la litterature, quatre classes de techniques d’Ingenierie des Exigences [NE00] : les techniques traditionelles, les techniques cognitives, les techniques contextuelles et les tech-niques de groupe. Tout comme pour les methodes, nous decrirons quelques techniques de groupe et citerons quelques exemples des autres categories de techniques.
Techniques Traditionnelles : ce sont des techniques utilisees depuis fort longtemps en genie logiciel pour deternimer les besoins et les souhaits des utilisateurs. Elles ont vu le jour bien avant que l’Ingenierie des exigences ne soit une discicipline a part entiere de l’Ingenierie Systeme [NE00, Cou07]. Parmi ces techniques, nous avons l’Interview [LG96], l’introspection [GL93] et l’Analyse des t^aches [TFS07].
Techniques de la Psychologie cognitive : la psychologie cognitive est l’examen de la facon dont les gens comprennent, diagnostiquent et resolvent les problemes qui les concernent eux-m^emes avec des processus mentaux qui interviennent entre le stimilus et la reponse [Nei67]. Les techniques pour l’Ingenierie des Exigences basees sur la psychologie cognitive ont ete, a l’origine, developpees pour l’acquisition de la connaissance [NE00]. Certaines d’entre elles sont l’analyse des protocoles [vML99] et le Tri de carte [SP05].
Techniques Contextuelles : elles sont vues par Nuseibeh et Easterbrook [NE00] comme alternatives aux techniques tarditionnelles et aux techniques basees sur la psychologie cogni-tive. Comme leur nom l’indique, elles mettent un accent particulier sur le contexte et l’envi-ronnement dans lesquels le systeme vise sera utilise, c’est-a-dire, l’environnement du monde reel. Parmi ces techniques gurent l’Ethnographie [RLD02], les Cas d’utilisation [KG04] et le Prototypage [LS92]. Techniques de groupe : ces techniques cherchent a favoriser l’accord des parties pre-nantes tout en favorisant la dynamique de groupe [NE00]. Elles engagent au moins quatre participants :
{ Equipes expertes [Kru94] – Cette technique amene les membres du groupe a discuter ensemble de certains sujets interessants ou a se centrer sur des problemes particuliers. Dans le developpement de logiciels, les « equipes expertes » ont souvent recours aux ma-teriels tels que les questionnaires, les prototypes etc, pour provoquer et encourager le dialogue dans le groupe. Ces « equipes expertes » ont l’avantage de suivre les inter-actions naturelles entre les gens plus que les techniques traditionnelles parce que le facilitateur prend un r^ole passif durant la session, et egalement parce que la structure requise est exible. Cependant, les groupes ne sont pas habituellement des communau-tes naturelles, mais un collectif ad-hoc constitue pour une occasion speci que. Bien que relativement pratique et economique a mettre en uvre, cette technique n’est pas tres appropriee pour trouver les solutions aux problemes complexes [Cou07].
{ Brainstorming – le Brainstorming est une technique pour la generation d’idees en groupe qui a et proposee par Osborn [Osb48]. Osborn a remarqu que la generation d’idees pouvait ^etre amelioree si les gens suivaient un protocole a quatre regles [Bri06] : { « ne pas critiquer les idees des autres »,
{ « ^etre ouvert aux idees absurdes et inutiles »,
{ « generer beaucoup d’idees autant que faire se peut », { « b^atir sur et etendre les idees des autres ».
Ce processus implique plusieurs participants de diverses origines et ayant di erentes perspectives. Dans la premiere etape, un grand nombre d’idees sont produites, puis on passe a une etape de consolidation durant laquelle le nombre d’idees decro^t. Un des grands avantages de cette technique est qu’elle permet la re exion et l’expression libre qui favorisent l’emergence d’idees nouvelles, creatives et innovatrices.
{ Construction d’une histoire collective [AG06] – Il s’agit d’une activite collective de construction d’une histoire a laquelle participent plusieurs personnes qui contribuent, avec leurs souvenirs et interpretations, aux experiences vecues. Un contexte partage d’une t^ache executee par un groupe peut ^etre « elicite » et represent a travers cette technique car elle aide a identi er, representer et rendre explicite les elements contex-tuels lies aux evenements de la t^ache decrite dans l’histoire, et cela, dans le but d’etablir les bonnes relations entre les elements [SB05]. Pendant que les membres d’une equipe contribuent a creer une histoire concernant un travail ou une situation experimentee par eux, ils peuvent progressivement en rajouter, poser des questions, faire des corrections et des commentaires et aussi faire des objections. Une phase de negociation peut ^etre envisagee, si cela est necessaire, pour faire des contre-propositions, les accepter ou les rejeter.
{ Conception collaborative [AEF+00] – Elle est une approche pour la conception avec des acteurs multiples. Cette conception est faite a travers l’interaction, la cooperation, la communication, l’harmonisation et la negociation entre di erents acteurs [JCLW08]. Dans le processus de la conception collaborative, plusieurs concepteurs completent l’ob-jet a concevoir (artefact). Il s’agit d’une conception dite « en m^eme temps » ou « en pa-ralelle ». Une conception complete d’un artefact inclut la capture des exigences pour cet artefact basees sur des retours des participants, la speci cation de l’artefact lui-m^eme, le processus de creation de l’artefact et ainsi de suite a travers tout son cycle de vie [KSFBY03].
La plupart des approches citees ci-dessus ne sont pas exclusivement dediees a l’Elicitation des Exigences. Par contre, elles sont ou peuvent ^etre utilisees pour les besoins d’Elicitation des Exigences. En outre, chacune d’elles a ses points forts et ses points faibles [GL93], si bien qu’un debat sur la suprematie de l’une par rapport a l’autre de maniere generale ne serait que speculation. En revanche, une telle discussion aurait un sens dans un contexte speci que, car certaines approches peuvent s’averer mieux adaptees que d’autres selon les situations.
Chacune des techniques et methodes precedemment citees peut ^etre supportee par un outil. En e et, selon Nuseibeh et Easterbrook, l’utilisation d’un outil automatise est essentiel pour une execution e cace des activites du processus d’Elicitation des Exigences [NE00]. Ainsi, nous presentons dans la section suivante, quelques outils pour l’elicitation.

La plupart des outils existants pour l’Elicitation des Exigences sont des outils pour les phases de modelisation et de gestion. Selon Coulin, cela peut s’expliquer par le fait que la modelisation et la gestion sont souvent la cible de developpement d’outils alors que les autres phases telles que l’elicitation sont considerees comme des activites plus sociales [Cou07]. Ce-pendant, les outils jouent un r^ole important dans chaque phase y compris les moins techniques car, les outils sont essentiels pour l’e cacit du processus [NE00].
Les outils existants sont regroupes en categories selon des similitudes en termes d’usages. Il n’existe pas de classi cation communement adoptee comme dans le cas des techniques pre-cedemment vues [Cou07]. Nous nous focaliserons davantage sur des outils qui permettent la collaboration tout en donnant quelques exemples sur d’autres types.
Outils de collaboration – Ils supportent des t^aches de groupe et specialement la phase d’Elicitation des Exigences. Ils sont souvent une collection de supports basiques tels que les outils de messagerie instantanee et les outils de vote [BGB01]. Ils peuvent aussi inclure la vi-deo conference, tout un environnement virtuel specialement concu pour les projets de groupe. Les outils de collaboration visent a promovoir une comprehension partagee de leurs utilisa-teurs et la resolution conjointe des problemes. Des exemples sont CRETA (Collaborative Requirements Engineering Support Tool) [TdAFdM02] et WikiWinWin [YWK+08] qui est un outil pour le modele de negociation des exigences pr^one par l’approche WinWin [BBHL94]. WikiWinWin est base sur le principe de contribution collective des idees appel le wiki. Nous avons egalement les GSS (Group Support Systems) dont GroupSystems est un leader dans la construction de tels systemes [Gro08]. Les GSS sont en general des applications Web suppor-tant les principales activites collaboratives et qui sont souvent utilises pour l’Elicitation des Exigences. Ils permettent aux utilisateurs d’enregistrer des rendez-vous, de faire des echanges « d’Emails », d’inclure d’autres dispositifs tels que l’agenda, les supports de messagerie instan-tanee et de vote. Ils permettent aussi le chargement et la recherche de document et de faire egalement des questionnaires. Les GSS sont basees sur quelques patrons de collaboration comme « generer », « reduire », « organiser » et « le consensus » [BdVJ03] que nous presenterons en detail dans le chapitre suivant. Des etudes ont revel que l’utilisation des solutions telles que celles proposees par GroupSystems est tres utile pour l’e cacit du processus et permet m^eme de reduire le temps de travail a 50% et faire un gain sur le temps du projet entre 70% a 90% [FSHD07, DHNV90].
Nous avons realis deux cas d’etudes avec l’outil ThinkTank de GroupSystems que nous presentons en detail dans la section 5.5 a la page 115.
D’autres types d’outils sont des outils de modeles ou templates qui sont essentielle-ment centres sur la modelisation des exigences dans une perspective de documentation. Par exemple, la che Volere [RR07] pour la speci cation et ScenarioPlus pour les cas d’utilisa-tion [Ale97]. Il y a aussi les outils de gestion des exigences qui sont, comme leur nom l’indique, principalement utilises pour identi er, organiser et enregistrer les exigences selon un format speci que et de maniere hierarchique et aussi assurer la tracabilite et le contr^ole de versions. On peut citer les outils AnalystPro [IBM08] et Truereq [Tru08]. Il y a egalement des outils pour les etudes comme QuestionPro [Que08]. Il existe bien d’autres outils encore, mais nous nous limiterons a ceux deja cites.