SFD - Spécifications Fonctionnelles Détaillées

À quoi sert ce document

Les SFD précisent, fonction par fonction, tout ce que les SFG ont laissé au niveau macro : chaque champ, chaque contrôle, chaque message d'erreur, chaque cas limite. Le critère de complétude est opérationnel : si un développeur doit poser une question métier pour avancer, la spécification n'est pas finie. C'est aussi le document le plus coûteux à produire du projet, ce qui justifie de ne le rédiger qu'après validation des SFG.

Quand le produire

• Sur un développement spécifique, où aucun paramétrage standard ne porte la règle.
• Quand l'équipe de réalisation est distante, externalisée, ou ne partage pas le contexte métier.
• Sur les fonctions à fort enjeu : calculs financiers, contrôles réglementaires, interfaces contractuelles.
• Quand la recette doit être opposable et donc adossée à une spécification écrite.

Le plan, rubrique par rubrique

1. Identification de la fonction

   Le rattachement au niveau supérieur et le suivi de version.

   • Identifiant, intitulé, macro-fonction de rattachement (SFG)
   • Version, statut, historique des modifications
   • BUC et exigences couverts

2. Description fonctionnelle

   Ce que fait la fonction, en quelques phrases, avant le détail.

3. Déclenchement et préconditions

   Comment la fonction est appelée et ce qui doit être vrai avant.

   • Mode de déclenchement : action utilisateur, ordonnanceur, événement, appel de service
   • Habilitations requises

4. Données en entrée

   Le détail champ par champ, sous forme de tableau.

   • Nom fonctionnel et nom technique
   • Type, longueur, format, unité
   • Obligatoire ou facultatif, valeur par défaut
   • Valeurs autorisées ou référentiel de rattachement
   • Contrôle de validité et message associé en cas d'échec

5. Traitements et règles

   L'algorithme fonctionnel, pas le code.

   • Enchaînement des traitements, étape par étape
   • Règles de calcul complètes, avec arrondis, devises, fuseaux horaires
   • Règles de gestion référencées (RG-xxx)
   • Cas limites explicités : valeur nulle, zéro, doublon, chaîne vide, date invalide, dépassement de seuil

6. Données en sortie

   Ce que la fonction produit, au même niveau de détail que les entrées.

   • Champs produits et leur mode de calcul
   • Format de restitution ou de fichier
   • Destination

7. Interface utilisateur

   La description de l'écran, si la fonction en comporte un.

   • Maquette ou capture annotée
   • Comportement des composants : activation, masquage, valeurs par défaut
   • Enchaînement des écrans et actions disponibles
   • Comportement responsive et accessibilité attendue

8. Gestion des erreurs

   Le catalogue exhaustif des erreurs de la fonction.

   • Code, condition de déclenchement, message affiché, message journalisé
   • Blocant ou non blocant
   • Action possible pour l'utilisateur

9. Habilitations

   Le détail des droits par profil sur cette fonction.

   • Matrice profil / action (consulter, créer, modifier, supprimer, valider)

10. Cas de test attendus

    Les jeux d'essai que la fonction devra passer, posés dès la spécification.

    • Cas nominaux
    • Cas limites et cas d'erreur
    • Jeux de données nécessaires

Les erreurs qui coûtent cher

• Laisser des cas limites implicites. Une valeur nulle, un doublon, une date au 29 février : ce qui n'est pas spécifié sera décidé par le développeur, sans que le métier le sache.
• Spécifier la technique. « Créer une table T_CLIENT avec un index sur SIRET » n'a pas sa place en SFD : c'est le rôle du DAT.
• Rédiger les SFD avant validation des SFG. Chaque changement de cible provoque une réécriture en cascade du document le plus volumineux du projet.
• Décrire les messages d'erreur par « message adapté ». Le libellé exact fait partie de la spécification, y compris sa traduction.
• Oublier la traçabilité vers les exigences. Sans elle, impossible de prouver en recette que le périmètre contractuel est couvert.