Existe-t-il une définition exacte, mais simple et compréhensible, de la distinction entre "cas d'utilisation", "User Story" et "Scénario d'utilisation"?

il y a pas mal d'explications, mais pour l'instant, je ne vois personne qui explique les différences en une phrase ou deux ...

(par exemple, http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison très long et difficile à obtenir, plein de discussions)

Une User Story est une version plus informelle, plus conviviale et plus petite d'un cas d'utilisation , moins le diagramme UML. il est généralement utilisé dans des scénarios itératifs.

Un scénario d'utilisation est un cas d'utilisation dessiné dans une procédure étape par étape, parfois accompagnée d'un organigramme.

Pour moi, les plus grandes différences entre une user story et un cas d'utilisation sont les suivantes:

• Une user story est un document léger pouvant être écrit sur une carte (pour pouvoir, en tant que je veux). Une User Story ne capture pas tous les détails, c'est un support informel pour la discussion.
• Un cas d'utilisation est un document lourd qui nécessite un document Word. Il décrit un "flux normal" d'étapes et / ou d'actions et des "flux alternatifs" détaillés. Un cas d'utilisation capture tous les détails, c'est une spécification formelle.

Selon Scott W. Ambler sur les scénarios d'utilisation , ces artefacts ressemblent au flux d'un cas d'utilisation:

Un scénario d'utilisation , ou scénario, décrit un exemple concret de la façon dont une ou plusieurs personnes ou organisations interagissent avec un système. Ils décrivent les étapes, les événements et / ou les actions qui se produisent pendant l'interaction. Les scénarios d'utilisation peuvent être très détaillés, indiquant exactement comment une personne travaille avec l'interface utilisateur, ou d'un niveau assez élevé décrivant les actions commerciales critiques, mais pas la manière dont elles sont exécutées.

Honnêtement, les différences avec le flux d'un cas d'utilisation ne sont pas claires, même après lecture de ce paragraphe (la dernière phrase étant peut-être la plus importante):

Comme vous pouvez l’imaginer, il existe plusieurs différences entre les cas d’utilisation et les scénarios. Premièrement, un cas d'utilisation fait généralement référence à des acteurs génériques, tels que Client, alors que les scénarios font généralement référence à des exemples d'acteurs tels que John Smith et Sally Jones. Rien ne vous empêche d'écrire un scénario générique, mais il est généralement préférable de personnaliser les scénarios pour améliorer leur compréhensibilité. Deuxièmement, les scénarios d'utilisation décrivent un seul chemin logique, tandis que les cas d'utilisation décrivent généralement plusieurs chemins (le cours de base plus les chemins alternatifs appropriés). Troisièmement, dans les processus basés sur UP, les cas d'utilisation sont souvent conservés en tant que documentation officielle, tandis que les scénarios sont souvent ignorés lorsqu'ils ne sont plus nécessaires.

Je me trompe peut-être, mais le scénario d'utilisation sonne vraiment comme un flux de cas d'utilisation, mais rebaptisé avec une touche agile.

Il n'y a pas de définition exacte de ce genre de choses. Tout varie un peu (ou beaucoup) d'une entreprise à l'autre et d'un système à l'autre.

Votre meilleur choix est de trouver un exemple déjà en place pour votre projet actuel et de le suivre.

Si vous créez un nouveau système, vous pouvez trouver des définitions de différents types de cas d'utilisation pour le système de votre choix - Il vous suffit de choisir le modèle qui semble le mieux communiquer vos intentions.

Ne vous attardez pas sur les noms.

Une user story est toujours informelle et décrit le besoin d'un utilisateur. Un cas d'utilisation peut être formel ou informel et décrit le comportement du système.

Il est possible d'avoir des user stories "tech", il n'en va pas de même pour les cas d'utilisation.

Une fois cela fait, la user story est généralement supprimée. Les cas d'utilisation peuvent être conservés pendant le cycle de vie du produit.

La portée est également différente. Les user stories ont généralement une portée plus petite et, par conséquent, un cas d'utilisation comprend plusieurs user stories. Une exigence modifiée pour un système existant est décrite dans une nouvelle user story ou une version mise à jour du cas d'utilisation.

La similarité entre les user stories et les cas d'utilisation est que les deux sont utilisés pour la planification et la planification.

Une user story, lorsqu'elle est décomposée en tâches pouvant être assignées individuellement à des développeurs, peut être plus ou moins granulaire et avoir une portée limitée par rapport à un scénario de cas d'utilisation. Une user story concerne le besoin de l'utilisateur - un objectif ou un résultat de son utilisation du système.

Exemples d'histoires d'utilisateurs:

1. Je suis un client et je souhaite payer le solde de mon compte en ligne - une vue de haut niveau
2. Je suis un client et je souhaite mettre à jour l'année d'expiration de mes informations de crédit stockées - une vue assez granulaire.

Au plus haut niveau d'abstraction, un cas d'utilisation semble très similaire - l'année d'expiration de la carte de mises à jour client -, mais il s'agit ici d'un énoncé de fonction plutôt que d'objectif.

À mesure que la granularité des scénarios de cas d'utilisation est définie, ils concernent davantage la fonction et la procédure.

La post-condition d'un scénario principal de cas d'utilisation doit être le même résultat que celui indiqué dans la User Story - L'année d'expiration de la carte de crédit du client est mise à jour.

Les scénarios de cas d'utilisation décrivent pas à pas dans un diagramme de flux de texte ou de processus (pas nécessairement UML ou BPM - j'utilise un diagramme de flux interfonctionnel standard pour plus de clarté et de facilité d'utilisation par les utilisateurs non formés du cas d'utilisation.

En résumé, les histoires d'utilisateurs décrivent les besoins et les résultats (ce que le système doit fournir), tandis que les cas d'utilisation décrivent les interactions entre les acteurs nécessaires pour atteindre l'objectif - ET ce qui peut mal tourner (Scénarios d'extension, de remplacement ou d'erreur) (comment l'utilisateur interagit-il avec le système atteint ce résultat)

Pour approfondir la discussion sur ce sujet, je suggère de lire http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison sur le site Web de Alistair Cockburn. Depuis qu'il est signataire du Manifeste Agile, la personne qui a inventé User Stories et qui est considéré comme un expert en cas d'utilisation, au cours des deux dernières décennies, je pense qu'il est une excellente source d'informations supplémentaires.

_{Remarque temporaire rapide : Ce poste doit être amélioré pour mieux répondre à la question, par exemple 1) des références supplémentaires doivent être incluses à partir des références 2) quelques citations peut-être 3) exactitude globale de l’anglais 4) qualité générale de la narration 5) etc. Je serai retour à elle. N'hésitez pas à l'améliorer vous-même.}

En jetant un coup d'œil sur leurs modèles, vous obtiendrez de précieuses informations sur les différences entre ces termes.

Cas d'utilisation

Il existe plusieurs modèles pour les cas d'utilisation. J'ai trouvé 3 après une recherche rapide: 1 , 2 , 3 . Quelques points communs (parfois vaguement) sont les suivants:

1. Nom du cas d'utilisation / titre
2. Description - un court texte décrivant la portée.
3. Acteur (s) / Acteur principal - personne (s) qui interagit avec ce cas d'utilisation particulier.
4. Condition préalable : tout ce que ce cas d'utilisation peut supposer être vrai avant de commencer son cycle de vie.
5. Scénario de réussite - séquence d’étapes décrivant le bon déroulement des événements.

6. Extensions - flux d'application lorsqu'il s'écarte du flux du scénario de réussite:

   1. Autres flux - autres options de flux correct
   2. Flux d' exception - flux d'événements pour les cas de problèmes

7. Garantie de réussite (ou post-condition) - état d'application une fois que tout est terminé

Certains points supplémentaires pouvant être inclus sont Niveau , Garanties minimales , Déclenchement , etc.

Ci-dessus se trouve ce qu'on appelle un cas d'utilisation entièrement habillé . Vous pouvez simplifier la création de cas d'utilisation en utilisant un cas d'utilisation occasionnel en utilisant uniquement les points les plus importants, par exemple:

1. Titre
2. Acteurs)
3. Séquence d'événements

Les cas d'utilisation ont été créés et popularisés par Ivar Jacobson à la fin des années 80 et au début des années 90. Plus tard, d'autres personnes ont également contribué à son travail (l'une d'elles est Alistair Cockburn, auteur de Writing Effective Use Case ). Pour paraphraser Martin Fowler, les cas d'utilisation peuvent utiliser du texte et des diagrammes UML, mais leur plus grande valeur réside dans le texte. Ils sont meilleurs quand ils ne sont pas grands et faciles à lire.

User story _{(aka. Feature)}

User story - une petite histoire qui décrit une fonctionnalité particulière. Il existe un modèle courant d'écriture d'une user story, à savoir:

En tant que type particulier d'utilisateur,
je veux faire quelque chose
pour une raison quelconque .

En outre, la user story peut avoir des critères d'acceptation .

Comme vous pouvez le constater, ce modèle est beaucoup plus petit que celui du cas d’utilisation. Les user stories sont généralement associées à la région scrum / agile / xp du développement logiciel. Ils sont destinés à être écrits sur de petites régions de surface, telles que des post-it et / ou sur des tableaux de notes. Là, ils se voient (généralement) attribuer des valeurs de points qui représentent approximativement la quantité d’efforts à investir dans cette histoire d’utilisateur ^réf .

Bill Wake a mis au point mnémonique INVEST pour décrire les qualités qu’une bonne histoire d’utilisateur devrait avoir, et je vais emprunter le bref résumé de Martin Fowler sur son site Web :

Indépendant : les histoires peuvent être livrées dans n'importe quel ordre
Négociable : les détails de ce qui est dans l'histoire sont co-créés par les programmeurs et le client au cours du développement.
Valeur : la fonctionnalité est considérée comme une valeur par les clients ou les utilisateurs du logiciel.
Estimable : les programmeurs peuvent proposer une estimation raisonnable pour construire l'histoire.
Petit : les histoires doivent être construites en peu de temps, généralement en nombre de personnes-jours. Vous devriez certainement pouvoir construire plusieurs histoires en une seule itération.
Testable : vous devriez pouvoir écrire des tests pour vérifier que le logiciel de cette histoire fonctionne correctement.

Scénario d'utilisation

Le scénario d'utilisation suit le modèle GWT qui signifie Given-When-Then, comme suit:

Scénario : titre
Donné : un fait particulier
Et : un autre fait particulier (peut être facultatif)
Quand : un événement survient
Puis : un autre événement se produit

Les scénarios d'utilisation sont associés au développement piloté par le comportement. Cela ressemble beaucoup à un test. Dans son billet de blog, Martin Fowler donne une histoire et un raisonnement derrière les scénarios d'utilisation. Voici la partie importante:

La partie donnée décrit l'état du monde avant de commencer le comportement que vous spécifiez dans ce scénario. Vous pouvez penser à cela comme les conditions préalables à l’épreuve.
Le lorsque la section est que le comportement que vous spécifiez.
Enfin, la section then décrit les modifications attendues en raison du comportement spécifié.

Des scénarios d'utilisation peuvent être utilisés pour écrire un test pour votre application. Pour citer le dernier paragraphe du message de Martin:

Bien que le style Given-When-Then soit symptomatique de BDD, l'idée de base est assez courante lors de l'écriture de tests ou d'une spécification par exemple. Meszaros décrit le modèle comme étant un test en quatre phases. Ses quatre phases sont la configuration (donnée), l'exercice (quand), la vérification (ensuite) et la démolition. Bill Wake a proposé la formulation suivante: Arrange, Act, Assert.

Références pour une étude ultérieure:

Pages Wikipedia pour cas d' utilisation , user story , scénario d'utilisation
Les blogs de Martin Fowler sur les cas d' utilisation , user story , scénario d'utilisation

Je ne connais pas bien User Story, mais lorsque j'ai étudié la question il y a plusieurs années:

Un cas d'utilisation est une tâche majeure.
Les scénarios d'utilisateur sont les différentes manières dont la tâche peut être exécutée. Ainsi, chaque cas d'utilisation comporte un ou plusieurs scénarios. Le cas d'utilisation est l'abrégé, les scénarios d'utilisateur sont un catalogue de toutes les instances possibles de cette tâche abstraite.

Donc:
cas d'utilisation A: l'utilisateur s'authentifie avec un identifiant et un mot de passe.

Scénarios:
1. L'ID est reconnu, le mot de passe est correct. (scénario "journée ensoleillée")
2. L'ID est reconnu, le mot de passe est incorrect.
3. L'ID est reconnu, le mot de passe est incorrect pour la troisième fois.
4. L'ID n'est pas reconnu.

J'ai toujours pensé aux cas d'utilisation comme un moyen de définir les exigences de manière narrative pour le client. Si le client dit "Mais que se passe-t-il s'il essaie de se connecter entre minuit et une heure lorsque le système est en panne?", nous avons découvert un autre scénario pour la tâche d'authentification et certaines exigences supplémentaires.

Une user story est celle d'un client, parfois incorrecte ou incomplète. Il peut ne pas être pris en compte sur les performances, sur la gestion des erreurs ou ne rien avoir sur le serveur

Un cas d'utilisation est du point de vue du développeur. C'est précis et complet. Il devrait répondre à toutes les exigences des clients.

Les "cas d'utilisation" et "user story" sont identiques en ce sens qu'ils représentent des "exigences" du client.

Le cas d'utilisation est la manière dont le système est utilisé dans chaque cas, généralement représenté par une interaction entre l'acteur et le système ou entre les systèmes.

La user story est le point de départ du processus de création d’un outil assisté par ordinateur qui permettra à l’utilisateur final de s’acquitter de ses tâches. Elle commence normalement par une phrase simple indiquant qui, quoi, pourquoi ("En tant qu’utilisateur qui ferme l’application, je souhaite être invité à enregistrer tout ce qui a changé depuis la dernière sauvegarde afin que je puisse conserver le travail utile et supprimer le travail erroné. "). Cette user story doit ensuite être intégrée dans un cas d'utilisation que les développeurs utilisent pour créer une application et les testeurs pour effectuer des tests.

Du point de vue d'un testeur d'assurance qualité, ils ne testent pas des "user stories", mais plutôt des "cas d'utilisation", ce qui signifie qu'ils testent des fonctionnalités logicielles.

Le scénario d'utilisation a pour objectif de capturer l'essence de l'interaction de l'utilisateur avec votre système en vue d'atteindre un objectif, sans entrer dans les détails des actions du système ou de la conception réelle. L'accent est mis sur l'utilisateur, pas sur le système.

... Le cas d'utilisation inclut également des déclarations sur ce que le système va faire, alors que le scénario d'utilisation évitera cette discussion.

Vous n'avez pas encore déterminé comment vous allez le mettre en œuvre.

Du site des produits-arts .