Rédaction d'un document Cahier des Charges

Comment rédiger un Cahier des Charges

Pour rédiger un document cahier des charges d'un projet logiciel ou autre, nous proposons cette template qui pourrait servir éventuellement comme guide. Il s'agit de définir successivement les points suivants : Contexte et définition du projet, Objectifs, Scope, Parties Prenantes, Description des besoins à répartir entre les besoins fonctionnels et non fonctionnels.

Contexte et définition du problème

Dans cette rubrique, vous allez définir le problème pour bien clarifier la finalité du travail. Il est important de souligner aussi les besoins ainsi que les contraintes et ce de manière très sommaire. Par exemple, vous pouvez exposer la situation actuelle ou futur de votre système tout en mettant l’accent sur les problèmes auxquels vous voulez faire face.

Objectifs

Après avoir exposé le problème dans la première partie, ici vous allez exprimer quelles sont les attentes et les résultats escomptés. Normalement ces attentes et résultats (objectifs du projet) doivent être quantifiables. Par exemple vous voudriez passer d’un taux d’utilisation de 40 à 70%. Cela va vous permettre après de savoir si vous avez bien atteint les objectifs ou non.

Périmètre

Le périmètre (scope) d’un projet veut dire les limites que vous allez donner à votre projet. Vous pouvez par exemple à ce niveau bien identifier votre cible (target), est-ce que votre projet concerne les jeunes ou bien il est dédié uniquement aux enfants. Vous pouvez aussi souligner le type de plateforme (web, mobile, cloud etc). Un périmètre qui est bien défini va vous aider par après pour ne pas déborder sur les objectifs du projet et de se contenter uniquement du travail demandé.

Parties prenantes

Les parties prenantes (stakeholders) concernent toutes les parties qui ont un intérêt de près (direct) ou de loin (indirect) dans la réalisation de votre projet. Par exemple, si vous avez à réaliser une application de gestion de paiement de caisse au niveau d’un super marché, et que cette application va comptabiliser les ventes effectuées par les vendeurs à l’intérieur du super marché, alors les parties prenantes dans ce cas vont être : le caissier, le vendeur, le manager, etc. Il est important de connaître ses parties prenantes vu qu’ils va falloir les impliquer lors du recensement des besoins et donc lors de l’évaluation de votre projet.

Description des besoins

En principe on distingue deux types de besoins. Les besoins fonctionnels et les besoins non fonctionnels. On peut ajouter à cela les besoins d’ordre techniques (type de technologie utilisé, etc).

Besoins fonctionnels

Les besoins fonctionnels concernent tous les besoins recensés soit par le client, les utilisateurs ou par les parties prenantes. Ces besoins ont un rapport direct avec le métier (business). Si par exemple votre projet consiste à réaliser une application mobile pour la gestion du courrier électronique, alors un besoin fonctionnel pourrait être : envoyer un email.

Tous les besoins fonctionnels doivent être listés à ce niveau là en respectant par exemple la template suivante pour chacun de ces besoins :

• Objectif
• Description
• Contraintes/règles de gestion
• Priorité

Besoins non fonctionnels

Un besoin non fonctionnel n’est pas lié directement au métier. Il est plutôt lié aux normes de qualité en vigueur et aussi aux contraintes de réalisation. Par exemple, pour une application web, un besoin non fonctionnel pourrait être le temps de réponse d’une page web ne doit pas dépasser cinq secondes. Les besoins non fonctionnels en général sont définis comme étant des besoins de qualité. Ainsi, on peut avoir des besoins en terme de fiabilité, de robustness, de stabilité, etc. S’ils sont exprimés dans un document cahier des charges, c’est que on doit les prendre en considération lors de la réalisation de notre projet.

Voilà, j'espère que cela va pouvoir vous aider dans vos futurs travaux de rédaction de cahier des charges.