Copyright Dunod, 2014

9782100713417

Toutes les marques citées dans cet ouvragesont des marques déposées par leurs propriétaires respectifs

Illustration de couverture :Hot air baloons over a lake in New Mexico

© iStock.com / Mcelroyart

Visitez notre site Web : www.dunod.com

Consultez le site Web de cet ouvrage

Le code de la propriété intellectuelle n'autorisant, aux termes des paragraphes 2 et 3 de l'article L122-5, d'une part, que les « copies ou reproductions strictement réservées à l'usage privé du copiste et non destinées à une utilisation collective » et, d'autre part, sous réserve du nom de l'auteur et de la source, que « les analyses et les courtes citations justifiées par le caractère critique, polémique, pédagogique, scientifique ou d'information », toute représentation ou reproduction intégrale ou partielle, faite sans consentement de l'auteur ou de ses ayants droit, est illicite (art; L122-4). Toute représentation ou reproduction, par quelque procédé que ce soit, notamment par téléchargement ou sortie imprimante, constituera donc une contrefaçon sanctionnée par les articles L 335-2 et suivants du code de la propriété intellectuelle.

Préface

En tant que spécialiste SysML, langage de modélisation qui a ajouté le concept de Requirement aux concepts objets plus classiques d'UML, je cherchais depuis longtemps un ouvrage de référence en français sur l'ingénierie des exigences, clair et pédagogique.

J'ai eu maintes fois l'occasion dans le passé de correspondre avec Stéphane Badreau et Jean-Louis Boulanger sur des sujets liés à la modélisation, à la gestion des exigences, et au rapprochement possible entre les deux mondes. Déjà avec UML, mais encore plus directement avec SysML, il est clair que les deux sujets sont fortement connectés. Comment assurer la traçabilité entre une description d'architecture et les exigences système, comment valider des exigences utilisateur avec des scénarios, comment assurer la cohérence entre le référentiel d'exigences et le modèle système, telles sont les problématiques fréquentes du consultant en modélisation au cours de ses missions de coaching et d'accompagnement de projets.

Aussi, quand Stéphane Badreau m'a annoncé son envie d'écrire un livre sur l'ingénierie des exigences, je n'ai pu que l'encourager à combler un vide dans l'édition française. Connaissant la qualité du support de formation de la société Compliance Consulting qu'il a contribué à élaborer, je n'avais aucun doute sur la pertinence et la complétude du contenu technique de l'ouvrage. Jean-Louis Boulanger apportant en complément son expertise de la modélisation, des méthodes formelles et de la certification de logiciels critiques, je sentais que mon besoin avait de très bonnes chances d'être comblé.

Ayant eu le privilège de lire en avant-première les chapitres de cet ouvrage, je n'ai pas été déçu, bien au contraire ! Je pense que l'étendue des préoccupations couvertes par ce livre est tout à fait unique. Bien sûr, on va trouver la définition de tous les concepts et les classiques bonnes pratiques d'écriture des exigences, mais aussi un chapitre entier sur la modélisation des exigences, ainsi qu'un autre très à jour sur les possibilités de certification en ingénierie des exigences. Bref, si vous avez à gérer des exigences dans vos projets (et qui ne doit pas le faire ?), cet ouvrage en français sera pendant quelque temps sûrement votre livre de chevet…

Pascal RoquesConsultant et formateur en modélisationpascal.roques@prfc.fr

Avant-propos

Depuis de nombreux mois, nous avions l'idée d'écrire un ouvrage de référence sur l'ingénierie des exigences, non pas un ouvrage pour des initiés, mais plutôt un ouvrage à mettre entre toutes les mains. Nous sommes partis du constat que très peu de littérature française existait sur le sujet, alors que bizarrement le nombre d'ouvrages en langues étrangères (en majorité en anglais et en allemand) est important. Pourquoi une telle différence de traitement ? Nous, Français, serions-nous moins intéressés par la réussite des projets, par la volonté de mieux formaliser les besoins des parties prenantes et de mieux satisfaire les demandes d'évolutions des clients ? Sûrement pas ! Quelles que soient les raisons d'une telle situation, nous espérons que ce livre permettra de combler un peu une partie du retard…

Quel est l'objectif de ce livre ?

L'objectif de ce livre est de fournir les connaissances de base liées à l'ingénierie des exigences pour le développement de systèmes complexes à forte composante logicielle, et ce pour tous les domaines.

À qui s'adresse ce livre ?

Ce livre couvre les besoins de toutes les personnes concernées par l'ingénierie des exigences et qui collaborent au développement d'un système complexe. Il s'adresse d'une part à tous ceux qui souhaitent comprendre les enjeux et les bénéfices de l'ingénierie des exigences, et d'autre part à tous ceux qui souhaitent connaître les activités, les méthodes, les techniques et les outils qui permettent de développer et de gérer un référentiel d'exigences.

Parmi les profils principaux des personnes concernées par cet ouvrage, nous pouvons citer les managers et responsables d'équipes, les chefs de produit, les chefs de projet, les ingénieurs, les analystes, les architectes, les développeurs, les vérificateurs et les testeurs.

Comment est-il organisé ?

Afin d'en faciliter la lecture, ce livre est organisé en quatre parties qui peuvent être abordées dans un ordre quelconque.

La première partie pose le décor. Après une brève introduction, cette partie présente les enjeux (nombreux) et les fondamentaux de l'ingénierie des exigences. Toute personne, quel que soit son niveau d'implication face aux exigences, devrait connaître son contenu.

La deuxième partie est le cœur de cet ouvrage. Après avoir présenté ce que sont le périmètre et le contexte d'un système, cette partie aborde les activités de développement et de gestion d'un référentiel d'exigences. Comme elle traite également de la modélisation, elle est, par conséquent, plus dédiée aux opérationnels travaillant sur les projets.

La troisième partie est consacrée à l'outillage et aux relations entre l'ingénierie des exigences et les autres activités d'un projet de réalisation et de maintenance d'un produit. Cette partie s'adresse plutôt aux opérationnels, managers et chefs de projet.

La quatrième et dernière partie présente les normes et les référentiels de bonnes pratiques dans différents domaines qui ont trait de près ou de loin à l'ingénierie des exigences. Un chapitre complet aborde l'aspect certification en ingénierie des exigences. Avec la conclusion, cette dernière partie laisse entrevoir l'avenir de la profession et s'adresse à toutes les personnes intéressées par la valorisation du métier.

Fig. 1  Plan du livre

Nous avons souhaité être le plus clair et le plus concret possible en donnant des exemples lorsque cela était nécessaire. En tant que lecteur, nous vous invitons et vous encourageons à nous faire part de vos remarques sur le contenu de ce livre.

Remerciements

Les auteurs remercient Pascal Roques qui a gentiment accepté d'écrire la préface de ce livre.

Nous remercions les personnes suivantes qui ont participé avec enthousiasme à la relecture de cet ouvrage : Patrice Amblard, Dominique Biraud, Dominique Houdier, Christophe Monjo, Camille Salinesi.

Nous remercions également nos familles respectives pour leurs encouragements et leur support durant tous les week-ends et toutes les soirées passés à faire, défaire et refaire les différentes parties de ce livre.

À Marie-Luce, Anne-Charlotte, Victoria et Nadia.

À Nadège, Geoffrey, Adrien, Marie et Jeanne.

1

Enjeux
et fondamentaux
de l'ingénierie
des exigences

Dans cette première partie, notre souci a été de poser le décor et de vous présenter les raisons qui peuvent amener une organisation à explorer le monde des exigences et mettre en place les processus, méthodes et outils d'ingénierie.

Nous avons essayé d'expliquer les nombreux enjeux de l'ingénierie des exigences et les bénéfices attendus lorsque les activités sont réalisées de façon optimale et toujours justifiées.

Après une brève introduction, le deuxième chapitre présente les enjeux de l'ingénierie des exigences. Le troisième chapitre donne les bases et les fondamentaux de l'ingénierie des exigences, à travers des définitions et la présentation de concepts.

À la fin de cette partie, quelle que soit votre position au sein de l'organisation, vous devriez avoir déjà une bonne idée de ce que peut vous apporter l'ingénierie des exigences dans un projet.

Chapitre 1. Introduction

Chapitre 2. Enjeux de l'ingénierie des exigences

1

Introduction

Objectif

Ce chapitre d'introduction a pour but de présenter le contexte dans lequel ce livre a été réalisé et de préciser les orientations prises par les auteurs.

1.1.   Présentation

La réalisation d'un produit (quelle que soit sa nature) est un processus long, complexe et coûteux, aussi est-il nécessaire de mettre en place des approches et des méthodologies permettant de garantir le succès.

L'un des points délicats dans la réalisation d'un produit réside dans la maîtrise du logiciel. Réaliser un logiciel est et restera une activité difficile. Depuis de nombreuses années, des efforts importants ont été consacrés à l'amélioration de la qualité des logiciels. Des approches qualités comme l'ISO 9001:2008, le CMMi et le SPICE ont été développées ; elles offrent des moyens de contrôler et d'améliorer le processus de développement des applications logicielles.

En complément des initiatives ont été réalisées pour formaliser et abstraire les applications logicielles au travers de modèles plus ou moins formels. Les approches orientées modèles sont actuellement en cours de mise en œuvre tant au niveau système qu'au niveau logiciel, et sur l'ensemble du cycle de réalisation du produit.

En parallèle, pour les différents domaines (aéronautique, automobile, électronique, électronique ferroviaire, industrie, machine, médical, nucléaire, etc.) des standards ont été définis afin d'offrir un cadre à la réalisation de systèmes à base de logiciels prépondérants.

Au final, l'ensemble de ces progrès a fait apparaître la nécessité de maîtriser et de définir le plus finement possible le besoin. De fréquentes et récurrentes études montrent que si le besoin est mal exprimé, incorrect ou incomplet, le produit réalisé ne correspondra pas aux attentes des utilisateurs.

La définition et la maîtrise du besoin passent par l'identification des exigences que le produit doit respecter. L'ingénierie des exigences est ainsi l'approche commune à l'ensemble des domaines métiers, aussi divers soient-ils.

Il est à noter que l'ingénierie des exigences n'est pas nouvelle, car dès le milieu des années 1990, on identifiait déjà les exigences. Dans le début des années 2000, les traçabilités manuelles ont été remplacées par des outils de gestion des exigences ou d'aide à la traçabilité. Mais ce n'est que vers 2005 que l'on a vu se développer les approches méthodologiques basées sur les exigences et une littérature associée comme [HUL 05].

1.2.   Orientation

Dans le cadre de ce livre, nous avons souhaité présenter les fondamentaux de l'ingénierie des exigences et faire un panorama le plus large et le plus complet possible pour expliquer le positionnement des exigences dans la réalisation d'un produit.

À travers les différents chapitres, nous allons présenter les apports et les enjeux liés à l'ingénierie des exigences et progressivement proposer une approche qui vise à définir un référentiel d'exigences et à le maintenir en cohérence durant le projet de réalisation du produit.

Quels que soient le domaine d'application et le point de vue client ou fournisseur d'un produit, il est nécessaire de mettre en place une démarche rigoureuse permettant l'identification de toutes les exigences caractérisant le produit à réaliser. L'une des difficultés réside dans le fait que les exigences sont de natures différentes et qu'elles doivent répondre aux besoins de l'ensemble des parties prenantes pour garantir la satisfaction des utilisateurs finaux. Bien souvent, les parties prenantes ont des intérêts divergents et, dans ce cas, le référentiel d'exigences se révèle comme étant un des supports importants à la résolution des conflits.

Les activités de l'ingénierie des exigences n'étant pas isolées au sein d'un projet, nous présenterons les adhérences avec les nombreuses autres activités d'ingénierie et de support. L'aspect outillage ne sera pas oublié car il est généralement admis qu'à partir d'une certaine complexité du produit et/ou du projet, l'utilisation d'un outil de développement ou de gestion des exigences apporte un réel gage d'efficacité et de performance.

Le dernier aspect qui nous tient à cœur, et qui est abordé au terme de cet ouvrage, est la certification en ingénierie des exigences et la reconnaissance du métier d'analyste en exigences.

En résumé

Ce court chapitre a permis de présenter le contexte de ce livre dont l'objectif est de fournir les connaissances de base en ingénierie des exigences et une aide à la construction d'une méthodologie de développement et de gestion des exigences.

2

Enjeux de l'ingénierie
des exigences

Objectif

En introduction, ce chapitre présente quelques résultats d'études qui montrent l'importance des exigences pour les produits[1] complexes et les projets informatiques.

Par la suite, nous présenterons les enjeux de l'ingénierie des exigences et les bénéfices attendus tant pour le client que pour le fournisseur. Dans ce contexte, lorsqu'il s'agit de gérer l'acquisition et la fourniture des produits, nous verrons que les exigences doivent être au cœur de la relation entre le client et le fournisseur.

Nous verrons aussi les symptômes d'une ingénierie des exigences inadéquate.

2.1.   Pourquoi mettre en œuvre une ingénierie des exigences ?

2.1.1.   Pour la réussite des projets

Depuis de nombreuses années, diverses études se sont penchées sur les raisons d'échec et de réussite des projets. Parmi ces études, les résultats du rapport CHAOS du Standish Group [STA 94, STA 01] font partie des plus connus et sont souvent cités en référence pour les projets informatiques[2]. Régulièrement mis à jour depuis la première publication en 1994, les résultats de 2002, 2006, puis de 2009, montrent indéfectiblement les mêmes raisons qui font qu'un projet réussit et les mêmes causes qui font qu'il échoue.

Le Standish Group (www.standishgroup.com) a audité des sociétés représentatives du marché américain, qu'elles soient grosses, moyennes ou petites. Les projets informatiques ont été classés en trois catégories :

Type 1 – les projets qui se terminent dans les temps et dans le budget, avec un périmètre fonctionnel livré conforme au périmètre initialement défini ;

Type 2 – les projets qui se terminent en ayant respecté soit le temps, soit le budget, avec un périmètre fonctionnel livré légèrement différent du périmètre initial ;

Type 3 – les projets qui ont été abandonnés en cours du projet pour diverses raisons.

D'une manière générale, les différentes études montrent que les projets de type 1 représentent 20 % des projets, les projets de type 2 représentent 50 % des projets et les projets de type 3 représentent 30 % de l'ensemble des projets.

À ce stade, il est intéressant de constater que la majorité des projets ne sont pas maîtrisés et qu'une part encore trop importante échoue.

Si maintenant, nous regardons les facteurs de succès, de challenge et d'échec des projets, nous trouvons :

Facteurs principaux de succès[3] :

1. Implication des utilisateurs (15,9 %)

2. Support du management exécutif (13,9 %)

3. Définition claire des exigences (13 %)

4. Bonne planification

5. Attentes réalistes (8,2 %)

etc.

Dans cette liste, les facteurs relatifs aux exigences (points 1, 3 et 5) représentent 37,1 %.

Facteurs principaux de challenge :

1. Manque de données en provenance des utilisateurs (12,8 %)

2. Exigences et spécifications incomplètes (12,3 %)

3. Changements sur les exigences et les spécifications (11,8 %)

4. Manque de support de l'exécutif (7,5 %)

5. Incompétence sur les technologies (7 %)

6. Manque de ressources (6,4 %)

7. Attentes irréalistes (5,9 %)

8. Objectifs pas clairs (5,3 %)

etc.

Dans cette liste, les facteurs relatifs aux exigences (points 1, 2, 3, 7 et 8) représentent 48,1 %.

Facteurs principaux d'échec :

1. Exigences incomplètes (13,1 %)

2. Manque d'implication des utilisateurs (12,4 %)

3. Manque de ressources (10,6 %)

4. Attentes irréalistes (9,9 %)

5. Manque de support de l'exécutif (9,3 %)

6. Changements sur les exigences et les spécifications (8,7 %)

etc.

Dans cette liste, les facteurs relatifs aux exigences (points 1, 2, 4 et 6) représentent 44,1 %.

Il est éloquent de voir que les facteurs le plus souvent cités ont trait de près ou de loin aux exigences. De ce fait, les exigences représentent le levier le plus important pour améliorer le taux de réussite des projets.

En résumé, si nous retenons les causes d'échec des projets qui sont relatives aux exigences, nous pouvons affirmer que :

Les exigences ne sont pas complètes ;

Les parties prenantes ne sont pas impliquées dans le projet ;

Les attentes sont irréalistes ;

Les exigences évoluent au cours du projet.

Vous l'aurez compris, s'assurer de la maîtrise du processus de définition des exigences est donc l'un des facteurs clés de la réussite d'un projet.

En complément, les normes applicables aux différents domaines rendent obligatoire la mise en œuvre d'un processus de développement et de gestion des exigences. Mais la principale difficulté de la gestion des exigences réside dans la définition de la notion d'exigence. Il existe plusieurs travaux qui tentent d'identifier ce qu'est une exigence et comment gérer les exigences. [HUL 05, POH 10] présentent des synthèses très complètes.

Sur un autre registre, d'autres études, comme celle menée par Martin & Leffinel (voir la figure 2.1) montrent que plus de la moitié des erreurs détectées pendant la vie d'un projet informatique sont attribuables à un problème de définition des besoins (56 % exactement) … et donc d'exigences.

Fig. 2.1  Origine des défauts de qualité logicielleSource Martin & Leffinel

En outre, plus l'origine d'une erreur se trouve en amont du cycle de vie d'un projet, plus cette erreur s'avère coûteuse à corriger. En d'autres termes, plus un défaut est introduit tôt, plus sa correction est onéreuse.

Par rapport à la phase d'expression des besoins, il est de coutume de présenter les chiffres relatifs au coût de correction sous la forme d'un graphique, représenté sur la figure 2.2. La progression du coût suit une courbe exponentielle.

Fig. 2.2  Coût relatif de correction d'une erreur sur les exigences

Dans le cadre de nos activités de consultant, nous avons été confrontés à ces différents problèmes et aux besoins d'identifier et de maîtriser les exigences. À titre d'exemple, dans les années 1990, la mise en place du projet SAET-METEOR (ligne 14 du métro parisien) a été l'occasion de construire un référentiel d'exigence et de l'exploiter au travers de modélisation (voir [BOU 00]). Par la suite, la RATP a formalisé l'ensemble de son besoin sous forme d'exigences. Dans le cadre de [BOU 06], nous avons montré comment la maîtrise des exigences et la modélisation devaient être combinées afin de construire des systèmes répondant au mieux aux besoins.

2.1.2.   Pour la satisfaction du client

L'enjeu principal de l'ingénierie des exigences est la satisfaction du client, et par là même des utilisateurs. La satisfaction du client est un vaste chantier, et dans le cadre de ce chantier, les exigences représentent un levier d'amélioration important.

Si l'on considère que la satisfaction du client est l'intersection entre les besoins du client, une définition du produit et une livraison du produit, il s'agit de faire en sorte que cette intersection soit la plus grande possible (voir la figure 2.3).

Fig. 2.3  Besoin, produit et définition : impact sur la satisfaction

En dehors de cette zone d'intersection, il y a de nombreuses raisons pour que le client ne soit pas satisfait. Nous pouvons résumer les différentes situations comme suit.

Besoins insatisfaits

Un défaut d'identification de tout ou partie des besoins du client peut être à l'origine de l'insatisfaction. Les besoins insatisfaits sont quasiment toujours existants dans un projet. Ceci vient du fait que le projet de développement du produit est contraint. Il est contraint au plus haut point par le budget et par le temps consacré au projet, mais aussi par d'autres contraintes qui peuvent apparaître plus secondaires. Par exemple, le fait que le fournisseur du produit propose une solution basée sur un produit générique va limiter le choix des fonctionnalités pour le client.

Non-conformité

La non-conformité dans un projet correspond à ce que l'on appelle une « anomalie » ou un « défaut ». Cet aspect est inhérent au développement des produits mais devrait au final être réduit à sa plus simple expression, en apportant des corrections sur le produit livré. Mais en règle générale, tout produit à base de logiciel contient des défauts qui auront été acceptés ou qui seront sujets à une procédure spécifique (notion de contraintes exportées[4]).

Sur-définition

La sur-définition est plus rare mais pas impossible (le fournisseur n'a aucun intérêt à fournir plus que prévu). Elle peut par exemple provenir d'une documentation qui n'est plus à jour par rapport au produit livré suite à une demande de changement qui a été directement effectuée sur le produit sans mise à jour de la spécification.

Conformité inutile

La conformité inutile est souvent liée à une sur-définition. Elle peut avoir comme origine une volonté de l'analyste et du développeur de vouloir en faire plus que ce qui est demandé par le client, consciemment ou inconsciemment. (i.e. faire le produit parfait – sans contrainte). Elle peut aussi intervenir lorsqu'on prend en compte un périmètre normatif ou législatif trop large. Dans certains cas, elle est voulue car on cherche à réaliser un produit utilisable dans plusieurs domaines ou pour plusieurs pays. Nous pouvons ajouter que la conformité inutile est une sur-définition qui a coûté cher en tests.

Fonctions inutiles

Les fonctions inutiles sont souvent le résultat d'une réutilisation d'une partie d'un produit existant comme point de départ du développement du nouveau produit. Les fonctions inutiles peuvent aussi être liées au fait que des membres de l'équipe projet ont pensé à de futurs projets et tenté d'améliorer la « réutilisation ».

Ces fonctions sont très difficiles à déceler par le client car il n'a pas exprimé de besoins pour cette fonction et la documentation du produit ne la décrit pas non plus. Ces fonctions sont visibles lors des analyses de couvertures réalisées par l'équipe de conception, mais elles sont souvent « trouvées » par erreur par le client, lors de tests aux limites ou d'utilisation du produit à la marge de son utilisation prévue.

À noter que dans les systèmes dits critiques (aéronautique, ferroviaire, nucléaire, spatial, etc.), les fonctions inutiles ne sont pas acceptables.

Conformité par hasard

En tant que chef de projet du développement du produit, une conformité par hasard n'est quasiment jamais reprochée par le client ! Pourquoi ? Parce que le client a exprimé un besoin, et sans en connaître réellement les raisons, ce besoin se trouve satisfait dans le produit livré. Sur le projet courant cela n'est peut-être pas très grave, mais lorsque vous allez vouloir faire évoluer ce produit au cours d'un projet ultérieur, vous serez confronté à une documentation incomplète du périmètre existant et plus facilement sujet à la non-régression. Bien entendu, pour les systèmes dits critiques, la conformité par hasard ne sera pas acceptée et il faudra disposer de tous les éléments de démonstration.

2.1.3.   Pour l'amélioration de la couverture du besoin

L'insatisfaction d'un client est bien plus souvent due à un besoin mal exprimé qu'à la qualité du produit qu'il reçoit. La phase d'expression du besoin est une étape cruciale d'un projet qu'il faut aborder de façon méthodique et rigoureuse.

La mise en place d'une formalisation adaptée et de techniques appropriées d'élucidation des exigences permet d'améliorer et de maximiser la couverture du besoin. Néanmoins, et comme l'illustre la figure 2.4, il y aura toujours des besoins insatisfaits et du développement de fonctions inutiles ou à très faible valeur ajoutée.

Fig. 2.4  Maximiser la couverture du besoin

Cette amélioration est induite par la maîtrise commune du besoin et par le suivi de ce besoin. En effet, il est possible de suivre l'ensemble des exigences sur l'ensemble des activités et ceci depuis les besoins client jusqu'à la ligne de code source qui y répond (pour un logiciel).

2.2.   Bénéfices pour le client

Les enjeux de l'ingénierie des exigences sont multiples et dépendent du point de vue où l'on se place.

Pour le client, il s'agit principalement :

d'obtenir la satisfaction des utilisateurs,

de réduire letemps de mise sur le marché.

2.2.1.   La satisfaction des utilisateurs

Pour le client, le principal enjeu est la satisfaction des utilisateurs. Comme le montre la figure 2.5, l'idée maîtresse est la maximisation de la zone d'intersection entre les besoins du client, la définition du produit et le produit effectivement livré.

Le modèle de Kano [ULL 97] (voir la figure 2.5) offre l'avantage de rendre visible des attentes non exprimées de la part du client et son utilisation est donc très intéressante pour prendre conscience des exigences implicites et de leur impact sur la satisfaction du client.

Fig. 2.5  Évaluation de la satisfaction des utilisateurs selon Kano

Le professeur Noriaki Kano[5] propose une classification des attentes des utilisateurs suivant les critères « prise en compte des attentes » et « niveau de satisfaction ». Il définit trois catégories de facteurs :

les facteurs de base ;

les facteurs de performance ;

les facteurs d'enthousiasme.

Tout d'abord, les facteurs de base (courbe « Basique » sur le schéma) regroupent l'ensemble des attentes normales et indispensables pour l'utilisateur final d'un produit. Ils se caractérisent par le fait que si une fonctionnalité dite de base d'un produit n'est pas présente, l'insatisfaction de l'utilisateur est très importante et peut même aller jusqu'au rejet du produit. La présence d'une fonctionnalité de base n'apporte pas de satisfaction particulière. Par exemple, c'est une chose tout à fait normale que les trains soient ponctuels à l'arrivée. Par contre, lorsque les trains n'arrivent pas à l'heure, la déception des voyageurs est grande.

Les facteurs de performance (courbe « Performance » sur le schéma) représentent les fonctionnalités qui offrent une satisfaction proportionnelle à la performance du produit. Par exemple, la consommation d'une voiture est un facteur de performance. Plus la consommation est basse, plus la satisfaction du conducteur est grande. Au contraire, un véhicule très consommateur en carburant n'obtiendra pas l'adhésion des futurs acheteurs.

Les facteurs d'enthousiasme (courbe « Excitation » sur le schéma) sont les facteurs qui procurent l'attraction, le ravissement et l'émerveillement. Leur absence ne procure pas de frustration, mais leur présence apporte une satisfaction supplémentaire non négligeable. Par exemple, lorsqu'Apple a sorti le premier iPhone avec son écran tactile, les acheteurs se sont rués sur le produit qui était révolutionnaire à l'époque.

Kano précise qu'il existe une zone d'indifférence, plus ou moins étendue, où la présence d'une attente et le niveau de satisfaction de l'utilisateur ne procurent ni l'excitation, ni le rejet.

Kano indique également que les attentes des utilisateurs changent de catégorie au cours du temps, et qu'elles progressent d'une catégorie à une autre. En règle générale, les attentes initialement classées dans les facteurs d'enthousiasme dérivent progressivement vers les facteurs de performance, puis finissent comme facteurs de base. Pour reprendre l'exemple d'Apple avec son iPhone, aujourd'hui, tout smartphone possède un écran tactile, et cette fonctionnalité fait partie de l'équipement de base d'un téléphone intelligent.

2.2.2.   La réduction du temps de mise sur le marché

Un second enjeu majeur est la réduction du temps de mise sur le marché. Dans un monde où les produits et les services associés doivent évoluer très vite, il faut sans cesse innover et proposer de nouvelles fonctionnalités aux utilisateurs. Le « time-to-market » est une doléance très importante pour le client, voire cruciale pour la survie même d'une entreprise.

La mise en place d'une ingénierie des exigences va permettre d'avoir un niveau de confiance optimal dans la progression du projet et d'éviter les retours arrière ou les hésitations. La qualité va ainsi pouvoir être contrôlée à tous les niveaux.

D'autre part, lorsque l'ingénierie des exigences est combinée à la réutilisation des artefacts[6] d'ingénierie, elle va également participer à la réduction du délai de mise sur le marché. Cette notion de réutilisation est abordée dans le chapitre 9 (section 9.8).

2.3.   Bénéfices pour le fournisseur

Pour le fournisseur, les enjeux sont multiples et plus nombreux que pour le client.

Il s'agit :

de maîtriser le périmètre du projet, et d'éviter le « coup de la balançoire »[7] ou de minimiser le « scope creep »[8]. Grâce à une bonne ingénierie des exigences, le chef de projet (CdP) couvrira les réels besoins de son client et des utilisateurs du produit, mais aussi maîtrisera les demandes de changements et leurs impacts sur le périmètre du projet.

de baisser les coûts du projet, le CdP sait exactement ce qu'il a à développer et va pouvoir optimiser le développement en ne livrant que ce qui est nécessaire à son client.

de diminuer les risques, le CdP va s'assurer que les équipes sont focalisées sur le référentiel d'exigences et qu'il n'y aura pas de mauvaise surprise à la livraison du produit.

d'améliorer le pilotage du projet grâce à la mise en place d'indicateurs de suivi.

d'augmenter la qualité des livrables, à chaque stade d'avancement du projet, le CdP vérifie le niveau de conformité aux exigences.

de faciliter les échanges avec une meilleure communication et collaboration au sein du projet.

Une bonne ingénierie des exigences facilite le travail de tous les intervenants du projet. Le client peut vérifier la bonne compréhension et prise en compte de son besoin. Les experts de domaine ou analystes sont confiants de la qualité de leur réponse au besoin, les architectes ont une vue sur les exigences non fonctionnelles du produit à concevoir, les développeurs peuvent implémenter facilement toutes les exigences liées aux composants et les testeurs connaissent les tests qu'ils ont à réaliser.

2.3.1.   La maîtrise du périmètre du projet

Définir le périmètre d'un projet est un exercice difficile, mais qu'il convient de ne pas négliger. La maîtrise du périmètre passe par une définition claire, sous forme textuelle, de ce qu'est le produit. Bien entendu, cette définition devra être validée par les parties prenantes du projet. Cette définition du produit à réaliser doit clairement identifier les interfaces connues du produit et les dépendances avec des produits existants.

Toutes les limites du produit et toutes ses interfaces avec l'environnement ne sont pas connues au début du projet, et l'une des activités complémentaires à la définition du produit consiste à identifier de façon la plus précise possible le périmètre du produit ; ce qui est à l'intérieur, ce qui est à l'extérieur.

Cet exercice est d'autant plus difficile que le périmètre change au cours du temps, soit de façon contrôlée (c'est espéré !), soit de façon inconsciente. Dans ce dernier cas, les anglophones parlent de « scope creep » ou de « dérive du périmètre ». Cette dérive peut être causée par une gestion inefficace des demandes de changement, un manque d'identification initiale des objectifs du projet, une gestion de projet hasardeuse, ou tout simplement une mauvaise communication entre les parties prenantes.

2.3.2.   La baisse des coûts du projet

Savoir exactement là où l'on va offre une garantie de coûts maîtrisés. Le fait de bénéficier d'un référentiel d'exigences commun aux équipes et de disposer de spécifications d'exigences de bonne qualité dès le début du projet apporte de nombreux avantages, comme une définition précise du besoin et du périmètre, ainsi qu'une compréhension commune du besoin.

La connaissance des exigences permet de gérer l'avancement du projet (nombre d'exigences traitées/nombre d'exigences totales), d'estimer la charge, et de réaliser le bon produit du premier coup. Le travail correctif ou de reprise (rework) est minimisé.

2.3.3.   La diminution des risques du projet

Les notions d'exigence et de risque sont indissociables. Au travers des exigences, le chef de projet va pouvoir estimer le niveau de risque de son projet et pouvoir se focaliser sur les exigences qui sont les plus critiques pour le client et celles qui seront considérées comme devant être traitées prioritairement. Le niveau de risque lié à l'exigence va donner le niveau de soin qu'il faudra apporter à sa rédaction, son suivi et sa vérification.

La survenue d'un changement de périmètre est également une cause importante d'échec sur un projet. La mise en place d'une ingénierie des exigences est une solution pour maîtriser les évolutions, les risques et les délais associés.

2.3.4.   L'amélioration du pilotage du projet

La maîtrise des exigences permet de fixer le périmètre du projet mais également de suivre l'avancement du projet. La gestion des exigences peut être utilisée pour fournir des indicateurs (nombre d'exigences créées, nombre d'exigences modifiées, nombre d'exigences à tester, nombre d'exigences à vérifier, etc.) qui permettront un pilotage précis du projet. Nous présenterons quelques indicateurs de pilotage dans le chapitre 9 (section 9.7) dédié à la gestion de projet.

2.3.5.   L'augmentation de la qualité du produit

À chacune des étapes d'un projet, grâce au référentiel d'exigences, les équipes sauront exactement ce qu'elles ont à faire. Le leitmotiv sera de vérifier la conformité des livrables des activités de développement aux exigences. Le résultat sera l'obtention d'un produit fini de qualité, répondant aux exigences des utilisateurs finaux et du client.

2.3.6.   La meilleure communication et collaboration au sein du projet

La communication entre toutes les parties prenantes et la collaboration organisée entre elles sont des facteurs clés de la réussite des projets. Grâce au développement collaboratif du référentiel d'exigences et à la maîtrise de ce référentiel dans la durée, les équipes auront le support idéal pour une communication efficace au sein du projet.

Notes

[1]  Nous utilisons ici le terme générique « produit » pour désigner soit un système, soit un logiciel, soit un matériel, soit un service, soit une documentation ou toute autre chose créée par l'homme.

[2]  Ces constats sont aussi valables pour d'autres types de projets : automobile, aéronautique, ferroviaire, nucléaire, spatial, naval, etc.

[3]  Le pourcentage indique la fréquence des facteurs invoqués pour les projets.

[4]  Lorsqu'un produit est mis à disposition, il peut rester des anomalies ou des points non traités. La fiche de version du produit doit alors être associée à un document décrivant les conditions d'utilisation du produit. Ces conditions doivent prendre en compte les conditions pour une bonne utilisation mais aussi des contraintes tenant compte des anomalies, des limites et des points non traités. À titre d'exemple, on pourrait citer les notices associées aux médicaments qui laissent aux médecins et aux malades un certain nombre de conditions à respecter ou des points à surveiller. Dans le cadre des systèmes ayant un impact sur la sécurité et des systèmes certifiés, on parle alors de contraintes exportées.

[5]  Voir son profil sur http://www.isqnet.org/ANQcongress2010/pops/NoriakiKano.asp.

[6]  Voir le glossaire.

[7]  Déperdition du besoin du client ; entre ce que veut le client, ce qu'il a exprimé, ce qu'a compris l'équipe d'avant-vente et le chef de projet, ce qui a été traduit dans les spécifications, ce qui a été implémenté, testé, documenté, ce qui a été livré et ce que souhaitait réellement le client !

[8]  Dérive qui se réfère à des changements incontrôlés ou à une croissance continue du périmètre dans le cadre d'un projet. Cela peut se produire lorsque le périmètre d'un projet n'est pas correctement défini, documenté ou contrôlé. Elle est généralement considérée comme nocive.