# Spécifications Fonctionnelles Détaillées

| | |
| --- | --- |
| **Projet** | *à compléter* |
| **Version** | *à compléter* |
| **Date** | *à compléter* |
| **Auteur** | *à compléter* |
| **Rédigé par** | MOA / business analyst, avec la MOE |
| **Destinataires** | Développeurs, testeurs, métier référent |
| **Statut** | Brouillon / En relecture / Validé |

---

## 1. Identification de la fonction

<!-- Le rattachement au niveau supérieur et le suivi de version. -->

<!-- Points à couvrir :
     - Identifiant, intitulé, macro-fonction de rattachement (SFG)
     - Version, statut, historique des modifications
     - BUC et exigences couverts
-->

*à compléter*

## 2. Description fonctionnelle

<!-- Ce que fait la fonction, en quelques phrases, avant le détail. -->

*à compléter*

## 3. Déclenchement et préconditions

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

<!-- Points à couvrir :
     - Mode de déclenchement : action utilisateur, ordonnanceur, événement, appel de service
     - Habilitations requises
-->

*à compléter*

## 4. Données en entrée

<!-- Le détail champ par champ, sous forme de tableau. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 5. Traitements et règles

<!-- L'algorithme fonctionnel, pas le code. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 6. Données en sortie

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

<!-- Points à couvrir :
     - Champs produits et leur mode de calcul
     - Format de restitution ou de fichier
     - Destination
-->

*à compléter*

## 7. Interface utilisateur

<!-- La description de l'écran, si la fonction en comporte un. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 8. Gestion des erreurs

<!-- Le catalogue exhaustif des erreurs de la fonction. -->

<!-- Points à couvrir :
     - Code, condition de déclenchement, message affiché, message journalisé
     - Blocant ou non blocant
     - Action possible pour l'utilisateur
-->

*à compléter*

## 9. Habilitations

<!-- Le détail des droits par profil sur cette fonction. -->

<!-- Points à couvrir :
     - Matrice profil / action (consulter, créer, modifier, supprimer, valider)
-->

*à compléter*

## 10. Cas de test attendus

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

<!-- Points à couvrir :
     - Cas nominaux
     - Cas limites et cas d'erreur
     - Jeux de données nécessaires
-->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

- 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.

**Erreurs les plus fréquentes**

- 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.

---

Modèle « SFD - Spécifications Fonctionnelles Détaillées » (Conception fonctionnelle), publié par DataALC.
Version en ligne, commentée : https://www.dataalc.com/boite-a-outils/templates/sfd/

Ce modèle est fourni comme base de travail : adaptez-le à votre contexte, supprimez les rubriques sans objet plutôt que de les laisser vides.