[go: up one dir, main page]
Aller au contenu

Cas d'utilisation

Un article de Wikipédia, l'encyclopédie libre.
Page d’aide sur l’homonymie

Ne doit pas être confondu avec Diagramme des cas d'utilisation ou Récit utilisateur.

Un cas d'utilisation, bloc fonctionnel 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 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 œuvre. 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.

Éléments constitutifs

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

Types

[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'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[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érences 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 œuvre[16],[17],[18]. 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[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éduits 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
Objectif et raison d'être du système. Identifie les fonctions principales du système pour l'entreprise.
Cerf-volant
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
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
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
À éviter
Illustration des niveaux de cas d'utilisation
Illustration des niveaux de cas d'utilisation.

Portée

[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

[modifier | modifier le code]

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

  • 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 de 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 à gauche, mais ce n'est pas 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 exemple 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 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 douze 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

[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 utilisateurs[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 procure une vision cohérente d'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 peuvent être prise en compte et intégrées aux cas d'utilisation, elles risquent d'être masquées par les interactions entre acteurs et système. Les deux cas de figure peuvent alors causer des problèmes ultérieurement lorsque les règles métier doivent être adaptées. 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 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 adaptations des cas d'utilisation pour l'analyse des menaces pouvant porter atteinte à la sécurité des systèmes[27]. Les utilisateurs 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 œuvre 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écit 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 œuvre. 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’enchaînement des écrans[18].

Références

[modifier | modifier le code]
  1. ↑ « cas d'usage », sur gdt.oqlf.gouv.qc.ca (consulté le )
  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 )
  3. ↑ a b c d e f g h i et j (en) Cockburn, Alistair., Writing effective use cases, Addison-Wesley, (ISBN 0-201-70225-8 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 )
  5. ↑ (en) Jacobson, Ivar., Object-oriented software engineering : a use case driven approach, ACM Press, (ISBN 0-201-54435-0 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, Wokingham/Reading (Mass.)/Paris etc., Addison-Wesley, ©1995, 347 p. (ISBN 0-201-42289-1 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 )
  8. ↑ a b c d et e Jacobson, Ivar., Rumbaugh, James. et Zaïm, Virginie. (trad. de l'anglais), Le processus unifié de développement logiciel, Paris, Eyrolles, , 488 p. (ISBN 2-212-09142-7 et 9782212091427, OCLC 45152206, lire en ligne)
  9. ↑ (en) Schneider, Geri. et Winters, Jason, Applying use cases : a practical guide, Boston, Addison-Wesley, , 245 p. (ISBN 0-201-70853-1 et 9780201708530, OCLC 45284668, lire en ligne)
  10. ↑ (en) Bittner, Kurt et Spence, Ian, Use case modeling, Addison Wesley, (ISBN 0-201-70913-9 et 9780201709131, OCLC 50041546, lire en ligne)
  11. ↑ (en) Övergaard, Gunnar., Use cases : patterns and blueprints, Addison-Wesley, (ISBN 0-13-145134-0 et 9780131451346, OCLC 57361841, lire en ligne)
  12. ↑ (en-US) « Software Engineering Body of Knowledge (SWEBOK) | IEEE Computer Society » (consulté le )
  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 0-201-65789-9 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 0-201-92478-1 et 9780201924787, OCLC 39962434, lire en ligne)
  17. ↑ (en) « Essential (Abstract) Use Cases: An Agile Introduction », sur agilemodeling.com (consulté le )
  18. ↑ a b c et d (en) Jacobson, Ivar., Booch, Grady. et Rumbaugh, Jim., The unified software development process, Addison-Wesley, (ISBN 0-201-57169-2, 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 )
  21. ↑ (en) Bittner, Kurt., Use case modeling, Addison Wesley, (ISBN 0-201-70913-9 et 9780201709131, OCLC 50041546, lire en ligne), 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 )
  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 )
  24. ↑ (en) « Use Cases and Business Rules: Can They Work Together? > Business Analyst Community & Resources | Modern Analyst », sur www.modernanalyst.com (consulté le )
  25. ↑ Goal-Driven SOA
  26. ↑ (en) Patton, Jeff (Software developer),, Fowler, Martin, 1963-, Cooper, Alan, 1952- et Cagan, Marty,, User story mapping : Discover the Whole Story, Build the Right Product, , 276 p. (ISBN 978-1-4919-0490-9, 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 )
  29. ↑ (en) Mike Cohn, « User Stories and User Story Examples by Mike Cohn », sur Mountain Goat Software (consulté le )
  30. ↑ (en-US) Andrew Stellman, « Requirements 101: User Stories vs. Use Cases », sur Building Better Software, (consulté le )

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 0-201-54435-0)
  • Ivar Jacobson, Grady Booch et James Rumbaugh (trad. de l'anglais par Zaïm, Virginie), Le processus unifié de développement logiciel [« The unified software development process »], Eyrolles, , 488 p. (ISBN 978-2-212-09142-7)
  • (en) Ivar Jacobson, Maria Ericson et Agneta Jacobson, The object advantage : business process reengineering with object technology, Wokingham/Reading (Mass.)/Paris etc., Addison Wesley, , 347 p. (ISBN 0-201-42289-1)
  • Alistair Cockburn (trad. de l'anglais), Rédiger des cas d'utilisation efficaces [« Writing effective use cases »], Paris, Eyrolles, , 290 p. (ISBN 2-212-09288-1, présentation en ligne)

Liens externes

[modifier | modifier le code]
v · m
Organismes
Personnalités
Concepts
Orientation objet
Structure
Comportement
Relation
Autres
Diagrammes
Structure
Comportement
Interaction
Articles liés
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Cas_d%27utilisation&oldid=219794263 ».