Nous avons vu qu’une approche séquentielle supposait produire en amont tous les documents nécessaires au développement d’un projet. Pour rappel, voici les différentes phases suivies :
Définition du projet : production des spécifications fonctionnelles
Conception de l’architecture : production des spécifications techniques
Codage : création du produit demandé
Recette : tests (automatiques et manuels)
Commençons par réfléchir, avec notre cliente Colette Tatou, aux spécifications fonctionnelles.
Présentation
Une spécification fonctionnelle décrit la manière dont un produit fonctionnera, entièrement du point de vue de l’utilisateur. Ici nous ne parlons pas de technique mais bien de fonctionnalités. Quel menu ? Quel écran s’affiche lorsque notre utilisateur entre “Nutella” dans le champ de recherche ?
Elle précise également quels sont les acteurs impliqués dans le projet et leur champ de responsabilité.
Contenu
Au même titre qu’un cahier des charges, le contenu des spécifications fonctionnelles dépend en grande partie de l’auteur.
Néanmoins, toute spécification fonctionnelle devrait contenir les champs suivants :
Un auteur (de préférence unique, le chef de projet de la maîtrise d’ouvrage)
Des scénarios utilisateurs,
Un aperçu sous forme de diagramme,
Des détails concernant chaque scénario utilisateur.
Pour Joël Spolsky, le fondateur de Trello et de StackOverFlow (entre autres), les spécifications fonctionnelles sont avant tout un outil d’aide à la décision. Elles doivent décrire tous les scénarios utilisateurs (que se passe-t-il si l’utilisateur oublie son mot de passe ? Ou si la recherche ne donne aucun résultat ?) afin d’aider le plus possible les développeurs. Ces derniers ne devraient pas se poser de questions sur les fonctionnalités mais se concentrer sur les problématiques techniques. Cela les aide à être plus performants et allège les aller-retours avec le client.
C’est pourquoi Joël ajoute quelques éléments à ses spécifications fonctionnelles :
Une décharge disant que ce n’est pas la version finale de la spec, qu’elle évoluera. En effet, il préconise une évolution constante du document qui suit l’avancée du projet. Il s’agit d’un parti pris qui peut être très intéressant dans le cadre de projets impliquant peu d’intervenants (une dizaine de développeurs).
Des non-buts : non, nous n’allons pas développer cette fonctionnalité. Cela permet de prévenir, en amont, certaines questions.
Des questions en suspens : les spécifications étant vues par Joël comme un outil d’aide à la décision, il est important d’y inclure les points restés sans réponse ou à tester.
Des annotations pour certaines équipes : elles seront lues par certaines personnes et ignorées par d’autres. Cela permet de centraliser les questions éventuelles. Par exemple, certaines notes concerneront les rédacteurs de la documentation ou les développeurs.
À l’inverse, les spécifications fonctionnelles des très gros projets seront conséquentes et moins flexibles.
Conseils de rédaction
Adaptez-vous à votre audience
Cela peut paraître évident mais vous ne rédigerez pas les mêmes spécifications si votre équipe est composée de 40 développeurs travaillant pour le ministère des finances que si vous officiez chez Google. Ils auront d’ailleurs très certainement un premier document de travail sur lequel vous pourrez vous appuyer.
Keep it stupid, simple
Votre audience a beau être intelligente, elle n’aime pas se poser des questions en lisant vos specs. Pour être efficace, utilisez des phrases courtes qui représentent véritablement votre propos. Évitez les longs paragraphes et, dès que vous le pouvez, préférez un schéma explicatif à une grande description. Tout est plus simple en image !
Soyez drôle
Dans la mesure du raisonnable et en fonction de votre audience, écrivez des specs agréables à lire. En effet, un des grands arguments à l’encontre des specs est que personne ne veut les lire et que, par conséquent, elles ne servent à rien. Mais imaginez si en place et lieu de “l’utilisateur X” vous parlez de Jocelyne Zgara, 20 ans, habitante du merveilleux village Mouilleron-le-captif dans la Loire ? Cela donne tout de suite plus envie de se plonger dans un document de 100 pages, n’est-ce pas ?
Soyez flexible et incluez vos collaborateurs
Dans la mesure du possible, soyez conscient que vos spécifications peuvent évoluer en fonction des retours de votre client et des équipes techniques. Incluez vos collaborateurs pendant le processus de rédaction en leur demandant leur avis et en prenant en compte leurs retours éventuels. Cela les impliquera dans le projet et les motivera pour la suite, tout en vous aidant à améliorer de manière significative vos spécifications.
Quand les spécifications fonctionnelles sont rédigées et validées par le client, il est temps de créer les spécifications techniques et de concevoir l’architecture !
