Projet logiciel : tout ce que vous devez savoir sur l’expression de besoin

Comment s’y prendre pour bien définir son expression de besoin dans le cadre d’un projet de développement informatique ? Que doit contenir votre expression de besoin, comment la structurer ? Une expression de besoin décrit seulement ce qui est attendu, elle ne donne pas d’indications sur la manière dont il faut réaliser l’outil informatique.

Une bonne expression de besoin déterminera en grande partie le succès du projet. Nombreuses sont les donneurs d’ordre qui ne parviennent pas par manque d’expérience, d’accompagnement, de connaissances ou encore de rigueur, à définir intelligiblement une expression de besoin. S’ensuit une équipe à la réalisation qui va développer un produit informatique qui ne sera pas en accord avec les réelles attentes des utilisateurs finaux. Et pour cause, le besoin a été mal exprimé et donc mal transmis à l’équipe réalisatrice. Dans cet article nous allons vous révéler, pas à pas, autant sur le fond que sur la forme, comment bien construire une expression de besoin dans l’informatique : que ce soit pour un logiciel, une application web ou bien une application mobile.

Pourquoi faire une expression de besoin ?

Commençons par le commencement. Quel est l’intérêt d’une expression de besoin ? C’est simple, l’expression de besoin (acronyme EB) est le premier document qui est produit sur un projet, avant même le commencement du projet. Ce document existe et est à l’origine de tout ce qui va s’ensuivre. L’expression de besoin détermine si le projet va se lancer ou pas, le détail des besoins, le retour sur investissement. L’expression de besoins est envoyée en premier lieu aux décideurs puis à la maitrise d’œuvre (MOE).

Qui rédige l’expression de besoin ?

En général c’est à la maitrise d’ouvrage qu’incombe d’exprimer son besoin et de donc de la rédiger dans un document. La personne qui va rédiger l’EB peut se faire accompagner et conseiller par un prestataire de services informatiques ou par toute personne légitime en interne.

Après l’expression de besoin vient la rédaction du cahier des charges, retrouver un article spécifique au cahier des charges rédigé par nos soins.

Quelles sont les difficultés rencontrées dans la rédaction d’une expression de besoin ?

Les pierres d’achoppement qui peuvent être rencontrées :

• Quand le rédacteur n’a pas assez de recul ou d’expérience vis à vis du métier exprimé dans l’expression de besoin.
• Quand il est difficile d’exposer de façon claire le problème que va résoudre le logiciel à d’autres personnes.
• Dérapages quand les demandes sont surréalistes.
• Lorsque le rédacteur se cantonne seulement à décrire la partie fonctionnelle ou seulement la partie technique du projet.

Faut-il respecter des contraintes de mise en forme ?

Et oui ! Il est très important de respecter des règles de mise en forme pour une expression de besoin facile à déchiffrer, à diffuser et à modifier. Comme à l’accoutumée pensez à inclure dans votre document les mentions suivantes :

• Le nom de l’auteur.
• La fonction de l’auteur.
• La date de création du document.
• Les dates de modification du document.
• L’historique des versions du document.
• La natures des modifications implémentées avec l’auteur correspondant.
• La liste de diffusion : les noms et fonctions des personnes à qui le document a été diffusé.
• Glossaire en début de document pour expliciter les termes et sigles employés non connus de tous.

Que doit contenir l’expression de besoin ?

Pour être complète et donner une vue globale aux parties prenantes qui vont prendre connaissance du besoin, veillez à inclure dans votre document :

• Le positionnement/l’importance stratégique de l’entreprise donneur d’ordre et du produit à développer.
• Le calendrier des échéances attendu.
• Le type d’utilisateur visé par le produit à développer.
• Les cas d’usage que le produit va chercher à remplir : par exemple commander une pizza en ligne, s’abonner à un magazine, payer en bitcoin etc. On peut également appeler cela la description des besoins fonctionnels des utilisateurs finaux. Cette partie est cruciale. Si elle est mal appréhendée et exprimée, ça ne sert à rien de continuer le projet plus loin.
• Le contexte technique.
• Les contraintes de toutes sortes : technique, d’exploitation, contextuelle etc.

Comment parler du positionnement stratégique de votre produit ?

Votre produit revêt une importance stratégique si vous avez décidé de le réaliser. Cette partie révélatrice du pourquoi de votre logiciel, décrit l’importance du projet aux yeux des utilisateurs finaux. Détaillez les bénéfices du logiciel pour l’entreprise et les utilisateurs finaux.

Enfin, un autre point souvent omis par ceux qui rédigent l’expression de besoin est : que va-t-il se passer si le produit n’est pas développé et que le projet ne se fait pas ? Prendre le temps de détailler tous ces points va vraiment aider l’équipe impliquée dans le projet à le comprendre en profondeur et à se l’approprier.

Comment construire votre calendrier des échéances ?

L’annonce d’un calendrier des échéances réaliste et cohérent donne un trait de légitimité et de sérieux en plus à votre EB. Dans le calendrier du projet logiciel indiquez :

• A partir de quelle date le projet peut commencer.
• Il y a t-il une date limite de finalisation ? Cette date de finalisation est-elle incitative ou fondamentale ?
• Le calendrier des disponibilités des personnes concernées par le projet.

Comment bien décrire les utilisateurs finaux du logiciel visé ?

Plus vous décrivez de façon précise les utilisateurs finaux du projet qui sera développé plus vous donnez de la matière aux équipes de conception et de développement pour comprendre l’essence même des cas d’usage qu’ils devront mettre sur pied. Un autre levier de réussite et l’acceptation de l’outil par les utilisateurs finaux.

Les caractéristiques des utilisateurs finaux à exposer :

• Qui sont-ils, quel est leur profil ? Consommateur d’High Tech, médecins, étudiants, femmes célibataires, financiers etc.
• Combien d’utilisateurs sont visés ? Au total et de manière simultanée ? Combien d’utilisateurs vont-ils partager en même temps le même réseau ?
• Sont-ils habitués à l’utilisation des outils informatiques ? Évaluer leur degré d’aisance avec les solutions informatiques.
• Découpage :
  • Qui seront les administrateurs du logiciel ?
  • Qui seront les utilisateurs simples du logiciel ?

Et pour chacun quelles seront leur tâches et leurs utilisations du logiciel.

Comment décrire les besoins fonctionnels et le contexte technique ?

Dans la partie besoins fonctionnels vous décrivez de façon neutre chaque besoin fonctionnel de l’utilisateur final. C’est-à-dire décrire un par un les cas d’usage de l’application. Exemple :

• B01 – L’utilisateur se crée un espace personnel.
• B02 – L’utilisateur consulte le catalogue produit.
• B 03 – L’utilisateur paye par Paypal.
• B 04 – L’utilisateur se désabonne.
• B 05 – L’utilisateur contacte le service client par chatbot.

Décomposer dans le détail, ni trop ni pas assez.

Nommés et numérotés les besoins pour une meilleur lecture et référence par la suite.

Vous pouvez ensuite prioriser les besoins et les regrouper par catégories.

Enfin pensez évidemment à décrire les aspects techniques :

• Sur quels types de supports physiques le logiciel sera-t-t-il utilisé ?
• Quels systèmes d’exploitation sont visés ?

Si vous avez besoin d’un accompagnement au plus près pour rédiger une expression de besoin professionnelle ou pour vos développement de logiciel informatique faites appel à nous.

Copyright images : unsplash.com