Spécification fonctionnelle

Spécification fonctionnelle : Document décrivant précisément le comportement attendu de chaque écran et de chaque règle, référence commune au design et au développement.

Cette entrée du glossaire relève de la famille « Produit et UX ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.

Pourquoi Spécification fonctionnelle compte sur un projet mobile

Dans un projet d’application, Spécification fonctionnelle sert à trancher : quelles fonctions entrent en version 1, dans quel ordre, et ce qu’on assume de laisser de côté.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

La traduction en exigences

Le cahier des charges doit fixer ce que recouvre « Spécification fonctionnelle » en version 1 et ce qui attend la suite. Un périmètre non borné s’étend tout seul pendant la recette.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les rôles utilisateurs, et ce que chacun a le droit de faire.
• Les écrans concernés, listés, avec leur état vide et leur état d’erreur.
• Ce qui est explicitement hors périmètre de la version 1.
• Les contenus fournis par le client, et la date à laquelle ils arrivent.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Comment le vérifier à la recette

À la recette, « Spécification fonctionnelle » se juge sur le parcours complet, pas sur un écran isolé qui fonctionne en démonstration.

• Faire dérouler le parcours principal par quelqu’un qui n’a pas participé au projet.
• Vérifier chaque état vide et chaque message d’erreur, écran par écran.
• Relire les textes affichés : fautes, jargon interne, phrases tronquées.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Ce qui tourne mal le plus souvent

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Décrire une fonctionnalité par une intention plutôt que par des écrans et des règles.
• Oublier les cas qui vont mal : liste vide, erreur réseau, droits insuffisants.
• Confondre l’avis de trois collègues et un test auprès de vrais utilisateurs.
• Laisser le back-office hors du cahier des charges, alors qu’il pèse lourd dans le chiffrage.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Postback d’événement
• Densité d’information
• Comité produit
• Timeboxing
• Compte invité

Questions fréquentes

Qu’est-ce que « Spécification fonctionnelle » ?

Document décrivant précisément le comportement attendu de chaque écran et de chaque règle, référence commune au design et au développement. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Comment le vérifier à la recette ?

Avec un critère écrit avant le développement, formulé de façon à pouvoir être refusé. « L’écran doit être agréable » ne se recette pas. « La liste vide affiche tel message et tel bouton » se recette.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.