C’est une question qui se pose naturellement lorsqu’une organisation souhaite mettre en place l’agilité dans ses projets. Pour y répondre, il convient de revenir aux fondamentaux de l’ingénierie des exigences.
Revenons à la notion d’exigence. L’exigence est une « caractéristique observable de l’extérieur d’une entité souhaitée » (Alan Davis). C’est donc une vue « boîte noire » d’un produit. Une exigence ne doit pas décrire l’intérieur de la boîte mais uniquement ce qui est visible de l’extérieur. Par conséquent, une exigence n’est pas et ne doit pas être une description d’une solution concrète. Partant de cette définition, et compte tenu qu’un produit (un système) est souvent décomposer en sous-systèmes, nous constatons que plusieurs niveau d’exigences peuvent coexister, tout va dépendre de l’endroit où se porte l’attention.
L’exigence représente le QUOI. Elle doit être justifiée et doit par conséquent être reliée à un objectif de haut niveau d’une partie prenante, le POURQUOI. L’exigence ne décrit pas le COMMENT. Le COMMENT doit être décrit dans les spécifications de conception, d’architecture, de tests…
POURQUOI ? (pour quelle raison) objectifs
QUOI ? exigences
COMMENT ? spécifications
Les normes internationales (IEEE, CMMi, ISO) ont défini le terme exigence en utilisant trois définitions complémentaires :
- Une exigence est une condition ou une capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif.
- Une exigence est une condition ou une capacité que doit posséder un produit (ou un composant de produit) pour remplir un contrat, se conformer à une norme ou tout autre document imposé formellement.
- Une exigence est une représentation documentée d’une condition ou d’une capacité du cas 1 ou du cas 2.
Cela montre clairement qu’il y a deux niveaux d’exigences à considérer pour un produit. En ingénierie des exigences, nous avons l’habitude de distinguer les « exigences utilisateur » (dans le cas 1) et les « exigences système » (dans le cas 2).
Les « exigences utilisateur » traduisent le problème à résoudre, l’opportunité à saisir pour un utilisateur, c’est le domaine du problème. Elles doivent être reliées à des objectifs de haut niveau que nous appelons des « buts ». Les exigences de haut niveau (les buts) sont décomposées en exigences plus fines par un mécanisme de scénarisation. La scénarisation permet d’envisager les différentes manières d’atteindre le but de haut niveau.
Selon l’IREB, les exigences utilisateurs peuvent être décrites sous la forme de buts et de scénarios. Les scénarios peuvent être regroupés en cas d’utilisation. Le niveau de granularité des exigences utilisateurs les plus fines peut être obtenu au niveau d’une étape d’un scénario.
Les « exigences système » sont une réponse aux « exigences utilisateur », c’est le domaine de la solution. On dit généralement que les « exigences système » satisfont les « exigences utilisateur ». Les deux niveaux d’exigences représentent toujours une vue « boîte noire » de notre système.
Dans une approche agile, le focus est mis sur les exigences de l’utilisateur et la valeur délivrée. La notion de User Story est très souvent employée pour décrire ce que souhaite l’utilisateur d’un produit. Elle s’exprime sous la forme :
« En tant que <utilisateur>, je souhaite <faire cela> afin de <atteindre un objectif>. »
Nous voyons que dans l’expression d’une User Story, un parallèle assez évident peut être fait entre le besoin de l’utilisateur <faire cela> et l’exigence utilisateur (le cas 1 défini plus haut), et <atteindre un objectif> avec un but de haut niveau.
Lors de l’identification des User Stories, il arrive très souvent que le souhait de l’utilisateur soit exprimé de manière très macroscopique, comme par exemple « En tant que conseiller de clientèle, je souhaite simuler un crédit à la consommation afin de proposer une offre à mon client. ». Cette User Story est trop « grosse » pour être réalisée dans une seule itération, il va donc être nécessaire de la découper en User Stories plus petites, c’est ce que l’on appelle le « grooming ». Ces User Stories macroscopiques sont souvent appelées soit des Thèmes, soit des Epics. Les Thèmes et les Epics peuvent être considérés comme des buts de haut niveau pour l’utilisateur. Lors du raffinage des Thèmes & Epics en User Stories, une démarche de type « scénarisation » doit être utilisée.
Dans Scrum, la décomposition des Thèmes & Epics en User Stories est réalisée en collaboration entre un Product Owner et l’équipe de réalisation.
J’ai un produit complexe à concevoir, quelles sont les questions essentielles à se poser ?
- quel problème dois-je résoudre ? quel est l’objectif à atteindre ?
- pourquoi dois-je concevoir ce produit ? quelle est sa justification ?
- que doit faire le produit pour atteindre l’objectif ? comment doit-il se comporter ?
- comment savoir si l’objectif est atteint ?
- quel risque vais-je prendre pour atteindre l’objectif ?
- comment vais-je le réaliser ?
- combien la réalisation du produit va-t-elle me coûter ?
- quand et sous quelle forme vais-je pouvoir livrer le produit ?
Lorsque la User Story est dimensionnée pour pouvoir être réalisée dans une itération, l’équipe de développement réalise une décomposition en tâches. Les tâches vont permettre la réalisation des US. Il est important à ce stade de se concentrer sur ce que doit faire le système pour satisfaire la US et comment il doit se comporter. C’est à ce niveau qu’apparaissent alors les exigences système. Les exigences système décrivent les fonctions et les interfaces du futur système. Les tâches étant en réalité la manière de réaliser les exigences système.
Cette notion d’exigence système dans un projet agile est très importante et souvent sous-estimée car c’est sur la définition de ces exigences que sera réalisé le futur système. Le référentiel d’exigences système constituera une référence pour les demandes de changements et l’analyse d’impact des modifications qui ne manqueront pas d’arriver sur le projet. Le référentiel d’exigences système est également le point de départ pour la capitalisation et la réutilisation des exigences.