Capturer les exigences fonctionnelles avec des cas d'utilisation et des témoignages d'utilisateurs

Table of Contents hide

1 Quelles techniques pour capturer les besoins fonctionnels ?

2 Capturer les exigences fonctionnelles à l’aide des user stories

4 Comment identifier les besoins fonctionnels avec un cas d’utilisation ?

5 Utilisateur réel vs acteur de cas d’utilisation

6 Comment obtenir les exigences fonctionnelles en identifiant les cas d’utilisation du système

La première étape de la définition d’un nouveau produit, service, processus ou système consiste à définir des exigences, c’est-à-dire des exigences fonctionnelles ou non fonctionnelles spécifiques.

Les exigences fonctionnelles décrivent comment le produit ou le service répond aux besoins des clients. Cela inclut les caractéristiques et les fonctionnalités dans les cas d’utilisation qui documentent la manière dont les utilisateurs interagiront avec le produit ou le service.
Les exigences non fonctionnelles sont des attributs opérationnels et de produit qui ne sont parfois pas évidents pour l’utilisateur, notamment les performances, la convivialité, la durabilité, la sécurité et les aspects financiers (prix et coût).

MODIFIER CETTE ILLUSTRATION – EXIGENCES FONCTIONNELLES VS EXIGENCES NON FONCTIONNELLES

Les exigences fonctionnelles peuvent être considérées comme ce que le produit doit faire pour le client, tandis que les exigences non fonctionnelles peuvent être considérées comme des contraintes auxquelles le produit ou le service doit être conçu pour répondre.

Les exigences fonctionnelles capturent le comportement prévu du système. Ce comportement peut être exprimé sous forme de services, de tâches ou de fonctions que le système doit exécuter. Dans l’industrie du développement de logiciels, l’approche par cas d’utilisation est rapidement devenue une pratique répandue pour capturer les exigences fonctionnelles. Cela est particulièrement vrai dans la communauté orientée objet et UML d’où ils sont issus, mais leur applicabilité n’est pas limitée aux systèmes orientés objet.

Quelles techniques pour capturer les besoins fonctionnels ?

Les exigences fonctionnelles sont généralement capturées sous la forme de cas d’utilisation ou de scénarios d’utilisation. Ces termes sont parfois utilisés de manière interchangeable, mais ils signifient en fait des choses légèrement différentes.

Les cas d’utilisation se concentrent davantage sur le système et sur ce qu’il doit faire pour répondre aux besoins des utilisateurs.
Les user stories , quant à elles, montrent les fonctionnalités du produit du point de vue de l’utilisateur, en spécifiant les rôles des utilisateurs et les objectifs spécifiques qu’ils souhaitent atteindre.

Capturer les exigences fonctionnelles à l’aide des user stories

Les user stories sont une méthode légère pour capturer rapidement le « qui », le « quoi » et le « pourquoi » des exigences d’un produit. En termes simples, les user stories sont des idées qui expriment les besoins souhaités par les utilisateurs. Les user stories sont courtes et chaque élément contient généralement moins de 10 ou 15 mots. Les user stories sont des listes de tâches qui vous aident à identifier les étapes le long du chemin du projet. Ils aident à garantir que votre processus et le produit qui en résulte répondent à vos exigences.

Modèle de récit utilisateur

Les user stories ne capturent que les éléments essentiels d’une exigence :

C’est pour qui ?
Qu’attend-il du système ?
Pourquoi est-ce important (facultatif ?) ?

Voici un format simple de user story utilisé par 70% des praticiens :

Rôle – L’utilisateur doit être un être humain réel qui interagit avec le système.

Soyez aussi spécifique que possible
L’équipe de développement n’est PAS un utilisateur

Action – Le comportement du système doit être écrit comme une action.

Généralement unique pour chaque User Story
Le « système » est sous-entendu et n’est pas écrit dans l’histoire
Voix active, pas voix passive (« Je peux être notifié »)

Avantages – L’avantage doit être un résultat réel non fonctionnel ou externe au système.

De nombreuses histoires peuvent partager la même déclaration d’avantages.
L’avantage peut être pour d’autres utilisateurs ou clients, pas seulement pour l’utilisateur dans l’histoire.

Comment identifier les besoins fonctionnels avec un cas d’utilisation ?

Afin de bien comprendre les exigences fonctionnelles du système, vous devez savoir à qui le système est destiné, c’est-à-dire qui utilisera le système ?

La réponse à cette question est : l’ acteur dans l’analyse de cas d’utilisation

Les cas d’utilisation ou les user stories capturent les exigences fonctionnelles dont le comportement peut être exprimé sous forme de services, de tâches ou de fonctions que le système doit exécuter. Les cas d’utilisation définissent l’interaction entre l’utilisateur et le service système, ce qui peut aider à définir les exigences fonctionnelles du système en cours de développement. Ou en d’autres termes, ce que le produit ou le service doit faire pour satisfaire les besoins et les désirs du client.

Un cas d’utilisation commence par un « acteur » ou « qui », un utilisateur spécifique du produit ou du service.

Un acteur est une personne ou un système externe qui joue un rôle dans l’interaction avec le système. Les instances d’acteurs peuvent être des individus ou des systèmes externes ; cependant, chaque acteur fournit une perspective unique et importante du système, une perspective qui est commune à chaque instance (personne/utilisateur réel) de l’acteur.

Utilisateur réel vs acteur de cas d’utilisation

Afin de bien comprendre l’objectif du système, vous devez savoir à qui il est destiné, c’est-à-dire qui l’utilisera. Les différents types d’utilisateurs sont représentés par des acteurs (rôles).

La différence entre un rôle et un utilisateur individuel est qu’un rôle représente une classe spécifique d’utilisateurs, plutôt qu’un utilisateur réel. Différents utilisateurs peuvent jouer le même rôle, auquel cas chaque utilisateur constitue une instance d’un acteur.

Cette distinction entre acteurs et instances d’acteurs est illustrée dans ce qui suit :

La figure ci-dessous montre un cas où Marie et Jean sont clients d’un distributeur automatique. Lorsqu’ils utilisent le distributeur automatique, chacun est représenté par une instance d’un acteur appelé client qui s’attend à avoir accès à certaines fonctions du système (en l’occurrence l’impression d’acheter de la nourriture).

MODIFIER CETTE ILLUSTRATION DE DISTRIBUTEUR AUTOMATIQUE

Inversement, le même utilisateur peut jouer plusieurs rôles (c’est-à-dire qu’une même personne peut jouer différents rôles).

Par exemple, le Dr Gates, qui est membre du comité de la Computer Society. Il est responsable de la gestion du système de gestion des membres, comme l’ajout et la suppression de comptes d’utilisateurs. Lorsqu’il fait cela, il joue un rôle appelé administrateur (acteur). Cependant, le même Dr Gates peut également être membre de la Computer Society. Dans ce cas, il jouerait également un rôle appelé « Membre » (Acteur)

Comment obtenir les exigences fonctionnelles en identifiant les cas d’utilisation du système

Un cas d’utilisation peut être identifié en posant aux parties prenantes les types de questions suivantes (auxquelles elles doivent répondre du point de vue des acteurs) :

Qu’est-ce que les utilisateurs dans ce rôle essaient d’accomplir ?
Pour remplir ce rôle, que doivent être capables de faire les utilisateurs ?
Quelles sont les principales tâches des utilisateurs dans ce rôle ?
De quelles informations les utilisateurs de ce rôle ont-ils besoin pour examiner, créer ou modifier ?
De quoi les utilisateurs de ce rôle doivent-ils être informés par le système ?
De quoi les utilisateurs dans ce rôle doivent-ils informer le système ?

Notez que:

Les cas d’utilisation sont souvent utilisés comme moyen de découvrir et de représenter les exigences fonctionnelles et système, car un cas d’utilisation définit les interactions et les tâches nécessaires à exécuter pour atteindre un objectif métier spécifique. Cependant, ils ne sont généralement pas un bon moyen de définir des exigences non fonctionnelles, telles que les performances et la qualité du système.

Capturer les exigences fonctionnelles avec des cas d’utilisation et des témoignages d’utilisateurs