Documentation fonctionnelle

Définition

La documentation fonctionnelle porte différentes appellations selon l'organisation. On retrouve les termes : dossier fonctionnel, devis fonctionnel, cahier des charges, spécifications fonctionnelles, spécifications logicielles, exigences de système, etc. Ce document décrit en détail les fonctionnalités d'un système informatique ainsi que les règles qu'il doit respecter.

Certaines personnes feront la comparaison suivante : les documents fonctionnels sont à l'informatique, ce que les plans sont à la construction. Dans cet ordre de pensée, il est vrai que les documents fonctionnels, tout comme les plans, servent à la réalisation du projet.

Mais contrairement aux plans de construction, la documentation fonctionnelle ne décrit pas un assemblage technique de composante, elle décrit un comportement logiciel pour répondre à un besoin. Ainsi on pourrait aussi comparer la documentation fonctionnelle à un scénario de film où l'analyste est le scénariste, le programmeur est le réalisateur et l'utilisateur est l'acteur.

Lectorat

Parties prenantes

Pour les parties prenantes (pilote, analyste d'affaires ou utilisateur), la documentation fonctionnelle leur servira de référence pour tous les détails de la fonctionnalité discutée. Le document leur permettra aussi de s'assurer que la compréhension de l'analyste est bonne et que les cas d'utilisation sont couverts.

Programmeurs et testeurs

Pour le programmeur, il se servira de la documentation pour établir sa liste de tâches à faire. Chaque petite règle fonctionnelle, condition et exception doit être codée. Le testeur se servira aussi du dossier fonctionnel pour déterminer ce qui sera à tester.

Analystes fonctionnels

Finalement, le document sert aussi aux analystes fonctionnels. D'ailleurs, une fois le projet réalisé, il servira principalement qu'à ceux-ci. Un analyste doit fréquemment consulter le document d'une fonctionnalité afin de :

• vérifier les impacts d'une nouvelle modification;
• vérifier le fonctionnement lorsqu'il supporte les utilisateurs;
• ajouter une précision sur une règle existante;
• simplement comprendre le fonctionnement d'une fonction qu'il n'a pas lui-même analysé.

Contenu

Un dossier fonctionnel contient l'ensemble des spécifications fonctionnelles (règles) qui définissent une fonctionnalité d'un système informatique. Ces règles sont logiques, mais ne sont pas techniques. Elles doivent être lues et comprises par le client qui n'est généralement pas informaticien de formation. On ne devrait donc pas retrouver des noms de table, de procédure ou de variable.

L'article Exemple d'un dossier fonctionnel commun donne un aperçu de ce que contient habituellement un dossier fonctionnel. Il est à noter qu'il n'y a pas de gabarit universel de dossier fonctionnel et qu'il existe quelques variantes d'une organisation à une autre. Certaines méthodologies proposent leurs propres gabarits.

Pertinence

Il est possible de développer un système informatique sans rédiger de documentation fonctionnelle. Dans cette situation, le système doit être développé par des programmeurs-analystes. Ceux-ci doivent bien documenter leur code et doivent s'assurer par les ateliers de rédiger des comptes rendus clairs et précis pour les parties prenantes. Dans ce cas, le dossier fonctionnel peut-être évité, surtout si le logiciel à développer est petit ou ne présente pas de complexité.

La question qui survient est : est-il possible d'épargner du temps (donc du budget) en ne rédigeant pas de documentation? La réponse est non et en voici les principales raisons :

• Les gens ont différentes personnalités. Certains préfèrent relever des défis techniques de programmation sans avoir à préparer des ateliers ou rédiger des comptes-rendus. D'autres sont davantage stimulés à extraire les exigences ou dénouer les problèmes opérationnels du client afin d'y trouver une solution logique. Les membres d'une équipe ont avantage à effectuer des tâches où ils ont de bonnes aptitudes. Lorsque les tâches ne sont pas faites par les bonnes personnes il y a une perte d'efficacité ou de qualité.
• La documentation est une des tâches assez courtes que réalise l'analyste fonctionnel. Comprendre le problème, faire des ateliers, proposer des solutions, faire des évaluations, se valider et obtenir le consensus est nettement plus long.
• La rédaction en soi est un processus de réflexion qui permet à l'analyste de s'assurer que les spécifications obtenues sont complètes.
• Finalement, la documentation facilite le maintien et l'évolution du système informatique.

Approbation

Si l'on se réfère aux analogies ci-dessus des plans de construction ou des scénarios de film, on a deux réponses différentes :

• Ceux qui considèrent les documents fonctionnels comme des plans de bâtiment diront qu'il est normal que le client approuve les plans d'une bâtisse qu'il paie pour se faire construire. Dans cette optique, si le client change d'idée en cours de route il devra débourser pour les modifications.
• Ceux qui considèrent les documents fonctionnels comme des scénarios diront qu'il est normal que le client modifie et apporte des changements à son scénario, car selon eux, une histoire est écrite uniquement lorsque tous les détails ont été peaufinés. Dans cet esprit, le client n'a pas à approuver quoi que ce soit au niveau du scénario, ce qu'il désire approuver est le résultat final et non pas ce qui sert à amener au résultat.

Un contrat

Un document approuvé n'est pas simplement qu'un dossier fonctionnel, mais un contrat. Dans la pratique, les clients sont très frileux à approuver un dossier qui se cristallise en contrat immuable au moment où ils apposent leurs griffes. Ils ont peur d'avoir oublié un cas, ou pire encore, qu'ils pourraient se rendre compte un peu plus tard qu'il existait une meilleure solution, mais que malheureusement ce qui doit être programmé doit correspondre à ce qui est écrit dans le document jadis approuvé. Ce genre de situation survient lorsque la rémunération du service informatique est forfaitaire.

Le client, un collaborateur impliqué

L'approbation peut cependant être utile lorsqu'elle signifie que le client a lu le document et qu'au moment de sa lecture, le contenu du document correspond à ses attentes. Ainsi, le client peut approuver le document plusieurs fois pendant son évolution. L'essentiel est qu'il en prenne pleinement connaissance.

Or, ce n'est pas l'analyste fonctionnel qui décide si un document fonctionnel doit être approuvé ou non. Ces directives viennent de la direction de l'entreprise pour laquelle il travaille. Pour lui, ce qui est important, c'est que le client soit toujours un collaborateur impliqué. Ainsi, le client est au fait de ce que l'analyste rédige comme documentation et peut s'assurer que la documentation lui convient.