Lorsque vous souhaitez faire évoluer votre application ou votre site, il est important de décrire de façon détaillée votre besoin, ou plus globalement ce qu’il y a dans votre tête. Pour ne rien oublier, voici un modèle pour comprendre comment décrire une fonctionnalité pour votre application mobile, votre site web, ou encore votre back-office d’administration.
Quelques conseils de rédaction
Ces conseils s’appliquent aussi bien pour la rédaction d’un cahier des charges que pour la rédaction d’une fiche fonctionnelle (ou plus généralement dans tous vos documents descriptifs).
- Être simple : pas de fioriture, aller droit à l’essentiel ! Vous pouvez par exemple utiliser les listes à puces qui permettent de s’affranchir des longues phrases et de ne lister que l’essentiel.
- Être concret : penser à l’utilisateur et son usage réel, mais aussi à votre lecteur, donner un exemple concret pour visualiser facilement la fonctionnalité !
- Être le plus exhaustif possible :
– Écrire les choses même si elles semblent évidentes
– Lister ce que l’on peut faire
– Lister ce que l’on ne peut pas faire
Comment décrire une fonctionnalité ?
Nom de la fonctionnalité
Trouvez un nom pour la fonctionnalité : simple, compréhensible et surtout unique.
Description rapide
Donnez une explication de la fonctionnalité : à quoi sert-elle ? Comment s’insère t-elle dans le parcours utilisateur de l’application ?
Cibles, cas d’usages et contextes
Expliquez à quoi va servir la fonctionnalité, à quels utilisateurs et dans quel contexte. Listez tous les cas d’usages de la fonctionnalité et leur contexte, en illustrant par des exemples concrets. Lorsque l’on utilise les méthodes agiles, on parle de User Stories. Chaque User Story doit être associée à une ou plusieurs cibles (ex : utilisateur, superviseur, administrateur).
Exemple de spécifications fonctionnelles :
- Utilisateur A + B :
- Cas d’usage : une fois le devis reçu, l’utilisateur peut le consulter et y répondre.
- Contexte : demande un temps de réflexion et de renseigner de nombreuses informations. L’utilisation se fait plutôt sur Desktop, hors-mobilité.
- Utilisateur C :
- Cas d’usage : lorsqu’un utilisateur reçoit un message, il doit pouvoir le visualiser et y répondre.
- Contexte : Nécessite une interaction en temps réel (mobilité)
- Utilisateur D :
- N’a pas accès à cette fonctionnalité.
- etc
Priorité
Donnez une priorité de réalisation par rapport aux autres fonctionnalités. Si vous avez du mal à prioriser vos fonctionnalités entre elles, pensez à placer vos fonctionnalités sur une matrice impact/effort.
Pré-requis
Quels sont les pré-requis pour accéder à cette fonctionnalité ?
Par exemple :
- avoir un compte client et être connecté
- que l’agenda de l’utilisateur ait été créé
- avoir reçu au moins un message
- …
Détails de la fonctionnalités et des sous-fonctionnalités
Listez dans le détail toutes les sous-fonctionnalités de la fonctionnalité, par exemple en répondant à « Est-ce que l’utilisateur peut/ne peut pas… ? «
- Consulter la liste de…
- Consulter tous les détails de…
- Créer…
- Modifier…
- Supprimer…
- Trier…
- Filtrer…
- Envoyer…
- …
Listez également les interactions potentielles avec d’autres fonctionnalités, par exemple :
- Depuis cette fonctionnalité, il faut pouvoir accéder aux paramètres de l’application
- Il faut pouvoir retourner à l’accueil
- On souhaitera consulter la liste des établissements de l’utilisateur
- Déclenche une notification push
- Envoi un e-mail de confirmation
- …
Indiquez tout autre information utile, par exemple :
- Principalement utilisé en mobile
- Existe déjà sur un autre outil utilisé par la cible mais pas très pratique
- Exemple d’un site “comme sur Le Bon Coin”
- Source des données : liste des devis à récupérer dans notre ERP
- …
Après avoir expliqué tout cela, peu de chance qu’il y ait incompréhension entre le résultat attendu et la réalisation ! Mais pas de panique, il n’est pas indispensable que vous ayez les réponses à toutes ces questions. L’idée est avant tout de sortir tout ce que vous avez dans la tête ; on est là pour penser au reste.