Résumé

Comment recueillir tous les besoins des acteurs du système d’information, et rien que leurs besoins réels ? Comment se mettre d’accord sur la spécification des exigences ? Comment aboutir à un cahier des charges clair, complet et consensuel ? Phase cruciale dans le choix, le développement ou la mise en œuvre d’une solution d’entreprise, la définition des besoins conditionnera en effet la réussite du projet, notamment son coût et sa qualité. Mais cette phase est complexe et délicate, en raison du nombre et de la diversité des parties prenantes, des demandes souvent divergentes, des contraintes variées et, last but not least, du facteur humain.

Véritable guide de terrain, nourri par la grande expérience de son auteur, cet ouvrage présente une démarche et des techniques éprouvées pour recueillir et formaliser les vrais besoins, afin d’élaborer un cahier des charges d’une qualité irréprochable, dans des délais raisonnables et au moindre coût. À partir d’un exemple permettant de mieux saisir les enjeux, la première partie expose les prérequis, puis décrit le processus et les activités préparatoires indispensables : définition des objectifs et du périmètre, analyse des parties prenantes, planification de l’élaboration. La deuxième partie détaille les quatre grandes étapes de cette méthode (recueil, analyse, spécification et validation), avec à la clé des modèles de documents, des grilles et des check-lists. Enfin, la troisième partie porte sur les techniques et les outils de gestion des exigences, et s’achève par des conseils pour s’améliorer encore.

Revue et augmentée, la deuxième édition de cet ouvrage s’enrichit notamment de deux nouveaux chapitres, l’un portant sur les ateliers de travail, l’autre sur les stratégies et tactiques d’élaboration d’un cahier des charges. Grâce à ce livre d’une clarté exceptionnelle, le lecteur sera ainsi prêt à relever les défis que pose toute mission de définition des besoins.

À qui s’adresse ce livre ?

• Aux assistants à la maîtrise d’ouvrage (AMOA)

• Aux consultants en systèmes d’information

• Aux experts techniques et métier

• Aux architectes du système d’information

• À tous ceux qui sont impliqués dans l’élaboration d’un cahier des charges

Au sommaire

Méthodologie. La méthode en action. Les enjeux d’une bonne définition des besoins. Compétences et savoir-faire. Exigences et cycle de vie du logiciel. La démarche. Définir le concept et les objectifs. Planifier le projet d’élaboration. Développement des exigences. L’étape de recueil. Les cas d’utilisation. L’étape d’analyse. Les exigences non fonctionnelles. Les contraintes. L’étape de spécification. Structure du cahier des charges. L’étape de validation. L’atelier de travail. Améliorer le processus. Stratégies et tactiques. Faire vivre les exigences. La gestion des exigences. Les outils. Au-delà des exigences. Neuf conseils.

Biographie auteur

Consultant en systèmes d’information, Yves Constantinidis a dirigé avec succès l’élaboration de plusieurs cahiers des charges de portée nationale (ministère de la Santé, ministère de l’Éducation nationale). Informaticien de formation, il intervient sur des missions de choix de solutions, de diagnostic du système d’information et d’amélioration du processus de développement. Son expertise l’a amené à publier trois ouvrages sur l’ingénierie du système d’information et la qualité du logiciel (éditions Hermès), et à intervenir comme formateur auprès d’établissements d’enseignement supérieur (Epita, École des hautes études en santé publique, université d’Angers…).

Michel Volle est président d’honneur du Club des Maîtres d’Ouvrage des Systèmes d’Information.

www.editions-eyrolles.com

YVES CONSTANTINIDIS

Guide d’élaboration
du cahier des charges

ÉDITIONS EYROLLES

61, bd Saint-Germain

75240 Paris Cedex 05

www.editions-eyrolles.com

En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage, sur quelque support que ce soit, sans l’autorisation de l’Éditeur ou du Centre Français d’exploitation du droit de copie, 20, rue des Grands Augustins, 75006 Paris.

© Groupe Eyrolles, 2011, 2013, ISBN : 978-2-212-13653-1

À la mémoire de mon ami Dominique Follens

Chez le même éditeur

Y. CONSTANTINIDIS. – Mémento Cahier des charges informatique.

N°13289, 2011, 14 pages.

O. ENGLEDER, S. FERNANDES. – Manager un projet informatique.

N°55524, 2012, 360 pages.

H.-P. MADERS. – Animer une équipe projet avec succès.

N°55523, 2012, 264 pages.

V. MESSAGER. – Coacher une équipe agile.

N°13414, 2012, 324 pages.

V. MESSAGER. – Gestion de projet agile (3e édition). Vers les méthodes agiles.

N°12750, 2010, 272 pages.

P. MANGOLD. – Gestion de projet informatique.

N°11752, 2006, 120 pages.

Dans la même collection

A. LUPFER. – Gestion des risques en sécurité de l’information.

Mise en œuvre de la norme ISO 27005.

N°12593, 2010, 230 pages.

A. FERNANDEZ-TORO. – Management de la sécurité de l’information (2e édition).

Implémentation ISO 27001 et 27002 – Mise en place d’un SMSI et audit de certification.

N°12697, 2012, 322 pages.

P. JOUFFROY. – ERP.

Méthode pratique de mise en œuvre pour PME et PMI.

N°12716, 2010, 334 pages.

F. DUFAY. – CMMI par l’exemple.

Pour une mise en place opérationnelle.

N°12687, 2010, 288 pages.

S. BORDAGE. – Conduite de projet Web (6e édition).

N°13308, 2011, 480 pages.

S. BOHNKÉ. – Moderniser son système d’information.

N°12764, 2010, 290 pages.

E. B...

Remerciements

Je tiens à remercier les confrères qui m’ont apporté leurs remarques et leurs idées, en particulier Josselin Coupard, Jean-François Goglin, Benjamin Lemoine, Dominique Lepère et Nathalie Picquet. Merci à tous mes clients, maîtres d’œuvre, maîtres d’ouvrage et utilisateurs qui, en se prêtant à des interviews ou en participant à des groupes de travail, m’ont permis d’améliorer ma démarche. Merci à Suzanne Robertson et Karl Wiegers, qui m’ont encouragé lors de l’écriture de cet ouvrage. Merci à Michel Volle, qui a écrit la préface de cet ouvrage.

Pour cette nouvelle édition, je tiens à remercier Patricia Colonnette et Florence Reyboz qui ont mis en œuvre mes conseils méthodologiques et m’ont apporté un précieux feedback.

Encore merci à Nicolas, Melina et Karin pour leurs idées fraîches et leur soutien moral.

Préface

D’après le Standish Group, les projets informatiques connaissent un taux d’échec qui ne saurait être toléré dans aucun autre domaine de l’ingénierie : de ses enquêtes, on peut retenir qu’en gros 25 % des projets échouent, 50 % aboutissent avec un délai et un coût très supérieurs à la prévision, 25 % seulement sont convenablement réussis. En cas d’échec, on entend souvent dire « c’est la faute de l’informatique », mais en fait, il convient de dire que, par principe, c’est toujours la faute du métier que le produit informatique devait outiller (maîtrise d’ouvrage, MOA). Certes, il arrive que le réalisateur du produit (maîtrise d’œuvre, MOE) soit défaillant, mais alors la MOA aurait dû prendre en temps utile des mesures pour redresser la situation. Souvent d’ailleurs, le seul tort de la MOE sera d’avoir accepté un contrat impossible, car l’ingénierie des besoins a été défaillante et le projet était donc condamné dès le départ : la MOA s’est lancée dans le projet sans savoir ce qu’elle voulait...

Guide de lecture

Cet ouvrage présente une démarche structurée d’ingénierie des exigences pour les systèmes d’information, en suivant une logique qui va des concepts généraux jusqu’aux conseils pratiques. Il a l’ambition de guider le lecteur depuis les objectifs stratégiques jusqu’à la validation finale du cahier des charges, et au-delà. Il gagne donc à être lu d’un bout à l’autre, dans l’ordre des chapitres.

La première partie décrit le métier, la démarche et les étapes préparatoires à la définition des besoins, nécessaire pour mener à bien une mission d’élaboration d’un cahier des charges.

Le chapitre 1 donne un exemple concret (bien que fictif) qui...

Quiz :
êtes-vous prêt ?

Ce test vous permettra de vous situer dans le métier du business analysis, quel que soit votre titre (consultant, analyste, AMOA, expert métier…). Pour chaque question, donnez la réponse qui vous paraît la plus juste.

Nous vous suggérons de répondre aux questions une première fois avant de lire ce livre, et de noter vos réponses. Puis une deuxième fois après l’avoir lu, de noter les réponses et de comparer les résultats.

1. Dans la constitution d’un cahier des charges, les difficultés proviennent surtout :

A. De la complexité technique.

B. Des aspects humains.

C. De la gestion des changements des exigences.

2. Pour élaborer un cahier des charges, les qualités requises sont :

A. Une bonne connaissance du domaine d’application.

B. Des bases solides en informatique.

C. La connaissance des techniques d’ingénierie des exigences.

3. Lorsque vous devez élaborer un cahier des charges, le mieux est :

A. D’utiliser tel quel un modèle de cahier des charges prédéfini.

B. D’adapter le modèle de cahier des charges à votre cas.

C. De créer un modèle spécifique de cahier des charges.

4. L’essence d’un cahier des charges est :

A. Un texte clair en français.

B. Des schémas rigoureux et lisibles.

C. Une structuration systématique et méthodique du document.

5. On vous demande d’élaborer un cahier des charges. Votre première tâche consiste à :

A. Faire préciser les objectifs.

B. Analyser le contexte.

C. Connaître les parties prenantes.

6. Dans le travail d’élaboration d’un cahier des charges, les deux qualités indispensables sont :

A. L’empathie et l’écoute.

B. La rigueur et l’organisation.

C. La créativité et l’imagination.

7. Dans le recueil des besoins, tout est dans :

A. La préparation.

B. L’écoute active.

C. Le feedback donné aux intéressés.

8. Dans l’analyse des exigences, il faut constamment surveiller :

A. La cohérence entre exigences.

B. La traçabilité des exigences.

C. La priorité entre exigences.

9. S’il ne fallait utiliser qu’un seul type de diagramme, ce serait :

A. Le diagramme de classes (ou entité-association).

B. Le diagramme d’états.

C. Le diagramme de flux.

10. Les exigences qui demandent le plus d’attention sont :

A. Les exigences fonctionnelles.

B. Les exigences non fonctionnelles.

C. Les contraintes.

Réponses au quiz

Voici les réponses au quiz précédent.

1. Dans la constitution d’un cahier des charges, les difficultés proviennent surtout…

Si vos connaissances techniques sont faibles, il se peut que A soit la bonne réponse. Mais dans la majorité des cas, les problèmes humains (réponse B) sont les plus délicats à traiter, du moins dans un premier temps. À long terme, lorsqu’il s’agit de maintenir le cahier des charges ou de faire évoluer les exigences, le suivi des modifications des exigences pose de réelles difficultés.

2. Pour élaborer un cahier des charges, les qualités requises sont…

Une bonne connaissance du domaine d’application (réponse A) est indispensable, et des bases solides en informatique (réponse B) sont fort utiles. La connaissance des techniques d’ingénierie des exigences est aussi importante que les deux autres qualités, mais est très souvent négligée.

3. Lorsque vous devez élaborer un cahier des charges, le mieux est…

Si un modèle de cahier des charges prédéfini est bien adapté au contexte et aux objectifs, il n’y a pas de raison de s’en priver. Sinon, il faudra adapter le modèle de cahier des charges à votre cas (réponse B), en essayant de garder un maximum de cohérence. Il est rare de devoir créer un modèle spécifique de cahier des charges. Même dans ce dernier cas, on combinera des modèles existants.

Cela va sans dire, il vaut mieux investir du temps à adapter un modèle existant qu’à « réinventer la poudre ».

4. L’essence d’un cahier des charges est…

Tout dépend du domaine d’application, de la réponse recherchée (choix de progiciel ou développement spécifique). Mais on oublie trop souvent que la langue naturelle est une merveilleuse invention et un outil de spécification universel.

5. On vous demande d’élaborer un cahier des charges. Votre première tâche consiste à…

Sans objectif, vous n’irez pas loin. La réponse A est donc a priori la correcte. Mais qui va vous donner l’objectif ? Celui qui finance, celui qui décide ou celui qui réceptionne le produit ? Et comment allez-vous interpréter cet objectif en termes opérationnels ? D’où la nécessité d’analyser des parties prenantes et le contexte. Les trois tâches sont donc imbriquées.

6. Dans le travail d’élaboration d’un cahier des charges, les deux qualités indispensables sont…

… les vôtres ! Là aussi, il n’y a pas de meilleure réponse. Si chez vous certaines qualités sont nettement prédominantes, utilisez-les, bien sûr, et essayez aussi de cultiver les autres.

7. Dans le recueil des besoins, tout est dans…

Les trois réponses sont les bonnes, bien sûr. La préparation méthodique et systématique tient une place importante dans cet ouvrage. Elle vous fera gagner énormément de temps et vous évitera de disperser votre énergie et celle des participants. L’écoute est un don du ciel, le meilleur outil de l’analyste, qu’il faut toujours cultiver. Le feedback donné aux intéressés est une bonne pratique qui contribue à l’efficacité et à la fiabilité de l’activité de recueil que vous pouvez tout de suite mettre en application, à tous les niveaux.

8. Dans l’analyse des exigences, il faut constamment surveiller…

… à vous de deviner la réponse (vous vous en doutiez maintenant) ! Pour savoir ce qu’il faut surveiller, il suffit d’imaginer ce qui se passerait si vous ne le surveilliez pas !

9. S’il ne fallait utiliser qu’un seul type de diagramme, ce serait…

Un diagramme n’est pas une fin en soi, c’est un mode d’expression. Il s’agit d’être le plus clair et précis possible pour ceux qui vont vous lire. Ce que vous devez exprimer dépend de vos objectifs, du contexte, des parties prenantes, du domaine d’application et du niveau de détail exigé.

10. Les exigences les plus importantes à spécifier sont…

Toutes, bien sûr ! La seule chose que l’on peut dire est que les exigences non fonctionnelles sont difficiles à écrire et beaucoup trop souvent négligées. Pour les contraintes, cela est très dépendant du type de prestations que l’on attend du fournisseur.

Méthodologie

L’ingénierie des exigences consiste, dans une large mesure, à créer des modèles abstraits à partir d’un relevé de faits généralement beaucoup plus concrets, puis à les présenter de manière claire, structurée et intelligible par tous les acteurs, donc dans un langage souvent différent de celui de départ. La capacité à effectuer des voyages aller-retour dans l’abstraction, à élaborer des modèles, tout en restant proche du métier de ses interlocuteurs, constitue la principale difficulté, mais aussi tout l’attrait du métier d’analyste des exigences. Pour exercer ce métier et mener à bien les missions qui lui sont confiées, celui-ci va faire appel à ses compétences et à son savoir-faire acquis par l’expérience, ainsi qu’à une démarche rigoureuse.

Dans cette partie, nous allons introduire, puis définir précisément, les notions de besoin et d’exigence, les enjeux d’une bonne définition des besoins, les compétences nécessaires à ce travail de définition, et sa position dans le cycle de vie du logiciel.

L’efficacité de ces activités dépend dans une large mesure du soin apporté à leur préparation. Celle-ci comprend les activités de planification, inhérentes à tout projet, et que nous allons détailler pour le cas particulier du développement des exigences.

La préparation comprend également la détermination précise des objectifs, du champ de l’étude et des parties prenantes. Ces trois activités, auxquelles nous consacrons un chapitre, sont cruciales.

La méthode en action

Dans ce chapitre, nous allons tenter d’introduire à la fois le vocabulaire, la problématique et les concepts. La situation prise comme exemple est fictive, mais présente toutes les difficultés auxquelles est confronté un analyste ou assistant à maîtrise d’ouvrage au cours de sa mission. Ces difficultés rendent nécessaire une approche organisée et systématique, appelée ingénierie des exigences.

Un exemple imaginaire, mais concret

Supposons que la direction du marketing d’un constructeur automobile envisage de mettre sur le marché un nouveau véhicule révolutionnaire, équipé d’un pilote automatique. Plus rien à faire pour le conducteur, ou alors si peu… Supposons que nous sommes à la tête d’une équipe chargée de spécifier¹ ce que le système de pilotage automatique doit faire, doit être ou doit avoir pour être opérationnel. Supposons que nous-mêmes ne connaissons rien, ou presque rien, à la mécanique automobile, ni même aux systèmes embarqués dans les véhicules, domaines réservés des techniciens et ingénieurs. Notre challenge est de définir les besoins et de les spécifier sous forme d’exigences.

L’analyste

Le métier de la définition des besoins est désigné en anglais par requirements analyst ou business analyst. En français, on parle d’analyste, d’analyste métier, de consultant métier, parfois d’analyste des exigences, et très souvent de consultant assistant à la maîtrise d’ouvrage. Dans la suite de cet ouvrage, nous utiliserons indifféremment ces termes.

Pour nous, la direction du marketing est le maître d’ouvrage opérationnel. Les techniciens et ingénieurs sont le maître d’œuvre. La direction générale, nécessairement impliquée dans un projet d’une telle envergure, est le maître d’ouvrage stratégique. Le document que nous allons produire, et qui s’adressera à l’ensemble de ces acteurs, appelés parties prenantes, s’appelle cahier des charges.

L’analyse de l’existant

La première tâche à laquelle nous allons nous atteler consiste...

Les enjeux d’une bonne définition des besoins

Le cahier des charges est un document constitué d’un ensemble structuré d’exigences, transmis d’un client à un fournisseur, et qui a un caractère contractuel. Comme nous le verrons tout au long de cet ouvrage, son élaboration est un travail collectif nécessitant la collaboration de nombreux acteurs. Le processus de cette élaboration est aussi important que le document qui en résulte.

L’utilité d’un cahier des charges

Un bon cahier des charges est un document clair, facile à lire et à comprendre par les différents acteurs, qui a été établi sur la base d’un consensus. Étant donnée la complexité de certaines situations que ce document représente, il peut être très complexe, mais il n’est jamais « compliqué » : c’est un document relativement facile à maintenir et à modifier.

Ce document, élaboré de manière participative, définissant clairement les exigences d’un client vis-à-vis d’un fournisseur, sera utile au choix, à la conception, à la réalisation, au paramétrage d’une application ou d’un système informatique, ainsi qu’à sa mise en œuvre opérationnelle, sa maintenance et son exploitation.

Un investissement

...

Compétences et savoir-faire

Élaborer un cahier des charges exige de solides connaissances techniques et méthodologiques, ainsi que des qualités humaines. Pour cette raison, il n’y a pas un parcours type pour devenir analyste des exigences. On trouve dans ce métier des anciens utilisateurs de produit, des ex-développeurs, des experts du domaine d’application. L’analyste doit apprendre, puis maîtriser, les techniques de l’ingénierie des besoins. C’est un animateur, un négociateur, un interprète qui va écouter les besoins des futurs utilisateurs et les reformuler dans un langage clair (figure 3-1).

Figure 3-1 : Les compétences de l’analyste

Le savoir

La connaissance du métier du client

Sans être un expert, l’analyste doit être familiarisé avec le métier de son client. En fonction des domaines d’activité, du niveau de détails attendu et du type d’application, cette connaissance se doit d’être plus ou moins approfondie.

Très souvent, l’expertise est chez le client. Sans être expert, l’analyste doit être capable de faire appel aux experts, de comprendre leur langage, de se plonger dans leurs procédures, d’analyser leurs processus ; en d’autres termes, de connaître leur métier sans pour autant le pratiquer.

La connaissance des techniques de modélisation

La représentation graphique des processus, des procédures, des données, des traitements sont souvent nécessaires, lorsque le langage écrit ne suffit pas ou manque de précision. Dans un...

Exigences et cycle de vie du logiciel

Dans ce chapitre, nous allons situer les activités de l’ingénierie des exigences dans le cycle de vie du logiciel. Cela va nous permettre de prendre la mesure de l’importance de ces activités, et de mieux comprendre les rôles et responsabilités des différents acteurs, ainsi que ceux du maître d’œuvre, du maître d’ouvrage, et de l’analyste et de leurs engagements réciproques.

Le cycle de vie du logiciel

Il existe plusieurs façons de représenter le cycle de vie du logiciel. Le terme de cycle est d’ailleurs souvent utilisé abusivement. Voici un modèle de cycle de vie en huit phases (source : IEEE Std 982.2-1988) :

• Objectifs et concepts : définition des objectifs du produit à construire, et première vision du logiciel.

• Exigences : recueil, analyse et formalisation des besoins, élaboration du cahier des charges.

• Conception : spécifications détaillées fonctionnelles et techniques, en...

La démarche

Pour être efficace, la définition des exigences doit devenir une activité systématique et organisée, faisant appel à des acteurs dont les relations sont formalisées ; en d’autres termes, une activité d’ingénierie. Dans le chapitre précédent, nous avons vu comment cette activité s’insère dans le cycle de vie du logiciel. Nous allons maintenant rentrer un peu plus dans le détail et décrire globalement le processus de développement des exigences.

Décrire, documenter, communiquer

Tout au long de cet ouvrage, nous décrivons des techniques qui, regroupées, s’appellent ingénierie des besoins ou ingénierie des exigences. Voilà une belle expression, mais dans quelle mesure le terme d’ingénierie est-il justifié ?

Recueillir, analyser, spécifier les besoins sont en grande partie des actions de description. Il s’agit de décrire un besoin en le formulant pour la première fois, en le reformulant différemment, de manière plus claire, plus constructive, plus cohérente ; en le montrant sous différents angles, comme un dessin d’architecte montre un bâtiment selon des vues différentes ; en le formulant dans un langage que tous (en tout cas tous ceux qui ont besoin de cette description), comprennent et interprètent de la...

Définir le concept et les objectifs

Cette étape préalable de définition du concept et des objectifs est cruciale pour la suite. C’est un miniprocessus de définition des exigences, en plus dense, plus rapide, et au plus haut niveau. Son livrable est une sorte de cahier des charges en concentré. Il conditionne la réussite du projet. Elle doit donc être menée avec le plus grand soin.

Une activité préalable indispensable

La première activité à laquelle doit s’attaquer l’équipe en charge de définir les besoins consiste à définir le concept et ses objectifs du produit, les objectifs du cahier des charges lui-même, ainsi que les exigences au plus haut niveau. Ces tâches seront menées en parallèle, car elles sont pratiquement indissociables. En effet, elles permettent de répondre aux quatre questions suivantes :

• Concept du produit : en quoi consistera le produit ? De quoi sera-t-il fait ? En quoi se distinguera-t-il des produits existants, qu’ils soient concurrents ou complémentaires ?

• Objectifs du produit : quelle utilisation sera faite du produit ? Dans quel but ? Pour servir qui ? Pour servir à quoi ? Pour gagner quoi ?

• Objectifs du cahier des charges : que veut-on faire du cahier des charges ? Choisir un produit sur étagère, développer une application spécifique, acquérir un progiciel, le paramétrer et le déployer ?

• Exigences au plus haut niveau : quelles sont les quatre ou cinq grandes fonctions que le produit doit remplir ? Quelles sont les deux ou trois exigences non fonctionnelles (qualité, performance) auxquelles le produit doit répondre en priorité ? Quelles seront éventuellement les contraintes techniques incontournables ?

Cette étape fait déjà appel aux techniques classiques de recueil, d’analyse, de spécification et de validation des exigences, mais étant donné son caractère stratégique, nous décrivons ces techniques spécifiquement adaptées à cette étape préparatoire...

Planifier le projet d’élaboration

Élaborer un cahier des charges est un projet en soi. Dans ce cadre, il nécessite une véritable planification. Après avoir défini les parties prenantes, le champ et l’objectif, nous avons en main tous les éléments pour élaborer le plan projet. Celui-ci consiste à déterminer les techniques, méthodes et outils à mettre en œuvre pour mener à bien le projet d’élaboration du cahier des charges, avec un maximum d’efficacité pour un minimum d’effort. Le livrable de cette étape préalable est un plan projet.

Le plan projet

Ce document vient en complément du document de cadrage et sert de feuille de route à l’équipe d’élaboration du cahier des charges. L’ensemble forme le « cahier des charges du projet de cahiers des charges ».

Le plan projet contient un devis estimatif des coûts et délais, ainsi qu’une description brève (une ou deux pages) de l’organisation et de la méthode de travail : taille de l’équipe, moyens à mettre en œuvre, formations à prévoir, circuit de l’information, fréquence des réunions, validation des documents, en fonction d’un certain nombre de paramètres...

Développement des exigences

Le projet d’élaboration du cahier des charges étant préparé et planifié, nous abordons maintenant le cœur de notre métier : le développement des exigences proprement dit. Nous décrivons les techniques et méthodes qui vont nous permettre, en partant des objectifs, de valider un cahier des charges, en optimisant les coûts, les délais et la qualité.

Souvenons-nous cependant que le processus est itératif, et que les résultats des étapes préparatoires ne sont jamais gravés dans le marbre. La planification initiale peut être remise en cause, comme pour tout projet. L’objectif et le périmètre peuvent varier. Des parties prenantes restées dans l’ombre peuvent toujours se manifester. Aussi est-il important, tout en gardant l’objectif en tête, de rester toujours à l’écoute des différents acteurs.

L’étape de recueil

De toutes les activités de l’ingénierie des exigences, l’activité de recueil est celle qui demande le plus de qualités humaines. Il faut trouver la personne qui détient l’information, l’encourager à exprimer, puis écouter ce qu’elle a à dire, avec neutralité et bienveillance. Il faut animer des groupes de travail où des tensions entre individus peuvent apparaître. Raison de plus pour bien préparer cette étape, en laisser le moins de choses possibles au hasard.

L’enjeu

Capturer les besoins est a priori chose simple et facile. Il suffit de se réunir avec les futurs utilisateurs, interviewer le client, ou compulser normes et standards pour recueillir les besoins à la source. La réalité est bien loin d’être aussi si simple. À moins de vouloir faire développer une petite application simple pour une demi-douzaine d’utilisateurs (et encore…), on se trouve vite confronté à des difficultés diverses : résistances, contradictions, guerres des clans, dissensions.

Mais plus concrètement, demandez à un futur utilisateur du système d’exprimer ses besoins. Posez-lui la question « Quel est le besoin ? » Spontanément, il exprimera, selon le cas :

• un problème ou une difficulté à laquelle il est confronté ;

• une solution (plus précisément sa solution) à ce problème ;

• la manière dont cette solution sera mise en œuvre ;

• un vrai besoin, c’est-à-dire une fonction attendue du futur système.

Autrement dit, dans la majorité des cas, l’utilisateur interviewé n’exprimera pas spontanément un besoin. Quelle est donc la « bonne technique » à employer pour recueillir les besoins ? Comment aider le futur utilisateur à s’exprimer ? Comment éviter que les réunions de travail ne s’éternisent, ou ne se transforment en pugilat verbal ? Il n’y a pas de recette miracle, mais des outils et des techniques. Le reste est affaire d’expérience et d’habileté, pour choisir le bon outil et l’utiliser à bon escient. Voici donc quelques techniques et outils, ainsi que des conseils d’utilisation.

Le processus de recueil

Il n’y a pas de plan type de l’étape de recueil, avec un enchaînement immuable de tâches prédéfinies. Les techniques pour recueillir les exigences sont nombreuses et très variées, et le choix de telle ou telle technique dépend du contexte, de l’existant et des contraintes : la disponibilité des personnes et leur niveau d’expertise, les documents pouvant être consultés, la possibilité d’observer sur le terrain les pratiques existantes ou des systèmes analogues à celui à l’étude. Mais comme avec les autres étapes, la planification et la vérification jouent un rôle important.

Figure 8-1 : Le processus de recueil

Planifier le recueil des besoins

C’est à partir de la liste des sources d’exigences et du tableau des parties prenantes que l’on va planifier dans le temps le recueil des besoins, et prévoir les ressources (humaines et matérielles) et la logistique. Cette planification doit être souple, car le volume et la qualité des informations que l’on va recueillir ne sont pas précisément connus à l’avance.

Rappelons que l’étape de recueil, en pratique, n’est pas isolée des autres. L’analyse, la spécification, et une grande partie de la validation des besoins se déroulent en parallèle avec le recueil. C’est une raison supplémentaire pour planifier soigneusement les interviews des différentes parties prenantes, et surtout les réunions des groupes de travail. Il faut souvent une semaine pour obtenir un rendez-vous, et plus d’un mois pour réunir un groupe de travail. La lecture des documents est évidemment plus simple à planifier, mais peut être longue.

Et surtout, ne pas oublier de « prévoir l’imprévu ». Des réunions supplémentaires sont souvent nécessaires pour éclaircir des points obscurs.

Préparer les grilles et les outils

En fonction des buts visés (développement de logiciel, ou choix d’un progiciel, par exemple), de la granularité à atteindre, des personnes à interviewer, on préparera des guides d’entretien ou de réunion.

Une partie des grilles d’interview ou des thèmes des groupes de travail devra être formalisée et envoyée par avance aux participants.

Pour recueillir des besoins à partir de documents écrits, il est également intéressant de se munir de grilles de lecture pour éviter d’être submergé par la masse de documents. La quantité d’informations à traiter peut rendre l’opération de recueil complexe, en particulier si l’on veut garder la traçabilité des exigences aux étapes suivantes.

Le principe de la construction d’une grille est simple. Il consiste à partir de l’objectif pour découvrir les exigences qui en découlent, et des exigences déjà exprimées pour découvrir les exigences plus détaillées. Nous verrons plus loin la mise en application de ce principe.

Recueillir et documenter les besoins

Il existe une multitude de techniques de recueil des besoins, plus ou moins complexes et consommatrices de temps et de ressources. Elles sont décrites dans la suite de ce chapitre.

Quelle que soit la technique choisie, l’information recueillie doit être soigneusement répertoriée et stockée en vue d’une analyse et d’une spécification ultérieures. Cela est vrai même si recueil, analyse et spécification ont lieu au cours d’une même réunion d’un groupe de travail.

Une des difficultés découle de la surabondance des informations recueillies, et ce, quelle que soit la...

Les cas d’utilisation

Les cas d’utilisation (use cases en anglais) sont devenus célèbres grâce, en particulier, à UML (Unified Modeling Language). Cependant, les adeptes d’UML utilisent le plus souvent les diagrammes de cas d’utilisation, ce qui est un peu réducteur. Les cas d’utilisation sous forme textuelle offrent, eux, une grande richesse d’expression.

Qu’est-ce qu’un cas d’utilisation ?

Un cas d’utilisation est un contrat de comportement, entre un système (par exemple, un logiciel) ou un sous-système et des acteurs qui interagissent avec lui. Ces acteurs peuvent être des utilisateurs (humains) du système ou des systèmes voisins.

Un cas d’utilisation regroupe un ensemble de scénarios (figure 9-1) qui peuvent, soit aboutir, soit échouer. Pour formuler un cas d’utilisation, on doit respecter les contraintes suivantes :

• Un cas d’utilisation se rapporte à un objectif et un seul.

• Il décrit un comportement utile à l’atteinte de cet objectif.

• La description prend le point de vue d’une (ou plusieurs) partie(s) prenante(s).

• Il comporte un acteur principal et un seul.

• Il débute avec un événement déclencheur.

• Il se poursuit jusqu’à ce que l’objectif soit atteint ou abandonné.

Figure 9-1 : Scénario de cas d’utilisation

Le contenu d’un cas d’utilisation

Un cas d’utilisation s’exprime essentiellement sous forme textuelle. Les différents items qui le composent varient selon les auteurs¹, le type d’application, le degré de précision que l’on veut atteindre grâce aux spécifications. Voici une structuration assez classique :

...