Rédiger correctement un Cahier des Charges

Non, ne vous en faites pas, ce n'est pas une secte.
C'est en fait le nom correct de "Cahier des Charges". CDCF signifie Cahier des Charges Fonctionnel.

À quoi sert un CDCF ?

Le CDCF est un document utilisé par les entreprises pour savoir ce que devra ou non faire un produit. Toutes les entreprises utilisent un CDCF pour tous les produits qu'elles conçoivent (que ce soit un stylo ou le nouveau satellite de la NASA).
Il sert aussi à certains particuliers (comme vous...) qui ont des projets de développement et de conception d'objets / de programmes / de sites web.

Que mettre dans un CDCF ?

Dans un CDCF, on intègre toutes les informations nécessaires pour savoir ce que doit faire ou non un produit, ainsi que ses caractéristiques (forme, poids, couleur(s), dimensions, ...).
Par exemple, dans le cas d'un stylo, on met tout ce qu'il doit pouvoir faire.
Dans le cas d'une voiture, on met tout ce que doit savoir faire la voiture.

Le CDCF est un document court (environ une page), qui doit être concis et complet (il ne faut oublier aucune information, car dans certains cas, cela peut se révéler catastrophique : imaginez que l'on oublie, dans le cas d'une voiture, combien de chevaux aura le moteur !!).

En plus de ce que doit savoir faire ou non le produit, on peut ajouter le prix final (dans le cas où le produit est à vendre), les normes auxquelles répond le produit, etc.


En fait, les entreprises se sont fixé des règles très précises et strictes sur la façon dont doivent être rédigés leurs documents. Toutes ces règles sont régies par l'AFNOR .



Le CDCF doit être obligatoirement respecté : c'est sur ce document que se basera toute la conception et toute la fabrication.

Qu'est-ce qu'il ne faut pas mettre dans un CDCF ?

Il ne faut pas mettre de solutions de conception.
Par exemple, si le CDCF d'un stylo dit qu'il faut que ce stylo soit rechargeable, il ne dira pas comment faire pour que le stylo soit rechargeable, mais uniquement qu'il faut qu'il le soit.
Si on développe une alarme qui doit réagir au mouvement, on dit dans le CDCF : "L'alarme devra s'enclencher en cas de mouvement", mais on ne dit pas : "L'alarme devra s'enclencher en cas de mouvement." En cas de mouvement, une bille envoie un signal à l'interrupteur et ferme le circuit électrique, ce qui provoque un signal sonore."

Toute la partie en italique ne devrait pas figurer sur le CDCF, car ce sont des solutions. Comme je l'ai déjà dit, il ne faut jamais proposer de solutions de conception dans un CDCF.



La première raison, c'est que ce n'est pas sa place... On réfléchit à la conception après avoir décrit le produit et son utilité.
Il y a aussi des raisons de sécurité : imaginez qu'une entreprise ait pour idée de développer un télé-porteur (pour ceux qui ne sont pas sûrs, le télé-porteur n'existe pas encore ), et qu'elle écrive dans son CDCF des solutions de conception... Comme un CDCF est édité un grand nombre de fois (suffisamment pour que toutes les équipes du projet puissent en avoir un exemplaire), le concept pourrait être "volé", et par conséquent reproduit...
Il faut aussi se dire que trouver toutes les caractéristiques d'un objet non encore inventé représente suffisamment de travail pour ne pas, en plus, devoir trouver comment le faire fonctionner.

Pour aller plus loin

Comme vous le voyez, dans cette partie, je ne fais qu'effleurer le sujet (sinon, il faudrait presque un big-tuto).

Si vous souhaitez aller plus loin dans le sujet, je vous conseille deux articles de Wikipédia :

• Cahier des Charges
;
• Cahier des charges Fonctionnel
.

Le premier lien est particulièrement riche d'un point de vue juridique et commercial, ce qui vous sera utile si vous réalisez vos projets dans un cadre professionnel.
Le second est beaucoup plus axé méthodologie, et parle notamment des normes.

Contraintes et objectifs

Tous les objets créés le sont parce qu'ils sont utiles (enfin, normalement).
Pour être utiles, ils doivent répondre à des besoins.
On appelle ces besoins : des contraintes.

On doit forcément répondre à ces contraintes (sinon, le produit ne sert plus à rien) .

En plus des contraintes "causées" par le client, il y a des contraintes émanant de l'entreprise qui développe : temps, argent, matériel, ...
En effet, si un client veut un produit (un stylo, par exemple) dans deux semaines, il faut pas lui donner dans 3, sinon, ça donne des clients mécontents, et l'entreprise perd de l'argent.
De plus, une entreprise ne peut développer des objets qu'avec les moyens dont elle dispose. Elle ne peut pas créer un objet qui lui coûtera 1 million de dollars si elle n'en a "que" 700 000 ou 800 000.
Il y a aussi la contrainte du personnel.

Les entreprises indiquent ces contraintes dans le cahier des charges.


À chaque fois qu'une entreprise développe un produit, elle a un objectif (d'où le titre, d'ailleurs...). Cet objectif, la plupart du temps, c'est de gagner de l'argent.
Seulement, en fonction des objets créés, l'argent gagné ne sera pas le même... Le cahier des charges doit aussi définir l'objectif à atteindre.

Ici, nous allons voir comment rédiger un CDCF correct en programmation, avec pour exemple le langage C.

Quelques explications

Quelles sont les particularités des CDCF en programmation ?

Il y a quelques différences entre un CDCF pour un objet et un CDCF pour un programme.
En effet, un objet ne doit pas "réagir" en fonction de ce que fait l'utilisateur. Un stylo, qu'on l'utilise avec la main droite ou la main gauche, c'est pareil, alors qu'un programme, si on appuie sur Tab et si on appuie sur Espace, ce n'est pas du tout pareil.

Que mettre dans le CDCF d'un programme ?

Comme dans un CDCF "normal", il ne faut pas mettre de solution de conception, mais uniquement ce que doit pouvoir ou non faire le programme.

Il faudra lister étape par étape ce qui se passe lorsque l'utilisateur fait quelque chose (appuyer sur une touche, cliquer avec sa souris, donner un coup de marteau sur son unité centrale [dans ce cas, il faudra afficher un message d'erreur, si c'est encore possible ] ).
C'est assez long, mais si vous pensez à tout, cela simplifiera grandement votre travail au moment de coder.
Je vous conseille d'ailleurs pour cette étape de prendre une feuille d'or de papier et de faire une sorte de brouillon de votre algorithme.



C'est exactement ce que vous êtes en train de faire. C'est-à-dire le listing des différentes "réactions" de votre programme en fonction des actions des utilisateurs.
Il faut absolument penser à tout. Les évènements si vous faites de la SDL, et ce qui va se passer lorsque l'utilisateur appuiera sur Suppr alors que vous ne l'aviez pas prévu.

C'est un peu le code de votre programme, mais rédigé en français : vous ne vous souciez pas des if et des else, ou même des while; et encore moins des fonctions de votre programme !!

Si vous codez un jeu, il faudra aussi énumérer toutes les interactions possibles (débuter un dialogue, prendre un objet, tomber, sauter, acheter un objet, tuer quelqu'un, ...), et dans quelle conditions ces interactions doivent avoir lieu.

Vous pouvez aussi, si vous réalisez des fenêtres, mettre les images nécessaires ainsi que ce qu'elles représentent.

Si vous réalisez un jeu avec des personnages, vous pouvez aussi ajouter une brève présentation de ceux-ci (en indiquant leurs particularités, s'ils en ont, par exemple), s'il y a des objets, décrivez à quoi servent les objets, etc.

Vous pouvez aussi, si votre projet est particulièrement conséquent, préciser quelle quantité de RAM et de CPU le programme devra utiliser au maximum.



Indiquez aussi sur quel(s) OS votre programme devra être utilisable.

Bref, indiquez tout ce qui va vous être utile pour ne rien oublier lors du codage.

Qu'est-ce qu'il ne faut pas mettre dans notre CDCF ?

Comme dans les autres cas, il y a des informations à ne pas donner, en plus des solutions de conception.

Il ne faut pas mettre les dossiers de votre programme, ainsi que ses fonctions, car ça, on y réfléchit lors de sa conception, et non avant.
Il ne faut pas non plus mettre la taille des images ou de la fenêtre, par exemple, car ça aussi, c'est du domaine de la conception.

Actuellement, je n'ai que ces exemples d'informations à ne pas mettre dans un CDCF, mais si vous en voyez d'autres, envoyez-moi un MP.

Un exemple pour bien comprendre

Pour exemple, je vais utiliser le cahier des Charges de M@teo21 dans son TP : Mario Sokoban.

Même si vous ne programmez pas, vous pourrez comprendre cette partie, car elle ne parle que de méthodologie.

Comme vous le voyez, le CDCF est divisé en plusieurs parties :

• À propos du Sokoban :
• Le but du jeu,
• Pourquoi avoir choisi ce jeu ;
• Le Cahier des Charges ;
• Récupérer les sprites du jeu.

La première partie (à propos du Sokoban) fait un simple tour d'horizon de ce qu'est le jeu, en quoi il consiste, mais ce, sans rentrer dans les détails.
Cependant, si vous avez bien suivi le tuto, vous aurez remarqué que la sous-partie Pourquoi avoir choisi ce jeu ne rentre pas tout à fait dans la rédaction du CDCF, car on y parle de création de fichiers .c, comment, pourquoi... Cette étape fait partie de la conception, normalement.

La seconde partie parle des capacités du programme (ce qu'il pourra faire / ne pas faire). C'est la partie fon-da-men-tale (je peux écrire plus gros, si vous voulez), qu'il ne faut surtout pas rater !!

Vous devez tout dire, sans exception : si vous codez en fenêtre, listez tous les évènements possibles et leurs conséquences ; si vous êtes en console, indiquez ce qui se passe au niveau de l'affichage de l'écran.
En clair, décrivez entièrement ce que devra faire le programme une fois terminé, comme si vous codiez, sauf que vous rédigez en un français compréhensible pour le commun des mortels les personnes qui ne programment pas.
C'est assez long, et il ne faut rien oublier...


Ensuite, on parle des sprites du jeu. C'est la partie concernant les images du jeu. Cette partie n'est pas forcément indispensable si vous avez peu d'images, mais dès que vous faites des projets un peu gros, vous commencerez à avoir 40-50 images, vous serez bien contents d'avoir une courte description de chacune d'elles !

Comme vous le voyez, M@teo ne parle pas une seule fois, dans son CDCF, de la façon dont il va s'organiser, il ne fait que présenter le résultat final.
J'insiste beaucoup sur le fait que vous ne devez pas donner de solutions de conception car c'est vraiment important !!

Un conseil en plus : si votre projet est très gros, je vous conseille de mettre la description des images avant de décrire le jeu lui-même.
En effet, souvent, lorsque vous décrivez les événements (en fenêtre), ils mettent souvent des images en action. Donc, il vaut mieux savoir à quoi sert chaque image et ce qu'elle représente.
Dans l'exemple, il aurait fallu mettre la présentation des sprites avant la partie décrivant que peut / ne peut pas faire le jeu.
Cela dit, le projet n'étant pas vraiment très gros, ce n'est pas non plus trop gênant.

Ici, nous allons voir en détails ce qu'il faut mettre dans un CDCF pour une page web dynamique (avec pour exemple un script PHP).



Cela risque d'être un peu plus complexe que pour un programme, car il faudra penser à tous les liens, toutes les pages qu'on devra créer... Sans pour autant trop entrer dans les détails parce qu'on ne veut pas avoir un document de 30 pages. Si vous avez bien lu, vous vous rappellerez qu'il faut plus ou moins 1 page. Mais bon, pour du PHP, comme c'est plus chiant (et parce que suis très gentil), on va accepter jusqu'à trois pages...
Il faudra faire attention à rédiger un CDCF pour chaque "sous-partie" de votre projet : un pour le forum, un autre pour les news, un autre encore pour le livre d'or, un autre pour la gestion du staff, un autre une fois de plus pour... euh... Enfin, vous m'avez compris.

Généralités sur les CDCF en PHP

Ce qu'il faut mettre dans un CDCF en PHP

En fait, comme d'habitude, il faudra lister ce que fera le site (original, n'est-ce pas ?).
Par exemple, dans les forums, il faudra dire si les sujets seront éditables...
Mais il faudra aussi indiquer des informations supplémentaires : la façon dont cela sera fait.

Cependant - et c'est une des particularités des CDCF pour le web - il ne sert à rien d'indiquer ce que ne pourra pas faire le script. En effet, s'il se passe une chose impossible en PHP, il faut forcément afficher un message d'erreur...

C'est là que ça devient compliqué : il ne faut en aucun cas proposer des solutions de conception mais simplement détailler la façon dont sera faite l'action demandée par l'utilisateur :

• la demande devra-t-elle être accessible par lien, ou par menu déroulant, ou autrement ?
• Une fois l'action accomplie, où devra être redirigé l'utilisateur ?
• Autres questions du même genre auxquelles il faudra répondre.

Ce qu'il ne faut pas mettre dans un CDCF en PHP

J'insiste, car c'est vraiment très important : il ne faut pas donner de solutions de codage.

Si l'utilisateur doit être redirigé à l'accueil du forum après avoir posté, dites-le, mais ne dites pas comment vous allez appeler le lien qui mène vers l'index du forum.

Un bon exemple pour bien comprendre

Dans mon exemple, je vais rédiger un CDCF pour un système d'inscription :

Ce que le système devra faire

Première phase de l'inscription

Cette partie indiquera les étapes de l'inscription.

• Demander à l'utilisateur d'entrer un pseudo dans une zone de texte.
  Le pseudo devra contenir entre 3 et 25 caractères.
• Demander à l'utilisateur d'entrer un mot de passe qui devra compter entre 6 et 30 caractères, là encore dans une zone de texte.
• Demander une confirmation du mot de passe.
• Une fois les deux mots de passe entrés, l'utilisateur clique sur un bouton qui vérifie si les deux mots de passe sont les mêmes.
• Si c'est le cas, on continue l'inscription.
• Si ce n'est pas le cas, on redirige l'utilisateur vers une page d'erreur et on lui fait reprendre l'inscription du départ (oui, je sais, c'est méchant), en guise de punition.
• On demande à l'utilisateur d'entrer une adresse e-mail pour confirmer son inscription.
• On l'envoie vers la seconde page de l'inscription, en le faisant cliquer sur un lien.

Seconde phase de l'inscription



Cette partie permettra à l'utilisateur de personnaliser son interface membre.

• Demander à l'utilisateur s'il souhaite que son adresse e-mail soit visible par un système de cases à cocher. Attention, la case devra être décochée par défaut.
• Demander au membre s'il souhaite être visible dans la liste des membres. Là encore, la case devra être dêcochée par défaut.
• Faire une grande zone de texte pour permettre à l'utilisateur de se présenter.

Voilà : après, c'est à vous d'imaginer tout un tas d'options diverses et variées, mais bon, personnellement, je suis moyennement motivé pour trouver 50 possibilités du script... Et vous, vous serez moyennement motivés pour lire ces 50 propositions.



En fait, il n'y a pas d'organisation universelle, le tout étant que votre document décrive précisément ce que fait le script.

Souvent, ce que je fais, c'est une liste détaillant tout ce qui se passe au fur et à mesure que le visiteur avance dans la page.
Regardez mon exemple : j'ai détaillé étape par étape ce qui se passe au fur et à mesure de l'inscription.
Si au début, vous avez du mal à trouver une organisation bien à vous, je vous conseille de faire pareil.

Ici, nous allons explorer les mystères des CDCF pour créer un design. Vous allez souffrir.

Généralités sur le CDCF en CSS

Ce qu'il faut mettre dans un cahier des charges CSS

Voilà : comme dans les autres chapitres, nous allons voir ce qu'il faut mettre dans un CDCF pour un design. Voici ce que je fais, en général :

• la couleur des boutons (pour les liens) ;
• la couleur des textes écrits dans les boutons ;
• la couleur des liens non-boutons ;
• la couleur des boutons lorsque la souris passe dessus ;
• la couleur des textes écrits sur les boutons lorsque la souris passe dessus ;
• la couleur des liens non-boutons lorsque la souris passe dessus.

Si besoin, vous pouvez faire la même chose avec la police (un conseil : soyez fainéants, et ne le faites pas si la police ne change pas ).

Je mets aussi :

• la couleur et la police des menus ;
• la couleur et la polices des textes ;
• la couleur et la police des titres.

• La position des menus ;
• celle de la speedbarre, s'il y en a une (si vous êtes fainéants, n'en faites pas ).

• La couleur ou l'image de fond ;
• la couleur ou l'image de la banderole.

Si vous avez des images et qu'elles doivent toutes avoir la même position (ce qui doit être assez rare) , indiquez-le aussi ; et idem si vous avez des tableaux, des cadres, indiquez si les angles sont droits, arrondis, la couleur des barres, ...

Comme vous le voyez, c'est assez long, et il faut penser à tout (d'ailleurs, je suis presque sûr d'avoir oublié quelque chose, mais moi, j'ai une excuse : je veux que vous lisiez le tuto en entier) .

Encore un exemple !

Voilà, on arrive au traditionnel exemple.

Je vais rédiger le CDCF du design de la speedbarre du SdZ (sous Bluzaz2).

• La speedbarre est décollée de 5 pixels à gauche et à droite de l'écran.
• Le cadre de la speedbarre est de couleur grise claire.
• Les barres dans le sens du slash (\) sont de la même couleur que le cadre (gris).
• Le texte affichant les liens vers l'accueil, les forums, le livre d'or, l'équipe, les MP et la déconnexion sont en bleu clair.
• Si la souris passe sur les liens, on les colorie en bleu marine.
• Au moment du clic, on garde la couleur obtenue lors du passage sur les liens (donc, bleu marine).
• Les liens sont centrés dans leurs cellules, et tous précédés d'une icône :
• lien vers l'accueil : l'icône est une maison ;
• lien vers les forums : l'icône est un smiley ;
• lien vers le livre d'or : l'icône est un livre ;
• lien vers l'équipe : l'icône est le visage de Zozor ;
• lien vers les MP : l'icône est une enveloppe ;
• lien vers la déconnexion : l'icône est un portrait américain au corps rouge.
• Les textes sont d'une taille de 90 %.
• Les icônes ont des contours gris clairs (comme les liens).
• J'allais oublier : le fond de la speedbarre est en blanc.
• L'épaisseur du cadre est de 1 pixel.

P.-S. : il se peut que les noms de couleurs que j'ai écrits ne soient pas exacts, car je suis daltonien. N'hésitez pas à me corriger sur les couleurs.
J'ai sans doute oublié certaines choses... Dans ce cas aussi, n'hésitez pas à me prévenir.