De La Modélisation Conceptuelle À L'ingénierie Des Exigences [PDF]

Zitiervorschau

Réf. : H3250 V2

Date de publication : 10 février 2011

De la modélisation conceptuelle à l'ingénierie des exigences Cet article est issu de : Technologies de l'information | Technologies logicielles Architectures des systèmes par Colette ROLLAND

Pour toute question : Service Relation clientèle Techniques de l’Ingénieur Immeuble Pleyad 1 39, boulevard Ornano 93288 Saint-Denis Cedex

Document téléchargé le : 06/11/2019 Pour le compte : 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Par mail : [email protected] Par téléphone : 00 33 (0)1 53 35 20 20

© Techniques de l'Ingénieur | tous droits réservés

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

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

Colette ROLLAND

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Université Paris 1 Panthéon Sorbonne, Centre de recherche en informatique

tiwekacontentpdf_h3250 v2

1.

Position de l’ingénierie des exigences ...............................................

2.

De la modlisation conceptuelle à l’ingénierie des exigences......

—

3.

Exigences et documentation.................................................................

—

6

4.

Approche d’élucidation des exigences dirigée par les buts ........

—

10

5.

Cas des réservations de chambres d’hôtels .....................................

—

14

6.

Conclusion..................................................................................................

—

18

Pour en savoir plus ...........................................................................................

H 3 250 - 2 2

Doc. H 3 250

’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.

L

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

H 3 250 – 1

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES _______________________________________________________________________

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

1. Position de l’ingénierie des exigences

tiwekacontentpdf_h3250 v2

Les approches traditionnelles d’ingénierie des Systèmes d’Information (SI) se fondent sur l’hypothèse qu’un SI représente une partie du monde et de ce fait, se focalisent sur la modélisation de l’information représentative de « l’Univers du Discours » que le système doit rendre accessible. Cela est réalisé par la modélisation conceptuelle qui consiste à abstraire la spécification conceptuelle du SI, le schéma conceptuel [16] de l’analyse des faits et événements pertinents de la réalité observée et pour lesquels la communauté des utilisateurs du SI a besoin d’être informée. Cette spécification se concentre sur « ce que doit faire » le SI, c’est-à-dire sur sa fonctionnalité. Elle sert de prescription pour le développement du système. La modélisation conceptuelle a permis de comprendre la sémantique de l’information, son sens par relation avec les faits observables de l’univers du discours, ce qui est important. Les recherches et pratiques associées à la modélisation conceptuelle ont aussi permis le développement de nombreux modèles conceptuels assurant la représentation de différents aspects pertinents de la réalité ; ces modèles ont été en quelque sorte, synthétisés dans les notations d’UML. Mais en revanche, l’expérience montre que la modélisation conceptuelle ne garantit pas que le système finalement délivré répond aux attentes de la communauté de son usage. En fait, un nombre important d’études sur le terrain [Standish95, ESI96, Meta03] montrent que les échecs de la mise en œuvre et de l’utilisation des systèmes d’information sont majoritairement imputables à une mauvaise compréhension des besoins auxquels ces systèmes tentent de répondre. Par ailleurs, il a été prouvé que les efforts requis pour corriger les erreurs d’un document d’exigences mal et/ou incomplètement formulé sont très importants [29]. Afin de corriger cette situation, il est nécessaire de définir des méthodes, des techniques et des outils pour élucider, spécifier, valider et négocier les exigences imposées aux SI par les besoins de ses usagers, de manière systématique. La communauté de l’Ingénierie des Exigences (IE) s’est développée pour répondre à ce challenge. Nota : exigence et besoin sont les deux faces de la même pièce : le besoin vient des parties prenantes du projet SI ; les exigences sont les contraintes imposées au système pour garantir la satisfaction du besoin.

La position centrale de l’IE est que tout SI a un propos que le contexte organisationnel lui assigne. Comprendre ce propos est une condition nécessaire pour développer un système d’information objectivé, en phase avec les attentes et besoins de la communauté de ses usagers. Cette observation suggère qu’il faille aller au-delà de la modélisation conceptuelle et étendre la modélisation du « qu’est-ce que le système doit faire » à « pourquoi le système doit-il le faire ». La question du « pourquoi » trouve sa réponse dans l’étude des objectifs et buts de l’organisation et de leur impact sur les exigences du SI. Elle est au cœur de l’ingénierie des exigences et centrale dans cet article. Cette attitude devrait permettre dans le futur, de développer des systèmes plus adaptés à leur usage et a déjà prouvé qu’elle permettait de le faire. L’article part des acquis de la modélisation conceptuelle et argumente en faveur de son extension par la modélisation du contexte intentionnel du SI à développer (parfois qualifié de système To-Be) au moyen de modèles de buts. Il présente le concept de but, montre comment on peut élaborer un modèle de buts et comment conduire des raisonnements permettant d’aboutir à la conceptualisation de SI objectivés, c’est-à-dire répondant au propos que l’organisation leur assigne. Le développement des idées s’appuie sur un exemple de réservations de chambres d’hôtels. Plus précisément, l’article est structuré comme suit. Le paragraphe 2 justifie l’extension de la modélisation conceptuelle, introduit l’ingénierie des exigences et fait un bref état de l’art du

H 3 250 – 2

domaine de l’IE. La notion d’exigence comme nouvelle forme d’expression du contenu du traditionnel cahier des charges est introduite et développée en paragraphe 3. Le paragraphe 4 présente les clés des approches d’IE dirigées par les buts et les illustre par des exemples variés. Le cas des réservations de chambres d’hôtels est traité en paragraphe 5. Le paragraphe 6 conclut l’article par un résumé des notions et démarches qui y ont été développées.

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.

UNIVERS DU DISCOURS

Acquisition et abstraction

Validation SCHÉMA CONCEPTUEL

INGÉNIERIE DES BESOINS

Conception Correction

SCHÉMA INTERNE

INGÉNIERIE DU SYSTEME Figure 1 – Organisation du cycle de développement d’un SI

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

_______________________________________________________________________ DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES

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é. Le modèle E/R propose par exemple, les trois concepts d’entité type, de relation type et d’attribut comme étant nécessaires et suffisants pour représenter toute partie du réel par une structure de données. Durant ces 25 dernières années, de très nombreux modèles conceptuels ont vu le jour, chacun cherchant à proposer un jeu de concepts qui permette une représentation plus fidèle de la réalité que ses prédécesseurs. On peut schématiquement retenir trois classes de modèles [60] :

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

• les modèles centrés sur la représentation des structures d’entités de la réalité ou modèles de données. Les modèles E/R et relationnel en sont des exemples ;

tiwekacontentpdf_h3250 v2

• les modèles fonctionnels poussant à « voir » la réalité comme un processus de transformation de l’information. Les modèles dits d’analyse structurée en sont des exemples ; • les modèles de comportement mettent le concept d’événement au centre de la modélisation et poussent à une vision dynamique, en mouvement de la réalité. Les modèles Remora et les graphes de Harel en sont des exemples. On peut voir l’ensemble des notations proposées par le standard UML comme étant le résultat d’un effort de synthèse et d’unification des multiples modèles qui ont vu le jour au cours des deux décennies passées. La question posée dans cet article est de savoir si ce sont finalement ceux dont on a besoin ou si ceux dont on a le plus besoin sont absents du standard. Dans l’ingénierie traditionnelle et les méthodes d’analyse comme MERISE, c’est au cours de l’étape de conceptualisation que le cahier des charges est pris en compte pour configurer la solution conceptuelle matérialisée dans le schéma conceptuel. Il est à noter que l’objectif est de décrire ce que le système doit faire, c’est-à-dire ses fonctionnalités. Comme le montre la figure 1 l’ingénierie du besoin fondée sur la modélisation conceptuelle est centrée sur la question du « quoi » à laquelle on répond par le cycle . La tâche d’acquisition de connaissance de domaine et des besoins s’appuie sur un cahier des charges et des interviews. Elle permet d’abstraire 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 besoins par des techniques telles que le maquettage et le prototypage.

2.2 Limites de la modélisation conceptuelle Le centrage sans doute trop exclusif de la modélisation conceptuelle sur le « quoi » inhibe les vraies questions du « pourquoi » et aboutit à des choix fonctionnels d’un système qui se révèle à l’usage, inadapté aux réelles attentes de ses usagers. Le schéma conceptuel est l’expression d’une solution fonctionnelle et non celles des exigences à l’égard du système. Il est l’énoncé d’une solution alors que le problème n’a pas été formulé correctement. L’absence d’une expression des exigences en tant que telle, rend difficile leur validation par les différentes et nombreuses parties prenantes concernées. En outre, la pratique du cycle précédent repose sur des hypothèses (le plus souvent implicites) qui ne semblent plus du tout valides aujourd’hui. Les fonctionnalités d’un système sont stables, elles n’évoluent que peu dans 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 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 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 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 [24]. On sait même que les besoins évoluent au cours du projet [12] [39]. Il devient nécessaire de propager les changements sur les exigences. On verra que cela peut être réalisé en établissant un lien conceptuel entre les buts et objectifs de l’organisation (réponse au « pourquoi »), les besoins qui en résultent et les spécifications fonctionnelles du système qui les supportent (réponse au « quoi »). On sait que le rôle central de l’analyste système a été reconsidéré et que la maîtrise d’ouvrage vient contrebalancer le rôle de la maîtrise d’œuvre. En fait, il est clair aujourd’hui que l’ingénierie des exigences requiert la participation d’un grand nombre d’acteurs de l’organisation, chacun apportant sa vision sur ce que le système devrait faire [22]. On distingue par exemple, les utilisateurs finaux du système – ceux qui utiliseront le système 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), les parties prenantes en français. Enfin, la validation des exigences sur la base du schéma conceptuel n’est pas satisfaisante. L’expérience l’a montré. On peut accepter l’idée que cette validation soit bien plus efficiente si elle est basée sur l’expression d’exigences formulées en langue naturelle et non sur la spécification abstraite et difficile à comprendre des spécifications fonctionnelles du système qui en résultent. Cela justifie l’introduction d’un document des exigences dans lequel celles-ci peuvent être spécifiées, discutées, négociées et validées. Toutes ces observations et remarques militent pour une révision de la pratique de l’ingénierie des exigences comme partie de la modélisation conceptuelle ; en fait elles suggèrent d’une part, l’introduction d’un document des exigences et d’autre part, la révision de la manière de conduire l’ingénierie des exigences et la production du document des exigences qui en résulte.

2.3 Chiffres motivant le changement d’attitude L’impact critique de l’analyse des exigences sur la qualité du logiciel a été reconnu de longue date et à maintes reprises. Dans l’une des premières études empiriques sur le sujet, Bell et Thayer relevaient que des exigences inadéquates, incomplètes, inconsistantes ou ambiguës étaient monnaie courante dans les projets analysés, et cause majeure de la piètre qualité des logiciels développés. Ils concluaient que « les exigences n’apparaissent pas de manière naturelle et spontanée ; elles doivent au contraire être découvertes, élaborées avec soin, et constamment revues » [5]. Dans son article célèbre sur la nature et les accidents du génie logiciel, Fred Brooks affirme, sur base de sa longue expérience de développement de logiciels complexes, que « la tâche la plus difficile, dans la construction d’un système logiciel, consiste à décider

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

H 3 250 – 3

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES _______________________________________________________________________

ce qu’il faut exactement construire, par élucidation et affinement itératifs d’exigences » [9]. Dans son étude des erreurs du programme Voyager et Galileo de la NASA, Lutz [40] rapporte que la principale cause vient des erreurs d’expression de besoins fonctionnels et d’interface.

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Des enquêtes plus récentes en Europe et aux États-Unis ont confirmé le problème à une plus grande échelle. Une enquête menée auprès de 800 projets conduits dans 350 compagnies américaines par le Standish Group [63] 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. La mauvaise qualité des documents de besoins constitue 47 % des causes d’échecs citées. Comme l’indique la figure 2, ce pourcentage est distribué de la façon suivante :

tiwekacontentpdf_h3250 v2

– 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 %). 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 des besoins : « La plupart des efforts de maintenance consistent à fournir des fonctionnalités nécessaires mais manquantes » [41]. En Europe, une enquête de grande envergure auprès de 3 800 organisations dans 17 pays différents [20] a conclu dans le même sens : les principaux problèmes sont liés à la spécification des exigences (> 50 % des réponses).

60 %

50 % 5% 40 % 6% 30 %

11 % 53 %

20 %

Le rapport du Standish Group est régulièrement actualisé et les résultats de 2010 montrent une amélioration sensible des cas de succès. Cependant, les causes d’échec restent liées dans les mêmes proportions que précédemment au manque de qualité du document d’exigences ; le rapport récent du groupe Meta [42] montre que 60 % des cas d’échecs sont imputables, soit au manque de qualité du document d’exigences, soit à l’inaptitude des processus d’ingénierie à prendre en compte leur évolution. Améliorer la qualité du document des exigences et la pratique de l’ingénierie des exigences sont donc des objectifs primordiaux. Ces objectifs ne sont pas faciles à 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’ingénierie des exigences 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.

2.4 Paradigme sous-jacent à l’IE La position adoptée par l’ingénierie des exigences est qu’il faut non seulement comprendre ce que le système doit faire (le « quoi ») mais aussi pourquoi il doit le faire (« pourquoi »). L’ingénierie des exigences va donc au-delà de la modélisation conceptuelle centrée sur le « quoi » pour mettre l’accent sur le « pourquoi ». La plus ancienne définition de l’IE contient déjà cette position. Dans leur article prémonitoire, Ross et Schoman écrivent : « Requirements definition is a careful assessment of the needs that a system is to fulfil. It must say why a system is needed, based on current and foreseen conditions, which may be internal operations or external forces. It must say what system features will serve and satisfy this context. And it must say how the system is to be constructed » [61]. L’ingénierie des exigences é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 le système d’information de l’organisation. En d’autres termes, l’IE par du principe qu’un système d’information a un propos au sein de l’organisation et que celui-ci est déterminant des exigences imposées à son développement. L’IE vise à aider à la fois à la conceptualisation du système et du propos qui lui est associé. Ce paradigme sous-jacent à l’IE a deux implications : • la découverte et la validation des exigences d’un système sont conduites au regard de son propos ;

12 %

• seuls les systèmes ayant un propos clairement identifié sont conceptualisés.

10 % 13 %

Causes d'échecs liés aux besoins autres cause d' échecs

objectifs peu clairs

besoins mal exprimés

besoins qui manquent de réalisme

manque de participation des utilisateurs

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

Figure 2 – Distribution des causes d’échecs selon l’étude du Standish Group

H 3 250 – 4

La figure 3 inspirée d’Axel van Lamsweerde [33] schématise le processus d’ingénierie des exigences centrée sur les questions « pourquoi » et « quoi », ainsi que la mise en correspondance des réponses inhérentes à l’une et à l’autre. Comme le montre la figure 3, l’ingénierie des exigences se focalise sur les early requirements, au moment où les problèmes (les besoins des parties prenantes) sont identifiés et des solutions alternatives sont explorées et évaluées. Le processus débute par l’identification des buts des parties prenantes tels que « Répondre à chaque demande de livre », ou « Planifier une réunion » et affine ces buts de manière itérative jusqu’à ce qu’ils se réduisent à des collections alternatives d’exigences (late requirements ) chacune d’elles permettant d’atteindre les buts initiaux. Les buts initiaux ne sont pas nécessairement connus et explicités. Ils peuvent être contradictoires.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

_______________________________________________________________________ DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES

des évolutions anticipables (adaptations ou extensions). Chacun de ces systèmes est composite, puisqu’il comprend des structures organisationnelles (avec leurs objectifs stratégiques, réglementations, politiques de gestion, procédures opérationnelles, etc.), des appareillages techniques (avec leurs lois et modes de fonctionnement), des logiciels de contrôle ou de gestion préexistants (avec leur documentation), etc.

Mission, Objectifs, Buts

POURQUOI ?

Le processus d'ingénierie est participatif et de nature décisionnelle Operationalisation des buts (stratégiques, tactiques, opérationnels)

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

QUOI ?

tiwekacontentpdf_h3250 v2

Spécification d'exigences

■ Le spectre d’investigation est large puisqu’il s’étend du domaine social des organisations à celui des lois de la physique et 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 futur, cible de l’ingénierie des exigences, comprend aussi bien le logiciel à développer que les composantes organisationnelles ou techniques affectées par ce logiciel, que nous appellerons environnement. Celui-ci est complexe car il est constitué d’êtres humains, de machines et/ou de logiciels. C’est en définitive le couple logiciel-environnement qui doit assurer la réalisation des buts identifiés. Le système doit être considéré selon de multiples points de vue : socio-économiques, physiques, opérationnels, évolutifs, etc.

■ L’espace d’investigation peut être structuré selon les deux dimensions introduites précédemment [36] [61] [65] :

Figure 3 – Paradigme sous-jacent à l’IE

On peut intuitivement comprendre la dépendance entre but organisationnel et exigence imposée au système. Par exemple, dans le cas des réservations de chambres d’hôtels traité au paragraphe 5, la pratique de la modélisation conceptuelle conduira l’ingénieur d’application à représenter les chambres des hôtels (il en est ainsi dans l’Univers du Discours) et donc à stocker et maintenir à jour les données correspondantes dans la base de données du SI (ce qui est coûteux). En revanche, s’il s’avère que l’objectif du pool d’hôteliers est d’offrir un service standard au moindre coût, cette représentation devient inutile et la connaissance des disponibilités en nombre de chambres par hôtel, éventuellement par catégorie, peut suffire. Au contraire, si l’objectif poursuivi est celui d’une fidélisation de la clientèle, non seulement la connaissance des chambres est indispensable à la personnalisation du service (composante de la fidélisation) mais la mise en place d’un système de récompense des clients fidèles l’est aussi. Dans les deux cas, on peut comprendre que le même cahier des charges initial aboutisse à des exigences différentes et des fonctionnalités très différentes aussi. Se centrer sur le « pourquoi » doit permettre de découvrir des exigences alignées à la stratégie et au métier 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, la position prise par l’IE est qu’il faut se donner les moyens de comprendre à quoi le système va servir dans son contexte organisationnel. C’est la position que nous développons dans cet article et qui n’est cependant pas encore la pratique courante. Deux points en résumé. Pour limiter les échecs des approches traditionnelles d’ingénierie, l’IE adopte la double position suivante : – un centrage sur le POURQUOI afin d’en dériver un QUOI motivé ; – une spécification du QUOI en termes d’exigences que le système doit satisfaire et non de spécification des fonctionnalités du système.

2.5 Processus d’ingénierie des exigences Le processus d’IE est complexe, ce qui explique qu’il soit encore mal maîtrisé :

■ Le champ couvert par l’ingénierie des exigences est large, puisqu’il s’adresse à deux systèmes : le système tel qu’il est (ou système existant, As-Is) et le système tel que l’on voudrait qu’il soit (ou système futur, To-Be). Derrière ce dernier peuvent même se profiler d’autres systèmes, correspondant à des variantes ou

• la dimension du POURQUOI : les objectifs du futur système doivent être identifiés et précisés, eu égard aux limitations et défauts du système existant et aux opportunités à exploiter dans le système futur ; • la dimension du QUOI : les exigences sur les fonctionnalités et les qualités du système futur doivent être identifiées et précisées de manière à assurer ces objectifs. On notera également que l’espace d’investigation comprend de multiples options alternatives : alternatives de réalisation d’un objectif par différents sous-objectifs, alternatives de réalisation d’un sous-objectif par différents jeux de fonctionnalités et alternatives d’affectation de responsabilités à différentes composantes du système futur.

■ Il y a d’autres aspects à prendre en compte en plus des aspects fonctionnels du système qui viennent en premier lieu à l’esprit : les aspects liés à 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 nombreuses parties prenantes comme nous l’avons déjà mentionné. Chacune a son champ de compétence et de connaissance, sa propre culture, ses propres points de vue et intérêts. Citons, les ingénieurs des besoins, les clients, les experts du domaine, les utilisateurs, les commanditaires, les ingénieurs de maintenance et les ingénieurs d’application. Ces différentes parties prenantes peuvent avoir des points de vue divergents, voire conflictuels.

■ Les spécifications des besoins 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 produit final. Ce sont par exemple, les incomplétudes et incohérences, ambiguïtés, inadaptations aux besoins 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 : ce sont par exemple, les sur-spécifications, les bruits, les références en arrière ou des besoins irréalistes.

■ Le processus couvre de multiples activités qui sont inter-reliées. La figure 4 en propose quatre : – l’extraction ou découverte des exigences ; – la spécification des exigences dans une forme précise et non ambiguë ; – la validation des exigences ; – la négociation conduisant au choix des exigences qui seront implémentées.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

H 3 250 – 5

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES _______________________________________________________________________

Propositions alternatives In de gén s b ieu es r oin s

t ien

Analyse du domaine et élucidation

ilis Ut

Extraction

Validation et vérification

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Figure 5 – Cycle de vie des exigences m Exp ar er ke t tin g

r eu ni ie ls gé ic In log s de

tiwekacontentpdf_h3250 v2

ini

str

ate

ur

meur

Program

Figure 4 – Activités de l’IE

L’extraction ou élucidation des exigences est l’activité clé de l’IE. Elle consiste à analyser les problèmes et opportunités posés par le système As-Is, à découvrir les buts d’amélioration à réaliser par le système To-Be, à prendre en compte les buts de changement imposés par la vision du futur et à procéder à leur opérationnalisation, en considérant les alternatives de réalisation, pour en déduire les exigences correspondantes à satisfaire par le SI. Le processus d’élucidation est un processus de découverte des exigences : les exigences ne sont pas données a priori mais bien découvertes par exploration des différentes manières d’atteindre les buts identifiés pour le système To-Be. Les acteurs impliqués dans le processus d’élucidation sont les parties prenantes du projet SI, tous ceux pour qui le SI est un enjeu. Ils comprennent généralement les responsables des structures de décision, les experts du domaine, des personnes affectées par les problèmes identifiés, les utilisateurs finaux du futur système, etc. La négociation est l’autre activité spécifique de l’IE. Elle permet l’évaluation des différentes alternatives identifiées au cours de l’activité d’élucidation, eu égard aux objectifs de qualité reconnus et aux risques potentiels que chaque alternative comporte, et à retenir une « meilleure alternative » sur la base de cette comparaison par négociation entre les différentes parties concernées, en y résolvant les conflits inhérents à la présence de points de vue multiples. En outre, il arrive fréquemment que les exigences élucidées doivent être classées par niveaux de priorité : l’intégration des demandes des différents intervenants peut dépasser l’enveloppe budgétaire et les délais fixés ; un développement incrémental du nouveau système est plus facilement planifiable sur base de ces priorités, ou re-planifiable en cas de circonstances nouvelles (retards, budgets ou délais réduits, etc.) ; enfin, certains conflits peuvent être résolus en favorisant les exigences plus prioritaires. La documentation consiste à structurer et à spécifier les exigences de manière précise, et à consigner le résultat dans un rapport compréhensible par l’ensemble des acteurs impliqués dans le processus d’IE. Ce rapport est le produit principal de l’IE. Il comporte aussi la description des différents éléments qui ont permis d’aboutir au résultat et sert de trace du processus d’IE. Notons qu’il existe sur le marché des outils de documentation des exigences incluant leur traçabilité. Citons DOORS, RTM et RequisitPro. On peut aussi faire appel à des outils de gestion de configuration pour le contrôle des différentes versions du document. La vérification/validation consiste à analyser soigneusement les spécifications obtenues, en les validant auprès des acteurs

H 3 250 – 6

Spécification et documentation

Exigences documentées

Négociation

Ad m

Exigences approuvées

consolidées

Chef du projet Spécification et documentation

Évaluation et négociation

Début

Exigences

ur

Validation et vérification

ate

Sp é sy cialis stè me te

Cl

concernés, dans le but de déceler des inadéquations par rapport aux besoins réels, et en les vérifiant les unes par rapport aux autres, afin de déceler des inconsistances et incomplétudes avant transmission aux développeurs du logiciel. Les erreurs décelées sont alors corrigées. Parmi les produits de cette étape figurent une version corrigée des spécifications produites par l’activité précédente, un ensemble de jeux de test d’acceptation produits à partir des spécifications d’exigences, une éventuelle maquette utilisée pour la validation, un contrat liant client et développeur, un éventuel appel aux soumissions (pour les développements sous-contractés), etc. Les différentes activités ci-dessus ne s’enchaînent pas de manière strictement séquentielle ; elles sont entrelacées, parfois se chevauchent, et les retours arrière sont fréquents. Ces activités sont cependant reliées par des liens de dépendance : les produits en amont, ne fût-ce que partiels, sont nécessaires aux activités en aval. Vu dans sa globalité, le processus d’ingénierie des exigences consiste en une itération sur des incréments successifs, selon un modèle en spirale [7] [32], schématisé à la figure 5. Chaque nouvelle itération est provoquée par la nécessité de compléter le document des exigences, de corriger des exigences inadéquates ou incohérentes, ou de revoir, adapter ou étendre le document suite à des besoins ayant évolué ou devant être particularisés à des contextes spécifiques d’utilisation. Notons qu’au-delà de la phase initiale d’ingénierie des exigences, des itérations peuvent se poursuivre durant toute la durée de vie du projet, notamment, en phase de conception architecturale. Ce modèle en spirale est très général, et doit être instancié aux spécificités de l’organisation « cliente ». Nous nous concentrons dans la suite sur l’activité de découverte des exigences par une approche dirigée par les buts. Nous développons dans le paragraphe suivant, la notion d’exigence et la documentation des exigences. Le paragraphe 4 présente le concept de but, la modélisation des buts et le processus de dérivation des exigences à partir d’un modèle de buts.

3. Exigences et documentation 3.1 Qu’est-ce qu’une exigence ? 3.1.1 Définition Dans leur célèbre livre, Suzanne et Jim Robertson [55] définissent une exigence comme « quelque chose que le produit doit faire ou une qualité qu’il doit avoir ». Selon Kotonya [32], une exigence est « une description du comportement attendu du système, une contrainte sur les opérations, une propriété du système, etc. ».

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

_______________________________________________________________________ DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Une exigence est donc une assertion prescriptive que doit satisfaire le système, par exemple : « les contraintes d’un participant invité à une réunion doivent être demandées à celui-ci dans un délai fixé ». Elle peut adresser différents aspects du système que l’on veut contraindre et exprimer, par exemple : – une contrainte : le système doit inclure un vérificateur orthographique ; – une fonction requise : le système doit identifier les « clients les plus anciens » ; – une qualité attendue : la carte de vœux aux « clients les plus anciens » doit être imprimée en couleur. Annie Anton [3] lie l’exigence au but qu’elle permet d’atteindre : « une exigence spécifie comment un but doit être satisfait par le système ». Par exemple, « le système doit faire la distinction entre clients et prospects ». Cette exigence garantit que le but organisationnel de distinguer les clients des prospects est atteint par le système et donc, qu’une requête à la base de données du système demandant « qui sont les clients ? », (respectivement, « qui sont les prospects ? ») restituera la liste des clients, (respectivement, la liste des prospects).

tiwekacontentpdf_h3250 v2

CLIENT

CLIENT – Type

(a) Design par spécialisation

(b) Design par attribut

CLIENT FIDÈLE

Figure 6 – Choix d’implémentation d’une exigence

CLIENT (c) Absence de fidélisation des clients

3.1.2 Formulation Une exigence est formulée en termes de phénomènes de l’environnement organisationnel et dans le vocabulaire des acteurs impliqués. Une exigence est une expression en langage naturel qui, souvent, commence par « le système doit... ». Par exemple, « le système doit garder trace des clients fidèles ». Une exigence peut se décomposer en sous-exigences. La formulation des exigences peut donc être hiérarchique. Par exemple, dans le cas des réservations de chambres d’hôtels, l’exigence R1 suivante : R1 : « Le système doit prendre les demandes de réservations faites par les clients de manière automatique » se décompose en : R1.1 : Générer une réservation coïncidant avec la demande, R1.2 : Offrir le passage sur la liste d’attente, R1.3 : Proposer une réservation alternative et similaire. Les trois sous-exigences R1.1, R1.2, R1.3 affinent l’expression de l’exigence R1 en donnant trois tactiques de réalisation de R1. R1.1 est la tactique de succès applicable lorsque les ressources hôtelières gérées par le système sont suffisantes pour offrir une réservation qui coïncide avec la demande formulée par le client ; la tactique R1.2 est applicable lorsque R1.1 a échoué ; elle propose au client de s’inscrire sur une liste d’attente avec l’espoir qu’il puisse en sortir rapidement ; la tactique R1.3 est motivée par le fait de ne pas perdre un client potentiel ; elle propose une réservation qui ne coïncide pas tout-à-fait avec sa demande mais est similaire (différence dans la période, l’hôtel demandé ou la catégorie d’hôtel, etc.).

3.1.3 Propriétés Une exigence est une prescription qui impose une contrainte à la solution conceptuelle, par exemple sur le système de classes ou sur les événements et opérations du système informatique, mais laisse cependant une marge de choix au développeur. Par exemple, l’exigence précédente « le système doit garder trace des clients fidèles » peut être implémentée soit par spécialisation de la classe « client », soit par l’introduction d’un attribut « type » dans la classe (figure 6, cas (a) et (b) respectivement). Évidemment, comme la définition d’Annie Anton le suggère, une exigence est nécessairement en relation avec un but et reflète souvent un choix organisationnel. Par exemple, dans le cas précédent, l’exigence « le système doit garder trace des clients fidèles » traduit une décision des stratèges de l’organisation qui ont acquis la conviction que le meilleur moyen de faire du business est de traiter avec les mêmes clients de manière répétée et donc d’aller

Figure 7 – L’exigence satisfait le but

dans le sens de leur fidélisation. Bien sûr, la décision aurait pu être autre si les décideurs avaient la certitude que par exemple, c’est en faisant appel à une clientèle de passage, sans arrêt différente, qu’ils pouvaient faire le plus gros chiffre d’affaires. L’exigence dans ce cas se serait limitée à « le système doit maintenir de l’information sur les clients » (figure 7). Il est donc important de noter que toute exigence a cette double propriété (figure 7) : – d’imposer des contraintes au design, tout en laissant une certaine liberté de choix au concepteur, comme on l’a démontré ; – de refléter une décision organisationnelle matérialisée par un but que l’exigence permet de satisfaire. La propriété (a) traduit le fait qu’une exigence est moins détaillée que ne l’est la spécification conceptuelle qui en résulte. Formuler un ensemble d’exigences est donc moins consommateur en temps et énergie que de réaliser une spécification conceptuelle. On verra dans l’étude de cas des réservations de chambres d’hôtels du paragraphe 5 que la spécification conceptuelle complète comporte 66 pages alors que la liste des exigences qui permet de l’élaborer se formule sur une seule page. Inversement, l’ingénieur du besoin qui formule les exigences doit avoir le souci de ne pas entrer dans des détails qui ne présentent aucun enjeu organisationnel mais relèvent de la sphère de la conception d’une solution technique implémentable. La propriété (b) traduit la volonté de déterminer des exigences motivées par les intentions organisationnelles. C’est par respect de cette propriété que l’on peut espérer que le système To-Be soit en ligne avec les attentes des parties prenantes et donc accepté et utilisé pour le bien de tous. L’exigence est le moyen pour atteindre une fin (le but). Il est donc essentiel que l’ingénieur du besoin s’assure que toute exigence est en correspondance avec un but clairement adopté par les parties en jeu. Cela n’exige pas que l’on pratique nécessairement l’approche dirigée par les buts préconisée dans cet article ; par construction dans ce cas, les exigences découleront des buts. En revanche, si une autre approche est suivie, la recommandation de l’auteur est de s’assurer, à ce stade, qu’il existe bien un but réel et réaliste dont l’exigence est le reflet. Alors que la démarche dirigée par les buts (figure 8) est de nature top-down (les exigences sont les feuilles du raisonnement par les buts), l’auteur préconise, si nécessaire, une alternative qui est de suivre une démarche bottom-up (des exigences formulées vers les buts) afin de garantir que l’alignement du SI au métier et à la stratégie de l’organisation sera bien assuré.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

H 3 250 – 7

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES _______________________________________________________________________

– Identifiant : R12.7.4 ; – Description : Le système doit imprimer un reçu pour chaque client ; – Type : Exigence Fonctionnelle ; – Besoin : Exigence Essentielle ; – Priorité : Non urgent ; – Stabilité : Stable ; – Source : Équipe de gestion des stocks ; – Critère de mesure de satisfaction : Le système doit imprimer un reçu correct pour 100 % des clients qui ont acheté des produits en payant en cash, par carte de crédit, par carte de débit, par carte club, par bons d’achat.

Mission, objectif, but Reflète, est aligné à Exigence Donne forme, détermine

Choix de conception et solutions techniques alternatives Figure 8 – Double face d’une exigence

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

3.2 Types d’exigences

tiwekacontentpdf_h3250 v2

Les exigences sont de nature différente. On peut les classer en exigences fonctionnelles et exigences non fonctionnelles. Les exigences fonctionnelles définissent les services à fournir par le système To-Be. La plupart des exemples donnés précédemment sont de ce type. Les exigences non-fonctionnelles contraignent la manière dont le système doit satisfaire les exigences fonctionnelles, ou la manière de le développer. Elles se répartissent en diverses sous-catégories : • les exigences de qualité de service (sûreté, sécurité, utilisabilité, performance, précision des représentations logicielles par rapport à leur contrepartie dans l’environnement, etc.) ; • les contraintes juridictionnelles (obligations légales, réglementations, normes imposées), les contraintes opératoires sur le déploiement et le fonctionnement du système To-Be ; • les contraintes architecturales (répartition géographique des composants logiciels eu égard à la structure de l’organisation, à la répartition des données à utiliser ou des appareillages à contrôler, contraintes induites par la plate-forme d’implémentation, interopérabilité, etc.) ; • les exigences de développement (coûts, délais, réutilisabilité, adaptabilité et extensibilité, etc.).

3.3 Documentation La spécification d’une exigence se fait au moyen d’attributs de description. Il y a plusieurs modèles de description, par exemple celui de Volere [55] ou celui du standard PSO55. À titre indicatif voici le modèle PSO55 :

3.4 Qualités attendues Le développement d’un document d’exigences est une tâche difficile, au vu de la multiplicité et de la diversité des qualités à viser [14] [34] [43] [55] [64]. En voici quelques-unes :

■ Complétude : les buts identifiés doivent entièrement couvrir les besoins à rencontrer par le système To-Be, y compris la prise en compte de défaillances ou malveillances pouvant survenir dans l’environnement ; les exigences doivent suffire à garantir la satisfaction de l’ensemble des buts ; elles doivent également exprimer le problème à résoudre à un niveau de détail suffisant pour permettre la conception d’une solution.

■ Cohérence : les buts, exigences et spécifications doivent être compatibles entre eux, au sens où ils doivent pouvoir être satisfaits tous ensemble.

■ Adéquation : les buts et exigences doivent représenter les besoins effectifs, justifiant le développement d’un nouveau système ; les spécifications logicielles doivent fidèlement traduire les exigences.

■ Pertinence : les buts identifiés doivent être pertinents eu égard aux besoins à rencontrer par le système To-Be ; les exigences doivent chacune contribuer à un ou plusieurs de ces buts, et être constitutifs du problème à résoudre, plutôt que d’une solution possible.

■ Précision : l’énoncé des différents types d’assertions (buts, exi-

■ Requirement attributes (from PSO55 standard) – Identifiant : identifiant unique facilitant la trace d’une exigence ; – Description : texte descriptif non ambigu ; – Type : type de l’exigence (fonctionnelle ou non fonctionnelle) ; – Besoin : exigence essentielle versus non-essentielle ; – Priorité : mesure de la priorité de l’exigence dans le cas de livraison incrémentale ; – Stabilité : degré de stabilité de l’exigence au cours du temps ; – Source : document or nom d’une partie prenante à l’origine de l’exigence ; – Critère de mesure de satisfaction : vérification de l’exigence dans le système.

Voici un exemple de spécification d’une exigence dans le cas d’une caisse enregistreuse d’un supermarché.

H 3 250 – 8

On peut noter que le critère de mesure permettant de vérifier que l’exigence est effectivement implémentée dans le système en action ne laisse aucune marge d’erreur puisque le ticket de caisse doit être édité (et stocké dans la base de données) pour chaque achat et quel que soit le mode de paiement utilisé.

gences, spécifications) ne peut être interprété de différentes manières.

■ Mesurabilité : les exigences et spécifications logicielles doivent être explicitées d’une manière permettant leur évaluation par rapport à des alternatives, leur approbation ou rejet, et la vérification de leur satisfaction par la solution logicielle conçue par la suite.

■ Réalisme : les exigences et leur traduction en spécifications logicielles doivent être réalisables dans une enveloppe de coûts et délais fixée.

■ Compréhensibilité : l’énoncé des différents types d’assertions doit pouvoir être compris par l’ensemble des acteurs impliqués dans le processus d’ingénierie des exigences.

■ Bonne structuration : le document des exigences doit être organisé de manière à faire clairement apparaître les liens structurels entre ses éléments – liens d’affinage ou de spécialisation, liens de dépendance, liens de cause à effet, liens de définition-utilisation ; tout élément utilisé doit y être défini au préalable.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

_______________________________________________________________________ DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES

■ Modifiabilité : des variantes, révisions, extensions ou contractions du document des exigences doivent pouvoir y être réalisées de la manière la plus locale possible. ■ Traçabilité : on doit pouvoir retrouver aisément le contexte de la création, modification et utilisation d’un élément du document des exigences ; on doit pouvoir aisément évaluer et répercuter l’impact d’une modification de cet élément sur les autres éléments qui en dépendent, ainsi que sur les éléments de produits logiciels, en aval dans le cycle de vie, qui sont affectés par cette modification (descriptions architecturales, jeux de test, code source, etc.).

3.5 Exemple

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

Pour conclure ce paragraphe, considérons l’exemple partiel d’un système de réservation de sièges sur les vols d’une compagnie aérienne. Voici quelques exemples d’exigences formulées en langue naturelle (partie description du modèle PSO55 introduit précédemment).

tiwekacontentpdf_h3250 v2

Le système doit : R1 : « Prendre les demandes de réservations faites par les clients de manière automatique » : R1.1 : Générer une réservation coïncidant avec la demande, R1.2 : Offrir le passage sur la liste d’attente, R1.3 : Proposer une réservation alternative et similaire ; R2 : Générer les billets à la demande ; R3 : Sur les vols internationaux hors Europe, annuler les réservations non confirmées 72 heures avant le départ ; R4 : Annuler une réservation pour laquelle le billet n’a pas été émis au bout de 48 heures ; R5 : Maintenir les disponibilités de sièges avec précision, de manière correcte et en temps réel ; ............................................................... Commentaire 1 : La hiérarchisation d’une exigence permet d’introduire de la précision dans son expression. Par exemple, la décomposition de l’exigence R1 ci-dessus en trois sous-exigences apporte de la précision sur les différentes tactiques que le système doit implémenter en réponse à une demande formulée par un client. Commentaire 2 : Chaque exigence a le degré de précision suffisant pour permettre le design de la spécification logicielle. Comme le montre le développement ci-dessous, les exigences sont le support d’une analyse conduisant à l’identification d’éléments du schéma conceptuel tels que les classes d’objets dont le système doit maintenir les états de manière persistante, les événements auxquels le système doit réagir, la définition des conséquences de l’occurrence de chaque événement en termes d’actions et d’impacts sur les classes. Par exemple, l’analyse de l’exigence R1 permet (voir ci-dessous) d’identifier un événement central du système « arrivée d’une demande de réservation sur un vol » et ses conséquences. Il permet aussi un raisonnement sur les classes nécessaires au traitement automatique de l’événement : Demande, Réservation, Client, Siège, Disponibilité des sièges, Vol. L’exemple de l’exigence R5, traité partiellement ci-dessous, met l’accent sur la multiplicité des événements impliqués par l’exigence. Dans ce cas d’étude, les sièges sont les ressources que le système doit gérer « en temps réel, de manière précise et correcte ». La plupart des actions du système agissent sur l’état des ressources, en les consommant (par exemple lors d’une réservation) ou en les restituant (par exemple dans le cas d’une demande d’annulation ou d’un no show). L’exigence met l’accent sur la criticité d’une gestion efficace et efficiente des ressources ; sur cette base, le concepteur doit faire un recensement exhaustif des événements conduisant à une consommation ou à une production de la ressource « siège ».

R1 : « Prendre les demandes de réservations faites par les clients de manière automatique ». Classes et associations : Demande, Réservation, Client, Siège, Disponibilité des sièges, Vol. Événement : Arrivée d’une demande de réservation sur un vol, Actions conséquentes et impacts sur les classes : cas 1 : Faire une réservation sur le vol pour le nombre de sièges demandés par le client si les disponibilités le permettent ; sinon cas 2 : Proposer la mise en attente de la demande ; sinon cas 3 : Proposer une réservation similaire en changeant les dates et/ou la destination. .................................................................... R5 : Maintenir les disponibilités de sièges avec précision, de manière correcte et en temps réel. Événements : « Nouvelle disponibilité » ; « Arrivée de réservation à échéance » ; « le client annule sa réservation » ; « No show up » ; « Arrivée d’une demande de réservation » etc. Commentaire 3 : Les exigences permettent d’atteindre les buts fixés par l’environnement. Elles répondent à des besoins organisationnels. Ce lien de cause à effet (le but implique l’exigence) doit être clairement explicité pendant la phase d’élucidation des exigences et dans la documentation faite dans le document d’exigences. Par exemple, l’exigence R1 explicite la décision organisationnelle de demander au client de formuler sa demande et ensuite de faire en sorte que le système explore toutes les voies possibles pour atteindre le but de satisfaire le plus grand nombre possible de demandes de réservation. R1 : « Prendre les demandes de réservations faites par les clients de manière automatique » : R1.1 : Générer une réservation coïncidant avec la demande ; R1.2 : Offrir le passage sur la liste d’attente ; R1.3 : Proposer une réservation alternative et similaire. Les trois tactiques de tentative de satisfaction d’une demande soit instantanément soit de manière différée sont cohérentes avec la recherche de maximisation du nombre de cas de satisfaction du but. R1 est le moyen d’atteindre une fin (le but) et la mise en œuvre de la politique organisationnelle retenue (le client formule son souhait et le système réagit avec l’intention de trouver tous les modes de satisfaction de la demande possibles). Il faut noter que cette politique n’est pas la seule possible ; l’alternative souvent implémentée sur les sites de ventes en ligne serait d’afficher ce qui est disponible et de laisser le client choisir ce qui lui convient ; c’est en ce sens que R1 reflète une décision organisationnelle, celui d’une politique d’action qui est une parmi plusieurs possibles. L’exemple de R4 est similaire. L’exigence est un moyen d’atteindre une fin, le but « optimiser le remplissage des vols ». R4 : Annuler une réservation pour laquelle le billet n’a pas été émis au bout de 48 heures. Les réservations multiples perturbent les simulations de remplissage des vols au fur et à mesure que la date de départ approche. La règle sous-jacente à R4 que le système appliquera de manière systématique et automatique permet d’éliminer « le bruit » dans les estimations de remplissage.

3.6 Commentaire conclusif En guise de conclusion de ce paragraphe, voici quelques énoncés à propos des exigences : • les exigences ne sont pas des propriétés du domaine ; • les exigences ne sont pas des spécifications de logiciel ;

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

H 3 250 – 9

Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

DE LA MODÉLISATION CONCEPTUELLE À L’INGÉNIERIE DES EXIGENCES _______________________________________________________________________

• les exigences sont des formulations du problème, non des formulations d’une solution ; • les exigences ne sont pas la simple traduction du cahier des charges initial ;

0..1 composé de

Cible

Objet

Parution : février 2011 - Ce document a ete delivre pour le compte de 7200031704 - institut algerien du petrole // belkacem BRAHMI // 41.106.3.84

4.1.1 Définition

tiwekacontentpdf_h3250 v2

1 1..* Paramètre

Direction

Source

Destination

Voie

Moyen

Bénéficiaire

Manière

1

Figure 9 – Structure du but en notation UML

4.1 Qu’est-ce qu’un but ?

Selon Axel van Lamswerde [36], « un but correspond à un objectif que le système doit atteindre par la coopération d’agents du système To-Be et de l’environnement ». Un but projette dans le futur, il fait référence à un état dans lequel on souhaiterait que le système soit, un objectif qu’on voudrait atteindre ou maintenir. Par exemple, « Faire une réservation de chambres » est l’expression de l’intention de faire une réservation de chambres dans un hôtel. L’atteinte de cette intention laisse le système dans l’état « Réservation faite ». Un but fait référence à des propriétés attendues et « optatives » [27] du système To-Be ou de son environnement. En tant que déclaration d’intention, les buts sont déclaratifs et prescriptifs, par opposition à des expressions descriptives qui énoncent des faits réels. Par exemple, « Transporter les passagers rapidement » est un but tandis que « Si les portes sont fermées, elles ne sont pas ouvertes » est une expression descriptive. La dimension optative laisse la place à l’incertitude : si mon but est de « Devenir riche », il n’est pas certain que je puisse le satisfaire et atteindre l’état attendu. Enfin, la dimension déclarative du but permet de raisonner sur les états du futur en faisant abstraction des façons d’y parvenir. Cette caractéristique est importante car elle permet de maîtriser la complexité en évitant de se noyer dans des détails. À titre d’exemple, citons un projet européen de conduite du changement imposé aux utilities par la dérégulation du marché [ELEKTRA]. L’accord initial était de conduire le changement au niveau des processus d’entreprise. L’une des utilities du projet étant mal documentée, il a été admis qu’une modélisation des processus du cœur de métier de l’entreprise était un prérequis. Le résultat de 6 mois de travaux a été 175 modèles représentant un mètre cube de papier. L’abstraction de la connaissance détaillée du Qui fait Quoi, Quand, capturée dans ces modèles a pu être réalisée par un arbre de 250 buts contenant sur une page A3. La conduite du changement a été intégralement menée avec succès au niveau intentionnel (arbre de buts) puis répercutée au niveau des processus ; la masse d’information à manipuler au niveau des processus rendait la conduite du changement tout simplement impossible à mener de manière efficace. Le report à un niveau d’abstraction plus haut a rendu la chose possible avec efficacité. Le concept de but est essentiel dans ce type de situation. L’aspect abstrait d’un but est parfois un inconvénient mais il a aussi cet important avantage de cacher les détails dont on n’a pas nécessairement besoin à cet instant pour résoudre le problème posé.

manière semi-formelle. Notre expérience pratique a montré qu’il n’est pas aisé de formuler les buts. Pour éviter des erreurs dans leur expression, lever les ambiguïtés de l’expression en langage naturel et guider l’ingénieur des exigences vers une formulation correcte des buts, nous proposons un formalisme de but dérivé d’une définition linguistique développée par [53]. Celle-ci est fondée sur l’étude d’un large échantillon de buts décrits dans la littérature, et sur le formalisme de la grammaire de cas [15] [21]. Les cas sont des types des relations sémantiques que des groupes des mots entretiennent avec le verbe dans toute clause d’une phrase. Les cas permettent de représenter la structure profonde d’une phrase par opposition à sa structure de surface. Fillmore [21] a initialement identifié six cas : agent, instrumental, datif, factuel, locatif et objet. Par exemple, dans « La clé ouvre la porte », la clé joue le rôle d’instrumental et la porte celui d’objet. L’approche par cas, appliquée à la formulation des buts, conduit à représenter un but par un verbe suivi de paramètres. Une expression de but est ainsi composée d’un verbe et d’un ou plusieurs paramètres, chaque paramètre jouant un rôle particulier à l’égard du verbe. Comme le montre la figure 9, nous retenons les sept paramètres suivants : Objet, Résultat, Source, Destination, Bénéficiaire, Manière et Moyen. À noter que les deux paramètres Objet et Résultat sont généralisés par le paramètre Cible ; Source et Destination par le paramètre Direction ; et Manière et Moyen par le paramètre Voie (figure 9). Seul le paramètre « cible » est obligatoire ; les autres paramètres apportent de la précision dans l’énoncé du but mais ne sont pas obligatoires.

■ Cible : la cible concerne les entités affectées par le but. Il y a deux types de cibles : l’« objet » et le « résultat ». L’objet existe avant la réalisation du but, tandis que le résultat résulte de la réalisation du but. Dans l’expression (Retirer)verbe de (l’argent)Obj , l’argent est un objet puisqu’il existe avant la réalisation du but. A contrario, dans l’expression (Générer)verbe (un rapport de transaction)Rés , un rapport de transaction est un résultat puisqu’il n’existait pas en tant qu’entité physique avant la réalisation du but.

■ Direction : il y a deux types de Direction appelées Source (So) et Destination (Des). La source est le point de départ du but (source d’information ou lieu physique) tandis que la destination est le point d’arrivée du but (inverse de la source). Par exemple, dans (Retirer)verbe de (l’argent)Obj du (GAB)So , GAB est la source puisqu’il représente l’endroit initial de l’argent, tandis que dans (Transférer)verbe (la somme déposée)Obj au (compte du client)Des , compte du client est la destination puisqu’il est le point d’arrivée du transfert.

■ Bénéficiaire : la personne ou le groupe en faveur de qui le but

4.1.2 Formulation Les buts sont souvent formulés de manière informelle, rarement de manière formelle (KAOS [13] est une exception) et parfois de

H 3 250 – 10

Résultat