La méthodologie d’écriture

Puisque nous savons ce que doit contenir le cahier des charges, je vais maintenant expliquer comment je l'ai écris. Deux chapitres importants vont composer cette section. D'une part, j'évoquerai l'approche descendante, qui est la clef de voute du cahier des charges. D'autre part nous verrons quels ont été les langages et outils utilisés dans le cadre de sa rédaction.

IV.3.2.1 L’analyse descendante

J'ai en fait utilisé cette méthode sans le savoir. C'était un peu comme une découverte pour moi, même si d'autres y avaient pensé bien avant. Mais qu'est ce donc que cette méthode de « l'analyse descendante » ?

De tous temps, les Hommes ont essayé de construire des choses complexes en partant de choses simples. C'est l'analyse montante.

L'analyse descendante est le raisonnement complètement inverse dans laquelle on part d'un système complexe que l'on décompose progressivement en sous-systèmes moins complexes. Par exemple, on devait trouver sur le site Internet Pièces Avenue, une foire aux questions ainsi qu'une boutique en ligne. Puis, en creusant un peu plus le sous système boutique en ligne, on se rend compte qu'il doit y avoir un catalogue produit et ainsi de suite.

Figure 44 – Analyse descendante, niveau A-1

Cette méthode est efficace car elle permet de ne rien oublier malgré la complexité du système. Elle garantit la complétude du cahier des charges. De plus, cette structure m'a aidé à ne pas faire de redites. Chaque fonctionnalité était spécifiée dans un seul et unique chapitre du cahier des charges. Encore une fois, pour ne pas inutilement allonger les délais, il faut éviter de descendre de manière trop profonde dans cette étude. Enfin, dernière remarque : Le plan du cahier des charges fonctionnel est basé sur les différents blocs de fonctions que l'on retrouve sur ces schémas.

IV.3.2.2 Le langage et les outils

Les deux précédentes parties abordent le contenu ainsi que la structure du cahier des charges. Un seul point reste encore à éclaircir : de quel manière ce contenu est-il rédigé et quels sont les outils sur lesquels je me suis basé dans le cadre de sa rédaction.

Sans entrer dans l'aspect abstrait de la définition d'un langage (syntaxe, sémantique, etc.), je voudrais simplement signaler ici qu'il y a plusieurs types de langages à la disposition du rédacteur. Chacun ayant ses avantages et inconvénients.

Par exemple, les langages formels ou mathématiques permettent d'éviter les mauvaises interprétations et permettent de spécifier plus simplement les tests, mais ils sont aussi beaucoup plus lourds à lire. D'autant plus que le cahier des charges est un document lu par des acteurs qui n'ont pas nécessairement les connaissances requises pour comprendre ces langages.

Il y a aussi les langages naturels comme le français. Ces langages sont évidemment plus simples à comprendre pour le lecteur et toucheront un lectorat plus vaste. Cependant, ils peuvent aussi être source de mauvaise interprétation. De plus, il y a des risques que le cahier des charges ne soit pas cohérent. Entre ces deux extrêmes, il y a les langages naturels structurés. Dans ce type de langage, les phrases sont construites sur la base de gabarits. C'est évidemment plus pénible à lire, mais ce langage est un compromis entre les deux précédents. Par exemple : « l'objet X a N référence à l'objet Y. L'objet Y peut ou non avoir une référence à l'objet X ».

Dans le cas de Pièces Avenue, j'ai principalement utilisé le langage naturel. Par petites touches j'ai aussi intégré le langage naturel structuré. Mais en plus de ces langages, je me suis aussi aidé de schémas.

Le premier type de schéma utilisé est le diagramme de cas d'utilisation ou « use-case » issus de la méthodologie UML. Les use cases ont principalement été utilisé pour spécifier les droits que peuvent avoir les internautes sur le front office ou des administrateurs dans le back office.

Le second type de schéma utilisé est le logigramme. Ce type de schéma permet de spécifier les enchainements dans les actions, ainsi que les différents états dans lequel peut se trouver le système.

IV.3.2.3 La communication

La communication joue un rôle central dans la rédaction du cahier des charges. En tant que chef de projet, la première chose que j'ai eu à faire a été de comprendre le métier de mon client. Puis, il fallait analyser la demande, comprendre les besoins qui ont été formulés par Stéfan et faire un feedback pour s'assurer que l'on a bien compris.

Quelques fois, j'ai même du aider le client à définir ses propres processus métier. Par exemple, le processus de retour des produits a été étudié en collaboration avec Stéfan. Il m'a tout d'abord expliqué son besoin. Ensuite, j'ai proposé un fonctionnement qui répond à ce besoin et nous l'avons validé ensemble.

L'étape suivante est de formaliser et de décrire dans le cahier des charges ces besoins. Lors de la rédaction du cahier des charges, il faut bien avoir à l'esprit que l'objectif principal est de transmettre un message au lecteur.

L'essentiel ici est donc de s'adapter au lecteur pour que celui-ci comprenne ce message et qu'il n'y ait aucune ambiguïté, quelque soit le plan du cahier des charges, son contenu, son style d'écriture ou le nombre de pages du document. Il faut donc prendre en considération son lectorat et faire des choix de rédaction en fonction de ce dernier.

Tout ceci a impliqué de nombreux échanges (téléphone, mail, etc.) mais aussi plusieurs itérations pour arriver au cahier des charges définitif.