(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.
>> Cliquez ici pour recevoir le modèle gratuit des Spécifications Fonctionnelles Générales
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.
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 ESN. 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
Bonjour, Je suis un ancien développeur qui a basculé (volontairement) vers l’AMOA et la BA car j’aime ça tout simplement. Mais du coup, comme je n’ai pas eu de formation à proprement parler, je me pose beaucoup de questions. Et je ne suis pas sûr de bien comprendre un point. Vous dites « 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. » Mais du coup, sur un projet (par exemple une appli Web) qui est déjà développée mais sans documents (comme… Lire la suite »
Bonjour Mickaël, Dans le cas des « rétro-spécifications », càd quand elles sont écrites a posteriori du développement de la solution, tout dépend de la mise en place de l’ingénierie des exigences souhaitée par l’entreprise. Je peux donc donner des bonnes pratiques, mais dans la réalité, elles ne sont pas forcément mises en place car c’est chronophage et donc cela coûte de l’argent… Bonnes pratiques: être capable de faire le lien entre vision stratégique > vision tactique (opérationnelle) > besoins métiers > exigences générales de la solution > exigences détaillées de la solution > cas de tests Exemple concret: – Vision stratégique:… Lire la suite »
je suis pas d’accord:
vous dites
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.
Ce document est rédigé par la Maîtrise d’ouvrage pas la maitrise d’oeuvre
Bonjour Hakim, petit point terminologique pour lever toute ambiguïté: – Maîtrise d’ouvrage (MOA) = le porteur du besoin = le Client – Maîtrise d’œuvre (MOE) = le réalisateur de la solution = le Fournisseur. Avant de décrire une solution (via la conception fonctionnelle et les SFD par exemple), il faut identifier et décrire les besoins métier. [MOA] Pour schématiser le processus de cette première étape, voici les activités que l’on retrouve côté MOA (on ne regarde pas la solution, on réfléchit par le prisme des besoins métiers): étude d’opportunité et Business Case > cahier des charges > Cadrage > Analyses… Lire la suite »