Spécifications et analyse du besoin : pourquoi elles comptent

Quand un projet informatique dérape, on accuse souvent la technique. Dans bien des cas, le point de départ est ailleurs : le besoin a été mal compris, ou compris différemment par chacun. L’analyse du besoin et les spécifications servent à éviter cela.

L’analyse du besoin : comprendre le problème avant la solution

Il s’agit de comprendre ce qui se passe aujourd’hui : qui fait quoi, avec quels outils, où est le blocage, quelles contraintes s’imposent (réglementation, budget, délais). On parle avec les personnes qui utiliseront la solution, pas seulement avec celles qui la financent.

Les spécifications : écrire ce qui sera réalisé

Les spécifications décrivent ce que la solution doit faire, dans un langage que le métier et les développeurs comprennent tous les deux. Elles n’ont pas besoin d’être longues ; elles contiennent :

• les cas d’usage : qui fait quoi, dans quel but ;
• les règles de gestion : les règles de calcul, les cas particuliers ;
• les critères d’acceptation : comment on saura que c’est réussi ;
• les priorités : indispensable, important, souhaitable.

Pourquoi elles comptent

• S’accorder avant de dépenser : tout le monde parle du même projet.
• Chiffrer sérieusement : on estime un périmètre connu.
• Recetter objectivement : les critères d’acceptation servent de référence.
• Maîtriser les évolutions : toute demande nouvelle se compare au périmètre écrit.
• Transmettre : le projet reste compréhensible si une personne part ou si un nouveau prestataire reprend.

Une erreur de compréhension corrigée au début coûte en général beaucoup moins qu’une erreur découverte une fois le développement terminé.

Les questions à poser avant de développer

1. Qui utilisera la solution, et dans quelles situations ?
2. Quel problème précis doit-elle résoudre ?
3. Comment le travail se fait-il aujourd’hui ?
4. Que se passe-t-il en cas d’erreur ou d’exception ?
5. De quelles données a-t-on besoin, et d’où viennent-elles ?
6. Quelles contraintes s’appliquent (protection des données, sécurité, délais) ?
7. À quoi verra-t-on que le projet est réussi ?

Et en méthode agile ?

Spécifier n’est pas réservé aux projets en cycle en V. En méthode agile, on écrit des récits utilisateur avec leurs critères d’acceptation, par petits lots. Le principe est le même : se mettre d’accord sur ce qui sera fait avant de le faire.