« Nous avons besoin d’une application de réservation » désigne une catégorie de produit, mais laisse la plupart des décisions ouvertes. Qui propose les rendez-vous ? Les clients peuvent-ils annuler ? Un membre de l’équipe doit-il approuver les modifications ? Un brief devient utile lorsqu’il relie ces questions au travail réel de l’entreprise. Commencez par un processus représentatif, puis ajoutez les rôles, les contraintes et les décisions de validation nécessaires à sa réalisation.
Sur cette page
Décrivez le processus actuel et le problème
Écrivez la séquence depuis l’événement qui déclenche le travail jusqu’au résultat qui le termine. Incluez les passages de relais entre personnes et systèmes. Dans une activité de réservation donnée à titre d’exemple, un client demande un créneau, le personnel consulte un calendrier partagé et la confirmation est envoyée manuellement. Le problème peut être des réservations qui se chevauchent ou un manque de visibilité pour les clients. Identifiez la difficulté importante avant de proposer une liste d’écrans.
- Quelles informations déclenchent la demande ?
- Qui décide si elle peut être traitée ?
- Qu’est-ce qui indique à chacun qu’elle est terminée ?
Donnez à chaque utilisateur une responsabilité claire
Distinguez les besoins des clients, du personnel et des administrateurs. Un client peut consulter ses propres réservations, le personnel gérer un planning et un administrateur déterminer qui dispose de cet accès. Décrivez les corrections autant que les actions habituelles. Si le personnel déplace une réservation, qui voit le changement et que devient le créneau initial ? Ces règles aident les équipes de conception et de développement à parler du même produit.
Délimitez la première version
Pour l’exemple de réservation, une version ciblée pourrait permettre au client de choisir un créneau libre, de recevoir une confirmation et de retrouver sa réservation, tandis que le personnel gère les disponibilités et les annulations. Si les réservations récurrentes ou les récompenses de fidélité peuvent attendre, placez-les dans une liste distincte en précisant pourquoi. Ne supprimez pas une étape de support qui rend le parcours convenu utilisable simplement parce qu’elle est moins visible que l’écran principal.
- Incluez un parcours complet, de la demande au résultat.
- Incluez les outils d’accès et de correction nécessaires à son fonctionnement.
- Fixez une condition de réexamen pour les idées reportées.
Listez les dépendances et signalez les inconnues
Identifiez les calendriers existants, les services de paiement, les dossiers clients et les autres systèmes dont l’application pourrait avoir besoin. Notez les langues, les appareils ciblés, les besoins de migration et les contraintes métier. Distinguez une exigence confirmée d’une question : « Le calendrier existant peut-il fournir les disponibilités en temps réel ? » constitue une information utile pour le brief. Le supposer peut masquer un travail d’investigation et fausser le périmètre initial.
Transformez les exigences en exemples vérifiables
Formulez des vérifications de recette en langage simple. Pour le parcours de réservation de l’exemple : lorsqu’un client réserve un créneau disponible, la réservation apparaît dans son compte et dans le planning du personnel ; si un autre client tente de réserver le même créneau limité à une seule réservation, il ne peut pas recevoir une deuxième confirmation. Convenez de la manière dont une annulation rétablit la disponibilité. Ces exemples révèlent des décisions que « gestion des réservations » laisse indéfinies. Nommez les personnes qui les examineront et approuveront les changements de périmètre.
- Vérifiez des tâches complètes avec des utilisateurs représentatifs.
- Consignez les questions séparément des exigences approuvées.
- Désignez une personne pour arbitrer les priorités contradictoires.
Intégrez le passage à l’usage quotidien
Expliquez qui administrera l’application, intégrera les données existantes et accompagnera les utilisateurs après le lancement. Identifiez les formations ou les documents de transfert dont l’équipe a besoin. Précisez comment les problèmes seront signalés et les mises à jour examinées. Ces détails permettent d’inclure dans le périmètre de développement le chemin concret entre une démonstration fonctionnelle et un produit que l’entreprise peut exploiter.