Les Spécifications Fonctionnelles Générales (SFG)

(temps de lecture moyen : 2 m 30 s)

Les 5 éléments 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 (réalisateur de la solution), sur la base du cahier des charges transmis par la Maîtrise d’Ouvrage (le Client, porteur du besoin).

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 éléments principaux des Spécifications Fonctionnelles Générales

Voici ce que je vous recommande de décrire :

  1. 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.
  2. La représentation des processus métier liés au périmètre applicable et les utilisateurs finaux.
  3. La traduction en une liste d’exigences fonctionnelles de haut niveau, décrites de manière synthétique, et caractérisées par leur niveau de criticité et d’urgence.
  4. Les exigences non fonctionnelles majeures, 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.
  5. Enfin, priorisez clairement les exigences logicielles à prendre en compte. 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

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

Les fonctionnalités correspondent à ce que doit faire le logiciel, les exigences non fonctionnelles (ENF) à la manière dont le logiciel doit fonctionner pour que le service rendu soit optimum. Les besoins métiers sont les désirs à satisfaire pour que l’organisation cliente puisse fonctionner – mais cela ne signifie qu’ils le seront au travers du logiciel cible.

  1. Rédiger des Spécifications Fonctionnelles Détaillées en lieu et place des SFG.

C’est une erreur fréquente, notamment lorsque le / la Business Analyst a un profil initial IT et qu’il / elle était habitué à rédiger de la documentation technique. On se retrouve ainsi 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 !

  1. A contrario, décrire les fonctionnalités de manière trop 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 de SFG avec le 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 exigences 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.
4.6 7 votes
Évaluation de l'article
4
0
Would love your thoughts, please comment.x