Les spécifications fonctionnelles générales

(temps de lecture moyen : 2 m 30 s)

Les 5 paragraphes principaux des Spécifications Fonctionnelles Générales
Les 3 erreurs à éviter
Un exemple : le fameux distributeur à billets

Les spécifications fonctionnelles générales (SFG, ou encore GFS en anglais) sont la représentation du besoin métier sous forme d’une proposition de solution technique.

Ce document est rédigé par la Maîtrise d’œuvre, sur la base du cahier des charges transmis par la Maîtrise d’Ouvrage.

Il n’y a pas de modèle exclusif et universel pour écrire des SFG. Cependant, gardez à l’esprit l’objectif de ce document : permettre au Maître d’Ouvrage et au Maître d’œuvre de se mettre d’accord sur les fonctionnalités de haut niveau à implémenter dans la future solution.

Les 5 paragraphes principaux des Spécifications Fonctionnelles Générales

Voici ce que je vous recommande de décrire :

La reformulation de la compréhension du besoin du Client, en y précisant clairement le périmètre et les contraintes internes et externes.
La représentation des processus métier liés au périmètre applicable et les utilisateurs finaux.
La traduction en une liste de fonctionnalités de haut niveau, décrites de manière synthétique, et caractérisées par leur niveau de criticité et d’urgence.
La liste des attentes non fonctionnelles, tout en indiquant que leur définition sera précisée dans les Spécifications Fonctionnelles Détaillées. Méfiez-vous particulièrement de ce point : il est très facile de se tromper sur les attentes du client à ce sujet si elles ne sont pas scrupuleusement définies et caractérisées. Un système d’information « rapide » ne veut rien dire. Une application « ergonomique » non plus.
Enfin, priorisez clairement les fonctionnalités qui seront déployées. Les Spécifications Fonctionnelles Générales sont la base pour planifier le projet, prévoir les « vagues » successives de versions etc.

Besoin d’un template gratuit pour écrire vos Spécifications Fonctionnelles Générales ?

Les 3 erreurs à éviter

Réécrire intégralement le cahier des charges : encore une fois, il ne s’agit pas de décrire les besoins métier mais de les traduire en fonctionnalités de haut niveau.

Les reformuler est une bonne chose, pour s’assurer d’une bonne compréhension de l’objectif et du contexte par la Maîtrise d’œuvre. Mais, de grâce, ne faites pas de copier-coller du cahier des charges …

Rédiger des Spécifications Fonctionnelles Détaillées en lieu et place des SFG (ou pire, un document de conception général ou détaillé).

C’est une erreur fréquente, notamment de la part de consultants techniques « bombardés » Business Analysts par leur SSII. On se retrouve souvent avec une conception technique de la solution à ce stade très précoce de l’analyse… Bonjour les dégâts pour la suite du projet !

>> Voir aussi : [VIDEO] Connaissez-vous les différences entre Spécifications Fonctionnelles Générales et Détaillées?

A contrario, décrire les fonctionnalités de manière vague, avec un vocabulaire qualitatif, que chacun interprétera à sa manière, est également à proscrire.

Jugez plutôt : un système « rapide », « en temps différé » (sans préciser la valeur du temps différé), « ergonomique », « pratique », « de qualité » … et j’en passe. Si vous n’avez pas d’autre choix que d’employer ce vocabulaire ambigu et interprétable, précisez que leur définition sera définie dans les Spécifications Fonctionnelles Détaillées.

Un exemple : le fameux distributeur à billets

Imaginez que la banque X veuille faire développer un programme personnalisé pour ses DAB (distributeurs à billets).

La société de prestations de services retenue suite à l’appel d’offre lui livre des Spécifications Fonctionnelles Générales qui pourraient inclure les informations suivantes :

Le périmètre de la solution: en plus de distribuer des billets à tous les propriétaires d’une carte bancaire valide (i.e. carte bleue, VISA, American Express), le DAB pourra également leur permettre de recharger leur mobile (opérateurs A, B et C uniquement). D’autre part, un service exclusif aux clients de la banque X leur permettra de consulter leur compte bancaire.
Les utilisateurs seront tous les clients de la banque X, mais également tous les propriétaires d’une carte bleue, Visa, et American Express.
Les fonctionnalités de haut niveau sont :
- Distribution de billets en euros : fonctionnalité critique (le programme ne peut être livré sans), urgente (1^ère version implémentée)
- Consultation du compte bancaire en euros: fonctionnalité majeure, urgente.
- Rechargement du forfait mobile en euros: fonctionnalité de faible criticité, non urgente.
Les spécifications non fonctionnelles sont :
- Rapidité de traitement : le programme doit restituer la carte bancaire au maximum 2 secondes après la validation de l’opération, et distribuer les billets moins de de 3 secondes après que la carte ait été reprise par l’utilisateur.
- Ergonomie du programme : l’utilisateur doit pouvoir valider ses demandes en maximum 4 clics.

>> Voir aussi : [VIDEO] Définir les Exigences Non Fonctionnelles