Instructions: Modèle de cas d'utilisation métier
Un modèle de cas d'utilisation métier décrit l'utilisation du métier par ses clients, partenaires et autres agences externes. Ces instructions constituent un manuel de modélisation de cas d'utilisation métier.
Relations
Description principale

Explications

Le principal objectif de la modélisation de cas d'utilisation et d'acteurs métier est de décrire l'utilisation du métier par les agences externes, et surtout par les clients et partenaires. Elle permet de présenter les tâches concernant directement le client ou le partenaire, ainsi que les tâches de support ou de gestion concernant uniquement de façon indirecte le parti externe.

Le modèle décrit le métier en termes de cas d'utilisation métier, qui correspondent à ce que l'on appelle généralement des "processus".

Diagramme décrit dans le texte d'accompagnement.

Acteurs et cas d'utilisation au niveau du comptoir d'enregistrement.

Catégories de cas d'utilisation métier

Lorsque vous examinerez les tâches d'un métier, vous serez en mesure d'identifier au moins trois catégories de travaux correspondant à trois catégories de cas d'utilisation métier :

  • principal : cas d'utilisation métier orientés vers l'extérieur et fournissant la chaîne de valeur (par exemple, Acheter un produit).
  • de gestion : cas d'utilisation métier internes qui coordonnent la chaîne de valeur (par exemple, Planification stratégique).
  • de support : cas d'utilisation métier internes qui supportent la chaîne de valeur (par exemple, Acheter des matières premières).

Nous reviendrons ultérieurement sur la signification et la représentation de la notion de "cas d'utilisation métier interne".

En général, un cas d'utilisation métier de type gestion décrit les relations existant entre le PDG et les personnes travaillant dans les cas d'utilisation métier. Il décrit également le développement et l'instanciation (lancement) des cas d'utilisation métier.

Diagramme décrit dans le texte d'accompagnement.

Dans cette illustration, qui prend l'exemple d'un restaurant, les cas d'utilisation métier principaux sont le marketing et le service à table, tandis que le cas d'utilisation métier de support est l'approvisionnement.

Notez que ce l'on considère ici comme un cas d'utilisation métier principal peut parfois être un cas d'utilisation métier de support dans un autre métier. Par exemple, le développement logiciel est un cas d'utilisation métier principal dans une entreprise qui développe des logiciels, mais dans une banque ou une société d'assurance, cette activité serait considérée comme un cas d'utilisation métier de support. Notez cependant que de nombreux cas d'utilisation métier détaillés, qui seraient développés si vous modélisiez un métier de développement logiciel, n'apparaîtront pas à au niveau supérieur des cas d'utilisation métier dans une banque qui viendrait à développer son propre logiciel ; ils ne seront même pas considérés comme des cas d'utilisation métier de support. Ils sont susceptibles d'apparaître plus tard en tant que cas d'utilisation subordonnés (voir le Concept : Modélisation de grandes organisations). Au niveau de la banque, les cas d'utilisation de support ne pourraient que refléter sa stratégie et ses objectifs ; l'un d'eux pourrait bien viser à "faire fonctionner l'unité métier de développement logiciel".

Un métier dispose de plusieurs cas d'utilisation métier

Les instances de différents cas d'utilisation métier, ainsi que différentes instances d'un même cas d'utilisation métier s'exécutent normalement en parallèle. Une instance de cas d'utilisation peut suivre un nombre presque infini de chemins. Ces chemins représentent les choix ouverts à l'instance de cas d'utilisation dans la description de l'enchaînement d'activités. En fonction d'événements ou de faits donnés, une instance de cas d'utilisation peut emprunter l'un des chemins possibles, dirigé par exemple par :

  • une entrée effectuée par un acteur,
  • une règle métier.

Lors de la modélisation de cas d'utilisation métier, vous pouvez présumer que plusieurs instances de cas d'utilisation pourront être actives simultanément sans générer de conflit. A ce stade du développement du métier, vous devez mettre l'accent sur ce que doit faire le métier. Vous résoudrez ultérieurement les conflits potentiels de ressources, lorsque vous modéliserez les réalisations de cas d'utilisation métier, étape à laquelle vous essaierez de comprendre comment doivent fonctionner les composantes du métier. Vous pourrez également résoudre ces problèmes au cours de la mise en oeuvre de la nouvelle organisation, en augmentant par exemple le nombre d'employés capables d'exécuter la tâche critique.

Les cas d'utilisation métier sont-ils liés aux acteurs métier ?

Tous les cas d'utilisation métier principaux doivent avoir une relation de communication issue ou à destination d'un acteur métier. Cette règle met en application l'objectif selon lequel les métiers doivent être construits autour des services demandés par leurs utilisateurs. Si le modèle de cas d'utilisation métier contient des cas d'utilisation métier principaux que personne ne demande, cela signifie qu'il y a un problème avec ce modèle.

Les cas d'utilisation métier peuvent être déclenchés périodiquement ou s'exécuter sur une très longue période ; une fonction de surveillance est un exemple de ce dernier cas. Même ces cas d'utilisation métier ont des acteurs métier qui les ont créés et attendent d'eux différents services. Dans le cas contraire, ils ne feraient pas partie du métier. D'autres cas d'utilisation métier génèrent des résultats pour un acteur métier alors qu'ils ne sont pas explicitement créés par cet acteur. Par exemple, le développement d'un produit largement distribué est rarement initié par un client identifiable. Ce sont au contraire des études de marché et les demandes accumulées exprimées par une multitude d'utilisateurs qui font prendre conscience de la nécessité de créer un nouveau produit.

Cas d'utilisation métier internes

Les cas d'utilisation métier de gestion et de support (définis plus haut comme internes) ne doivent pas nécessairement être connectés à un acteur métier, bien qu'ils aient en général une sorte de contact externe. L'acteur métier d'un cas d'utilisation métier de gestion peut par exemple correspondre aux propriétaires du métier ou à son conseil d'administration.

Il paraît tout de même étrange qu'un cas d'utilisation métier n'ait pas d'acteur, étant donné qu'un cas d'utilisation est censé représenter l'interaction de quelqu'un ou de quelque chose avec le métier et fournir de la valeur, mais on peut considérer cette classe de cas d'utilisation métier comme des extensions de cas d'utilisation métier, peut-être théoriques, ayant des acteurs métier. L'utilisation des extensions explicites est abordée dans les Instructions : Relation d'extension dans le modèle de cas d'utilisation métier, mais ici le cas d'utilisation métier (étendu) de base peut être conceptuel et vous pouvez choisir de ne pas le modéliser. Les cas d'utilisation métier de gestion et de support sont donc des extensions de cette base conceptuelle, déclenchés par des conditions (ayant pour résultat un Produit : Evénement métier) qui se produisent au cours de l'existence du métier. Cette approche permet d'éviter le recours à des acteurs métier artificiels, mais vous oblige à réfléchir à la valeur ajoutée apportée par les cas d'utilisation métier de support et de gestion.

Les cas d'utilisation métier abstraits n'exigent pas d'acteur métier car ils ne sont jamais instanciés (lancés) seuls.

Les cas d'utilisation métier doivent supporter les objectifs métier

Les processus métier sont les vecteurs permettant au métier de faire des choses. Comme il est très difficile de convertir directement la stratégie métier en actions, il faut trouver autre chose. C'est ici qu'entrent en scène les objectifs métier, qui garantissent l'exécution par les processus métier de la stratégie métier en dirigeant, à tous les niveaux de l'organisation, des actions devant permettre la réalisation de l'objectif métier ultime : l'idée métier.

Chaque cas d'utilisation métier doit donc supporter au moins un objectif métier. En convertissant la stratégie en objectifs à différents niveaux, on obtient des objectifs concrets et mesurables, qui peuvent être supportés directement par les processus métier. La définition de relations de support entre les objectifs et les processus garantit l'alignement des processus métier sur la stratégie métier. Cela permet également de repérer le niveau approprié de cas d'utilisation métier, souvent difficile à déterminer. Il serait trop complexe et trop lourd de modéliser en tant que séquence de tâches un cas d'utilisation métier unique (par exemple, Réalisation de bénéfices) supportant directement les objectifs stratégiques de l'entreprise. D'un autre côté, associer un cas d'utilisation métier distinct à chaque tâche opérationnelle de l'organisation (par exemple, Transférer un appel ou Réserver une salle de conférence) aurait pour conséquence un trop grand nombre de cas d'utilisation métier. La définition des objectifs métier supportés par un cas d'utilisation métier permet d'indiquer si le cas d'utilisation métier est "trop élevé" ou "trop bas". 

Lorsqu'un cas d'utilisation métier supporte explicitement un ou plusieurs objectifs métier, il devient plus facile de quantifier sa valeur. La contribution du résultat du cas d'utilisation métier à l'objectif peut être mesurée. Les performances du cas d'utilisation métier peuvent également être contrôlées afin d'offrir une comparaison objective de la valeur et du coût.

L'existence de ces relations facilite la définition des priorités au sein des cas d'utilisation métier. Les cas d'utilisation métier supportant de nombreux objectif métier ou des objectifs importants et risqués, seront très probablement considérés comme significatifs d'un point de vue architectural. Nombre d'objectifs peuvent également être associés à une inutile complexité. Si un cas d'utilisation métier supporte plusieurs objectifs différents, il est probable que des conflits se produisent. Les objectifs prioritaires dans ces cas ne sont parfois pas clairement définis ; les actions sont alors inefficaces.

La catégorie du cas d'utilisation métier (principal, de support ou de gestion) ne détermine pas directement les types d'objectifs métier qu'il supporte. Alors que la catégorie fournit des instructions, la stratégie métier déterminera à terme les objectifs métier supportés par un cas d'utilisation métier donné. Par exemple, un cas d'utilisation métier appelé "Commercialiser et vendre un produit" peut supporter l'objectif métier Prix compétitifs pour un métier disposant d'une stratégie de croissance agressive. Le même métier, des années plus tard, peut souhaiter augmenter ses investissements sur ces produits et marchés avec pour objectif de satisfaire et de fidéliser sa clientèle. Il est alors possible que le cas d'utilisation métier Commercialiser et vendre un produit doive supporter l'objectif suivant, très différent du précédent : Qualité supérieure. Voir les Instructions : Objectif métier pour plus d'informations sur la modélisation des objectifs métier.

Reprenons ici l'exemple du grand magasin de meubles utilisé dans les Instructions : Objectif métier. Le modèle de cas d'utilisation métier de ce type de magasin pourrait être le suivant :

Diagramme représentant le modèle de cas d'utilisation métier d'un magasin de meubles.

Le client peut choisir des produits, aller les chercher dans l'entrepôt jouxtant la salle d'exposition et les payer. Les produits défectueux peuvent être rendus. "Identifier les besoins des clients" est le nom du cas d'utilisation métier souvent appelé Etude de marché. Une fois le produit approprié repéré, il est lancé et le marchand devient alors un fournisseur. Les ventes de produits doivent être contrôlées, mais on peut se demander s'il s'agit d'un cas d'utilisation métier distinct (représenté dans la figure ci-dessous) ou si cela relève de l'Etude de marché. S'il fallait mapper les cas d'utilisation métier évoqués ci-dessus aux objectifs métier décrits dans les Instructions : Objectif métier, le résultat pourrait être le suivant :

Diagramme décrit dans le texte d'accompagnement.

Le cas d'utilisation métier Trouver le produit approprié supporte des objectifs métier en léger conflit. Il convient de définir clairement une méthode permettant de trouver un équilibre entre les prix et la qualité afin de garantir la réalisation de ces deux objectifs métier. Si la qualité est évaluée sur la base du nombre (ou du pourcentage) de produits défectueux retournés, la cause de ces défauts doit être établie afin d'en effectuer le suivi jusqu'au fournisseur. Par exemple, il est possible que plusieurs produits livrés aux clients soient retournés en raison du travail peu soigné de l'équipe de livraison. Cependant, si l'on prend uniquement en compte le nombre de livraisons, la qualité des livraisons n'est pas connue.

Le cas d'utilisation métier Payer le produit peut supporter "Méthode de paiement", mais pas "Prix bas", car la fixation des prix s'effectue au cours du cas d'utilisation métier (distinct) Trouver le produit approprié.

Dans certaines entreprises, quelques cas d'utilisation métier ne supportent pas d'objectifs métier. Il peut alors s'avérer pertinent de fusionner Contrôler les ventes, par exemple, avec Identifier les besoins des clients, car Contrôler les ventes ne supporte pas directement d'objectif métier. Cependant, une fusion de ce type ne doit pas être effectuée trop hâtivement car un manque de support des objectifs métier peut indiquer qu'il faut les rendre plus concrets. Au pire des cas, Contrôler les ventes fournit des entrées à Identifier les besoins des clients.

Le cas d'utilisation métier Livrer un produit supporte l'objectif métier Date de livraison. Les clients ne doivent pas attendre trop longtemps la livraison des produits qu'ils ont achetés. En réfléchissant à la meilleure façon de réaliser cet objectif, on peut imaginer des solutions totalement inédites. Par exemple, un tunnel souterrain pourrait relier l'entrepôt à des maisons du centre ville de façon à ce que les produits puissent être envoyés à plus de 150 km/h et ainsi livrés avant même le retour du client à son domicile ! C'est bien sûr tout à fait irréaliste, mais ce genre de brainstorming peut donner de nombreuses pistes pour améliorer le métier.

Voici un exemple montrant que certains cas d'utilisation métier apparemment insignifiant peuvent revêtir une grande importance dans l'optique des objectifs métier. Supposons que de nombreux clients fassent leurs courses aux heures de repas. L'un des objectifs métier étant d'améliorer la qualité des installations et un autre d'attirer les clients, nous pouvons décider de proposer un service de restauration qui leur permettra de manger u morceau avant ou après avoir fait leurs courses. Le cas d'utilisation métier qui supporte cet objectif, Prendre un repas, est représenté ci-dessous. Et le restaurant pourrait bien devenir l'une des principales attractions du métier !

Diagramme décrit dans le texte d'accompagnement.

L'impact de l'ajustement de la frontière du métier est également représenté dans le diagramme ci-dessous. Un nouvel acteur métier, Transporteur, a été introduit ; il s'agit d'un partenaire chargé de venir chercher les produits à l'entrepôt et de les livrer aux clients. Cela nous permettra peut-être de réduire le délai de livraison, ce qui constitue l'un des objectifs métier.

Structuration du modèle de cas d'utilisation métier

Il existe trois grandes raisons de structurer le modèle de cas d'utilisation métier :

  • faciliter la compréhension des cas d'utilisation métier,
  • réutiliser des composantes des enchaînements d'activités partagées entre plusieurs cas d'utilisation métier,
  • faciliter la gestion du modèle de cas d'utilisation métier.

Il existe trois types de relations permettant de structurer les cas d'utilisation métier. Vous utiliserez ces relations pour externaliser des composantes de cas d'utilisation métier pouvant être réutilisées dans d'autres cas d'utilisation métier, ou qui sont des spécialisations ou des options du cas d'utilisation métier. Le cas d'utilisation métier qui représente cette modification est appelé cas d'utilisation en addition. Le cas d'utilisation métier modifié est appelé cas d'utilisation métier de base.

  • Si une partie d'un cas d'utilisation de base représente une fonction dont le cas d'utilisation ne dépend que du résultat, et non de la méthode utilisée pour obtenir ce résultat, vous pouvez l'externaliser dans un cas d'utilisation en addition. L'addition est inclue explicitement dans le cas d'utilisation de base, au moyen d'une relation d'inclusion. Voir aussi les Instructions : Relation d'inclusion dans le modèle de cas d'utilisation métier.
  • Si une partie d'un cas d'utilisation de base est facultative ou n'est pas nécessaire à la compréhension de l'objectif principal du cas d'utilisation, vous pouvez l'externaliser dans un cas d'utilisation en addition afin de simplifier la structure du cas d'utilisation de base. Dans ce cas, l'addition est inclue implicitement dans le cas d'utilisation de base, au moyen d'une relation d'extension. Voir aussi les Instructions : Relation d'extension dans le modèle de cas d'utilisation métier.
  • Si des cas d'utilisation métier ont des points communs en termes de comportement et de structure et présentent des objectifs similaires, leurs composantes communes peuvent être externalisées dans un cas d'utilisation de base (parent) dont les cas d'utilisation en addition (enfants) hériteront. Les cas d'utilisation enfant peuvent insérer un nouveau comportement ou modifier un comportement existant dans la structure dont ils héritent du cas d'utilisation parent. Voir aussi les Instructions : Généralisation de cas d'utilisation dans le modèle de cas d'utilisation métier.

Diagramme décrit dans le texte d'accompagnement.

La figure ci-dessus représente des acteurs, des cas d'utilisation et le comptoir d'enregistrement. Nous représentons également ici le cas d'utilisation d'inclusion Manipulation des bagages et le cas d'utilisation d'extension Via l'enregistrement.

Vous pouvez utiliser une généralisation d'acteur pour illustrer la façon dont les acteurs constituent des spécialisations les uns des autres. Voir aussi les Instructions : Généralisation d'acteur dans le modèle de cas d'utilisation métier.

Voir aussi la discussion sur la structuration des cas d'utilisation système dans les Instructions : Modèle de cas d'utilisation.

Délimitation de l'effort de modélisation

Vous devez apporter beaucoup de soin à la délimitation de l'effort de modélisation métier, notamment lorsque vous développez des modèles métier qui serviront simplement à "redonner un coup de fouet" à un projet d'ingénierie logicielle. Dans ce cas, il est généralement inutile d'étendre votre action à la totalité de l'organisation, même si vous modélisez uniquement un sous-ensemble des processus métier. Pour rester concentré sur l'essentiel et produire les résultats attendus, vous devez définir une composante de l'entreprise comme votre "système métier". La composante sélectionnée doit être celle qui pourrait directement utiliser le système à construire. Les composantes de l'organisation que vous décidez de considérer comme externes au modèle peuvent être représentées par des acteurs métier.

Exemple :

L'entreprise a décidé d'entreprendre un effort afin de construire une nouvelle application de gestion des ventes et des commandes. Pour étudier les besoins de l'organisation et aligner la façon dont le métier est réalisé au sein de l'organisation, la première étape consiste à construire un ensemble de modèles métier. Les services de l'entreprise qui n'utiliseront pas de façon active la nouvelle application de commande sont considérés comme externes au modèle et représentés au moyen d'acteurs métier.

Diagramme décrit dans le texte d'accompagnement.

La figure ci-dessus représente les acteurs et cas d'utilisation métier d'un modèle de cas d'utilisation métier d'une organisation de gestion des commandes. Cette organisation vend des solutions complexes, personnalisées en fonction des besoins de chaque client.

Exemples de brèves descriptions des cas d'utilisation métier :

Processus de commande : processus décrivant la façon dont l'entreprise entreprend les actions appropriées pour livrer une solution à un client, en fonction d'un ensemble de besoins client. Ce processus se déclenche lorsqu'est prise la décision métier de traiter une solution faisant l'objet d'un consensus. Une situation courante illustrant ce processus consiste en la réception par l'entreprise d'un bon de commande provenant d'un client. Ce processus prend fin lorsque le client s'estime satisfait de la livraison, que la solution a été mise en place et que le paiement a été reçu. L'objectif est de répondre aux besoins client sans perdre de vue la rentabilité.

Processus de proposition : processus de génération d'une ou plusieurs propositions en réponse aux besoins exprimés par le client. Ce processus est déclenché par la requête d'un client et prend fin lorsque ce dernier accepte (ou rejette) la ou les offre(s) de la proposition. L'objectif est de parvenir à un accord sur une offre acceptable aussi bien pour le client que pour l'entreprise.

Processus d'offre : cas d'utilisation métier abstrait inclus dans le processus de proposition et dans le processus de commande. Ce processus est déclenché lorsque des besoins client appellent la génération d'une offre. L'objectif de ce processus est de générer une solution répondant aux besoins du client et de lui associer un prix.

Description générale

Une description générale de modèle de cas d'utilisation métier doit :

  • résumer l'objectif de l'organisation,
  • indiquer les limites du modèle, c'est-à-dire mentionner les éléments non inclus et les motifs de cette exclusion,
  • définir les cas d'utilisation métier primaires.

Exemple :

Ce modèle de cas d'utilisation métier couvre la partie de l'entreprise qui gère les commandes des clients ; en effet, seule cette partie présente un intérêt pour le projet d'ingénierie logicielle qui utilisera les résultats de la modélisation métier en tant qu'entrée. C'est pourquoi nous n'incluons pas les parties de l'entreprise s'occupant de la facturation, de la fabrication, de la gestion et du développement des produits, qui sont considérées comme externes et sont donc représentées comme des acteurs métier.

Dans cette organisation, la réalisation d'une vente n'implique pas seulement de parvenir à un accord sur une solution ; il faut également construire cette solution. Pour définir le prix d'une solution, vous devez procéder à son ingénierie et à sa construction à un certain niveau de détail. C'est l'objet du processus de proposition. Une fois qu'un accord a été trouvé avec le client, la solution est conçue dans ses moindres détails, puis installée dans les locaux du client. C'est l'objet du processus de commande. Les processus de proposition et de commande incluent chacun le cas d'utilisation métier abstrait Processus d'offre.

Caractéristiques d'un modèle de cas d'utilisation métier efficace

  • Les cas d'utilisation métier sont alignés sur la stratégie métier, comme décrit dans les objectifs métier concrets.
  • Les cas d'utilisation sont conformes au métier qu'ils décrivent.
  • Tous les cas d'utilisation ont été repérés. Pris ensemble, ils exécutent toutes les tâches du métier.
  • Toutes les tâches du métier doivent être inclues dans au moins un cas d'utilisation.
  • Il doit exister un équilibre entre le nombre et la taille des cas d'utilisation :
  • Le modèle est plus compréhensible s'il comporte peu de cas d'utilisation.
  • La multiplication des cas d'utilisation rend plus difficile la compréhension du modèle.
  • Des cas d'utilisation de grande dimension peuvent se révéler complexes et difficiles à appréhender.
  • Il est souvent plus facile de comprendre les cas d'utilisation de plus petite dimension. Cependant, assurez-vous que le cas d'utilisation décrit la totalité d'un enchaînement d'activités présentant de l'intérêt pour le client.
  • Tous les cas d'utilisation doivent être uniques. Si l'enchaînement d'activités est identique ou similaire à un autre cas d'utilisation, il sera par la suite difficile de garantir leur synchronisation. Vous pouvez les fusionner afin d'obtenir un seul cas d'utilisation.
  • La description générale du modèle de cas d'utilisation métier doit donner une image claire et exhaustive de l'organisation.