Exprimer les besoins de l'utilisateur à partir d'un cahier des charges

1. Objectifs

   • Expliquer le rôle d'un cahier des charges et ce qui le distingue des spécifications
   • Repérer les parties utiles au designer UI/UX dans un cahier des charges
   • Lire activement un cahier des charges pour en extraire acteurs, actions, contraintes et zones floues
   • Distinguer besoins fonctionnels et non fonctionnels
   • Rédiger des exigences claires, vérifiables et priorisées
   • Relier chaque écran au besoin d'origine grâce à la traçabilité

1. Présentation

   • Dans un projet réel, le travail ne commence pas toujours par des entretiens avec les utilisateurs : souvent, le client remet d'abord un cahier des charges, un document qui décrit ce qu'il attend de l'application.
   • Ce document est précieux, mais il est rédigé avec les mots du client : il mélange besoins, solutions et formules vagues. Le rôle du designer est d'en extraire les besoins des utilisateurs, de lever les ambiguïtés et de les reformuler en exigences sur lesquelles toute l'équipe pourra s'appuyer pour concevoir les écrans.

• Nous continuons avec BiblioCampus, notre application fictive de réservation de livres. Pour les activités, créez le dossier 11-cahier-des-charges/ dans votre dépôt GitHub ui-ux-design-bts.

1. Qu'est-ce qu'un cahier des charges ?

   • Le cahier des charges est le document dans lequel le client (la maîtrise d'ouvrage) décrit ce qu'il attend du projet : besoins, contraintes, délais et budget. Il décrit le quoi, pas le comment.
   • Le prestataire (la maîtrise d'œuvre) y répond ensuite en rédigeant des spécifications qui décrivent la solution :

1. Le plan type

   • Chaque cahier des charges est différent, mais on y retrouve généralement ces parties :

• La partie Périmètre est souvent négligée. Elle est pourtant essentielle : ce qui n'est pas prévu (« pas de lecture de livres en ligne dans cette version ») évite bien des malentendus.

1. Lire activement le cahier des charges

   • Lisez d'abord le document en entier, sans rien noter, pour comprendre le projet. Relisez-le ensuite en surlignant avec quatre couleurs :

1. Besoins fonctionnels et non fonctionnels

   • Un besoin fonctionnel décrit ce que l'application doit permettre de faire. Un besoin non fonctionnel décrit une qualité ou une limite : rapidité, sécurité, accessibilité, compatibilité…

1. Identifier les acteurs et leurs cas d'utilisation

   • Un acteur est un profil qui interagit avec l'application. Un cas d'utilisation est une action qu'il réalise pour atteindre un but. Le diagramme de cas d'utilisation donne une vue d'ensemble et fait apparaître les oublis :

1. Rédiger des exigences

   • Une exigence est une phrase courte et précise qui exprime un besoin vérifiable. Une bonne exigence :
     • commence par un acteur et un verbe d'action: « L'étudiant réserve… » ;
     • ne contient qu'une seule idée;
     • décrit le besoin, pas la solution graphique (pas de « bouton bleu en haut à droite ») ;
     • peut être vérifiée: on peut répondre par oui ou par non.
   • On regroupe les exigences dans un tableau, avec un identifiant, une priorité, la source dans le cahier des charges et un moyen de vérification :

1. Exemple 1 : de la phrase du client à l'exigence

   • Le cahier des charges indique : « Les emprunts sont limités à trois livres par étudiant. »
     • acteur: l'étudiant ;
     • type: non fonctionnel (une règle de gestion) ;
     • exigence: ENF-02 – Un étudiant a au plus trois emprunts en cours ;
     • vérification: la quatrième réservation est refusée avec un message qui explique pourquoi et propose de rendre un livre.
   • Remarquez que la vérification fait apparaître un besoin d'interface : un message clair, conforme au critère de gestion des erreurs vu en ergonomie.

1. Lever les ambiguïtés

   • Les mots flous du cahier des charges ne doivent jamais être interprétés seul. Chacun devient une question au client:

1. Exemple 2 : un besoin oublié

   • Le cahier des charges de BiblioCampus ne parle que des étudiants. En traçant le diagramme de cas d'utilisation, l'équipe se demande : qui enregistre les retours ?
   • Le client confirme que la bibliothécaire doit aussi utiliser l'application, sur un ordinateur de l'accueil. Ce profil a des attentes très différentes : aller vite pendant l'affluence, voir les retards d'un coup d'œil. Sans cette question, toute une partie de l'interface aurait été oubliée.

1. La traçabilité

   • La traçabilité relie chaque élément du projet à son origine. Elle permet de justifier chaque écran et de vérifier que tous les besoins sont couverts :

1. Exemple 3 : des exigences aux écrans

   • Une fois les exigences validées, on peut lister les écrans nécessaires et le parcours de l'utilisateur. Chaque écran indique les exigences qu'il couvre :

1. Activité 1 : lire un cahier des charges

   • Lisez cet extrait de cahier des charges, puis surlignez avec les quatre couleurs de la leçon :

• Vérifier : acteurs : étudiants, gestionnaire du restaurant ; actions : consulter le menu, réserver un repas, payer, indiquer un régime, connaître le nombre de repas, noter les repas ; contraintes : réservation la veille avant 20 h, paiement par carte étudiante, Android et iOS, livraison avant septembre, budget limité ; mots flous : « rapide », « simple », « serait un plus ».

1. Activité 2 : fonctionnel ou non fonctionnel ?

   • Classez ces besoins de CantineCampus :
     • a) L'étudiant consulte le menu de la semaine.
     • b) L'application fonctionne sur Android et iOS.
     • c) Le gestionnaire consulte le nombre de repas réservés.
     • d) Les réservations sont fermées à 20 h la veille.
     • e) L'étudiant indique son régime alimentaire.
     • f) Les données de paiement sont protégées.
   • Vérifier : a), c) et e) sont fonctionnels ; b), d) et f) sont non fonctionnels. Pourquoi d) est-elle une règle et non une action ?

1. Activité 3 : tracer le diagramme de cas d'utilisation

   • Dessinez le diagramme de cas d'utilisation de CantineCampus : acteurs, cadre de l'application, cas d'utilisation et liens.
   • Vérifier : les deux acteurs apparaissent ; chaque action de l'activité 1 est un cas d'utilisation ; vous vous demandez s'il manque un acteur (qui publie le menu ?).

1. Activité 4 : corriger des exigences

   • Un stagiaire a rédigé ces exigences. Indiquez le défaut de chacune, puis réécrivez-la :

• Vérifier : EX-01 n'est pas mesurable ; EX-02 n'a ni acteur ni verbe ; EX-03 est floue (« tout ») ; EX-04 contient deux idées dont une floue (« beau ») ; EX-05 décrit une solution graphique et non un besoin ; EX-06 regroupe trois exigences. Vos versions ont un acteur, un verbe et une seule idée vérifiable.

1. Activité 5 : préparer les questions au client

   • Relevez les zones floues du cahier des charges de CantineCampus et rédigez au moins six questions à poser au gestionnaire du restaurant.
   • Vérifier : vos questions sont ouvertes et précises, par exemple : « Que se passe-t-il si un étudiant ne vient pas chercher son repas ? », « Qui publie le menu, et quand ? », « Que signifie “rapide” pour vous ? ».

1. Activité 6 : construire le tableau des exigences

   • Rédigez le tableau des exigences de CantineCampus : identifiant, exigence, type, priorité MoSCoW, source et moyen de vérification. Visez au moins huit exigences.
   • Vérifier : chaque exigence fonctionnelle commence par un acteur et un verbe ; la note des repas est priorisée à part (« serait un plus ») ; chaque ligne a un moyen de vérification.

1. Activité 7 : écrire les récits utilisateur

   • Transformez quatre exigences fonctionnelles de CantineCampus en récits utilisateur, avec deux critères d'acceptation chacun.
   • Vérifier : chaque récit indique l'identifiant de l'exigence d'origine, ce qui assure la traçabilité.

1. Activité 8 : lister les écrans

   • À partir de vos exigences, dessinez la liste des écrans de CantineCampus et le parcours d'un étudiant qui réserve son repas.
   • Indiquez sous chaque écran les exigences qu'il couvre.
   • Vérifier : toutes les exigences « Must » sont couvertes par au moins un écran, et aucun écran n'existe sans exigence associée.

1. Activité 9 : jouer la réunion de validation

   • Par deux, l'un joue le gestionnaire du restaurant, l'autre le designer. Le designer présente le tableau des exigences et pose ses questions ; le gestionnaire répond et valide ou corrige.
   • Mettez à jour le tableau avec les réponses obtenues.
   • Vérifier : chaque réponse est notée, et le tableau final ne contient plus aucun mot flou.

1. Activité 10 : déposer votre travail sur GitHub

   • Regroupez dans 11-cahier-des-charges/README.md votre analyse, votre tableau des exigences, vos questions et votre liste d'écrans. Ajoutez les photos de vos schémas, puis envoyez le tout :

git add 11-cahier-des-charges
git commit -m "Ajoute la leçon sur l'expression des besoins à partir d'un cahier des charges"
git push

• Vérifier : le fichier README.md et vos images apparaissent bien sur la page GitHub du dépôt.

1. Erreurs fréquentes

1. À retenir

   • Le cahier des charges décrit le « quoi » attendu par le client ; les spécifications décrivent le « comment ».
   • On le lit d'abord en entier, puis activement : acteurs, actions, contraintes et mots flous.
   • Les besoins fonctionnels décrivent ce que fait l'application ; les non fonctionnels, comment elle doit le faire.
   • Une bonne exigence a un acteur, un verbe, une seule idée et un moyen de vérification.
   • Chaque mot flou devient une question au client, dont la réponse est validée par écrit.
   • La traçabilité relie le cahier des charges, les exigences, les récits utilisateur, les écrans et les tests.

Un cahier des charges dit ce que le client a écrit ; votre travail est de découvrir ce dont ses utilisateurs ont réellement besoin.