Identifier les cas d’utilisation à partir du processus métier
Le BPMN est de plus en plus utilisé pour identifier les exigences relatives au logiciel qui soutient les processus métiers. Les exigences logicielles sont souvent mal alignées avec les processus métiers. Par conséquent, l’élaboration des exigences basée sur des modèles de processus métiers assurera l’alignement entre les modèles de processus métiers et les modèles logiciels, et donc, fournira probablement ce que les utilisateurs attendent.
Les équipes de développement peuvent utiliser le modèle de processus métier pour documenter visuellement les flux de travail métier, et associer les cas d’utilisation à ces processus métiers afin de modéliser les fonctionnalités souhaitées que le système doit réaliser. Dans ce tutoriel, nous expliquerons en détail comment utiliser la fonction de transition de modèle pour établir une traçabilité entre les cas d’utilisation et les processus métiers.
Qu’est-ce que le BPMN et le BPD ?
BPMN fournit aux analystes métiers un ensemble de notations graphiques pour modéliser les processus métiers. Il a été initialement développé par Initiative de gestion des processus métiers (BPMI) et est maintenant entretenu par Groupe de gestion des objets (OMG). L’un des objectifs du développement du BPMN est de fournir un langage graphique commun aux personnes exerçant des rôles différents, provenant de pays différents et/ou parlant des langues différentes, afin de comprendre le même processus métier sans barrière.
BPD, abréviation de Diagramme de processus métier, est le lieu où le processus métier est modélisé à l’aide du BPMN. Il s’agit d’un diagramme ressemblant à un organigramme, qui illustre le flux du processus, les participants impliqués et les échanges de messages entre eux. Les analystes métiers dessinent des BPD pour modéliser la manière dont différents participants collaborent pour atteindre un objectif métier. Une fois le modèle métier finalisé validé auprès des utilisateurs finaux, l’analyste système peut alors commencer à planifier le système.
Le diagramme suivant est un BPD simple d’un processus d’inscription pour une organisation. Il couvre la plupart des notations typiques que vous verrez. Examinons-le.

| Notation | Description |
|---|---|
![]() |
Pool – Représente un participant dans un processus. Dans le BPMN, les pools et les lignes sont utilisés pour représenter les participants. Une ligne est contenue dans un pool pour modéliser une sous-partition du pool parent. |
![]() |
Événement de départ – Le début d’un processus. Des déclencheurs peuvent être définis pour indiquer aux lecteurs dans quelles situations le processus sera déclenché. Par exemple, lorsqu’un courrier électronique est reçu/lorsqu’il est lundi matin/lorsqu’une erreur s’est produite. |
![]() |
Tâche – Une activité atomique que les participants désignés (modélisés par pool/ligne) pourraient effectuer. Les tâches et autres objets de flux sont reliés ensemble pour former un flux de travail métier complet. |
![]() |
Événement de fin – La fin d’un processus. Un résultat peut être défini pour indiquer aux lecteurs ce qui se produira lorsque le processus se terminera. Par exemple, émettre un signal/produire une erreur, etc. |
Dans ce tutoriel, nous ne nous concentrerons pas en profondeur sur le BPD ni sur la modélisation des processus métiers. Si vous souhaitez en savoir plus sur le BPMN, le BPD ou la modélisation des processus métiers, veuillez lire le tutoriel Introduction à BPMN Partie I à IV.
Qu’est-ce qu’un diagramme de cas d’utilisation ?
La modélisation des cas d’utilisation fait référence à la technique de capture des exigences utilisateur de haut niveau à l’aide du diagramme de cas d’utilisation UML. Le modèle de cas d’utilisation est conçu pour les concepteurs logiciels ou système, et non pour les personnes métiers.
Il y a trois éléments principaux dans un diagramme de cas d’utilisation.
| Notation | Description |
|---|---|
![]() |
Cas d’utilisation – Chaque cas d’utilisation représente un objectif utilisateur, qui est un objectif que l’utilisateur du système souhaite atteindre. Notez que les cas d’utilisation ne peuvent être utilisés que pour montrer ce que l’utilisateur souhaite faire, et non ce que le développeur doit développer, bien que cela puisse être identique dans certains cas. Si vous souhaitez documenter ou modéliser les fonctions impliquées dans un cas d’utilisation, vous pouvez utiliser l’outil de flux d’événements, ou élaborer un cas d’utilisation avec diagramme de séquence / diagramme d’activité. Gardez à l’esprit que la modélisation des cas d’utilisation vise à modéliser ce que l’utilisateur souhaite atteindre. |
![]() |
Acteur – Utilisateur du système. Le mot « utilisateur » ici n’est pas limité aux êtres humains. Il peut s’agir d’un système qui interagit avec notre système afin de remplir un objectif commercial spécifique. |
![]() |
Lien de communication/Association – Connecte l’acteur au cas d’utilisation pour indiquer l’accès au système par l’acteur. Chaque lien de communication implique une séquence de transactions entre l’acteur et le système. |
Transition du BPD au diagramme de cas d’utilisation
Bien que le BPD et le diagramme de cas d’utilisation ne doivent pas nécessairement s’appuyer l’un sur l’autre, ils pourraient toutefois être liés de manière complémentaire. En général, nous développons des logiciels pour automatiser ou optimiser certains flux de processus métier. Grâce au BPD, vous pouvez comprendre comment les participants collaborent et qui est responsable de quoi, ce qui vous permet d’identifier les fonctions dont ils ont besoin que le système soutienne. Ces fonctions système (flux de travail ou processus métier) souhaitées par l’utilisateur peuvent être modélisées à l’aide de cas d’utilisation, puis développées par l’équipe. En conséquence, on peut dire que le BPD vous aide à identifier les cas d’utilisation pour un système en cours de développement.
Visual Paradigm est un outil de modélisation visuelle qui permet de passer de la mise en œuvre du processus métier à la modélisation des cas d’utilisation (de la demande métier à la demande d’application) en établissant des liens de traçabilité entre les deux modèles grâce à la fonctionnalité de transition de modèle. Nous avons besoin du traçage pour les raisons suivantes :
- Nous pouvons nous assurer que le système s’inscrit dans une utilisation réelle du monde réel en étudiant la partie du flux de processus impliquée par un cas d’utilisation.
- Pour répondre à des questions telles que « Pourquoi avons-nous besoin de cette fonction (du système) ? » en traçant la partie du processus à partir de laquelle un cas d’utilisation provient.
- Pour répondre à des questions telles que « Une opération spécifique a-t-elle déjà été mise en œuvre ? » en traçant depuis le BPD jusqu’au diagramme de cas d’utilisation.
BPD vs. Diagramme de cas d’utilisation
Lorsque vous effectuez une transition d’un BPD vers un diagramme de cas d’utilisation, vous pouvez produire un acteur à partir d’une voie/lot, et produire un cas d’utilisation à partir d’une tâche/sous-processus. Le tableau suivant vous montre les caractéristiques du lot, de la voie, de l’acteur, de la tâche, du sous-processus et du cas d’utilisation, en termes de transition de modèle.
| Depuis | Vers | Description |
|---|---|---|
![]() ![]() |
![]() |
Lot/Voie vers Acteur
Dans le BPD, un lot représente un participant au processus métier, tandis qu’une voie est une sous-partition du lot. Toute personne ayant une activité à accomplir, liée au processus, est considérée comme un participant. Dans un diagramme de cas d’utilisation, un acteur représente un utilisateur du système. Gardez à l’esprit qu’une personne ou un rôle qui n’est pas un utilisateur du système ne doit pas être considéré comme un acteur. |
![]() ![]() |
![]() |
Tâche/Sous-processus vers Cas d’utilisation
Dans le BPD, une tâche/sous-processus (activité) désigne toute action que peut accomplir un participant afin de finaliser un processus métier. Dans un diagramme de cas d’utilisation, un cas d’utilisation présente un objectif que l’utilisateur souhaite atteindre en utilisant le système. Gardez à l’esprit qu’une activité n’a pas nécessairement de lien avec une fonction du système, et qu’un seul cas d’utilisation peut satisfaire plusieurs activités. |
Certaines personnes peuvent penser qu’un diagramme de cas d’utilisation ressemble à un BPD, mais qu’il diffère fortement en termes de notations et de buts. Souvenez-vous du fait que BPMN est conçu pour les professionnels métiers, tandis que le diagramme de cas d’utilisation est destiné aux analystes ou développeurs système. Ils servent des objectifs différents et interprètent une entreprise sous deux perspectives distinctes. C’est pourquoi, dans la section précédente, j’ai résumé la relation entre le BPD et le diagramme de cas d’utilisation en disant « le BPD vous aide à identifier les cas d’utilisation ». Le BPD ne peut vous donner que des indices lors de l’identification des cas d’utilisation. Il n’existe aucune règle stipulant que chaque tâche présente dans un BPD est équivalente à un cas d’utilisation. Mais nous pouvons approfondir un processus métier à l’aide d’un cas d’utilisation pour automatiser une fonction par le système cible.
Dans l’étude de cas, je vous donnerai quelques idées sur ce à quoi vous devez prêter attention lors de la transition d’un BPD vers un diagramme de cas d’utilisation. Vous comprendrez alors à quel point ils diffèrent.
Étude de cas : La société True Aqua d’eau distillée
La société True Aqua d’eau distillée est un jeune fournisseur d’eau distillée en ville. Elle vend de l’eau distillée pour usage commercial et domestique. La description textuelle suivante décrit leur processus de livraison d’eau.
| Pour commander de l’eau distillée, le client appelle le numéro d’assistance ou nous envoie un courriel. Actuellement, 90 % des commandes proviennent d’appels téléphoniques, tandis que 10 % sont passées par courriel. L’assistant du service client qui reçoit la commande vérifie si le client est déjà existant ou s’il s’agit d’un nouveau client. Si le client n’a jamais commandé auparavant, l’assistant du service client créera un compte client pour lui avant de procéder à la livraison de l’eau.
La livraison de l’eau distillée a lieu une fois par semaine, chaque mercredi. Ainsi, chaque mercredi matin, l’assistant du service client transmettra les commandes au service Logistique pour la livraison. Dès que le responsable du service Logistique a reçu les commandes, il organisera la livraison en affectant des travailleurs à différentes commandes, en imprimant et en affichant le planning. Les travailleurs reçoivent les appels et livrent l’eau au client en conséquence. |
Un modèle de processus métier a été créé sur la base de la description. Maintenant, vous êtes invité à développer un système informatique afin d’optimiser l’ensemble du processus. La première chose que vous devez faire est de développer un modèle de cas d’utilisation. Avec l’aide du BPD, essayez de développer un diagramme de cas d’utilisation.
- Télécharger Distilled Water Delivery.vpp. Vous pouvez également trouver ce fichier en bas de ce tutoriel.
- Ouvrez le fichier .vpp téléchargé dans Visual Paradigm. Pour ouvrir un projet, sélectionnez Projet > Ouvrir depuis la barre d’outils de l’application.
- Ouvrez le BPD Processus de commande d’eau distillée. Étudiez attentivement le flux du processus.

- Le processus commence lorsque le client passe une commande. Ici, nous pouvons envisager un cas d’utilisation – Passer une commande. Ce cas d’utilisation aidera à automatiser le processus en fournissant une interface permettant au client de passer une commande sans l’aide d’un assistant du service client, à vérifier l’identité du client et à créer un compte si le client n’existe pas. Cliquez avec le bouton droit sur Passer une commande et sélectionnez Éléments associés > Transférer vers un nouveau cas d’utilisation… depuis le menu contextuel.

- Cela affiche la fenêtre Transférer l’élément du modèleoù vous pouvez sélectionner le modèle dans lequel placer le cas d’utilisation et l’acteur, et les renommer. Dans ce cas, nous sommes satisfaits des noms du cas d’utilisation et de l’acteur. Maintenons-les inchangés. Cliquez sur OK.

Cela crée un nouveau diagramme de cas d’utilisation dans UeXceler.

- Retournez au BPD.
- Examinons la tâche Créer un compte client. Dans le processus métier, l’assistant du service client doit créer un compte pour chaque nouveau client. Dans le nouveau système, cela peut soit faire partie du cas d’utilisation Passer une commande soit être un cas d’utilisation distinct déclenché manuellement par l’assistant du service client. Dans une situation réelle, vous devez clarifier ce type de doute avec le donneur d’ordre, car un modèle de cas d’utilisation incorrect entraînera le développement de fonctions qui ne correspondent pas aux attentes de l’utilisateur. Dans cet exemple, supposons que l’utilisateur souhaite que la tâche Créer un compte client soit une tâche effectuée par l’assistant du service client. Créons un cas d’utilisation à partir de celle-ci. Cliquez avec le bouton droit sur Créer un compte client et sélectionnez Éléments associés > Transférer vers un nouveau cas d’utilisation… depuis le menu contextuel.

- Encore une fois, nous sommes satisfaits du nom du cas d’utilisation et de l’acteur. Laissez tout dans la fenêtre Transférer l’élément du modèleinchangé. Cliquez sur OK. Le diagramme de cas d’utilisation est mis à jour avec un nouveau cas d’utilisation et un acteur. Examinons cela.

- Retournez au BPD. Passons au sous-processusOrganiser la livraison. Le responsable du département logistique peut utiliser le système pour planifier et informer les travailleurs de livrer de l’eau. Par conséquent, il s’agit également d’un cas d’utilisation du système. Cliquez avec le bouton droit sur le sous-processusOrganiser la livraison et sélectionnezÉléments associés > Transférer vers un nouveau cas d’utilisation… dans le menu contextuel.
- Vérifiez l’acteur Responsable dans la fenêtreTransférer l’élément de modèle fenêtre. Si nous conservons le nom de l’acteur commeResponsable, cela est ambigu dans le modèle de cas d’utilisation car il peut y avoir de nombreux départements avec de nombreux responsables différents dans l’entreprise. Par conséquent, renommez l’acteur enResponsable du département logistique.

- Cliquez surOK. Le diagramme de cas d’utilisation est mis à jour.

- Retournez au BPD. La tâche finaleLivrer de l’eau est un travail qui ne peut être effectué que par un humain et n’a rien à voir avec l’interaction du système. Par conséquent, nous n’avons pas besoin de créer un cas d’utilisation pour cela.
- Supposons que le responsable régional souhaite que le système prenne en charge une nouvelle fonction permettant de générer un rapport affichant les statistiques sur les commandes. Cette fonction peut l’aider à réviser et à affiner la stratégie marketing. Bien que cette fonction n’ait pas été modélisée dans le modèle de processus métier, nous pouvons la dessiner directement dans le diagramme de cas d’utilisation. Ouvrez le diagramme de cas d’utilisation. Dessinez un acteurResponsable régional. Créez un cas d’utilisationGénérer un rapport statistique à partir de celui-ci avec une association entre les deux.

- Disons que le client souhaite autoriser le client à visualiser les relevés de facturation et à annuler une commande. En outre, le client souhaite autoriser le responsable du département logistique à imprimer le rapport logistique. Dessinez les cas d’utilisation respectivement.

- Nettoyez le diagramme.

- La relation de transition vous permet de suivre le modèle de processus métier à partir du modèle de cas d’utilisation (et inversement). Essayons. Placez le pointeur de la souris surPasser la commande cas d’utilisation.

- Cliquez sur le Modèle Transitor ressource dans le coin inférieur droit de la forme. Sélectionnez Transit depuis > Processus de commande d’eau distillée<.Passer la commande dans le menu contextuel.

Cela ouvre le BPD avec la tâche Passer la commande sélectionnée.













