Utilisez-vous des «scénarios» et des «cas d'utilisation» comme un seul ou séparément?
Il y a beaucoup de discussions et d'informations sur la différence entre les scénarios et les cas d'utilisation, mais je veux savoir comment fonctionnent-ils - ou non - ensemble ?
À un niveau élevé, la principale différence entre un scénario et un cas d'utilisation, si je comprends bien, est que le scénario ne contient aucune des technologies ou des interactions système et se concentre uniquement sur ce que l'utilisateur (persona) fait.
Les scénarios et les cas d'utilisation sont-ils donc tous deux créés ou est-il acceptable de les combiner en un seul?
J'ai l'hypothèse qu'ils peuvent s'entraider dans la construction des informations précieuses qui vont dans les deux, mais sont finalement utilisées à des fins différentes comme dans:
Les scénarios sont utilisés pour éclairer les décisions de conception et aider à visualiser le monde de l'utilisateur de manière plus vivante au cours du cycle de conception et de développement, en gardant tout le monde concentré sur la création du produit pour l'utilisateur.
Les cas d'utilisation sont utilisés pour informer l'analyste métier et les développeurs des étapes logiques à prendre en compte pendant le cycle de développement.
Scénario de Wikipedia
... une histoire fictive sur la "vie quotidienne de" ou une séquence d'événements avec le principal groupe d'intervenants comme personnage principal. En règle générale, un personnage créé plus tôt est utilisé comme personnage principal de cette histoire. L'histoire doit être spécifique des événements qui se produisent en rapport avec les problèmes du groupe de parties prenantes principales, et normalement les principales questions de recherche sur lesquelles le processus de conception est construit. Ceux-ci peuvent se révéler être une histoire simple sur la vie quotidienne d'un individu, mais de petits détails sur les événements devraient impliquer des détails sur les utilisateurs et peuvent inclure des caractéristiques émotionnelles ou physiques ...Cas d'utilisation de Wikipedia
... décrit l'interaction entre un individu et le reste du monde. Chaque cas d'utilisation décrit un événement qui peut se produire pendant une courte période de temps dans la vie réelle, mais qui peut consister en des détails complexes et des interactions entre l'acteur et le monde.
MISE À JOUR: Sur la base de la réponse d'Aadaam, j'ai pensé que je devais ajouter plus de détails autour de la question pour clarifier ce que je cherchais.
Je comprends qu'il existe une différence claire entre un scénario et un cas d'utilisation, mais il existe également des similitudes claires. Ces similitudes créent de la confusion lorsque vous avez un projet qui utilise les deux.
Dans le projet auquel je fais référence, il y a des designers ux et des analystes commerciaux. Les concepteurs d'UX s'appuient sur des scénarios pour transmettre l'histoire de l'utilisateur. Les analystes commerciaux s'appuient sur les cas d'utilisation pour transmettre l'ensemble des exigences et des fonctionnalités de l'entreprise, des utilisateurs et du système.
Donc, avec cela à l'esprit - comment et pourquoi utiliseriez-vous les deux pendant un projet? Ou existe-t-il un moyen de rationaliser en construisant l'un et en nourrissant l'autre?
J'ai ma propre opinion à ce sujet, mais je veux d'abord garder mes biais pour obtenir une réponse objective.
Quelques informations supplémentaires pour plus de clarté, merci à Aadaam d'avoir fourni des réponses pertinentes sur ce sujet.
Ces informations ci-dessous proviennent d'un cours que j'ai récemment suivi sur l'analyse centrée sur l'utilisateur dans le domaine de la recherche ux
Distinctions des scénarios et des cas d'utilisation
et comment ils peuvent s'intégrer dans une organisation
Les scénarios sont des histoires d'utilisateurs
- Ils ne reflètent pas les activités du système (sauf comme expérience par l'utilisateur)
- Les scénarios devraient être indépendants de la technologie (autant que possible)
- Par exemple, "Jim visualise son plan de voyage actuel ..."
Les cas d'utilisation concernent généralement l'utilisateur et la technologie
- Par exemple, "Jim affiche la page d'accueil, se connecte avec son ID utilisateur et son mot de passe, et le système récupère son plan de voyage actuel ..."
En effectuant plus de recherches sur ce sujet, je suis tombé sur cet article sur les histoires d'utilisateurs, les cas d'utilisation et les scénarios.
L'article définit les trois éléments, mais plus important à la fin de l'article, il résume assez bien, je pense.
Les informations ci-dessous ont été écrites par Nadine Schaeffer.
Scénarios
Commençons par les scénarios. Ils sont généralement liés à des personnages et font partie de la création d'une histoire sur qui est l'utilisateur d'une technologie particulière, ce qu'il veut, ce qu'il sait. Un scénario est donc généralement écrit sous forme narrative, peut-être avec des images et des illustrations également. Les scénarios sont généralement écrits au début d'un projet pendant les phases de découverte et de collecte des exigences.
Cas d'utilisation:
Enfin, décrivons les cas d'utilisation. Les cas d'utilisation sont généralement rédigés dans le cadre de la documentation détaillée des exigences du produit. Ils capturent le but d'une action, l'événement déclencheur qui démarre un processus, puis décrivent chaque étape du processus, y compris les entrées, les sorties, les erreurs et les exceptions. Les cas d'utilisation sont souvent écrits sous la forme d'un acteur ou d'un utilisateur effectuant une action suivie de la réponse système attendue et des résultats alternatifs. Ils fournissent des ancrages centrés sur l'homme pour guider la conception et le développement en fournissant des visages tangibles, des noms et des histoires sur la façon dont la technologie sera utilisée.
En résumé:
Les cas d'utilisation , les histoires et les scénarios ne sont pas des termes interchangeables - chacun définit un processus spécifique et ensemble de livrables. Cela étant dit, il n'y a pas de règles strictes et rapides. Il est logique de passer en revue les besoins de votre projet, le stade de développement dans lequel vous vous trouvez, les compétences et les niveaux de familiarité de l'équipe, puis de choisir le processus de définition des utilisateurs et des tâches qui vous conviendra le mieux.
Mise à jour:
J'ai contacté Nadine Schaeffer, qui a écrit l'article auquel je fais référence dans cette réponse, pour obtenir son opinion et ses réflexions sur ma question.
J'ai demandé si je pouvais partager ses commentaires ici, ce qui était une réponse par e-mail:
J'utilise des scénarios et des cas d'utilisation à des fins différentes et à différentes étapes d'un projet.
J'aime démarrer un projet avec des personnages et des scénarios. Dans mon esprit, ces deux artefacts sont étroitement liés. Les personas créent des archétypes crédibles de types d'utilisateurs, et les scénarios racontent des histoires plausibles sur ce que font ces personas. En tant que designer d'expérience utilisateur, j'ai tendance à écrire des personnages et des scénarios.
Les cas d'utilisation, cependant, concernent moins les personnes ou les personnages, et davantage ce qu'un produit doit permettre à un utilisateur de faire. Il s'agit d'une méthode centrée sur l'utilisateur pour définir les caractéristiques et les exigences du produit. Par conséquent, ils sont souvent rédigés par le chef de produit.
Nadine Schaeffer - Directrice chez Cloudforest Design et consultante en expérience utilisateur professionnelle
Sa réponse m'a apporté de la clarté et a mis mon esprit à l'aise autour de cette question qui me tracasse depuis un moment.
Un cas d'utilisation est quelque chose pour lequel le système est utilisé. Autrement dit, un cas d'utilisation est un espace réservé pour la solution d'un objectif ou d'une méthode (dans la terminologie GOMS).
Par exemple, si vous voulez rendre vos wireframes "interactifs" en les introduisant dans une sorte d'outil de présentation et en ajoutant une navigation aux zones cliquables, un cas d'utilisation est à la fois:
- l'utilisateur crée une présentation interactive à partir de maquettes afin de la présenter aux clients ou d'effectuer des recherches sur les utilisateurs (généralement raccourci à l'utilisateur crée une présentation interactive )
- l'utilisateur ajoute des points chauds à une maquette d'écran unique pour activer la navigation vers d'autres maquettes d'écran (généralement raccourci à l'utilisateur ajoute des points chauds à une maquette unique )
Comme vous le voyez, l'un d'eux est un objectif (quand il est atteint, la tâche est terminée), l'autre est un sous-processus significatif pour atteindre cet objectif, c'est-à-dire qu'il s'agit d'un espace réservé pour un - méthode pour atteindre cet objectif.
Les deux sont appelés cas d'utilisation, et ils sont généralement dans une relation "comprend" lors de l'utilisation de la terminologie UML (qui est "UX pour les ingénieurs logiciels" ).
Un scénario est une séquence d'étapes possible qui satisfait un cas d'utilisation donné . Bien que nous aimerions que nos exigences (cas d'utilisation) soient aussi exemptes de décisions trop tôt que possible, il est généralement impossible de dire comment un cas d'utilisation pourrait être satisfait sans inventer une sorte d'histoire pour son exécution.
Example Scenario of UC1: create interactive presentation
Persona: User
Preconditions: the screen mockups are done for each key screen
Postconditions: there's a clickable interactive mockup
Steps:
1. User adds a single key screen
1.1 Alternative flow: user tries to add keyscreens in batch
Condition: [User has the keyscreens named in alphanumerical order in a directory]
1.1.1 User selects batch upload
1.1.2 Presents directory selection dialog
1.1.3 User selects directory
1.1.4 Opens all the recognizable files in the directory, processes them
in alphanumerical order
1.1.5 Continue from 1.2
1.2 User selects first keyscreen to work with
blablabla
Un scénario écrit rapidement du cas d'utilisation ci-dessus, basé sur le style d'Alistair Cockburn
La principale différence est que un cas d'utilisation est constant : c'est une représentation d'un besoin fonctionnel. Un scénario pourrait changer à mesure que nous en saurons plus sur le système. Le scénario représente simplement un exemple de solution imaginée .
Il existe des méthodes de représentation qui possèdent moins de contraintes inutiles sur les exigences initiales (comme les diagrammes de flux de données n'ont pas d'exigences de séquence), cependant, le cas d'utilisation semble être plus efficace.
Lecture recommandée: Allistair Cockburn: Rédaction de cas d'utilisation efficaces . Un classique sur le sujet, avec le blog de Cockburn, qui en inclut des parties.
Question interessante. J'ai lutté avec les mêmes sentiments et maintenant que j'y repense, je trouve que j'utilise des scénarios et des cas d'utilisation entrelacés les uns avec les autres. Lorsque mes scénarios décrivent toute l'histoire des interactions de base (souhaitées) avec le système, les cas d'utilisation décrivent l'histoire plus en détail.
Ainsi, une façon de voir les scénarios et les cas d'utilisation travailler ensemble est qu'ils fonctionnent comme différents niveaux de détail dans votre processus de narration. Lors de la lecture du scénario, vous pouvez "zoomer" sur un certain aspect en affichant le cas d'utilisation applicable.
Le livre Storytelling for UX m'a aidé à clarifier les principales différences entre ces deux méthodologies. Les divers exemples du livre fournissent une excellente lecture perspicace.
Je pense que la question ici va au-delà des simples définitions et des discussions sur la terminologie. Les composants UML sont des artefacts sains qui doivent être planifiés, analysés, conçus, développés et mis en œuvre à l'aide de stratégies, méthodes et outils spécifiques.
Déconstruire un cas d'utilisation Je commence normalement par développer un récit non seulement des besoins des utilisateurs mais aussi de tous les acteurs impliqués dans un scénario donné . Je porte également une attention particulière aux relations sous-jacentes, au flux et à la séquence des événements, aux limites, aux contraintes, aux pré et post et anti-conditions, au traitement des conditions d'exception, etc.
Élaboration d'une description de cas d'utilisation À partir du récit, je commence à remplir une description de cas d'utilisation formelle avec un ensemble de champs se rapportant aux critères ci-dessus. La description du cas d'utilisation me fournit l'ontologie indispensable pour mieux comprendre le cas d'utilisation avec lequel je travaille ainsi que tous les éléments internes et externes jouant un rôle dans et hors de celui-ci. C'est la description du cas d'utilisation qui détermine le nombre requis de scénarios de cas d'utilisation que je devrai développer. Chaque scénario peut générer un ou plusieurs diagrammes de cas d'utilisation.
Scénario d'utilisation Comme son nom l'indique, un scénario décrit une situation particulière qui fait partie de l'histoire globale que nous essayons de raconter avec un niveau d'abstraction plus élevé lors de la phase de développement du cas d'utilisation. A ce stade, il serait préférable de développer le scénario en termes de quasi ou pseudo code, ou simplement une liste ordonnée décrivant le scénario étape par étape. Ce n'est pas une possibilité farfelue qu'une description de cas d'utilisation génère de nombreux scénarios de cas d'utilisation.
Diagramme de cas d'utilisation Maintenant que nous avons développé tous les scénarios possibles basés sur la description du cas d'utilisation, la production de diagrammes de cas d'utilisation est une tâche beaucoup plus facile à réaliser. Cependant, il peut être nécessaire de maintenir un certain niveau d'abstraction au départ afin de se concentrer sur les principaux acteurs et d'utiliser les activités de cas ainsi que les limites et les relations du système. Il s'agirait alors de remplir les blancs en typant les relations (généralisation, inclusion et extension) lorsque plus de détails seront disponibles.
Reconstruire le cas d'utilisation Lorsque nous avons commencé avec un récit de cas d'utilisation (histoire) et avons fini par le déconstruire (décomposer) avec toutes les descriptions, scénarios et diagrammes nécessaires, il incomberait maintenant de réellement reconstruire ou recomposer le cas d'utilisation en emballant tous ses éléments et en l'encapsulant et en le présentant comme un emballage cohérent. Le package peut être étiqueté avec un identifiant unique et ajouté au dictionnaire système ou à tout autre référentiel que vous utilisez pour héberger vos composants UML.
J'utilise le scénario pour déterminer l'objectif. Comme - "Visiteur prend rendez-vous."
Le cas d'utilisation inclut l'interaction - "Le visiteur examine ses coordonnées et fournit les informations de paiement. Le système a validé les informations de paiement et répond avec BookingId que le client peut utiliser pour vérifier son statut de réservation. Le système envoie une confirmation SMS = au visiteur. "
J'utilise un "scénario" pour rassembler les comportements et essayer de donner aux parties prenantes et une compréhension empathique de la façon dont un produit ou un service sera concrètement utilisé.
J'utilise un "cas d'utilisation" ou plus communément une "histoire d'utilisateur" lors de l'analyse et de l'extraction du noyau de l'expérience utilisateur derrière les détails de la recherche et également pour organiser une conception tout au long du processus de développement.
Alors oui, ils se combinent. Surtout si vous n'avez pas de scénario convaincant pour un cas d'utilisation, ne le construisez pas.
Je ne suis pas d'accord, les termes sont quelque peu interchangeables. Ivar Jacobson, qui a inventé la modélisation des cas d'utilisation, les a initialement appelés scénarios d'utilisation, puis s'est arrêté sur des cas d'utilisation. Cockburn et Fowler qui ont beaucoup écrit sur la modélisation des cas d'utilisation ne font pas de distinction entre les termes autrement que pour indiquer que les cas d'utilisation sont constitués de scénarios principaux et de scénarios alternatifs.