L’état des lieux

Tous les outils UML pouvant nous servir à identifier et à formaliser les besoins ont été vus. UML permet de formaliser les attentes à l’égard d’un nouveau système. Ces outils permettent une ingénierie complète de ces besoins, prélude à la construction du système destiné à les satisfaire.

Tous les outils nécessaires ne figurent pas nécessairement dans la panoplie UML. Par exemple, UML ne prévoit rien pour le référentiel des règles de gestion, qu’il faudra organiser à l’aide d’une feuille Excel ou d’une base Access. Certains modeleurs UML offrent des extensions aptes à intégrer les règles de gestion au projet ; mais ce n’est pas une capacité native d’UML.

Quel que soit le processus projet (cycle en V, incrémental, agile, itératif), il convient de prendre en compte l’ensemble du cycle de vie du livrable. Cela signifie que l’équipe projet fournit non seulement un livrable à déployer, mais surtout un ensemble de services aux acquéreurs, et donc que le déploiement après recette ne libère pas la DSI de toute responsabilité. Elle doit piloter la maintenance, et pour cela elle doit avoir en main la documentation qui a accompagné la construction...

La notion de cahier des charges fonctionnel (CdCF) ?

1. Définition

La norme NF X 50-151 propose la définition suivante : « Le cahier des charges fonctionnel est le document par lequel le demandeur exprime ses besoins (ou ceux qu’il a la charge d’exprimer) en termes de fonctions de service et de contraintes. Pour chacune d’elles sont définis des critères d’appréciation ainsi que leurs niveaux, chacun d’entre eux étant assorti d’un certain degré de flexibilité. » (Cité par Jacques Bernard-Bouissières, dans : Expression du besoin et cahier des charges fonctionnel, AFNOR Editions 2008.).

On retrouve dans cette définition le terme central de « fonction de service ». La même norme définit cette notion comme étant une « action demandée à un produit ou réalisée par lui, afin de satisfaire une partie du besoin d’un utilisateur donné » (Jacques Bernard-Bouissières, op. cit.).

Cette définition n’impose rien quant à la méthode de pilotage du projet qui sera employée, et elle est tout à fait compatible aussi bien avec les cycles en V qu’itératifs ou agiles. La vraie question est plutôt : un document formalisant les besoins est-il disponible et accessible aux équipes du projet, puis aux équipes de maintenance et d’architecture ?

Si le projet suit un cycle itératif, le CdCF sera construit au fur et à mesure de l’avancée du projet ; donc son cycle de rédaction sera itératif. Si le cycle est traditionnellement en V, le CdCF sera d’abord produit, avant que la conception et la réalisation puissent être lancées.

Donc le CdCF s’insère complètement dans le cycle du projet ; il n’est un obstacle à aucun cycle et demander de produire un CdCF n’impose ni ne contraint le mode de travail de l’équipe du projet.

Le CdCF peut-il être exhaustif ? La cohérence, la complétude du cahier des charges dépendent :

de la capacité à capturer puis à gérer les exigences formulées par les utilisateurs ;
de la stabilité de ces exigences.

Qui peut...

Le plan-type proposé par la norme ISO

Le plan-type ci-après est proposé par Jacques Bernard-Bouissières ; il est proche de la version ISO. Son volume restreint le rend adapté aux situations d’urgence.

1. Les chapitres du CdCF

Chapitre du CdCF			Contenu
1	Objet du document		Rappels de l’objet du CdCF, de son rôle dans le projet.
2	Documentation, terminologie
	21	Références documentaires	Citer les normes internes à l’entreprise, ainsi que les documents d’urbanisme, d’architecture, les règles de mise en production, etc.
	22	Terminologie	Glossaire de l’entreprise, glossaire du projet.
3	Contexte ; motivation de l’action		Énumérer les défauts de l’existant, ses insuffisances, les contraintes réglementaires.
4	Rôle et utilisation
	41	Les besoins et leur justification	Ce chapitre reprend les exigences, les fonctions de service et les processus.
	42	Les acteurs	Utilisateurs primaires, secondaires, administrateurs, exploitants, aide en ligne.
	43	Le cycle de vie de la solution	Énumérer les principaux contextes d’utilisation de la future solution.
5	Description fonctionnelle
	51	Les fonctions de service	Énumérer les fonctions attendues par l’ensemble des acteurs.
	52	La relation entre fonction et situation de service	En pratique, sans objet dans...

Le cahier des charges dans le cycle en V et les cycles agiles

1. Le cycle en V : exposer le problème, puis le résoudre

a. Le cahier des charges, un référentiel accompagnant le produit toute sa vie

Au cours du traditionnel cycle en V (qui concerne toujours un nombre important de projets), les équipes ne construisent qu’après la remise d’un cahier des charges, validé et considéré comme clos, du moins à 80 %.

On a donc clairement les deux phases bien individualisées : l’analyse, dont le produit en sortie est le cahier des charges fonctionnel, et la construction, elle-même partagée entre la conception (l’ingénierie de la solution) et la réalisation (la production du code). Puis les tests d’assemblage et d’intégration sont menés, et une fois la recette prononcée, le produit est déployé et mis en production.

Le chapitre Les impacts d’UML sur la recette d’un livrable examine comment UML peut rendre service à l’élaboration des tests.

Lors de la phase de maintien en condition opérationnelle (maintenance évolutive et corrective), le CdCF sert de référentiel des services rendus par le produit. En principe, l’évolution du produit se mène en parallèle avec la mise à jour du CdCF. La rédaction de ce document expliquant l’architecture interne du produit, sa maintenance s’en trouve facilitée.

Conserver la synchronisation de la documentation de la fourniture avec sa maintenance est très difficile : de ce fait, elle est rarement assurée, ce qui accélère son obsolescence. Les maintenances du produit qui ne sont pas tracées par une évolution du CdCF initial se traduisent par une perte de qualité et peuvent à terme induire des coûts faramineux.

Les référentiels de gestion de projet (IPMA, PMI) conseillent de consacrer 20 % de la charge à l’administration et au pilotage du projet. Le maintien du CdCF en fait partie.

b. Le cahier des charges, un référentiel à deux étages

Certains auteurs proposent la rédaction du cahier des charges en deux étapes :

la lettre de mission (ou note de cadrage, ou kick-off) concrétise le lancement...

Livré mais toujours sous responsabilité

La livraison du produit ne le sort pas de la responsabilité de ses créateurs. Une fois livré, le produit entre en phase de maintenance (corrective et évolutive) et cette phase est grandement facilitée si un CdCF rend compte de tous les aspects de ce produit.

L’enjeu est le suivant : toute correction, toute extension des fonctionnalités peu à peu opacifient le code et rendent l’architecture du logiciel de moins en moins visible. Et donc accélèrent son entrée en sénescence. Des indicateurs peuvent le montrer : par exemple, dans certains contextes industriels sensibles, on mesure périodiquement le temps moyen entre les pannes d’une solution (le MTBF, Mean Time Between Failure) et on surveille son évolution.

Figure 3 : Évolution du MTBF d’un produit logiciel de « bonne qualité » en fonction du temps

Plus le MTBF est élevé, meilleures sont la qualité du produit et la fiabilité de son fonctionnement.

En période dite de jeunesse, le produit livré présente des défauts. Même si la recette a été prononcée, le produit présente des écarts avec ce qui a été spécifié dans le CdCF.

Les erreurs logicielles étant corrigées peu à peu, le MTBF...

Pour aller plus loin

Le sujet du cahier des charges qui a inspiré une foule de publications est considéré comme majeur par les responsables de projets. Le cadre de cet ouvrage ne permet pas de le traiter de manière plus approfondie.

Plusieurs sites Internet sont consacrés à la gestion de projet. Les référentiels internationaux (Project Management Institute, International Projet Management Association, PRINCE2...) sont de plus en plus invoqués et mis en œuvre ; ils proposent des certifications appréciées par les entreprises. Dans certains cas, elles sont obligatoires.

Le site http://cahier-des-charges.net propose un ensemble de modèles de cahiers des charges.

Pour en savoir plus sur la méthode APTE, rendez-vous sur http://methode-apte.fr/methode_apte.

Quelques ouvrages très utiles :

Jacques Bernard-Bouissières, Expression du besoin et cahier des charges fonctionnel, éditions AFNOR.

Jean-Louis Foucard, La boîte à outils du pilote des systèmes d’information, Dunod.

Chantal Morley, Management d’un projet système d’information, Dunod.

Kathleen B. Hass, L’analyse d’entreprise : une discipline qui se professionnalise, Mark International.

Rédiger le cahier des charges fonctionnel d'un projet