lecoindesjeux

Rédiger une spécification fonctionnelle détaillée

Une Spécification Fonctionnelle Détaillée, plus souvent appelée SFD, est un document qui contient l’ensemble des règles de fonctionnement de votre jeu et qui en théorie est rédigé avant de commencer tout développement. Elle complète le cahier des charges qui a pour vocation principale de présenter votre projet et les différents éléments de jeu.

Utilité

Si cette étape peut sembler fastidieuse car importante en terme de temps à consacrer, elle apporte beaucoup d’avantages durant la phase de développement et permet de se poser les bonnes questions avant de rentrer « dans le dur ».

Il y a deux points de vue qui s’opposent sur l’intérêt de rédiger un tel document pour votre jeu. Il y a ceux qui y voient une perte de temps et qui préfèrent se lancer le plus vite possible dans la phase de programmation. Cette approche présente l’avantage de pouvoir assez rapidement disposer d’une version jouable, après tout, de nombreux jeux et applications ont vu le jour en procédant ainsi. Et il y a ceux qui voient un peu plus loin qu’une première mouture du jeu et qui savent qu’ils seront très vite confrontés à des problématiques auxquelles ils n’avaient pas pensé.

Pour ma part, j’ai eu l’occasion de travailler des deux manières, que ce soit pour des applications personnelles ou dans le cadre de projets professionnels. Je peux témoigner aujourd’hui que l’absence d’une phase de réflexion organisée envoie un projet dans le mur à presque tous les coups.

Les avantages de la SFD

Ils sont multiples :

  •  Se poser les bonnes questions au bon moment : cette phase de réflexion permet de se projeter précisément dans ce que sera le jeu. En découpant votre projet en modules, vous vous rendrez compte tout de suite des problèmes ou limites auxquelles vous n’aviez pas pensé en rédigeant votre cahier des charges.
  • La phase de programmation ne doit être consacrée qu’à la programmation ! Il n’y a rien de plus déstabilisant que de se rendre compte d’un problème de logique dans votre jeu qui va vous faire revoir une à une  toutes les lignes de code que vous venez d’écrire… De plus, vous aurez suffisamment de problèmes techniques qui se présenteront à vous pour remplir vos journées, inutile d’en rajouter :)
  •  Si vous travaillez en équipe, votre document sera une base de travail précieuse pour un collègue à qui vous confierez le développement d’une partie du projet. Qui plus est, vous pouvez soumettre votre document à une personne extérieure au projet qui aura tous les éléments pour donner son avis et vous apporter des éléments de réflexion.
  • Aujourd’hui tout est bien clair dans votre tête, vous consacrez vos journées entières à votre jeu, vous en avez une vision très précise, mais qu’en sera-t-il dans 3 mois ? Ce document a aussi pour intérêt de coucher vos idées pour vous permettre de vous remémorer en détail les caractéristiques de votre jeu lorsque vous serez passé à autre chose.
  • Ce document vous fera aussi gagner du temps lorsque vous devrez rédiger la règle du jeu qui est une étape longue et fastidieuse ! Vous disposerez de toutes les règles de gestion dans un unique document, il vous suffira alors de reformuler ce que vous avez rédigé afin d’en faire quelque chose d’utile et convivial pour le joueur.

Méthode de rédaction

Maintenant que vous êtes convaincus, vous voudrez en savoir plus j’imagine ? Voici la méthode que j’utilise depuis plusieurs années, évidemment libre à vous de compléter ou modifier cette structure de document selon vos besoins.

1ère étape : Introduction

Objet du document : pour que toute personne intégrée au projet puisse comprendre le but du document, présentez simplement le but du document en expliquant que vous abordez les aspects fonctionnels uniquement et en décrivant la structure que vous utiliserez.

Objectif et cible : il s’agit d’un résumé du cahier des charges, dans lequel vous présentez votre projet et décrivez les principaux éléments de jeu. Ce paragraphe pourra servir d’accroche aux joueurs lorsque vous rentrerez dans la phase de promotion du jeu.

Historique : décrivez les dates marquantes du projet : premières idées, cahier des charges, maquettes, versions du document etc.

2ème étape : Les modules

Vous allez découper votre application en sous parties afin d’en retirer plusieurs modules. Ce n’est pas un problème si certains de vos modules sont très liés, le but est de vous permettre de travailler par lots pour vous faciliter la tâche.

Par exemple, imaginons que vous vous lanciez dans un jeu d’élevage de hamsters, vos modules pourraient être : la nourriture, les cages et équipements, la reproduction, les achats/ventes, les maladies

Puis, vous utilisez la même structure pour chaque module

  • Accès : comment le joueur accède aux pages composant le module. C’est l’occasion d’indiquer les pages qui nécessiteront une connexion du joueur. Ces accès pourront vous permettre ensuite de dresser une cartographie du site.
  • Maquette : faite à la main, sous Paint ou déjà en html/css, la maquette est un bon moyen de retranscrire l’image que vous vous faites de votre application et de faire comprendre la vision que vous en avez.
  • Informations : listez l’ensemble des informations que vos écrans doivent présenter.
  • Actions possibles : quelles sont les interactions entre le joueur et les pages
  • Règles de gestion : le dernier mais non des moindres : détaillez toutes les règles dont vous vous servirez : formule de calcul, condition d’affichage, traitements exécutés après action du joueur, comportement de la page etc. Si besoin, découpez en sous parties pour ne pas perdre en clarté.

3ème étape : Annexes

Intégrez tous les documents utiles au projet. Il peut s’agir de sources d’informations utiles à votre projet que vous aurez trouvé sur le net ou ailleurs.

Si vous ne rédigez pas de documentation consacrée aux aspects techniques, je vous conseille de venir mettre en annexe vos modèles conceptuels de données ainsi que tout diagramme UML que vous jugerez utile. Ce sont des documents très intéressants pour la compréhension du projet qui seront bénéfiques aux personnes avec lesquelles vous partagerez votre SFD.

 

Cette étape ne vous garantira pas de devoir tout de même revenir en phase de développement sur ce que vous aurez rédigé dans ce document mais si vous avez été complet dans votre analyse cela ne devrait se produire qu’occasionnellement.

 

Et vous avez-vous déjà eu l’occasion de rédiger un tel document? Quel est votre retour d’expérience?

About Manodor

Laisser un commentaire