Exprimer un besoin logiciel sans être informaticien

Exprimer un besoin logiciel ne demande aucune compétence technique. Cela demande de la précision sur votre métier. La difficulté n'est pas de savoir comment un programme fonctionne, mais de décrire ce que le travail exige vraiment, y compris ses exceptions. Voici comment procéder.

Décrire un usage, pas une solution

La formule « il nous faut un bouton d'export » désigne une solution. Le besoin, lui, est ailleurs : « la comptabilité doit récupérer chaque mois les heures validées, sans les ressaisir ». Formulé ainsi, il laisse ouvertes plusieurs réponses possibles, dont certaines plus simples que le bouton imaginé.

Une phrase de besoin tient en trois parties :

• Qui : le rôle concerné, par exemple un technicien, un responsable d'agence, un client.
• Quelle action : ce que la personne doit pouvoir faire.
• Pourquoi : le résultat attendu, qui justifie l'action.

Exemple : « en tant que technicien, je dois pouvoir clôturer une intervention depuis le lieu du chantier, afin que le client reçoive son compte rendu le jour même ».

Ajouter les règles et les exceptions

Une action seule ne suffit pas. Ce sont les règles qui font la valeur d'un outil, et ce sont elles que l'on oublie le plus souvent. Pour chaque besoin, notez :

1. Les conditions : qu'est-ce qui doit être vrai pour que l'action soit possible ?
2. Les champs obligatoires et ceux qui restent facultatifs.
3. Les droits : qui a le droit de faire cette action, qui a seulement le droit de la consulter ?
4. Les cas particuliers : l'annulation, la correction après coup, le dossier urgent qui saute une étape.
5. Ce qui arrive ensuite : une notification, un changement de statut, une écriture dans un autre logiciel.

Les exceptions se découvrent en posant une question simple à chaque étape : « et si ce n'est pas le cas habituel, que faites-vous ? ».

Joindre des exemples réels

Un exemple vaut mieux qu'une description abstraite. Rassemblez, en masquant les données personnelles :

• un dossier complet tel qu'il existe aujourd'hui, du début à la fin ;
• les documents produits : devis, rapport, bon de commande ;
• un extrait des fichiers utilisés, avec leurs colonnes réelles ;
• un cas qui s'est mal passé, et la raison.

Ces pièces répondent d'avance à des dizaines de questions et révèlent des règles que personne ne pensait à énoncer.

Séparer l'indispensable du souhaitable

Tout besoin écrit n'a pas le même poids. Classez chaque ligne en trois niveaux : indispensable à la mise en service, utile mais reportable, confort à envisager plus tard. Ce classement évite les discussions sans fin quand il faudra arbitrer. Le sujet est détaillé dans l'article consacré à la façon de démarrer par une version minimale.

Ce qu'il ne faut pas écrire

Les termes vagues se glissent partout. Un besoin bien écrit permet de répondre par oui ou par non à la question : « est-ce fait ? ».

Faire relire par ceux qui feront le travail

Avant d'envoyer votre document, faites-le relire par deux personnes qui utiliseront l'outil chaque jour. Elles repéreront ce qui manque, les cas oubliés et les formulations qui ne correspondent pas à leur réalité. Un besoin validé par ses futurs utilisateurs évite des corrections coûteuses après la livraison. Les rubriques attendues dans un document plus formel figurent dans l'article sur le cahier des charges d'une application web.

NexSecure traduit les besoins métier en applications, dans le cadre de son offre de développement web sur mesure.