L’ingénierie des exigences au secours de la gestion des user stories

L’un des principaux défis auxquels sont confrontées les équipes lors de l’organisation et du suivi du développement des stories est de savoir comment identifier les interdépendances entre les stories, ainsi que les impacts sur les différents composants systèmes associés…

Les user stories sont l’un des outils centraux utilisés par les équipes de développement pour construire des systèmes dans un cadre agile. Cependant, l’identification et le suivi des interférences des stories n’est pas toujours facile. De même, tous les frameworks agiles ne permettent pas de visualiser les composants du système influencés par les user stories nouvelles et livrées. Dans cet article, nous verrons en quoi une approche d’ingénierie des exigences permet de relever ces défis rencontrés par les équipes lors de l’utilisation des user stories.

Un précédent article, intitulé « La conception logicielle, Spécification vs User Story »¹, a permis de mettre en avant une comparaison des avantages et des inconvénients de l’utilisation des spécifications et des user stories. Dans cet article-ci, il est intéressant de pousser cette discussion un peu plus loin. Comme indiqué auparavant, il est possible de profiter à la fois des mots de spécification / exigences et des user stories.

En effet, la structure et le côté proactif de l’ingénierie des exigences peuvent soutenir, et améliorer le côté réactif et agile du développement et du suivi des user stories. Par conséquent, cet article dresse un parallèle entre la structure des exigences et les user stories. Il propose également une approche de définition et de suivi des user stories basée sur un processus itératif d’ingénierie des exigences.

I/ Qu’est-ce qu’une user story ?

Il existe de nombreuses définitions d’une user story dans la littérature spécialisée et académique. Elles sont principalement décrites en fonction de différentes perspectives et niveaux de granularité. Cependant, sur la base des points communs, nous pouvons dire qu’une user story est une courte phrase décrivant le besoin de quelqu’un pour atteindre un but.

Les caractéristiques majeures d’une user story

• Elle adopte une approche plus axée sur l’utilisateur pour décrire les différentes fonctionnalités d’un système.
• Et elle met en évidence la valeur d’une fonctionnalité plutôt que de les spécifier techniquement.

En d’autres termes, les user stories décrivent les désirs des utilisateurs plutôt que les exigences du système.

Elles sont largement utilisées dans les méthodologies agiles de développement de systèmes logiciels. En général, ces stories suivent certains modèles prédéfinis. L’un des plus connus est le suivant² :

En tant que <l’utilisateur concerné>, je veux <le besoin de l’utilisateur> afin de <l’objectif à atteindre>

De nos jours, les user stories ne sont souvent composées que d’une phrase, et complétées par des diagrammes, des critères d’acceptation, etc.

Lors de la rédaction et de la discussion des user stories, l’équipe (développeurs, analystes métier, etc.) doit diviser les stories en sous-parties plus petites. En effet, des stories plus petites peuvent être utiles pour éviter les erreurs d’interprétation et les ambiguïtés. Cela permet également de se concentrer sur un besoin et un objectif uniques et explicites.

User stories et agilité

Pour organiser des éléments de travail sur des projets agiles, il existe de nombreux cadres et méthodes proposés sur le web et dans la littérature. Par exemple, une équipe peut organiser ses différents éléments de travail tels que³ :

• User Story : une courte phrase indiquant que l’utilisateur a besoin du point de vue de l’utilisateur. Il peut varier en termes de niveau de granularité.
• Epic : un ensemble de user stories interdépendantes et cohérentes.
• Initiative : un ensemble d’épopées qui mènent vers un objectif commun.

L’un des principaux défis auxquels sont confrontées les équipes lors de l’organisation et du suivi du développement des stories est de savoir comment identifier les interdépendances entre les stories (nouvelles et livrées) ainsi que les impacts sur les différents composants systèmes associés.

En effet, difficile d’avoir une vision du système et de rechercher des stories quand des centaines, voire plus, sont liées à une seule épopée. De plus, un processus de définition et de suivi des stories n’est pas toujours mis en place par l’équipe ou par l’entreprise. Même en utilisant des outils de gestion de projet agiles dédiés (tels que JIRA), il n’est pas toujours facile de voir les relations et les interdépendances des user stories.

II/ Ingénierie des exigences

Les exigences définissent le système à construire et à améliorer. Dans un sens plus large, les systèmes peuvent correspondre à n’importe quel logiciel, unité commerciale ou même à toute une organisation. De plus, les exigences sont des énoncés exprimant les besoins et les contraintes des clients, concernant le fonctionnement du système, de manière formalisée.

Les exigences sont normalement écrites sur un ton impératif. La norme ISO / IEC / IEEE 29148⁴ utilise l’expression ‘‘The system shall…’’ qui est la manière recommandée pour rédiger les exigences. Par exemple : « L’application doit être accessible via différentes plates-formes ».

Les exigences peuvent également être affinées pour améliorer leur sémantique et pour énoncer explicitement les besoins et les désirs du client. En effet, les exigences peuvent être affinées en sous-exigences, ce qui clarifie les principales idées qui sous-tendent l’exigence parent.

L’intérêt des sous-exigences

Parfois, les sous-exigences sont également utiles pour séparer deux idées complémentaires présentes sur l’exigence parent. Lorsque les (sous-)exigences ne peuvent plus être décomposées, elles sont appelées exigences atomiques. Dans le sens inverse, l’ensemble des exigences définissant un système sont appelées « une spécification ». Ainsi, nous avons ce qui suit :

• Exigence : une déclaration décrivant le besoin du client.
• Spécification : un ensemble d’exigences définissant un système.

L’ingénierie des exigences est un processus itératif de définition des exigences système. Il englobe l’analyse du contexte (les problèmes, les points douloureux et les besoins du client), la formalisation des exigences, la modélisation des exigences concernant les composants systèmes associés et la validation des exigences par le client. Notez que la phase de modélisation n’est pas toujours utilisée par les organisations.

Par conséquent, le processus peut être utilisé sur différentes méthodologies de développement de système (par exemple, cycle en V ou cadres agiles). Dans cet article, nous nous intéressons à la manière dont l’ingénierie des exigences peut être utilisée sur des méthodes agiles. Et plus précisément à la manière dont elle peut être utile pour définir, surveiller et suivre les user stories.

III/ Les liens entre l’ingénierie des exigences et les cadres agiles

Selon le Scrum Guide, le Backlog Produit est « une liste ordonnée de tous les éléments identifiés comme nécessaires au produit. Il constitue l’unique source d’exigences pour tout changement à apporter au produit. » Donc, la ‘‘Definition of Done’’ décrit les critères qui doivent être respectés (tests techniques et fonctionnels validés, tests de non-régression validés, etc.) pour qu’une exigence du système (produit) soit considérée comme finie et prête à être déployée.

Le terme user story est originaire de la méthode ‘‘Extreme programming ’’⁵. En revanche, il est utilisé aujourd’hui dans la plupart des méthodologies agiles pour décrire un élément du Backlog Produit lié aux besoins des utilisateurs. En ce sens, la condition des satisfactions (acceptence criteria) représente simplement un test d’acceptation de haut niveau qui sera vrai une fois l’user story terminée². En d’autres termes, il s’agit des tests fonctionnels pour valider si l’user story finie correspond aux souhaits exprimés en amont.

En prenant une vision plus large des méthodologies agiles, on peut argumenter qu’une user story est similaire à une exigence utilisateur. De plus, l’ingénierie étant une méthodologie de conception et de développement des exigences d’un système – non figée à un seul cadre de développement de système –, il est possible de la concilier avec des développements effectués dans des cadres agiles ou même en cycle V. Dans ce cas, la DoD définira les critères à vérifier pour qu’une exigence du système corresponde aux besoins et aux attentes des utilisateurs.

IV/ Une approche pour définir et suivre les user stories

Nous pouvons voir dans les sections précédentes que la structure d’organisation des user stories et des exigences est un peu similaire. Donc, sur la base des structures décrites, nous pouvons dessiner le parallèle suivant :

• Comme l’user story se veut une description du besoin de l’utilisateur, on peut dire qu’elle se situe au même niveau qu’une exigence.
• Comme nous l’avons observé, l’user story peut être découpée. Ainsi, ce découpage peut être comparé au processus de raffinement d’une exigence.
• De plus, une épopée étant l’ensemble des user stories interdépendantes, nous pouvons l’associer à une spécification.
• Enfin, une initiative peut être liée au système à construire.

Notez que nous ne disons pas qu’une exigence est sémantiquement égale à une user story, mais plutôt qu’elle peut y être associée. Ainsi, nous pouvons utiliser ces associations pour appliquer des approches d’ingénierie des exigences. Un exemple de ces associations est présenté dans l’image ci-dessous :

Les étapes du processus d’ingénierie des exigences

Une fois ces associations réalisées, nous pouvons appliquer les 4 phases génériques d’un processus d’ingénierie des exigences⁶ pour la gestion des user stories.

• Élicitation.

C’est la première phase d’un processus d’ingénierie des exigences. Il s’agit de collecter des informations pertinentes et de définir les exigences sur la base d’analyses et de discussions entre les parties prenantes. L’élicitation des user stories de nos jours est assez similaire. Mais elle implique de se concentrer davantage sur la partie discussion, en adoptant principalement une perspective utilisateur.

Tant qu’un environnement collaboratif et ouvert est maintenu lors de l’identification des user stories, l’approche actuelle est une bonne pratique, car elle permet à différents acteurs (analystes métier, développeurs et hommes d’affaires) de partager leurs points de vue.

• Formalisation.

La deuxième phase repose sur la formalisation. Des approches mathématiques et logiques peuvent être utilisées pour représenter formellement les exigences, ainsi qu’un langage naturel basé sur un modèle prédéfini. Cependant, lors de la rédaction d’une user story, un standard moins formel est proposé. En effet, une variante de phrases mentionnant explicitement le triptyque « utilisateur, besoin, objectif » est recommandée.

Néanmoins, ces phrases écrites ne sont pas toujours représentatives de l’ensemble du sens de l’user story. Ainsi, en tant qu’approche plus formelle, l’inclusion systématique de critères d’acceptation et tout autre support pour lever l’ambiguïté et les doutes peuvent contribuer à l’exhaustivité de la story. Des scénarii d’utilisation, des BDD et des solutions techniques peuvent également être ajoutées ultérieurement lorsque les stories sont hiérarchisées.

• La modélisation.

La modélisation constitue la troisième phase du processus. Ici, les exigences sont modélisées en fonction des fonctionnalités souhaitées et des composants systèmes associés. C’est aussi lors de cette étape que l’on identifie généralement les relations (dépendances) entre les exigences. Elle se fait sur la base des relations entre les composants du système concernés.

Pour les besoins de modélisation, on peut utiliser une variété de langages de modélisation tels que UML, ArchiMate et BPMN. De plus, nous soutenons que nous pouvons appliquer une approche similaire à la modélisation des user stories. En effet, ces modèles peuvent fournir une vue holistique du système et des user stories associées. De même, nous pouvons également observer les relations entre les user stories et leurs composants systèmes associés.

À titre d’exemple, nous avons modélisé l’user story en utilisant ArchiMate⁷ comme suit : « En tant qu’utilisateur final, je souhaite accéder au service de streaming via un navigateur web ».

Un tel modèle peut également être utile pour suivre les user stories et identifier les impacts sur le système lors de sa correction ou de son amélioration (en ajoutant ou en supprimant des user stories).

• Validation.

Enfin, la dernière phase est la validation par les clients. Sur la base de la discussion, de la définition et de la validation des user stories, l’équipe peut hiérarchiser les stories avec l’aide des utilisateurs et démarrer le développement.

Notez que l’ensemble du processus est itératif. Les résultats ne sont pas figés. L’équipe peut examiner, ajouter et découper des user stories en fonction des besoins du client et de l’entreprise. Les solutions fonctionnelles et techniques peuvent être repensées et pivotées si nécessaire.

Afin de suivre les user stories créées, plusieurs outils sont disponibles actuellement. L’article « Les supports applicatifs pour les méthodologies agiles. Et vous, vous utilisez quoi ? »⁸ présente une comparaison. À vous de choisir laquelle vous convient le plus.

Conclusion

Dans cet article, nous avons établi un parallèle entre le développement, et la gestion des exigences et des user stories. Nous avons suggéré que les deux puissent bénéficier de l’ingénierie des exigences. Ainsi, nous avons proposé une approche basée sur l’ingénierie des exigences pour développer et pour gérer des user stories dans un contexte agile.

Notez que cette approche n’a pas l’intention de générer un document de 300 pages avec des diagrammes et des flux d’informations, mais aide plutôt à structurer les informations système. En effet, un système d’information bien organisé peut éviter de perdre du temps lorsque l’on essaie de rechercher « cette story d’accessibilité », d’améliorer la lisibilité et, espérons-le, d’aider les nouveaux arrivants (nouveaux employés ou nouveaux membres de l’équipe).

N’oubliez pas que dans le Manifeste Agile⁹, il est indiqué « des logiciels opérationnels plus qu’une documentation exhaustive » et non« AUCUNE documentation ». Par conséquent, fournir des user stories bien construites et concises est essentiel pour maintenir et pour améliorer le système en main.

Sources 

1. La conception logicielle, Spécification vs User Story. https://meritis.fr/methodo/conception-logiciel-specification-vs-user-story/. Mireille Ranaivondrambola
2. User Stories. https://www.mountaingoatsoftware.com/agile/user-stories. Mike Cohn
3. Epics, Stories, Themes, and Initiatives. https://www.atlassian.com/agile/project-management/epics-stories-themes. Max Rehkopf
4. ISO/IEC/IEEE 29148: System and Software Engineering – Life Cycle Processes – Requirements Engineering. https://standards.ieee.org/standard/29148-2018.html. International Organization for Standardization (ISO).
5. Beck, Kent (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN 9780201616415. OCLC 41834882.
6. Enterprise interoperability assessment: a requirements engineering approach. https://doi.org/10.1080/0951192X.2020.1736636. Gabriel S. S. Leal, Wided Guédria & Hervé Panetto
7. The ArchiMate® Enterprise Architecture Modeling Language. https://www.opengroup.org/archimate-forum/archimate-overview
8. Les supports applicatifs pour les méthodologies agiles. Et vous, vous utilisez quoi ?. https://meritis.fr/methodo/supports-applicatifs-methodologies-agiles-utilisez-quoi/ Daria RYAZANTSEVA
9. Manifesto for Agile Software Development. https://agilemanifesto.org/