Les Spécifications Fonctionnelles Détaillées (SFD)

(temps de lecture moyen: 2 m)

Les Spécifications Fonctionnelles Détaillées (« SFD » ou « DFS » en anglais) désignent l’ensemble des documents décrivant en détail les exigences, règles métiers et comportements de la solution cible, en conformité avec les besoins du Client analysés et recueillis en amont.

Les SFD sont certainement le plus connu des livrables rédigés par le Business Analyst. Mais malheureusement, c’est aussi celui qui est sans doute le plus décrié par les équipes techniques en charge du développement de la solution cible.

En tête des critiques :

• un document trop « littéraire », confus voire illisible au regard des attentes techniques,
• ou au contraire, inutilisable car rédigé de manière trop technique, en avance de phase sur les choix d’architecture et outils, et de ce fait, souvent erronés.

La raison principale est le manque de formation des Business Analysts. Voici donc quelques bonnes pratiques essentielles pour vous aider à rédiger des SFD de qualité.

Voici mes 5 recommandations pour livrer des SFD de qualité

1. Apportez une plus-value aux acteurs cibles des spécifications fonctionnelles détaillées (SFD)
   

Au risque d’enfoncer une porte qui devrait être ouverte, retenez que ce document doit être validé (et donc compris) par la Maîtrise d’Ouvrage ET qu’il sert d’input principal aux équipes techniques de la MOE pour concevoir et développer la solution. Les SFD sont un pont entre le métier et la technique, un effort rédactionnel de qualité est donc un minimum requis et non une option.

2. Écrivez des Spécifications Fonctionnelles Détaillées (SFD) claires et non ambiguës.

• Claires : ne mélangez pas dans un même paragraphe les définitions, les règles métier, les exceptions, le cas nominal, et les cas alternatifs.
• Non ambigües : tout terme ayant une signification métier ou technique particulière doit être clairement défini. Si vous avez le moindre doute sur un risque d’interprétation, c’est le signe que vous devez jouer aux Académiciens et écrire une définition dans le glossaire.

3. Séparez la définition des fonctionnalités de celle de l’IHM

D’une part, vous faciliterez le travail des concepteurs techniques et des développeurs. D’autre part, cette ségrégation permettra de concevoir plus facilement une solution cible évolutive et maintenable.

4. Regroupez dans un document transverse les éléments communs à plusieurs spécifications.

Dans les Spécifications Fonctionnelles Détaillées (SFD), le Business Analyst va s’attacher à décomposer en sous-fonctions les fonctionnalités de haut niveau décrites dans les SFG.

Le livrable « SFD » sera donc composé de plusieurs documents (je recommande un document par fonctionnalité de haut niveau), et il est fort probable que certaines définitions et règles métier soient communes / transverses.

Prenez donc l’habitude de créer un glossaire et un document « Règles Métier » dès qu’une définition ou une règle métier dépasse le strict périmètre de la spécification en cours de rédaction.

5. Illustrez les fonctionnalités à l’aide de schémas conceptuels.

Rien de mieux que la représentation visuelle pour faire passer des messages compliqués. Et, point non négligeable, cela permet de contrôler, corriger, améliorer, et valider la faisabilité d’une fonctionnalité.

6. N’oubliez pas de décrire les Exigences Non Fonctionnelles

Souvent oubliées ou mal formulées, les Exigences Non Fonctionnelles (ENF) sont pourtant indispensables car elles décrivent les propriétés que le système doit posséder. 

Enfin, ne confondez pas Spécifications Fonctionnelles Générales et Spécifications Fonctionnelles Détaillées… Ces documents sont rédigés à des moments distincts du cycle de vie du projet, et ne poursuivent pas les mêmes objectifs.