Ou comment bien rédiger les spécifications fonctionnelles
En développement numérique, une spécification fonctionnelle, » une spec fonctionnelle », désigne les objectifs et l’utilité du projet en cours de développement ; le QUOI.
Les spécifications fonctionnelles complètent les spécifications techniques, qui elles, décrivent le COMMENT arriver à ces utilités-là.
De la rédaction et des schémas
Objectif : formaliser dans un cahier des charges, de façon claire, exhaustive et compréhensible pour toutes les parties prenantes du projet, les besoins métiers à travers des documents qui décrivent précisément :
- les fonctionnalités attendues. ex : “Se connecter”, “S’identifier”, “Ajouter au panier”, “Valider le paiement”
- les cas d’usage
- les parcours utilisateurs
- les critères d’acceptation
- les règles métier
- les exceptions et cas d’erreur
Sans anticiper la solution technique !
Le but est d’aligner la vision du client, de l’équipe projet et des développeurs, en garantissant que le produit final répondra aux besoins exprimés par les utilisateurs.
Il existe 2 types de spécifications fonctionnelles :
- Les spécifications fonctionnelles générales (SFG) rédigées par le porteur du projet ou l’AMOA
- Les spécifications fonctionnelles détaillées (SFD) rédigées par ceux qui vont réaliser le projet
Les bénéfices de specs claires, exhaustives et compréhensibles
- Garantir la compréhension commune entre toutes les parties prenantes afin d’éviter les malentendus et les potentielles erreurs de conception et de développement
- Communiquer clairement les attentes et les besoins du clients
- Valider les avancées à chaque étape terminée et se projeter. Le cahier des charges est un guide pour l’équipe de développement.
- Possibilité d’apporter des modifications à ces specs tout au long du projet, suivant les avancées
- Servir de base pour d’autres projets
- Maîtriser le périmètre du projet, les coûts et délais
Un exemple de specs
Dans le cadre du ↪︎ projet « Domos » ↩︎, j’ai rédigé des Spécifications Fonctionnelles Détaillées (SFD). Voici les étapes suivies :
1. Définir le périmètre fonctionnel
A partir des ateliers et entretiens d’élicitation, les besoins utilisateurs ont été finement recueillis : quels sont les objectifs, qui sont les utilisateurs finaux, quels bénéfices attendus, quelles fonctionnalités à couvrir ?
En cohérence avec le brief, j’ai délimité ce qui est inclus et ce qui ne l’est pas dans le périmètre du projet.
2. Structurer un document évolutif de type wiki
Durant toute la durée du projet, la documentation peut être complétée et doit garder une organisation logique et équilibrée, avec des titres clairs et une navigation facilitée, d’où le choix d’outil de type Wiki comme [NOTION] ou [CONFLUENCE].
- Introduction/contexte : présentation du projet, ses objectifs, le périmètre concerné
- Glossaire : définitions partagées des termes métier et techniques pour éviter toute ambiguïté
- Arborescence fonctionnelle : liste organisée des fonctionnalités principales et sous-fonctions, sous forme de diagramme et de tableau pour visualiser leur articulation. Les schémas, diagrammes, wireframes ou maquettes permettent de clarifier les parcours utilisateurs et les interactions [FIGMA].
- Règles métier : définition des règles transverses ou spécifiques à chaque fonctionnalité
3. Décrire chaque fonctionnalité
L’objectif est ici de recenser de manière exhaustive les fonctionnalités pour éviter les oublis et les retours en arrière coûteux. Surtout, il faut privilégier des phrases courtes, simples, sans jargon inutile ou termes ambigus (« rapide » devient « réponse en moins de 2 secondes »).
| Eléments | Précision | Spécification |
|---|---|---|
| Nom de la fonctionnalité ou cas d’usage | Descriptif facilement compréhensible | « Connexion utilisateur » |
| Acteurs | qui utilise la fonctionnalité (profils utilisateurs) | Habitant, Collaborateur |
| Précondition | ce qui doit être vrai avant d’utiliser la fonctionnalité | Utilisateur inscrit, email en base |
| Scénario | déroulement étape par étape, interactions utilisateur/logiciel, écrans concernés, messages affichés | 1. Affichage du formulaire de connexion |
| 2. Saisie email et mot de passe | ||
| 3. Validation | ||
| 4. Contrôle des identifiants | ||
| 5. Message d’erreur ou accès accordé | ||
| Règles de gestion | conditions, calculs, traitements automatiques, gestion des erreurs | Blocage après 3 tentatives échouées |
| Postcondition | état attendu après exécution | Utilisateur connecté ou message d’erreur |
| Priorité | importance de la fonctionnalité (haute, moyenne, basse) | Haute |
| Contraintes techniques ou réglementaires | à mentionner si nécessaire | |
| Critères d’acceptation | à vérifier lors du recettage | Accès en moins de 2 secondes, gestion des erreurs |
L’élicitation est nécessaire tout au long de l’avancement du projet. Il me faut m’aligner régulièrement avec les parties prenantes pour valider une bonne compréhension des besoins.
Ces besoins et fonctionnalités nécessitent d’être priorisés avec notamment la création d’une matrice impact/effort.
4. Prévoir les scénarios de test
Pour chaque fonctionnalité, je propose des scénarios de test ou critères d’acceptation pour vérifier que le développement correspond bien à la spécification d’origine.