Cas d'utilisation

Un article de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche
Ne doit pas être confondu avec Diagramme des cas d'utilisation ou Récit utilisateur.

Un cas d'utilisation, ou cas d'usage[1] ( « 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[2],[3]. 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 et de l'utilisateur final[4].

Origine et évolution[modifier | modifier le code]

En 1987, Ivar Jacobson présente le premier article sur les cas d'utilisation lors de la conférence OOPSLA '87[4],[2]. 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[5]. 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[6].

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[7]. 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[8].

À la suite de Jacobson, plusieurs auteurs ont contribué à la technique des cas d'utilisation, parmi lesquels on citera en particulier Alistair Cockburn[3] 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[9] qui ont publié en 2001 des bonnes pratiques, Kurt Bittner et Ian Spence[10] qui ont perfectionné en 2002 les pratiques d'analyse des exigences fonctionnelles, et Gunnar Overgaard[11] 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[réf. souhaitée]. 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)[2].

Principes[modifier | modifier le code]

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 oeuvre. Selon le SWEBOK, ils font partie de la famille des techniques de collecte d'exigences à base de scénarios[12].

Selon Bittner et Spence, « Un cas d'utilisation (...) permet de décrire une séquence d'événements qui, pris tous ensemble, définissent un système faisant quelque chose d'utile »[13]. 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, « Un cas d'utilisation définit une séquence d'action, avec des variantes, que le système peut réaliser et qui produit un résultat observable qui a de la valeur pour un utilisateur particulier »[8];
  • En 2001, « Un cas d'utilisation capture un contrat entre les parties prenantes et un système concernant les comportements de celui-ci. Un cas d'utilisation décrit les comportements d'un système sous différentes conditions en réponse à une requête de l'une de ses parties prenantes »[3];
  • En 2011, « Un cas d'utilisation est l'ensemble des manières d'utiliser un système pour atteindre un but spécifique pour un utilisateur particulier. L'ensemble de tous les cas d'utilisation indique toutes les façons utiles d'utiliser un système »[2].

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.

Eléments constitutifs d'un cas d'utilisation[modifier | modifier le code]

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[3].

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[3]. 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 au final tous les scénarios et variantes du cas d'utilisation[2].

Types de cas[modifier | modifier le code]

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[14]. La conséquence est que l'enchainement des actions est alors pris comme un fait accompli, sans que l'ergonomie qui en résulte ne soit jamais remise en question[8].
  • 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érence par le biais des paramètres[3].
  • Le « cas d'utilisation essentiel » (en anglais « essential use case »[15]), 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 oeuvre[16],[17],[18]. Au lieu de décrire l'enchainement 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[14]. C'est l'approche recommandée pour une démarche centrée sur l'utilisateur[14].
  • 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[6]. Les cas d'utilisation du système informatique en seront déduit dans un deuxième temps.

Niveaux d'objectif et granularité[modifier | modifier le code]

Un cas d'utilisation élémentaire correspond à la plus petite unité activité produisant un résultat significatif pour l'utilisateur[2]. Il s'agit en général des tâches qui lui sont attribuées[14]. C'est par ailleurs un ensemble perçu par l'utilisateur comme cohérent, indépendant en soi, et utile[19].

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[3]:

Niveau d'objectif Analogie avec l'altitude Symbole Description du niveau
Stratégique Nuage
Goal-level-icons-cloud.png
Objectif et raison d'être du système. Identifie les fonctions principales du système pour l'entreprise.
Cerf-volant
Goal-level-icons-flying-kite.png
Objectif 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.
Utilisateur Niveau de la mer
Goal-level-icons-waves-at-sea.png
Objectif 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-fonction Poisson sous la mer
Goal-level-icons-fish.png
Participe à la réalisation d'un objectif utilisateur auquel il est lié par une relation de type inclusion
Trop détaillé Coquillage au fond de la mer
Goal-level-icons-seabed-clam-shell.png
A éviter
Illustration des niveaux de cas d'utilisation
Illustration des niveaux de cas d'utilisation

Portée des cas d'utilisation[modifier | modifier le code]

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 des cas d'utilisation[modifier | modifier le code]

Une vue d'ensemble des cas d'utilisation peut être offerte sous forme :

  • graphique, avec un ou plusieurs diagrammes de cas d'utilisation[20];
  • graphique, avec une cartographie des cas d'utilisation. Celle-ci est une représentation graphique d'un ensemble de cas et de leurs relation (spécialisation/généralisation, inclusion, extension, interdépendance et similarités)[14], qui peut être utilisée à l'instar des cartes heuristiques.
  • tabulaire, avec un tableau énumérant les cas d'utilisation[3], 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[14];
  • textuelle, avec une description des scénarios sous forme narrative continue, de liste numérotée, de liste indentée ou de pseudo-code[14];
  • tabulaire, avec 2 colonnes (l'une pour les intentions de l'utilisateur et l'autre pour les responsabilités du système)[14];
  • formulaire ou fiche (reprend également une représentation tabulaire ou textuelle comme ci-dessus)[3];
  • 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[2].

Les cas d'utilisation sont souvent écrits à la fois par les analystes, les utilisateurs finaux ou un expert[réf. souhaitée]. 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[8].

Description graphique[modifier | modifier le code]

Article détaillé : Diagramme des cas d'utilisation.
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
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 sur la gauche, mais ce n'est aps une norme.

Description textuelle[modifier | modifier le code]

Exemple de description de cas d'utilisation sous forme tabulaire
Exemple de description des cas d'utilisation

La documentation textuelle d'un cas d'utilisation se compose en général des parties suivantes[21] :

  • Désignation du cas d'utilisation : devrait en principe commencer par un verbe ( « afficher une image » par exemple).
  • Description brève
  • Évènement déclencheur
  • Enchainements des événements du point de vue de l'utilisateur, sans préciser les étapes techniques sous-jacentes. On distingue :
    • Le scénario de base
    • Les variantes (par exemples scénario d'échecs et d'exceptions)
    • Des séquences plus détaillés pour certains événements
  • Exigences particulières : exigences qui n'apparaissent pas ci-dessus (par exemple des exigences non-fonctionnelles ou contraintes)
  • Pré-conditions : conditions requises pour que le cas soit applicable
  • Post-conditions : conséquences du succès de l'application du système
  • Extensions : liste de tous les scénarios différents du nominal, suivis de leurs conditions de réalisations ainsi que de leurs actions et éventuellement sous-cas d'utilisation
  • Diagrammes

On peut y ajouter également[3] :

  • Acteur : acteurs principaux, déclencheurs du cas
  • Parties prenantes et leurs intérêts : sous forme de liste
  • Niveau et portée
  • Questions ouvertes : permettent l'amélioration du cas en appuyant sur les zones d'ombres du projet
  • Annexes

Alistair Cockburn suggère 12 recommandations de rédaction:

  1. Partir des grandes fonctions et se maintenir le plus possible au niveau objectif utilisateur.
  2. Centrer son attention sur le cas nominal.
  3. Préciser toujours les parties prenantes et leurs intérêts.
  4. Utiliser le présent de l’indicatif.
  5. Utiliser la voie active pour décrire les sous-objectifs en cours de satisfaction.
  6. Le sujet doit être clairement localisable.
  7. Rester concis et pertinent ; éviter les longs documents.
  8. Éviter le conditionnel, et placer les comportements alternatifs dans les extensions.
  9. Signaler les sous-cas d’utilisation, représentés par la relation d’inclusion « include ».
  10. Identifier le bon objectif.
  11. Signaler la portée.
  12. Laisser de côté l’interface utilisateur.

Avantages et limites des cas d'utilisation[modifier | modifier le code]

Avantages[modifier | modifier le code]

Les cas d'utilisation sont efficaces pour le recueil des exigences sur la base des scénarios d'utilisation d'un système car ils se focalisent sur les interactions acteurs / système selon les choix de leurs utilisateurs. Ils permettent également de préparer les tests de recette basés sur l'utilisation du système.

Les cas d'utilisation peuvent aisément être mis en relation avec des tâches et activités métier lorsqu'ils sont structurés par niveau d'objectif. Ceci facilite d'une part la communication avec le management des utlisateurs[22] et d'autre part la gestion des changements organisationnels, y compris dans un contexte de réingénierie de processus[6]. Les cas d'utilisation peuvent de ce fait aussi servir de base pour des manuels et la documentation centrées sur l'utilisateur.

La structure des cas d'utilisation offre une vision cohérente sur un ensemble d'exigences étroitement liées. Ils sont ainsi plus faciles à lire qu'une présentation linéaire d'exigences faiblement structurées. Ceci permet en outre à toutes les étapes d'un projet de bénéficier du contexte des fonctionnalités à développer[22].

Limites et risques[modifier | modifier le code]

Selon certains auteurs, les cas d'utilisation ne peuvent à eux-seuls piloter les processus de développement car ils ne tiennent pas compte des règles métier transverses. Lorsque celles-ci seraient prise en compte et intégrées aux cas d'utilisation, elles risqueraient d'être masquées derrière les interactions entre acteurs et système. Les deux cas de figure pourraient alors causer des problèmes ultérieurement lorsque les règles métier doivent être adaptées suite à l'évolution des besoins. Toutefois ces risques sont à relativiser, car de nombreux modèles de description proposent d'identifier les règles métiers à part, et de faire explicitement référence à ces règles dans les cas d'utilisation lorsque c'est opportun[14],[23],[24].

Le mélange des interactions acteurs / système et des règles métier au sein des cas d'utilisation cause par ailleurs un handicap dans le cadre de l'évolution d'une architecture orientée service (SOA) dont les services sont basés sur les cas d'utilisation. Une alternative basée sur la séparation des règles métier et des cas d'utilisation et permettant respectivement aux services SOA d'encapsuler les règles métier et aux cas d'utilisation de se focaliser seulement sur les choix de navigation des utilisateurs est proposée dans la démarche 'Goal-driven SOA[25].

Les cas d'utilisation risquent par une description trop détaillée d'influencer l'ergonomie du système sur la bases d'idées préconçues sur la séquence des actions et le mode d'interaction entre l'utilisateur et le système[18]. Ce risque peut être éliminé par le recours aux cas d'utilisation essentiels[14],[18].

Selon certains auteurs, les cas d'utilisation ne seraient pas adaptés aux approches agiles en raison de la nécessité de documenter intégralement tous leurs scénarios avant de pouvoir les incorporer dans la planification d'une itération[22]. Toutefois cette critique est très discutable, car Cockburn, l'un des co-auteur du manifeste agile, affirme une préférence marquée pour les cas d'utilisation[22]. De plus la technique des « cas d'utilisation 2.0 », publiée en 2011, a été développée spécifiquement pour une intégration aisée avec les pratiques agiles[2]. Cette approche est comparable à la technique des cartographies de récits utilisateurs (« user story mapping » en anglais) qui lui est postérieure, souvent utilisée dans un contexte agile[26].

Variantes et concepts voisins[modifier | modifier le code]

Les « cas de d'abus » et les « cas de détournement d'utilisation » (respectivement « abuse case » et « misuse case » en anglais, jouant sur la proximité des mots avec « use case » ) sont des adaptation des cas d'utilisation pour l'analyse des menaces pouvant porter atteinte à la sécurité des systèmes[27]. Les utilisateur de ces cas sont alors des acteurs malveillants.

Le diagramme de cas d'utilisation est une représentation graphique d'un système et d'un ou plusieurs cas d'utilisation avec les acteurs impliqués[20]. Il s'agit d'une représentation particulière de cas d'utilisation définie par UML, et non le cas d'utilisation en lui-même.

Une « réalisation de cas d'utilisation » correspond à une manière de mettre en oeuvre un cas d'utilisation[8].

Une « instance de cas d'utilisation » est une exécution d'un cas d'utilisation par le système pour un utilisateur donné lors d'une interaction à un instant précis (par exemple pour enregistrer une transaction commerciale).

Un récits utilisateur ( « user story » en anglais[28] ) est la description d'une fonctionnalité souhaitée décrite du point de vue d'un utilisateur[29]. Tout comme le cas d'utilisation, le récit est centré sur l'utilisateur (un rôle, un acteur), doit apporter de la valeur, et permet de piloter le développement et les tests. Une première différence concerne le sujet traité: les cas d'utilisation correspondent à un ensemble d'actions alors que les récits se veulent plus flexibles et peuvent ainsi décrire aussi bien un cas d'utilisation complexe, qu'une fonctionnalité élémentaire[30]. Une seconde différence concerne les acteurs: le récit ne traite que le point de vue d'un seul utilisateur, alors que le cas d'utilisation fait ressortir la pluralité des acteurs impliqués et des points de vue.

Un cas d'utilisation correspond à une exigence fonctionnelle mais ne définit pas l'interface utilisateur qui le met en oeuvre. Le processus unifié recommande ainsi de recourir à des esquisses et des prototypes plutôt qu'à des cas d'utilisation pour représenter la logique de l'interface utilisateur et l'enchainement des écrans[18].

Références[modifier | modifier le code]

  1. « cas d'usage », sur gdt.oqlf.gouv.qc.ca (consulté le 30 juin 2019)
  2. a b c d e f g et h (en) Dr. Ivar Jacobson, Ian Spence et Kurt Bittner, « Use-Case 2.0 ebook », sur Ivar Jacobson International, (consulté le 12 juin 2019)
  3. a b c d e f g h i et j (en) Cockburn, Alistair., Writing effective use cases, Addison-Wesley, (ISBN 0201702258 et 9780201702255, OCLC 44046973, lire en ligne)
  4. a et b (en) Ivar Jacobson, « Object-oriented Development in an Industrial Environment », SIGPLAN Not., vol. 22, no 12,‎ , p. 183–191 (ISSN 0362-1340, DOI 10.1145/38807.38824, lire en ligne, consulté le 12 juin 2019)
  5. (en) Jacobson, Ivar., Object-oriented software engineering : a use case driven approach, ACM Press, (ISBN 0201544350 et 9780201544350, OCLC 26132801, lire en ligne)
  6. a b et c (en) Jacobson, Ivar. et Jacobson, Agneta., The object advantage : business process reengineering with object technology, Addison-Wesley, [©1995] (ISBN 0201422891 et 9780201422894, OCLC 32276135, lire en ligne)
  7. (en) « About the Unified Modeling Language Specification Version 2.5.1 », sur www.omg.org (consulté le 30 juin 2019)
  8. a b c d et e Jacobson, Ivar., Rumbaugh, James. et Zaïm, Virginie., Le processus unifié de développement logiciel, Eyrolles, (ISBN 2212091427 et 9782212091427, OCLC 45152206, lire en ligne)
  9. (en) Schneider, Geri. et Winters, Jason, Applying use cases : a practical guide, Addison-Wesley, (ISBN 0201708531 et 9780201708530, OCLC 45284668, lire en ligne)
  10. (en) Bittner, Kurt et Spence, Ian, Use case modeling, Addison Wesley, (ISBN 0201709139 et 9780201709131, OCLC 50041546, lire en ligne)
  11. (en) Övergaard, Gunnar., Use cases : patterns and blueprints, Addison-Wesley, (ISBN 0131451340 et 9780131451346, OCLC 57361841, lire en ligne)
  12. (en-US) « Software Engineering Body of Knowledge (SWEBOK) | IEEE Computer Society » (consulté le 6 juillet 2019)
  13. (en) Ivar Jacobson, Kurt Bittner, Ian Spence, Use Case Modeling, Addison Wesley Professional, (ISBN 0-201-70913-9)
  14. a b c d e f g h i et j (en) Van Harmelen, Mark., Object modeling and user interface design, Addison-Wesley, (ISBN 0201657899 et 9780201657890, OCLC 45058748, lire en ligne), Article « Structure and Style in Use Cases for User Interface Design » de Larry L. Constantine et Lucy A. D. Lockwood
  15. La traduction tient compte du fait que dans « essential use-case », « essential » se réfère à « case » et non à « use »
  16. (en) Constantine, Larry L., Software for use : a practical guide to the models and methods of usage-centered design, Addison Wesley, (ISBN 0201924781 et 9780201924787, OCLC 39962434, lire en ligne)
  17. (en) « Essential (Abstract) Use Cases: An Agile Introduction », sur agilemodeling.com (consulté le 6 juillet 2019)
  18. a b c et d (en) Jacobson, Ivar., Booch, Grady. et Rumbaugh, Jim., The unified software development process, Addison-Wesley, (ISBN 0201571692, 9780201571691 et 9780321822000, OCLC 636807532, lire en ligne), p. 116, 142 et 160-166, en particulier p.116 « The best way to develop this user interface specification is to sketch several versions (...) » et l'encart page 164 sur les cas d'utilisation essentiels: « (...) use-case specifiers first prepare lightweight use-case descriptions that do no contain any implicit user-interface decision. (...) The user-interface designers can (...) create user interfaces without being bound by implicit decision. »
  19. Bruce Powel Douglass, « Chapter 4 - Agile Stakeholder Requirements Engineering », dans Agile Systems Engineering, Morgan Kaufmann, (ISBN 9780128021200, DOI 10.1016/b978-0-12-802120-0.00004-7, lire en ligne), p. 147–188
  20. a et b (en) « Unified Modeling Language Specification Version 2.5 », sur www.omg.org, (consulté le 3 juillet 2019)
  21. (en) Bittner, Kurt., Use case modeling, Addison Wesley, (ISBN 0201709139 et 9780201709131, OCLC 50041546, lire en ligne), p. Chapitre 7 intitulé « The Structure and Contents of a Use Case »
  22. a b c et d « Use Cases or User Stories? », sur InfoQ (consulté le 6 juillet 2019)
  23. (en) Ed Anderson, Mike Bradley et Rosemary Brinko, « Use case and business rules: styles of documenting business rules in use cases », Addendum to the 1997 ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (Addendum) - OOPSLA '97, ACM Press,‎ , p. 85–87 (ISBN 9781581130379, DOI 10.1145/274567.274584, lire en ligne, consulté le 6 juillet 2019)
  24. (en) « Use Cases and Business Rules: Can They Work Together? > Business Analyst Community & Resources | Modern Analyst », sur www.modernanalyst.com (consulté le 6 juillet 2019)
  25. Goal-Driven SOA
  26. (en) Patton, Jeff (Software developer),, Fowler, Martin, 1963-, Cooper, Alan, 1952- et Cagan, Marty,, User story mapping (ISBN 9781491904909, 1491904909 et 1491904860, OCLC 880566740, lire en ligne)
  27. (en) Donald Firesmith, « Security Use Cases », Journal of Object Technology, ETH Zurich, Chair of Software Engineering, vol. 2, no 3,‎ , p. 53-64 (lire en ligne)
  28. « récit utilisateur », sur www.granddictionnaire.com (consulté le 3 juillet 2019)
  29. (en) Mike Cohn, « User Stories and User Story Examples by Mike Cohn », sur Mountain Goat Software (consulté le 3 juillet 2019)
  30. (en-US) Andrew Stellman, « Requirements 101: User Stories vs. Use Cases », sur Building Better Software, (consulté le 3 juillet 2019)

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • (en) Ivar Jacobson, M. Christerson, P. Jonsson, G. Overgard, Object-Oriented software engineering: A use case driven approach, Addison Wesley Professional, (ISBN 0201544350)
  • Ivar Jacobson, Grady Booch et James Rumbaugh (trad. Zaïm, Virginie), Le processus unifié de développement logiciel [« The unified software development process »], Eyrolles, (ISBN 9782212091427)
  • (en) Ivar Jacobson, Maria Ericson et Agneta Jacobson, The object advantage : Business Process Reengineering with object technology, Addison Wesley, (ISBN 0-201-42289-1)
  • Alistair Cockburn, Rédiger des cas d'utilisation efficaces [« Writing effective use cases »], Eyrolles, (ISBN 2212092881, présentation en ligne)

Liens externes[modifier | modifier le code]