Spécifications fonctionnelles : passer du besoin à une règle vérifiable
L’expression de besoin logiciel explique la difficulté rencontrée et le résultat recherché. L’analyse fonctionnelle logiciel détaille ensuite les acteurs, les informations manipulées et les transitions autorisées. Les spécifications réunissent ces décisions pour que les utilisateurs et l’équipe de réalisation puissent parler du même comportement.
Pour remplacer Access ou Excel, partez d’un dossier qui traverse réellement le processus. Relevez les champs saisis, les calculs et les validations. Un écran de l’ancien outil sert de support à la discussion, mais ne décide pas à lui seul de la future interface. Le cadrage du logiciel sur mesure fixe le périmètre dans lequel ces règles seront développées.
- Nommer l’acteur autorisé et le déclencheur de l’action.
- Décrire les données requises et le résultat attendu.
- Préciser le refus, l’erreur et la correction possible.
Une fiche par comportement attendu
| Rubrique | Décision à documenter |
|---|---|
| Contexte | Un devis est soumis à validation par son auteur. |
| Condition | Le profil du lecteur autorise la validation et les champs requis sont présents. |
| Résultat | Le statut, l’auteur de la décision et la date sont enregistrés. |
| Exception | Un refus conserve le motif et renvoie le dossier au rôle défini. |
| Acceptation | Les utilisateurs vérifient le cas autorisé et les tentatives refusées. |
Cette trame décrit un scénario de conception à adapter à votre fonctionnement. Remplacez les mots généraux par le nom de vos rôles et les statuts retenus. Le cahier des charges de consultation présente plutôt les objectifs, les contraintes et les livrables attendus pour demander des propositions.
Relier règles, données et critères d’acceptation
Attribuez un identifiant stable à chaque règle. Référencez cet identifiant dans les écrans concernés et dans le cahier de recette métier. Une modification de calcul doit ainsi faire apparaître les cas de test à revoir. Microsoft rattache également la clôture d’une user story à ses critères d’acceptation et aux tests dans son processus Azure Boards.
- Décrire le parcours nominal avec les utilisateurs qui le pratiquent.
- Faire relire les exceptions par le responsable qui les arbitre.
- Associer chaque règle à une preuve de validation.
- Versionner les décisions et faire approuver les changements de périmètre.
Un critère d’acceptation doit permettre de trancher. « L’écran est pratique » laisse une appréciation ouverte. « Le rôle consultation ne peut ni modifier ni exporter » définit des actions à essayer. Fixez aussi les volumes de travail et conditions d’usage que vous souhaitez mesurer, à partir de votre activité.
Préparer les accès et les échanges
Pour les données personnelles, la CNIL demande une protection dès la conception. Les spécifications doivent donc nommer les profils, les opérations sensibles et les données de test. Décrivez les échanges comptables champ par champ : source de référence, destinataire et traitement d’un rejet. Le guide du connecteur comptable permet de compléter cette partie.
Questions pratiques
Faut-il spécifier tous les écrans avant de commencer ?
Découpez le projet en périmètres cohérents. Chaque périmètre confié à la réalisation doit avoir ses règles, ses exceptions et ses critères de réception définis. Une maquette validée sans règles de calcul ne suffit pas.
Qui valide les spécifications ?
Le responsable du processus valide les règles métier ; l’équipe technique confirme leur faisabilité et leurs dépendances. Conservez la version approuvée et les décisions ultérieures. La validation porte sur un comportement compris par les utilisateurs.
Sources officielles
Références vérifiées le 20 octobre 2026. Les grilles proposées servent à préparer le projet avec vos responsables métier et techniques.