Spécifications fonctionnelles

Spécification fonctionnelle : les basiques

Spécification fonctionnelle : comment spécifier votre projet digital ?
Comment rédiger de bonnes spécifications fonctionnelles ? Quel est le périmètre d'une spécification ? Sur quels documents pouvez-vous vous appuyer pour écrire vos specs ?
Quel plan pour la rédaction de vos spécifications ?
Cet article fait un point complet sur les méthodes de rédaction des spécifications et sur les éléments à décrire dans un travail de spécification générale. Vous trouverez un guide pour rédiger vos spécifications ainsi qu'un exemple de plan de spécification fonctionnelle générale tout en bas de la page dans la section méthode. C'est une tâche qui demande de bonnes compétences en design de l'interaction.

Les spécifications décrivent le fonctionnement du dispositif digital. On spécifie le comportement de chaque écran de l'interface utilisateur. On clarifie la réponse que l'interface doit apporter lorsque l'utilisateur réalise une action ou active une fonction. Il faut détailler tous les interactions à l'écran, c'est à dire tout ce qui peut se passer sur le plan interactionnel dans la manipulation de l'interface utilisateur.

L'écriture des spécifications s'inscrit comme une étape de la conduite d'un projet digital. C'est d'ailleurs un temps fort de tout projet, puisque la période de spécification se matérialise par un livrable. Elle intervient en phase de conception, lorsque tous les écrans constitutifs du dispositif digital ont été conçus. Les spécifications peuvent aussi bien s'appuyer sur des maquettes fonctionnelles (wireframe) que sur des maquettes graphiques.
Dans l'absolu, il est toujours plus commode de décrire le fonctionnement de l'interface sur la base des éléments les plus aboutis : or, les créations graphiques révèlent un niveau d'information supérieur à celui délivré par les storyboards.

Une spécification peut être de nature fonctionnelle ou technique... En règle générale, on observe que les spécifications fonctionnelles concernent la partie front-office quand les spécifications techniques se concentrent plutôt sur la partie back-office.

Spécifications fonctionnelles

C'est le chef de projet fonctionnel qui produit le rapport de spécifications fonctionnelles détaillées (on parle aussi de SFD). Le concepteur de l'interface (UI designer) serait le profil le plus pertinent pour écrire les spécifications... Néanmoins, dans les faits, le concepteur intervient principalement sur le design de l'information et le design de l'interaction au travers des maquettes fonctionnelles. Son effort porte davantage sur la conception que sur la description.

Le périmètre couvert par la spécification fonctionnelle se rapporte au fonctionnement de l'interface côté utilisateur, en front-office. Dans ce cas, le rédacteur s'attache à éclaircir toutes les spécificités de l'interface qui concernent les interactions avec l'utilisateur final... Pour prendre un exemple, on peut citer le cas d'un site ecommerce : il s'agira de décrire les interactions de chacun des écrans qui permettent de manipuler et d'utiliser le site ecommerce, côté utilisateur.

On se concentre sur le caractère fonctionnel du dispositif : les fonctionnalités, les modules interactifs, le fonctionnement de chacune des parties de l'interface, pour chacun des gabarits du dispositif digital.

Les spécifications fonctionnelles différencient les éléments fonctionnels transversaux, qui s'appliquent à l'ensemble de l'interface, des éléments fonctionnels contextuels, qui s'appliquent exclusivement à un écran, ou à un groupe d'écrans.

Spécifier le fonctionnement d'un dispositif digital est une tâche relativement lourde. En effet, chaque écran d'un support interactif est porteur de nombreuses interactions entre l'utilisateur et le système. Tous les comportements de l'interface doivent ainsi être explicités. Un comportement d'interface peut concerner une interaction de surface (survol d'un élément) comme une interaction de structure (filtre d'une page de résultat). Les spécifications fonctionnelles doivent bien différencier les interactions de surface des interactions de structure.
Les interactions de surface ne relèvent que des échanges d'informations entre le navigateur et le terminal de consultation (tel élément change de couleur au survol, tel élément apparaît au clic). Les interactions de surface n'impliquent pas d'échange avec la base de données. Ils sont superficiels et peu structurants.
En revanche, les interactions de structure concernent des actions de nature plus complexes. Elles impliquent un ou plusieurs échanges avec les bases de données. Pour des dispositifs digitaux de grande envergure, la nature des interactions de structure peut être relativement complexe. C'est pourquoi, dans certains cas, on procède à l'écriture des spécifications techniques de façon dédiée.

Spécifications techniques

C'est le chef de projet technique qui écrit le rapport de spécification techniques détaillées.

Le périmètre couvert par la spécification technique concerne le fonctionnement technique de l'interface côté administrateur, en back-office. Dans le cas des specs techniques, le rédacteur décrit toutes les spécificités de l'interface qui concernent les interactions avec la base de données et le système informatique (progiciel, ERP...). Pour reprendre l'exemple du site ecommerce : il s'agira de préciser les interactions entre la base de donnée et le système après que l'utilisateur ait réalisé une action impliquant une vérification dans le système... Plus concrètement tous les échanges de données entre l'interface d'administration et le système informatique central de l'entreprise. On se situe côté administrateur.

On se concentre ici sur le caractère technique du dispositif digital : la base de données, les serveurs, les flux échangés avec les progiciels de gestion intégrés (gestion des stocks produits, comptabilité...). Mais aussi tous les échanges de données techniques entre la base de données et l'interface utilisateur, en front-office.
Les spécifications techniques décrivent également le fonctionnement de l'interface d'administration utilisée par les chefs de produits pour gérer toute la partie commerciale et marketing du site ecommerce, dans l'exemple du site marchand.

Les spécifications techniques différencient les interactions entre le front-office et le back-office, des interactions entre le back-office et le progiciel de gestion intégré. En effet le back-office est au centre du système et fait la jonction entre la solution informatique de l'entreprise et le site dédié à l'utilisateur final...

Si on peut considérer la spécification fonctionnelle comme étant un exercice impliquant, il faut bien admettre que la spécification technique est un travail plus ardu. Il faut spécifier les interactions entre le back-office et le front-office, expliciter le fonctionnement du back-office, et en plus clarifier les échanges de données et les flux d'informations échangés entre le système informatique central (ERP) et le back-office.

Pour un support interactif de taille critique, la rédaction des spécifications techniques est un grand challenge.

Spécifications générales

Comme vous l'avez compris, certains projets de taille critique sont si volumineux qu'il est nécessaire de séparer les exercices de rédaction. On aura ainsi un cahier de spécification fonctionnelle et un cahier de spécification technique. Dans ce cas, on parle de spécifications fonctionnelles générales (SFG).

Dans les projets digitaux qui impliquent plusieurs centaines d'acteurs et plus encore (Cdiscount, Amazon, Carrefour, Auchan, Le Monde, Le Figaro...), ce n'est pas un chef de projet mais plusieurs chefs de projets qui rédigeront les spécifications. Chacun se chargera d'une partie du dispositif digital. Ainsi, la rédaction de spécifications fonctionnelles et techniques peut occuper une équipe de dizaines de personnes...

Pour les projets digitaux de taille plus modérée, les spécifications fonctionnelles et les spécifications techniques sont fusionnées au sein d'un seul et même document : le cahier des spécifications fonctionnelles et techniques. Le périmètre des éléments à détailler ne change pas, mais la densité est plus mesurée. Une à deux personnes peuvent se charger de spécifier le fonctionnement, et l'ensemble peut figurer au sein d'un seul et même document...

Un rapport de spécification est généralement assez volumineux. Il est rédigé, dans 90% des cas, sous la forme d'un document word. Il est rare que des spécifications fassent moins de 100 pages. Il est courant que les spécifications dépassent les centaines de page...

Les spécifications générale, un livrable clé

Les spécifications générales sont un livrable clé du projet.
Au même titre, et de même poids que les autres principaux livrables du cycle projet :

• Le brief.
• La note de cadrage.
• L'arborescence (optionnel).
• Les wireframes.
• Les maquettes graphiques.
• Les spécifications générales détaillées.
• Le procès-verbal de recette.

Tous les projets digitaux de grande envergure sont spécifiés. C'est un incontournable de la gestion de projet web, et de la conduite de projets digitaux au sens large.

Les spécifications, un document contractuel

Dans l'industrie digitale, le porteur de projet a le choix de réaliser son dispositif digital lui-même ou de le confier à un prestataire externe pour le faire exécuter.
Le porteur de projet peut être un individu comme une entreprise, et il en va de même pour le sous-traitant, qui est soit un individu, soit une entreprise (soit un collectif d'indépendants, etc.). Ces considérations sont importantes, et nous allons en venir aux faits...

Plus il y a d'acteurs impliqués dans un projet, plus il est probable que des spécifications soient rédigées. En effet, les spécifications sont avant tout rédigées dans deux buts :

• Fixer les principes fonctionnels et techniques du dispositif digital d'une part.
• Partager et diffuser ces principes aux acteurs impliqués dans le projet digital.

Quelle que soit la configuration du projet, il est relativement rare qu'un porteur de projet seul, ou faisant appel à une équipe très réduite pour exécuter le dispositif, exige la rédaction de spécification.

En effet, on ne voit apparaître les énormes rapports de spécifications que pour les projets les plus complexes, les plus ambitieux, qui sont aussi ceux qui impliquent un maximum de travail collaboratif.

Les grandes entreprises de la world company ont tendance à considérer les spécifications comme un document contractuel, exigible de la part du prestataire lorsqu'un éditeur est amené à produit le dispositif d'un tiers.

Dans ces cas, il faut veiller à rédiger des spécifications à la fois précises et exhaustives, pour couvrir tous les risques impliqués par le contrat... C'est pourquoi, dans les faits, on peut rédiger une bonne page pour décrire le fonctionnement de la fonction envoyer à un ami. HéHé, ben oui. C'est contractuel.

En dehors du cadre contractuel, un acteur de taille critique qui choisira d'internaliser la production, optera quand même pour la réalisation de spécifications afin de documenter le projet et de faciliter le travail collaboratif entre les différents services.

Devez-vous rédiger des spécifications ?

Si vous êtes arrivé jusqu'ici, la réponse est oui :).
Le choix de spécifier le projet ou de ne pas spécifier du tout est une décision stratégique qui revient à chaque porteur de projet. Néanmoins, vous pouvez observer 3 règles pour vous aider à trancher la décision.

Plus l'envergure fonctionnelle du projet est large, plus il apparaît judicieux d'en spécifier le fonctionnement. Par exemple, au-delà de 50 gabarits, il y a des risques que le dispositif digital soit assez sophistiqué...

De même, plus il y a d'acteurs et de collaborateurs impliqués dans la production du projet, plus il semble nécessaire de créer une documentation permettant de fixer la connaissance projet. En effet, c'est la garantie que les informations spécifiques du projet traverseront le temps, ce qui n'est pas nécessairement le cas des personnes au contact du projet...

Enfin, toute configuration de projet relevant de la dualité commanditaire - prestataire, qui implique un passage de commande conséquent, appelle une rédaction de spécifications, le plus souvent du côté du prestataire. Dans les projets d'envergure modérée, il n'est pas recommandé de rédiger des spécifications, même pour une configuration entre un donneur d'ordre et un prestataire. En effet, rédiger des spécifications demande du temps et représente un coût... On préfèrera alors utiliser ce temps pour rédiger le traditionnel guide utilisateur qui fait la passe d'armes et le relais entre les réalisateurs et les administrateurs en charge de la gestion du dispositif au quotidien.

Est-ce raisonnable de ne pas spécifier ?

Objectivement, si les équipes de conception et de production se connaissent très bien, et que la communication est optimale, alors oui, on peut se passer de spécifications. Cela concerne toutefois des équipes resserrées et implique que chaque membre de l'équipe travaille à proximité des autres. En effet la communication est très importante, et il faudra répondre des dizaines de fois à la question :

• Qu'est-ce qui se passe SI ?
• Qu'est-ce qui se passe QUAND ?

On peut donc se passer de spécification fonctionnelle dans le cas où les équipes de conception-production travaillent conjointement et partagent une connaissance pointue du projet. Cette configuration reste assez rare pour les projets de taille critique.

Peut-on industrialiser les spécifications ?

Hélas non. On ne peut pas vraiment industrialiser la rédaction des spécifications. Chaque projet est différent et appelle du sur-mesure.
Comme nous le décrivions, les projets concernés par la rédaction de spécifications fonctionnelles et techniques sont généralement ambitieux sur les plans fonctionnels et éditoriaux... Il faut reprendre à zéro à chaque fois, et écrire toutes les spécifications, de A à Z. Le copier-coller est assez difficile :)...

Les professionnels du digital considèrent, à juste titre, la rédaction des spécifications comme étant une tâche relativement fastidieuse, pour ne pas dire ingrate voire assommante. C'est pour cette raison limpide que les spécifications sont confiées, dans 3 cas sur 4 en moyenne, à des profils juniors, voire très juniors (stagiaires). Effectivement, bien que la tâche soit relativement complexe et appelle une solide expérience, elle désintéresse les profils les plus aguerris, lesquels préfèrent se frotter à des sujets plus intéressants... Ceci vaut particulièrement pour les spécifications fonctionnelles. Dans les faits, les spécifications techniques sont plus complexes et relèvent de l'ingénierie, elles sont généralement entre de bonnes mains, car il n'y a pas le choix...

Bien que la démarche ne puisse être industrialisée, vous pouvez néanmoins gagner du temps en vous appuyant sur des modèles. Les modèles de spécifications vous aident à visualiser toutes les sections à documenter. Ils peuvent être considérés comme une checklist.
IAFACTORY propose quelques modèles à cet effet, si le coeur vous en dit :).

Fixer les limites fonctionnelles du projet

Les spécifications fonctionnelles sont généralement le parent pauvre de la documentation projet. Elles sont pourtant aussi importantes que les wireframes. En effet, les maquettes fonctionnelles comme les maquettes graphiques restent des documents statiques. Un wireframe figure le design d'information et permet de bien visualiser la ventilation des composants d'interface à l'écran. Mais il apporte peu d'informations sur le design d'interaction et reste trop superficiel pour être le garant de toutes les règles de fonctionnement de l'interface.
Les spécifications générales définissent précisément les règles interactionnelles engagées dans chaque écran. Et aucun cas marginal n'échappe, en général, à une spécification précise : tous les cas spécifiques doivent être relevés et décrits.

Rédiger des spécifications fonctionnelles peut s’avérer fastidieux, complexe et long. C’est la raison pour laquelle de nombreuses équipes projets font l’impasse sur cette étape. Il s'agit pourtant d'un travail crucial pour la fluidité du travail collaboratif en production. La rédaction de spécifications fonctionnelles précises garantit effectivement la limpidité de la production et les échanges avec les acteurs techniques.

Enfin, on dit souvent que le diable se cache dans les détails. Ce n'est jamais aussi vrai que dans le travail de spécification. En effet, au moment de rédiger les specs de votre projet, vous constaterez toutes les zones d'ombre qui figurent à la périphérie des wireframes... Les fameux cas marginaux, les limites de l'interface, les règles spécifiques.

Clarifier le fonctionnement de l'interface

Concrètement, il s’agit de décrire et de spécifier les règles technico-fonctionnelles relatives à un gabarit en vue de la production du support (création des éléments graphiques périphériques, intégration html, développement).

Les spécifications fonctionnelles répondent à des questions simples à formuler, mais difficiles à décrire...

• Que se passe-t-il si l'utilisateur clique ici ?
• Comment réagit l'interface lorsque l'internaute active ces filtres.
• Quelles informations délivrent la base de donnée dans ce là.
• Combien d'articles peuvent être affichés simultanément ?
• Comment se comporte le menu de navigation lorsqu'on ajoute une section ?
• Combien de produits peuvent être ajoutés au panier ?
• Combien de temps le panier reste-t-il actif ?

Les spécifications fonctionnelles aident le développeur front-end à saisir le détail de toutes les interactions de surface. De même, les spécifications techniques sont précieuses pour le développeur back-end dans la programmation du site.

Afin d’optimiser le coût des spécs et surtout d'économiser du temps dans la rédaction des spécifications, vous pouvez optez pour une méthode radicale : documenter et spécifier uniquement les grandes interactions. C'est mieux que rien... Toutefois ce n'est pas idéal car le travail sera superficiel là où les spécifications se doivent d'être consistantes...

Voici les objectifs à couvrir dans la rédaction de spécifications fonctionnelles :

• Clarifier le périmètre fonctionnel du site.
• Eocumenter le fonctionnement du projet et les implications techniques.
• Préciser le détail des ajustements de l’interface en réponse aux actions.
• Expliciter les variables d’ajustement, les comportements dynamiques.
• Formaliser la gestion des cas particuliers.
• Assurer la fluidité de la production et du développement.
• Spécifier les interactions front-back.

Les spécifications générales peuvent faire office de document contractuel et de preuve juridique. Les spécifications peuvent vous prémunir en cas de litige.

Comment rédiger une spécification fonctionnelle ?

Le choix de la méthode pour spécifier votre projet digital dépend du contexte de votre projet.

En règle générale, l'écriture des spécifications intervient après la phase de conception détaillée, plus précisément après la validation des maquettes graphiques. Il s'agit du cas le plus courant et le plus pertinent, dans la mesure où les spécifications ont vocation à documenter et décrire les règles d'interface, ce qui impliquent qu'elles aient été formalisées au sein de maquette fonctionnelle et graphique...

D'autre part, les spécifications ont aussi vocation à guider le travail de développement front-end et back-end en levant toutes les incertitudes sur de potentielles interprétations du design.
En effet, la conception fonctionnelle et graphique matérialisent le design de l'information, mais pas le design de l'interaction... C'est effectivement la principale difficulté, dans la rédaction des spécifications, que de lever toutes les ambigüités autour des interactions. Il ne doit pas y avoir de place pour les interprétations sur les comportements de l'interface. Toute mauvaise interprétation peut faire perdre du temps en production.

Par ailleurs, sur le plan des méthodes de rédaction des spécifications, il peut y avoir deux cas de figure...

1. La conception n'a pas été réalisée :
Dans ce cas, les spécifications fonctionnelles servent à décrire le fonctionnement souhaité. Ce ne sont plus des spécifications. C'est une expression de besoin. Néanmoins, dans le milieu professionnel, ce cas de figure existe et l'usage est répandu d'utiliser le terme de spécification. Cependant, ces documents sont beaucoup moins précis qu'une spécification génrale détaillée, car il est difficile pour le rédacteur d'anticiper tous les cas de figure du design d'interaction que révèle une conception détaillée...

2. La conception a été effectuée :
Dans ce cas, les spécifications fonctionnelles servent à éclaircir toutes les règles de fonctionnement esquissées dans les travaux de conception.

Idéalement, la rédaction des spécifications fonctionnelles prend appui sur un document support : des maquettes fonctionnelles ou des maquettes graphiques. On insère des captures d'écrans dans les spécifications pour illustrer les descriptions.
Il est recommandé de privilégier les maquettes graphiques définitives et validées, qui représentent la version la plus proche du produit fini, avant la phase de production.
Les wireframes subissent énormément de modifications en cours de conception, et les interprétations graphiques peuvent différer des choix opérés par le concepteur, notamment dans la ventilation des éléments à l'écran. Dans certains cas, des modifications de fonctionnement peuvent résulter des choix opérés par la direction artistique. Ainsi, il est plus sage de spécifier sur la base des créations graphiques.

Ecrire les spécifications

Il n'y a pas de méthode type pour spécifier le fonctionnement de votre projet.
La meilleure pratique consiste à bien vérrouiller l'envergure fonctionnelle en maquettant tous les écrans du dispositif. Vous pourrez alors vous appuyer sur des bases tangibles pour écrire le rapport de spécifications.

Les spécifications débutent par un ensemble de considérations générales sur les enjeux et les objectifs du projet. Il ne faut pas y perdre trop de temps et considérer cette introduction comme une contextualisation du projet :

• Enjeux du projet.
• Objectifs du projet.
• Grands axes stratégiques.

Dans certains cas, on reprend une partie de la documentation de conception, notamment certains travaux relatifs au champ disciplinaire du design d'expérience utilisateur. Là aussi, soyez aussi brefs que possible :

• Grands profil de cible du projet (persona).
• Principaux parcours d'utilisation adressés par le dispositif.

Ensuite, il faut très vite embrayer sur le choix des solutions techniques et leurs raisons, en expliquant pourquoi vous avez opté pour tel CMS ou pour une création sur-mesure ex nihilo...

• Choix de la solution technique.
• Choix des webservices (suivi du trafic...).
• Contrainte et cadre d'utilisation de l'outil de gestion de contenu (Joomla, Drupal, Wordpress, Magento, Prestashop...) ou de la solution sur-mesure qui est créée.
• Langages de développements.

Dans un environnement adaptatif, vous devez préciser les principales versions de terminaux ciblés, autour des points de rupture. Les problématiques de responsive web design ont considérablement alourdis le volume des spécifications...
En effet, là où il suffisait de spécifier un écran à l'âge de pierre, on doit aujourd'hui expliciter les comportements de l'interface pour les ordinateurs, les tablettes, les smartphones...

Mais, pas de panique.
D'abord, vous n'aurez pas les maquettes graphiques projetées en responsive pour chaque écran.
D'autre part dans les spécifications, on s'attache seulement à décrire les cas particuliers. Si le périmètre fonctionnel est identique (iso fonctionnel comme disent les spécialistes), alors vous n'aurez pas beaucoup de travail supplémentaire. Il y a une marge d'interprétation pour le développeur front-end. Aux équipes de conception de s'entendre sur ce qui doit être illustré sur le plan du design de l'information, en matière de responsive design...

• Version grand écran desktop.
• Version ordinateur portable.
• Version tablette.
• Version smartphone.

Naturellement, toute considération relative à la conception fonctionnelle et éditoriale est bienvenue. Ainsi, il n'est pas hérétique de préciser quelques informations au sujet du scope éditorial du projet, avant de détailler tout le fonctionnement de la coquille encore vide :

• Principes d'arborescence éditoriale.
• Design de navigation en réponse à l'envergure éditoriale et fonctionnelle.

Dans les premières parties des spécifications, vous allez vous attacher à décrire l'envergure fonctionnelle du dispositif :

• Inventaire fonctionnel du dispositif digital : liste des fonctionnalités, listing des gabarits types.
• Veillez à disposer d'une nomenclature précise pour nommer chacun des éléments fonctionnels du projet (important pour la documentation, la mémoire du projet, et surtout pour la production).

Si l'équipe de conception a pris le soin de réaliser une arborescence fonctionnelle, c'est à dire une cartographie de la structure du fonctionnement, insérez ce schéma dans vos spécifications.
Si ce document n'existe pas, vous avez une bonne raison de le créer : en effet, l'arborescence fonctionnelle figure le fonctionnement général du dispositif digital, en projetant visuellement les imbrications entre les différents gabarits. Faîtes ce travail et vous gagnerez du temps dans vos spécifications.

Vous devez être en mesure d'opérer des regroupements de gabarits autour des grandes zones fonctionnelles du projet. Ces espaces fonctionnels doivent être suffisamment originaux et indépendants pour faire l'objet de règles communes... Par exemple, pour un site ecommerce, on peut regrouper les gabarits autour de la descente catalogue, de l'espace client, du processus de commande. Attachez-vous à classer les gabarits types du dispositif autour de grandes sections.

Pour chaque section, vous allez lister les gabarits, et vous procèderez à une revue détaillée de chaque écran, pour chaque zone fonctionnelle.

Avant de vous lancer dans les spécifications fonctionnelles des écrans, consacrez une section générale sur les règles transversales du fonctionnement de l'interface. En principe, vous devriez pouvoir vous appuyer sur un zoning macro du dispositif. Le zoning figure les grandes zones fonctionnelles à l'écran (identification de l'émetteur, navigation, corps de page, zone de rebond). Utilisez le zoning pour expliquer les principes persistants de l'interface.

Vous pouvez alors commencer à rédiger les spécifications pour chaque écran. La méthode est simple :

• Insérez une capture d'écran de la maquette graphique.
• Affectez un numéro à chacun des composants de l'interface.
• Décrivez le comportement de chaque composant d'interface, numéro par numéro.
• Soyez clair, factuel, et neutre dans les descriptions.
• Concentrez-vous sur les règles de fonctionnement.
• S'il s'agit de spécifications générales fonctionnelles et techniques, veillez à différencier les descriptions fonctionnelles des descriptions techniques (une couleur fait l'affaire).

Pour faire simple, en matière d'écriture des spécifications, dîtes-vous que n'importe qui doit être en mesure de comprendre le fonctionnement de l'interface et le comportement des fonctions à l'écran. Oui, n'importe qui, et même votre arrière-grand-mère :) ! C'est la seule chose à garder en tête pour être parfaitement clair sur le plan du style. Restez descriptif. Factuel. Et exhaustif. Détaillez toutes les limites, et envisagez tous les cas de figure...

Il faut qu'on puisse comprendre le fonctionnement de l'interface pour chaque gabarit du projet. Une personne qui n'a pas connaissance du projet doit être capable de comprendre comment fonctionne l'interface. C'est ça une bonne spécification fonctionnelle. Il n'y a pas de format type.

Autrement dit, il s’agit de procéder à la définition minutieuse du fonctionnement de l’interface, du macro vers le micro, pour chaque gabarit et toutes les fonctionnalités.

Les implications front de toutes les fonctions sont détaillées ainsi que les impacts en back-office. Bien évidemment, les spécifications fonctionnelles détaillent tous les comportements de l’interface en réaction à l’agrégation de données dynamiques (gestion des tris, des priorités d’affichage, etc.).

Si vous disposez de plusieurs projections adaptatives pour chaque écran, faîtes des captures et décrivez uniquement ce qui change...

Après avoir décrit le fonctionnement de chaque écran, il conviendra également de s'intéresser à des considérations complémentaires :

• Structure des dossiers et des sous-dossiers.
• Nomenclature et chartage des noms de documents et des images.
• Accès en ligne aux éléments : adresses FTP, accès complémentaires aux webservices.
• Accès aux solutions de suivi des indicateurs de fréquentation.

Exemple de plan de spécification

Voici un récapitulatif pour vous aider à organiser le plan de vos spécifications fonctionnelles et techniques. C'est un exemple de plan de spécifications générales. Une trame de spécs quoi. Ce n'est pas un plan de spécification juste, c'est juste un plan de spécification, à adapter à chaque projet... Ainsi, pour les grandes lignes des spécifications :

• [0] Contact et liste de diffusion
• [1] Contexte du projet
• Enjeux du projet.
• Objectifs du projet.
• Grands axes stratégiques.
  [...]
• [2] Principes de design UX
• Grands profil de cible du projet (persona).
• Principaux parcours d'utilisation adressés par le dispositif.
  [...]
• [3] Principes techniques
• Choix de la solution technique.
• Choix des webservices (suivi du trafic...).
• Contrainte et cadre d'utilisation de l'outil de gestion de contenu ou de la solution sur-mesure.
• Langages de développements.
  [...]
• [4] Principes de design adaptatif
• Version grand écran desktop.
• Version ordinateur portable.
• Version tablette.
• Version smartphone.
  [...]
• [5] Envergure éditoriale
• Principes d'arborescence éditoriale.
• Design de navigation.
  [...]
• [6] Envergure fonctionnelle
• Inventaire fonctionnel du dispositif digital : liste des fonctionnalités, listing des gabarits types.
• Cartographie du fonctionnement - arborescence fonctionnelle.
• Règles de nomenclature.
  [...]
• [7] Spécifications fonctionnelles générales et spécifications techniques
• Regroupements des templates par zone fonctionnelle.
• Règles de fonctionnement transversales.
• Règles de fonctionnement spécifique par écran...
• Complément de spécification responsive de l'écran en question si besoin...
• Capture d'écran et spécification fonctionnelle + spécification technique de chaque élément de l'écran.
  [...]
• [8] Structure documentaire
• Structure des dossiers.
• Nomenclature et chartage des noms de documents et des images.
• Accès en ligne aux éléments : adresses FTP, accès complémentaires aux webservices.
• Accès aux solutions de suivi des indicateurs de fréquentation.
  [...]
• [9] ...
• Vous êtes libre d'augmenter la densité du rapport :).

Démarche pour spécifier votre projet

Lorsque vous spécifier votre projet, veillez bien à traiter les :

• Spécifications du fonctionnement transversal du projet.
• Spécifications du fonctionnement précis des éléments de navigation.
• Spécifications du fonctionnement spécifique de chaque gabarit.
• Spécifications du fonctionnement de chaque fonctionnalité et chaque module.

Les profils les plus préposés pour la rédaction des spécifications fonctionnelles ne sont autres que ceux qui ont conçu le projet : "Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément"...
Pouvez-vous attendre d'une personne extérieure au projet qu'elle rédige les spécifications de votre dispositif ? Cela paraît étrange, et pourtant ça arrive très souvent dans les projets digitaux de taille critique : la tâche fastidieuse des spécifications fonctionnelles est externalisée.

Travaux complémentaires aux spécifications fonctionnelles

En amont des spécifications, l'inventaire fonctionnel dresse la liste de tous les composants fonctionnels du dispositif. La projection des composants au sein de l'arborescence fonctionnelle permet de visualiser le design d'interaction.

Les specs fonctionnelles peuvent introduire de la lourdeur dans le projet... quoi de mieux qu'un prototype pour expliciter le projet !

Les spécifications fonctionnelles les plus claires sont celles qui s'appuient sur des wireframes précis : le wireframing n'est jamais très loin des spécifications. Par ailleurs, un prototype fonctionnel permet d’illustrer visuellement certaines explications parfois ambigües engagées par les spécifications.