Un Récit est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l'utilisateur. Il est aussi possible d’utiliser les cas d’Utilisation si une expression des besoins en UML a été modélisée.

Les méthodes Agiles actuelles s’appuient sur de nouvelles formes d’expression des exigences : Récits d’utilisateur, Cas d’utilisation, Modélisation CRC. La fiche d’expression d’un besoin dans le formalisme des Récits Utilisateurs est simplement une fiche bristol (détail sur la figure suivante).

La notion de « récit » peut amener à une forme d’estimation en « Points de Récits » mais pour des raisons d’expériences pratiques, j’utilise personnellement l’estimation en « Ideal days » (même s’il n’y a pas beaucoup de journées vraiment idéales). 

Une technique propre à UML comme les Points de Cas d’Utilisation[1] (Use Cases) peut aussi être envisagée. Un Cas d’Utilisation modélise un service. Il représente un ensemble de séquences d'actions qu'un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système. Mais attention, Points de Récit (User stories) et Cas d’utilisation ou (Use cases), même s’il s'agit de deux modes de représentation des exigences utilisées par les méthodes Agiles, n'ont ni la même portée, ni le même niveau de détail (comme le précise le site QualityStreet.fr) :

§  Le Récit se décrit en une courte phrase (Rôle -> But) alors que le Cas d’Utilisation est beaucoup plus riche en informations. Il possède un Titre (le but), est lié à un Acteur, propose un résumé, et surtout, décrit un déclencheur, un scénario nominal, les variations à ce nominal, des options alternatives, ainsi que tous les cas d'erreur et leur mode gestion. Il peut décrire aussi les règles métiers et les données.

§  Le Récit propose uniquement un but, pas une séquence d'actions. Il se lit donc plus facilement.

§  Le Récit correspond souvent et seulement à l'un des scénarios (nominal ou alternatif) du Cas d’Utilisation, parfois à une simple activité utilisateur.

§  Un Point de Récit ne nécessite pas un travail d'analyse aussi poussé que le Cas d’Utilisation, il émerge plus rapidement (en 1 ou 2 ateliers de travail).

§  Les Points de Récit sont rédigés (en principe) sur des cartes : leur durée de vie est limitée, et ils n'ont pas pour vocation à être conservés (contrairement aux Cas d’Utilisation). Or, ce besoin de traçabilité peut être réel.

§  Les Points de Récit reposent sur un mode oral, collaboratif, de proximité : ils sont discutés (entre client et développeur), et tout n'est pas rédigé (contrairement aux Cas d’Utilisation). Or ce besoin de formalisme peut lui aussi être réel (gros projets, équipe importante, offshore...).

§  Les Points de Récit contiennent des tests d'acceptation (rédigés au dos de la carte); les Cas d’Utilisation sont une base solide et efficace pour les tests fonctionnels mais ceux-ci sont réalisés plus tard et ailleurs.

§  Un Point de Récit doit être implémenté et testé en une itération. Un Cas d’Utilisation peut être traité sur plusieurs itérations (scénario nominal sur l’un, scénarios alternatifs sur l’autre) en fonction des risques à lever.

§  Cas d’Utilisation ou Points de Récit : le choix va impacter le mode d'estimation et de planification du projet (Technique des Points de Cas d'Utilisation ou Technique des Points de Récit associée à la vélocité d'une itération).

§  Les relations entre Points de Récit ne sont pas toujours évidentes. Le problème est moindre pour les Cas d’Utilisation, notamment grâce aux diagrammes qui les accompagnent.