Un cas d'utilisation, bloc fonctionnel ou cas d'usage (« use-case » en anglais), définit en génie logiciel et en ingénierie des systèmes une manière d'utiliser un système qui a une valeur ou une utilité pour les acteurs impliqués. Le cas d'utilisation correspond à un ensemble d'actions réalisées par le système en interaction avec les acteurs en vue d'une finalité. L'ensemble des cas d'utilisation permet ainsi de décrire les exigences fonctionnelles d'un système en adoptant le point de vue et le langage de l'utilisateur final.
Origine et évolution En 1987, Ivar Jacobson présente le premier article sur les cas d'utilisation lors de la conférence OOPSLA '87. Il y décrit comment cette technique mise au point chez Ericson peut servir à capturer les exigences d'un système, sous une forme graphique, dans le cadre d'une méthode d'analyse et de conception « orientée objet ». En 1992, il publie OOSE, une méthode d'ingénierie des systèmes qui est orientée objet et pilotée à partir des cas d'utilisation. En 1994, il publie ensuite un ouvrage sur l'emploi des cas d'utilisation dans le contexte de la réingénierie des processus et des modèles d'affaires.
Dans le même temps, Grady Booch et James Rumbaugh travaillent à unifier leurs méthodes d'analyse et de conception orientées objets, la méthode Booch et l' Object modeling technique (OMT). Ils sont rejoints en 1995 par Ivar Jacobson, et donnent naissance au langage de modélisation UML, dont la normalisation confiée à un consortium, l'Object Management Group (OMG), aboutit en 1997. Au-delà du langage de modélisation graphique, Jacobson, Booch et Rumbaugh travaillent également à une méthode de développement unifiée, qui sera basée dans un premier temps sur Objectory, puis enrichie. Cette méthode devient en 1999 le processus unifié et perpétue le principe d'un pilotage par les cas d'utilisation, et précise comment ceux-ci sont utilisés pour capturer les exigences et servir de fil conducteur à tout le processus de développement.
À la suite de Jacobson, plusieurs auteurs ont contribué à la technique des cas d'utilisation, parmi lesquels on citera en particulier Alistair Cockburn qui a développé en 2000 une approche des cas d'utilisation axée sur leur finalités et qui a également popularisé une description narrative et tabulaire -- véritable alternative aux diagrammes de cas d'utilisation --, Geri Schneider et Jason Winters qui ont publié en 2001 des bonnes pratiques, Kurt Bittner et Ian Spence qui ont perfectionné en 2002 les pratiques d'analyse des exigences fonctionnelles, et Gunnar Overgaard qui a proposé en 2004 d'appliquer le concept des patrons de conception aux cas d'utilisation.
Dans les années 1990 les cas d'utilisation devinrent une des pratiques les plus utilisées pour travailler sur la relation fonctionnelle. Ils furent notamment populaires au sein de la communauté orienté-objet, dont est issu le concept de cas d'utilisation. Cependant leur usage ne se limite pas aux systèmes orientés-objet, les cas d'utilisation n'étant pas orientés-objet par nature.
En 2011, Ivar Jacobson, Ian Spence et Kurt Bittner, publient « Use Case 2.0 », un livre électronique, pour actualiser l'approche et faciliter l'emploi des cas d'utilisation dans le contexte de méthodes agiles, en les enrichissant de la notion de tranche (« use-case slice » en anglais).
Principes Le cas d'utilisation est une technique pour capturer les exigences d'un système et servir de fil conducteur à l'ensemble des activités nécessaires à sa mise en œuvre. Selon le SWEBOK, ils font partie de la famille des techniques de collecte d'exigences à base de scénarios.
Selon Bittner et Spence, . Le cas d'utilisation correspond donc à un ensemble d'actions réalisées par le système en interaction avec les acteurs en vue d'une finalité.
Plusieurs définitions plus précises témoignent de l'évolution du concept, partant initialement d'une compréhension comportementale, pour arriver à une vision pilotée par les objectifs :
en 1999, ; en 2001, ;
en 2011, .
Les cas d'utilisation tentent d'éviter tout jargon technique et essayent au contraire d'adopter le langage de l'utilisateur final ou de l'expert du domaine.
Éléments constitutifs Un cas d'utilisation est identifié par une finalité pour un acteur du système appelé acteur primaire. Par acteur il faut entendre un utilisateur humain ou un autre système. Un cas d'utilisation peut aussi impliquer d'autres acteurs, appelés acteurs secondaires.
Chaque cas d'utilisation correspond à un ou plusieurs scénarios qui définissent l'interaction entre le système et les utilisateurs. Généralement, il y a un scénario principal et éventuellement des variantes. Celles-ci correspondent à des cas particuliers et à des exceptions. Les scénarios peuvent inclure d'autres cas d'utilisation.
Chaque cas fait l'objet d'un descriptif ou d'une spécification qui présente les différents cas de figure.
Dans l'approche des « cas d'utilisation 2.0 », la description initiale est réduite à sa plus simple expression, sans scénario. Ce cas est alors enrichi par la description de « tranches de cas d'utilisation » (« use-case slice » en anglais). Chaque tranche représente un scénario ou une variante, mais selon un découpage qui permet à chaque tranche d'être implémentée au cours d'une itération. L'ensemble des tranches doit en principe couvrir finalement tous les scénarios et variantes du cas d'utilisation.
Types Il existe plusieurs types de cas d'utilisation, qui correspondent à des usages différents :
le cas d'utilisation concret est la forme la plus courante. Les scénarios en décrivent la séquence des interactions en détail, étape par étape, telles qu'elles sont vues par l'utilisateur. La conséquence est que l'enchaînement des actions est alors pris comme un fait accompli, sans que l'ergonomie qui en résulte ne soit jamais remise en question ; le cas d'utilisation paramétré regroupe plusieurs cas très similaires. La description est alors générique et permet la prise en compte de légères différences par le biais des paramètres ; le « cas d'utilisation essentiel » (en anglais « essential use case »La traduction tient compte du fait que dans « essential use-case », « essential » se réfère à « case » et non à « use » ), parfois également appelé « cas d'utilisation abstrait », est une forme épurée, qui ne se réfère qu'aux intentions de l'utilisateur et sans aucune idée préconçue sur la technologie qui sera utilisée, la chronologie des interactions, l'ergonomie adoptée, ou la mise en œuvre. Au lieu de décrire l'enchaînement des actions du scénario, le cas d'utilisation essentiel montre les différentes intentions de l'utilisateur et les responsabilités correspondantes du système. L'avantage de ce procédé est qu'il laisse une grande liberté pour concevoir des solutions innovantes susceptibles de remettre en cause les pratiques habituelles. C'est l'approche recommandée pour une démarche centrée sur l'utilisateur ;
un « cas d'utilisation métier » (en anglais business use case) est un cas d'utilisation dans le cadre d'un modèle d'affaires. Le système considéré n'est alors pas un système informatique mais un processus métier ou une entreprise. Les cas d'utilisation du système informatique en seront déduits dans un deuxième temps.
Niveaux d'objectif et granularité Un cas d'utilisation élémentaire correspond à la plus petite unité activité produisant un résultat significatif pour l'utilisateur. Il s'agit en général des tâches qui lui sont attribuées. C'est par ailleurs un ensemble perçu par l'utilisateur comme cohérent, indépendant en soi, et utile.
Alistair Cockburn préconise une approche des cas d'utilisation par les objectifs (« goal-oriented behaviour » en anglais). Constatant alors qu'il y a une différence entre les objectifs décrits à l'échelle d'une organisation et ceux définis pour les tâches d'un utilisateur, il introduit la notion de niveau d'objectif: Niveau d'objectifAnalogie avec l'altitudeSymboleDescription du niveauStratégiqueNuagecentré|sans_cadreObjectif et raison d'être du système. Identifie les fonctions principales du système pour l'entreprise.Cerf-volantcentré|sans_cadreObjectif métier de l'entreprise. Identifie les fonctions principales du système pour des activités métier de l'entreprise. Il correspond à des activités métier impliquant plusieurs utilisateurs. UtilisateurNiveau de la mercentré|sans_cadreObjectif poursuivi par un utilisateur lorsqu'il utilise le système. Il correspond à une tâche élémentaire de l'utilisateur (durée de 2 à 20 minutes) Sous-fonctionPoisson sous la mercentré|sans_cadreParticipe à la réalisation d'un objectif utilisateur auquel il est lié par une relation de type inclusionTrop détailléCoquillage au fond de la mercentré|sans_cadreÀ éviter alt=Illustration des niveaux de cas d'utilisation|vignette|634x634px|Illustration des niveaux de cas d'utilisation.
Portée Si le niveau d’objectif renseigne sur le niveau de détail du cas d’utilisation, la portée elle indique le périmètre d’action. Trois niveaux de portée sont distingués : la portée entreprise : en rapport avec les fonctions importantes de l’entreprise ; la portée système : axe sur le projet en lui-même ; la portée sous-système : intérêt à une partie seulement du projet.
Documentation Une vue d'ensemble des cas d'utilisation peut être : graphique, avec un ou plusieurs diagrammes de cas d'utilisation ; graphique, avec une cartographie des cas d'utilisation. Celle-ci est une représentation graphique d'un ensemble de cas et de leurs relations (spécialisation/généralisation, inclusion, extension, interdépendance et similarités), qui peut être utilisée à l'instar des cartes heuristiques ; tabulaire, avec un tableau énumérant les cas d'utilisation, les acteurs impliqués, et éventuellement d'autres informations pertinentes.
Chaque cas d'utilisation peut être documenté sous forme : graphique, avec un diagramme de cas d'utilisation représentant le détail ; graphique, avec un diagramme d'interaction représentant les échanges entre l'utilisateur et le système ; textuelle, avec une description des scénarios sous forme narrative continue, de liste numérotée, de liste indentée ou de pseudo-code ; tabulaire, avec 2 colonnes (l'une pour les intentions de l'utilisateur et l'autre pour les responsabilités du système) ; formulaire ou fiche (reprend également une représentation tabulaire ou textuelle comme ci-dessus) ; carte ou post-it, présentant de façon épurée cas d'utilisation 2.0. Celui-ci est décomposé en « tranches » (« use-case slice » en anglais) faisant chacune l'objet d'une carte ou un post-it. Chaque tranche représente un incrément à implémenter.
Les cas d'utilisation sont souvent écrits à la fois par les analystes, les utilisateurs finaux ou un expert. En UML, chaque cas d'utilisation est représenté au sein d'un diagramme de cas d'utilisation, chacun des scénarios de celui-ci pouvant être décrit lors de l'analyse par un ou plusieurs diagrammes dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions.
Description graphique
alt=Exemple simple de cas d'utilisation avec un système représenté par un rectangle, à l'intérieur duquel un ovale représente un cas d'utilisation, qui est relié à deux acteurs sous forme de personnage filiforme à l'extérieur du système|vignette|304x304px|Exemple de diagramme de cas d'utilisation. Les diagrammes de cas d'utilisation permettent de représenter une vue sur le système considéré, avec des cas d'utilisation et les acteurs impliqués. Généralement les acteurs primaires sont représentés à gauche, mais ce n'est pas une norme.
Description textuelle alt=Exemple de description de cas d'utilisation sous forme tabulaire|vignette|371x371px|Exemple de description des cas d'utilisation. La documentation textuelle d'un cas d'utilisation se compose en général des parties suivantes :