L’efficacité d’un recueil du besoin dans le cadre d’un cahier des charges ou autre (EB, SFD, Epic, US, Feature) s’évalue en partie au regard du nombre des 4 « productions » clés qu’il a permis de collecter. C’est la collecte de ces productions qui va guider le questionnement, ceci ayant pour effet bénéfique d’augmenter le nombre de questions utiles et de garantir  vos résultats.

4 clés pour être plus efficace

Avant de prendre un exemple concret, voici déjà la liste des productions clés d’un cahier des charges que nous allons comptabiliser :

• exigences (ou fonctionnalités) : c’est ce qui est voulu par le commanditaire, ce que le système doit faire ou permettre de faire,
• motivations (ou raison d’être) : pourquoi a-t-on besoin de pouvoir réaliser telle action dans le système cible, une motivation pouvant être macro (au niveau des enjeux d’un projet) ou micro (au niveau de l’exigence),
• concepts métier (ou du vocabulaire métier) bien compris, c’est-à-dire définis,
• exemples.

Remarque : en mode Agile, la subtilité consiste à marier la fonctionnalité avec la motivation et l’utilisateur cible.

Risques à ne pas collecter les productions d’un cahier des charges

Voici quelques risques à ne pas collecter les productions clés d’un cahier des charges au cours des ateliers de recueil du besoin.

Productions d’un cahier des charges : les exigences

Concernant les exigences, si l’on n’en a pas alors on ne peut pas définir les besoins du commanditaire. Dans les faits, si je ne dis pas clairement « je veux ça, je veux ça et ça », personne ne pourra me le faire. Je vais donc formuler clairement le besoin, de manière incisive, en exigences ou user stories (exemples de  phrase typique : « je veux… » ou « le système doit… »).

Dit différemment, sans fonctionnalités, il ne peut pas y avoir de système à mettre en place.

Productions d’un cahier des charges : les motivations

Concernant les motivations profondes, certains vous diront très vite que ce n’est pas nécessaire à leur niveau et pourtant, si l’on n’en a pas, alors :

• on ne peut pas comprendre pourquoi une exigence est nécessaire, quels seraient les impacts si on ne l’avait pas,
• en cas d’arbitrage (suppression, dépriorisation, manque de budget ou de temps), on ne sera pas en mesure de la défendre, de la « justifier » et de faire prendre conscience aux décisionnaires des impacts à assumer sur le système cible,
• on est dans l’incapacité de répondre à l’un des objectifs du recueil du besoin : collecter le besoin profond et non le besoin de surface. En effet, sans motivation, toutes les exigences sont dès lors du même niveau d’importance, ce qui rend tout travail de priorisation impossible.

Productions d’un cahier des charges : les concepts métier

Concernant le vocabulaire métier, c’est du simple bon sens que de se rendre compte qu’il est impossible de comprendre l’objet de la discussion si les concepts manipulés ne sont pas connus. C’est tout particulièrement handicapant dès lors que nous sommes en charge de l’animation de la réunion, mais aussi tout le long du projet. Il s’agit donc de connaître (et partager le temps du projet) parfaitement chacun des concepts propres à l’organisme / au service dans lequel nous intervenons. « Connaître » signifiant donc « être en mesure d’en donner une définition validée par le métier, avec des exemples en démontrant la véracité. »

On distingue généralement deux grandes catégories de concepts métier :

• ceux du langage « commun »,
• ceux relevant d’un langage spécifique à l’organisme, voire même au service.

Par exemple, « client » est un terme commun dont tout le monde est en mesure de donner une définition précise, avec des exemples. Mais votre définition est-elle bien celle de l’organisme faisant l’objet de votre prestation ? Ne laissons pas de place à l’induit et assurons-nous le plus tôt possible que notre vision des choses est la bonne. Non pas en demandant « naïvement » ce qu’est un client mais plutôt en reformulant notre compréhension des choses et en la faisant valider par l’interlocuteur métier.

Ainsi, un client peut être un particulier, une entreprise, une association, l’organisme fait-il une distinction entre tout cela ? Quelle action permet de devenir l’un de leurs clients : payer, signer un contrat, s’inscrire sur une liste ? Quelles sont les données clés d’un client ? Etc.

Productions d’un cahier des charges : les exemples

Collecter des exemples est primordial, que ce soit pour illustrer une fonctionnalité ou un concept métier. En effet, cela permet d’ancrer le cahier des charges dans le réel, de sortir de l’abstraction et du théorique. C’est également très utile pour s’assurer que l’on a bien compris les choses, surtout lorsqu’on œuvre sur un sujet complexe.

Cas pratique

A présent que ces bases sont posées, prenons un cas pratique et voyons quelles productions clés d’un cahier des charges nous pourrions en tirer. Pour ce faire, voici un exemple d’un besoin que pourrait exprimer un commanditaire :

« Nous voulons moderniser le système de gestion des règlements client. Il faut pouvoir indiquer au niveau d’un client un délai de règlement. Nous avons besoin de pouvoir rapprocher les règlements constatés en banque avec les factures émises, comme ça nous pourrons identifier les factures non encore réglées. On doit tracer toutes les actions de relance avec les réponses apportées par les clients. On veut pouvoir catégoriser les clients selon qu’ils sont bons payeurs, payeurs moyens ou très mauvais payeurs. En effet, on veut pouvoir blacklister des clients : avec certains ne plus renouveler de commandes et avec d’autres interrompre les contrats en cours. »

Classer les productions d’un cahier des charges

Dans un premier temps, il s’agit d’être en mesure de classer les informations transmises selon leur « type. »

Type de production	Production
Exigence	1.     indiquer au niveau d’un client un délai de règlement 2.     rapprocher les paiements constatés des factures émises 3.     identifier les factures non réglées 4.     tracer les actions de relance avec les réponses client 5.     catégoriser les clients 6.     blacklister un client
Motivation	1.     moderniser le système de gestion des règlements clients 2.     identifier les factures en souffrance 3.     identifier les mauvais payeurs, bons payeurs, etc. 4.     arrêter le renouvellement des commandes 5.     interrompre les contrats en cours
Concept	1.     Règlement 2.     Délai de règlement 3.     Client 4.     Catégorie de client 5.     Facture 6.     État de la facture (réglée, non réglée) 7.     Action de relance 8.     Réponse client 9.     Contrat 10.  État du contrat (en cours, etc.)

Nettoyer les productions d’un cahier des charges

A compter de  là, il est primordial de commencer par nettoyer la matière obtenue avant de chercher à ajouter d’autres choses. En effet, tant que cela n’a pas été parfaitement compris, tout ce que l’on pourra ajouter s’empilera sur un château de sable, jusqu’à l’inéluctable : tout s’écroule et l’on ne comprend plus rien. On tombe si facilement sur les taux d’échec du Chaos report…

Clarifier les productions d’un cahier des charges

Dans un premier temps, n’hésitons pas à clarifier tous les concepts, même les plus communs. Par exemple :

• La définition du client par l’organisme correspond-elle à votre vision ? Y a-t-il une typologie de client déjà en place autre que la catégorisation demandée ? Peut-on avoir des exemples de client ? Ce qu’ils achètent ?
• Concernant le règlement d’un client, sur quoi porte-t-il ? Et qu’est-ce que ce délai de règlement ?
• Qu’est-ce qui est facturé ? Réglé et non réglé sont-ils les seuls états possibles d’une facture ?
• Qu’est-ce qu’une action de relance ? Sur quoi porte-t-elle ? Quel est son but ? Concerne-t-elle uniquement les clients ? Peut-on avoir des exemples de relance ?
• En quoi consiste les réponses des clients ? Peut-on avoir des exemples ?
• Les contrats portent sur quoi exactement ? A quoi souscrivent les clients ?

Rapprocher les productions d’un cahier des charges : exigences et motivations

Ensuite, il existe évidemment un lien fort entre les exigences, qu’il faudra bien entendu détailler, et les motivations qui les animent.

Par exemple « indiquer au niveau d’un client un délai de règlement » est plutôt orienté « solution ». Il sera impossible de challenger le besoin tant que l’on n’a pas compris ce qu’est le délai et pourquoi cette information devrait être portée par le client.

• Pourquoi a-t-on besoin de rapprocher les règlements des factures ?
• Pourquoi est-il nécessaire de tracer les actions de relance ?
• Etc.

Rédiger les productions d’un cahier des charges

In fine, on constate que ces quelques lignes peuvent déjà donner lieu à une formalisation conséquente et de toute forme.

Rédiger des enjeux

Les enjeux de la demande avec :

• des objectifs (moderniser la gestion des règlements client pour identifier les factures non réglées, identifier les mauvais payeurs)
• des défauts actuels (corollaire des objectifs, sinon vous aurez forcément des problèmes…)
• un périmètre : les règlements client et les relances / réponses.

Modéliser un diagramme de flux

Un diagramme de flux et sa description littéraire avec :

• les acteurs suivants :
  • les clients,
  • la banque,
  • l’organisme et ses sous-acteurs : ceux qui effectuent les relances, ceux qui gèrent les règlements (si ce ne sont pas les mêmes, etc.),
• les flux suivants :
  • règlement,
  • facture,
  • relance,
  • réponse,
  • commande,
  • etc.

Modéliser un diagramme de classe

Un diagramme de classe et sa description littéraire construit sur les concepts identifiés ci-dessus.

Modéliser une architecture fonctionnelle

Une architecture fonctionnelle initiée sur la base des exigences identifiées ci-dessus et auxquelles s’ajouteraient d’autres exigences basées notamment sur le questionnement CRUD (Create, Read, Update, Delete) :

• créer un délai de règlement, le consulter, le modifier, le supprimer, l’associer à un client, etc.
• créer des catégories de client, les consulter, les modifier, les supprimer, les associer à des clients, etc.

Modéliser un diagramme d’état

Par extension, nous pourrions par exemple envisager de modéliser un diagramme d’état d’un client : comment passe-t-il de bon payeur à payeur moyen ou à mauvais payeur ? Quelles sont les règles de gestion qui régissent ces transitions ?

Modéliser un diagramme d’activité

Le diagramme d’activité de la gestion des règlements, intégrant le processus de relance, etc.

Conclusion

Sans ce travail intensif de classification des données et de creusage / clarification d’un sujet, nous resterons toujours à la surface des choses. Il ne sera pas possible de répondre aux objectifs du recueil du besoin que sont l’identification des besoins profonds, leur exhaustivité et leur non distorsion.

De même, il ne sera pas possible de rédiger un livrable d’un niveau de qualité élevé. En effet :

• nous n’aurons pas levé toutes les ambiguïtés de langage, au risque d’introduire de nombreux synonymes par exemple,
• la structure sera bancale du fait d’une mauvaise identification des productions (les informations seront mal classées),
• le document produit ne sera pas compréhensible de tous car aucun travail de définition / clarification des termes n’aura été effectué,
• etc.

Tout cela fait de notre travail un objet non pérenne, donc jetable.

En espérant que cet article vous sera utile. Vous êtes libre de vous inscrire à notre newsletter en dessous de l’article garantie 100% sans spam. Vous recevrez à cette occasion notre bonus, un mini guide pour bien commencer votre cahier des charges.

Au plaisir !