AILES : Le travail d'un développeur : spécifier (Besoin)

Les spécifications
Si le cahier des charges a été clairement écrit, des spécifications ont normalement été établies. Elles décrivent tant sur le plan fonctionnel que sur celui de l'interface Homme-Machine (I.H.M.) ce que doit faire le logiciel. Il s'agit d'un document contractuel, signé par le client (MOA) et la société (MOE). Cf. aussi MOE et MOA : Christophe Thiry réagit, afin de ne pas confondre besoin et solution!

Cahier des charges et spécifications
Quelle est la différence avec le cahier des charges ? Ce dernier (le cahier des charges) représente l'expression du besoin vu par le client. Il est en général... peu précis. S'il peut suffire à concevoir directement une (petite) application, il se révèle insuffisant pour de gros projet.
C'est là qu'interviennent les spécifications qui reprennent les besoins du client mais exprimés cette fois par la société qui va réaliser le logiciel.
Cette description du besoin doit donc rester compréhensible par le client (donc en français bien rédigé), mais doit aussi être très précise.

Principe des spécifications
Tout ce qui y est décrit doit être réalisé (même si c'est "stupide"!).
L'avantage des spécifications réside, normalement, dans la maîtrise que l'on en a de sa rédaction : c'est la société qui va coder qui rédige ce document. Elle ne doit donc surtout pas se "piéger" elle-même en spécifiant des solutions trop difficiles à mettre en œuvre.
Attention, en aucune façon les spécifications ne décrivent *comment* les développeurs vont s'y prendre pour respecter les descriptions des spécifications.
Ce qui veut dire que dans ce type de document, chaque phrase compte : même la plus anodine peut receler des trésors de difficultés techniques qui pourraient mettre en péril la conduite d'un projet.
(cf. également les illustrations sur le sens du mot bug)
Or, les spécifications représentent un document contractuel! Il n'est pas question de prendre arbitrairement des libertés avec. Toute modification doit être concertée avec le client...
Si les modifications sont suffisamment importantes pour faire évoluer de façon notable le besoin du client, il sera alors procédé à l'établissement d'un avenant, véritable mini-contrat formalisant cette évolution de besoin.
Dans l'idéal, vous vous appuyez sur une architecture, sachant que les spécifications fonctionnelles en sont une des vues architecturales majeures.

Utilisation des spécifications
Pour le développeur que vous êtes, c'est la "bible". En la lisant, vous savez ce que vous allez devoir coder, mais vous ne savez pas comment.
Vous devez respecter la spécification qui vous est fournie, même si vous la trouvez "peu pertinente" : il est courant d'assister dans un projet à des dialogues entre codeur et chef de projet du style :
- « Mais pourquoi tu veux que je code cette fonctionnalité, elle est débile, et puis on peut faire bien plus efficace en codant telle autre fonctionnalité ?...»,
- « Oui, je sais, mais ce que tu proposes ne fait pas parti des spécifications, donc on ne le fait pas. J'essaierai éventuellement de faire passer le message au client afin de faire évoluer la spec', voire de faire un avenant au contrat afin d'inclure les modifications techniques que tu proposes.». D'où l'importance des spécifications.

Spécifier
Certains développeurs expérimentés peuvent être amenés à participer aux spécifications de telle ou telle partie.
Le piège à éviter est donc celui de "l'imprécision". Il faut à la fois convaincre le client que son besoin est bien atteint, et se convaincre que c'est faisable "facilement" sur le plan technique.
Ce document contractuel important sera toujours validé par vos supérieurs et connaîtra une évolution en accord avec le chef de projet, le responsable commercial et le client.
(cf. question en entretien d'embauche)

Toujours Spécifier ?
Soyons clair : sur de petits projet, il n'est pas rare que vous n'ayez aucune spéc', voire même aucun cahier des charges. Dans des projets où le cycle de production est très court (la finance, par exemple), les besoins vous sont exprimés oralement en vitesse. Vous attaquez directement la modélisation, en documentant le plus possible vos diagrammes objets et en priant pour que les suivants les comprennent suffisamment pour les faire évoluer!
Pourquoi spécifier ? Parce qu'en cas de problème ou retard suite à des exigences farfelues et inattendues de la part du client, vous avec toujours cette expression *contractuelle* du besoin sur laquelle vous appuyer pour régler tout litige...
C'est l'un des moyens de mieux formaliser et maîtriser la difficile relation entre maîtrise d'ouvrage et maîtrise d'œuvre.