Чем отличаются сценарии использования от модели use case

Продолжая обучение начинающих бизнес-аналитиков, сегодня рассмотрим 2 популярные схемы описания требований в Agile-проектах. Читайте далее, чем User story отличается от Use Case, а также как они связаны с UML-диаграммой прецедентов, а также функциональными и нефункциональными требованиями к решению, которые входят в ТЗ по ГОСТ.

От потребности к решению: виды требований и способы их описания

Напомним, руководство к профессиональному своду знаний по бизнес анализу BABOK®Guide выделяет 3 основных вида требований (бизнес, стейкхолдеров и к решению), а также переходные, актуальные на момент трансформации от текущего состояния (as-is) к желаемому (as-to-be). Подробнее об этом мы говорили в отдельной статье. Аналитик плотно работает со всеми видами требований, последовательно трассируя потребности, проблемы и возможности в требования к решению через бизнес-требования и требования заинтересованных сторон (стейкхолдеров).

Если решением является информационная система или программно-аппаратный комплекс, как это бывает в большинстве случаев, то в техническое задание (ТЗ) на его разработку попадают именно требования к решению: функциональные и нефункциональные. Для этого выделяются соответствующие пункты в стандартах по разработке (ISO/IEC/IEEE 29148:2018, ГОСТ 34.602-89, ГОСТ 19.201-78) и спецификации требований к программному обеспечению (Software Requirements specification, SRS) на основе IEEE/ISO/IEC 29148-2011. На практике формирование такого комплексного ТЗ по всем правилам является длительным и итеративным процессом со множеством циклов согласования между Заказчиком и командой реализации. Поэтому, чтобы лучше понять потребности стейкхолдеров и быстрее начать работу над программным продуктом, бизнес-аналитик описывает требования к системе в виде пользовательских историй (user story), которые кратко формулируют, какие возможности она предоставляет конкретной роли.

Что такое пользовательская история и чем она хороша

Обычно user story создаются по шаблонам возможности или ограничения:

• <Роль> должен иметь возможность <возможность> в <показатель производительности> с <момент отсчета> в <условия эксплуатации>, чтобы <ценность>. Например, Администратор клиники должен иметь возможность просмотреть данные о прошлых и запланированных посещениях пациента в течение 3 секунд после определения личности клиента по номеру телефона входящего звонка, чтобы добавить новое или изменить запланированное посещение.
• <Система> должна <выполняемая функция> <объект> каждые <производительность> <единица измерения>, чтобы <ценность>. Например, CRM-система должна отправлять СМС-напоминание клиенту о предстоящем посещении за сутки перед посещением, чтобы он помнил о приеме и пришел вовремя.

Таким образом, формулировка исходных требований стейкхолдеров в виде пользовательских историй соответствует BDD-походу к разработке (Behavior-driven development), позволяя описать ожидания пользователей от проектируемой системы на понятном им языке и определить поведенческие сценарии тестирования для приемочных испытаний. User stories особенно распространены в продуктовой аналитике, но не заменяют собой формальное ТЗ по ГОСТ’ам с перечислением функций системы, о чем мы уже упоминали здесь и здесь. На практике такое представление требований часто встречается в Agile-проектах, особенно на начальном этапе бизнес-анализа при выяснении и уточнении потребностей заинтересованных сторон. Подробнее о том, как разные модели и методологии разработки ПО реализуют принципы Agile и движение по этапам SDLC, читайте в нашей отдельной статье.

Сценарий использования и UML-диаграмма Use Case

Однако, user story – далеко не единственная схема представления требований, хотя именно она больше всего подходит к описанию требований стейкхолдеров. Также для описания функциональных требований, описывающих поведение проектируемой системы в едином смысловом контексте, применяется инструмент сценариев или вариантов ее использования (Use Case). В этом случае функциональные требования к системе представляются в виде набора функций, объединенных по контексту. Например, Use Case «Запланировать посещение клиента в клинику» может включать следующие функции:

• Просмотреть историю посещений (данные о прошлых и запланированных визитах);
• Добавить новое посещение;
• Выбрать посещение;
• Просмотреть детали (дата, время, место, врач) посещения;
• Изменить детали будущего посещения;
• Удалить будущее посещение.

Все эти функции представляют собой прецеденты UML-диаграммы вариантов использования (Use Case), которые связаны различными видами отношений. При этом направленную ассоциацию от актора проведем только к тем прецедентам, которые имеют смысл с пользовательской (бизнесовой) точки зрения. Таким здесь являются «Просмотреть историю посещений», «Добавить новое посещение» и «Просмотреть детали». А то, что для просмотра деталей конкретного посещения его надо выбрать из всего списка (просмотрев историю) — это системный use case. Поэтому целевой пользовательский UC «Просмотреть детали» ссылается на «Выбрать посещение» связью include. Это означает, что в реализации «Просмотреть детали» не может быть выполнен без выполнения «Выбрать посещение». В текстовой форме представления требований в виде Use Case это было бы прописано в графе «Предусловие, что мы рассмотрим далее. О том, как разрабатывать UML-диаграмму Uce Case, мы поговорим в другой раз. А проверить свое знание основ UML вы можете, пройдя бесплатный интерактивный тест прямо на нашем сайте.

Бизнес-логика выполнения каждого прецедента UML-диаграммы Use Case обычно детализируется в диаграммах деятельности, реже в диаграммах последовательности и состояний. Однако, сценарий использования не ограничивается только графической UML-схемой, а также включает текстовое описание по следующей структуре:

• Имя, в формате глагол-существительное, которое описывает достижимую цель и объяснять смысл сценария.
• Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
• Актор — действующее лицо, кто-то или что-то вне системы, влияющий на нее или находящийся под её влиянием (человек, устройство, другая система или подсистема).
• Предусловия, которые должны быть истиной для выполнения сценария.
• Активатор (триггер) – внешнее, внутреннее или временное событие, инициирующее выполнение сценария.
• Результат (постусловие) – новый объект или изменение состояния существующего объекта, который показывает, что актор достиг своей цели.
• Порядок Событий (основной поток) — типичный ход событий как ряд пронумерованных шагов.
• Альтернативные пути и дополнения use case’а могут содержать вторичные пути или другие сценарии на шаги основного.
• Бизнес-правила для определения результата в зависимости от конкретного запроса к системе, например, входных данных: «Изменение деталей или удаление возможно только для будущих посещений, дата и время которых еще не настали на момент просмотра записи».

Обычно сценарий использования по такой структуре оформляется в виде таблицы. В этом случае UML-диаграмма прецедентов (Use Case) является краткой наглядной схемой текстового представления основных функциональных возможностей взаимодействия с проектируемой системой, без детализации их выполнения. Бизнес-логика каждого прецедента описывается в пунктах сценария «Поток Событий»(Основной поток) и «Альтернативный поток». Как это сделать на практике, рассмотрим в следующей статье.

Чем User Story отличается от Use case

Подводя итог описанию рассмотренных схем представления требований, подчеркнем сходства и отличия User Story и Use case:

• обе этих схемы представления требований подходят для описания требований стейкхолдеров;
• обе схемы активно используются в ИТ-проектах, позволяя начать реализацию системы  и создать прототип, демонстрирующий ключевые функциональные возможности;
• UML-диаграмма вариантов использования (Use Case) может использоваться с обеими схемами представления требований, наглядно показывая основные функциональные возможности взаимодействия стейкхолдера с проектируемой системой, без детализации их выполнения. Однако, неподготовленному читателю такая диаграмма покажется сложной и непонятной, в отличие от простых формулировок User Story и текстового (табличного) представления Use Case.
• User Story более легковесная техника, она требует меньше времени на формулирование, а потому она активно применяется в Agile-проектах, тогда как Use Case требует больше времени на разработку и потому более подходит для проектов, где нужна высокая степень формализации подробно задокументированных требований;
• пользовательские истории требуют дальнейшей детализации для описания подробностей выполнения процессов, взаимодействия пользователя с системой, данных и бизнес-логики, тогда как Uase Case является самодостаточным;
• User Story отлично подходит для разработки поведенческих сценариев тестирования, программы и методики приемочных испытаний;
• сценарии использования, в отличие от пользовательских историй, описывают процесс и его шаги подробно, предоставляя всю необходимую информацию о взаимодействии актора с системой, включая цель, пред- и пост-условия, триггеры, основные и альтернативные потоки, а также бизнес-правила;
• User Story позволяет указать нефункциональные требования с точным заданием значений нужных показателей, например, время отклика на событие, наработку на отказ и пр.;
• Use Сase объединяет функциональные требования по контексту.

На практике обе схемы представления требований могут пересекаться и использоваться совместно. Например, из пользовательской истории могут выходить несколько сценариев использования и наоборот.

Подробнее узнать о сходствах, отличиях, достоинствах и недостатках, примерах применения Use Case и User Story, а также научиться описывать требования по этим схемам представления вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Разработка ТЗ на информационную систему
• UML для бизнес-аналитика

_{Quick temporary note: This post needs improvements to better answer the question, such as 1) additional details should be included from references 2) some citations maybe 3) overall correctness of English 4) overall quality of narrative 5) etc. I’ll be back to it. Feel free to improve it yourself.}

Taking a look at their templates can give valuable insight into the differences between these terms.

Use case

There are multiple templates for use cases. I found 3 after a quick search: 1, 2, 3. Some points they (sometimes vaguely) have in common are:

1. Name of use case / title
2. Description — some short text describing the scope.
3. Actor(s) / Primary actor — person(s) who interact with this particular use case.
4. Precondition — anything that this use case can assume to be true prior to beginning it’s life cycle.
5. Success scenario — a sequence of step describing correct flow of events that take place.

6. Extensions — flow of application when it deviates from success scenario’s flow:

   1. Alternate flows — other options of correct flow
   2. Exception flows — flow of events for when things go wrong

7. Success guarantee (aka. Post condition) — state of application after everything is done

Some additional points that can be included are Level, Minimal Guarantees, Trigger, etc.

Above is what’s called fully dressed use case. You can simplify use case creation by using a casual use case by using only the most vital points, for example:

1. Title
2. Actor(s)
3. Sequence of events

Use cases were created and popularized by Ivar Jacobson in late 80s early 90s. Later other people also contributed to his work (one of such people is Alistair Cockburn who is author of Writing Effective Use Cases). To paraphrase Martin Fowler use cases can make use of text and UML diagrams, but their greatest value lies in the text of it. They are best when they are not big and easy to read.

User story _{(aka. Feature)}

User story — a small story that describes a particular feature. There is a common pattern of how to write a user story, which is:

As a particular type of a user
I want to do something
so that some reason.

In addition, user story can have acceptance criterias.

As you can see this template is much smaller than that of use case. User stories are commonly associated with scrum/agile/xp region of software development. They are meant to be written on small regions of surface, such as post-it notes, and/or on scrum boards. There, they are (usually) given point values which approximate how much effort needs to be invested into that user story ^ref.

Bill Wake developed INVEST mnemonic to describe what qualities a good user story should have, and I will borrow Martin Fowler’s short summary of that from his website:

Independent: the stories can be delivered in any order
Negotiable: the details of what’s in the story are co-created by the programmers and customer during development.
Valuable: the functionality is seen as valuable by the customers or users of the software.
Estimable: the programmers can come up with a reasonable estimate for building the story
Small: stories should be built in a small amount of time, usually a matter of person-days. Certainly you should be able to build several stories within one iteration.
Testable: you should be able to write tests to verify the software for this story works correctly.

Usage scenario

Usage scenario follow the GWT pattern which stands for Given-When-Then, like so:

Scenario: title
Given: a particular fact
And: another particular fact (may be optional)
When: some event happens
Then: some other event happens

Usage scenarios are associated with Behavior-Driven Development. It sounds very similar to a test. Martin Fowler in his blog post gives some history and reasoning behind usage scenarios. Here is the important part:

The given part describes the state of the world before you begin the behavior you’re specifying in this scenario. You can think of it as the pre-conditions to the test.
The when section is that behavior that you’re specifying.
Finally the then section describes the changes you expect due to the specified behavior.

Usage scenarios can be used for writing test for your application. To quote the last paragraph of Martin’s post:

Although Given-When-Then style is symptomatic to BDD, the basic idea is pretty common when writing tests or specification by example. Meszaros describes the pattern as Four-Phase Test. His four phases are Setup (Given), Exercise (When), Verify (Then) and Teardown. Bill Wake came up with the formulation as Arrange, Act, Assert.

References for farther study:

Wikipedia pages for use case, user story, usage scenario
Martin Fowler’s blogs on use case, user story, usage scenario

_{Quick temporary note: This post needs improvements to better answer the question, such as 1) additional details should be included from references 2) some citations maybe 3) overall correctness of English 4) overall quality of narrative 5) etc. I’ll be back to it. Feel free to improve it yourself.}

Taking a look at their templates can give valuable insight into the differences between these terms.

Use case

There are multiple templates for use cases. I found 3 after a quick search: 1, 2, 3. Some points they (sometimes vaguely) have in common are:

1. Name of use case / title
2. Description — some short text describing the scope.
3. Actor(s) / Primary actor — person(s) who interact with this particular use case.
4. Precondition — anything that this use case can assume to be true prior to beginning it’s life cycle.
5. Success scenario — a sequence of step describing correct flow of events that take place.

6. Extensions — flow of application when it deviates from success scenario’s flow:

   1. Alternate flows — other options of correct flow
   2. Exception flows — flow of events for when things go wrong

7. Success guarantee (aka. Post condition) — state of application after everything is done

Some additional points that can be included are Level, Minimal Guarantees, Trigger, etc.

Above is what’s called fully dressed use case. You can simplify use case creation by using a casual use case by using only the most vital points, for example:

1. Title
2. Actor(s)
3. Sequence of events

Use cases were created and popularized by Ivar Jacobson in late 80s early 90s. Later other people also contributed to his work (one of such people is Alistair Cockburn who is author of Writing Effective Use Cases). To paraphrase Martin Fowler use cases can make use of text and UML diagrams, but their greatest value lies in the text of it. They are best when they are not big and easy to read.

User story _{(aka. Feature)}

User story — a small story that describes a particular feature. There is a common pattern of how to write a user story, which is:

As a particular type of a user
I want to do something
so that some reason.

In addition, user story can have acceptance criterias.

As you can see this template is much smaller than that of use case. User stories are commonly associated with scrum/agile/xp region of software development. They are meant to be written on small regions of surface, such as post-it notes, and/or on scrum boards. There, they are (usually) given point values which approximate how much effort needs to be invested into that user story ^ref.

Bill Wake developed INVEST mnemonic to describe what qualities a good user story should have, and I will borrow Martin Fowler’s short summary of that from his website:

Independent: the stories can be delivered in any order
Negotiable: the details of what’s in the story are co-created by the programmers and customer during development.
Valuable: the functionality is seen as valuable by the customers or users of the software.
Estimable: the programmers can come up with a reasonable estimate for building the story
Small: stories should be built in a small amount of time, usually a matter of person-days. Certainly you should be able to build several stories within one iteration.
Testable: you should be able to write tests to verify the software for this story works correctly.

Usage scenario

Usage scenario follow the GWT pattern which stands for Given-When-Then, like so:

Scenario: title
Given: a particular fact
And: another particular fact (may be optional)
When: some event happens
Then: some other event happens

Usage scenarios are associated with Behavior-Driven Development. It sounds very similar to a test. Martin Fowler in his blog post gives some history and reasoning behind usage scenarios. Here is the important part:

The given part describes the state of the world before you begin the behavior you’re specifying in this scenario. You can think of it as the pre-conditions to the test.
The when section is that behavior that you’re specifying.
Finally the then section describes the changes you expect due to the specified behavior.

Usage scenarios can be used for writing test for your application. To quote the last paragraph of Martin’s post:

Although Given-When-Then style is symptomatic to BDD, the basic idea is pretty common when writing tests or specification by example. Meszaros describes the pattern as Four-Phase Test. His four phases are Setup (Given), Exercise (When), Verify (Then) and Teardown. Bill Wake came up with the formulation as Arrange, Act, Assert.

References for farther study:

Wikipedia pages for use case, user story, usage scenario
Martin Fowler’s blogs on use case, user story, usage scenario

The notable quote from Alistair Cockburn, co-author of the Agile Manifesto, reads, “A user story is to a use case as a gazelle is to a gazebo.” This sheds light on the immense differences between use cases vs. user stories for agile teams. They may sound similar in name, but they are very different and often used in completely different industries.

While both use cases and user stories help teams plan work and determine what’s needed to complete work, the format for how they are used is quite different. User stories are simple, short descriptions from the customer’s perspective. They are the beginning of a larger process that describes a customer’s actions as they use or interact with your product. Use cases contain much more context. Creating detailed use cases is a much more in-depth process that’s designed to help teams understand how a user or customer interacts with a system. We’ll dig deeper into both of these processes below.

If you’re in agile software development, chances are you’re more familiar with utilizing user stories. In this post, we’ll dig deeper into use cases vs. user stories differences, including why today’s development teams have migrated towards user stories and why there’s still valid reason for utilizing use cases in the development process.

What’s the difference between use cases vs. user stories?

Use cases vs. user stories: What’s the difference, and how do you decide what’s best for your team and development process?

Use case vs. user story: Past and present

Use cases were the standard for many years, and they were often used in business analysis, systems analysis, software requirements, and iterative development. With the rise of agile, software projects began to favor user stories in place of use cases because they allowed for improved incremental thinking and agility.

What is a use case?

A use case is a description of each of the ways a user may want to interact with a system, a device, or a piece of equipment. They describe how the system design will respond to requests from its end-user, commonly known as an actor. These actors could be human beings or other systems.

Take an online shopping site and a food delivery service, for example. A customer placing an order or checking if a restaurant is open are two different use cases. Or, on the less technical side, consider a toaster. Say someone (the actor) only wants their bagel toasted on one side. Choosing the “bagel” toaster setting is a use case.

Use cases help teams structure all of the different functional requirements and determine the scope of the project — which means they’re full of details.

These details include:

• The goal of the use case
• Whether the actor is a human or another system
• Preconditions, or the state the system has to be in for the use case to occur
• The regular series of steps the system will take
• Alternative paths the system could take
• Postconditions — actions the system takes at the end of the use case or the various states the system could be in after the use case concludes

Take the “bagel” setting on a toaster.

• Use case title/goal: Bagel setting
• Actor/user: This is someone who likes their bagel only toasted on one side.
• Preconditions: There needs to be a “bagel” function/button.
• Regular steps/standard path: The actor cuts their bagel in half and places each half in the toaster. They push the lever down to toast the bagel. Then, they press the button titled “BAGEL” and wait for their bagel to be toasted the way they like.
• Alternative paths: The actor may forget to activate the “bagel” setting, resulting in a poor user experience.
• Postconditions: The toaster returns to its usual state (bagel setting not set).

What is a user story?

A user story is the who, what, and why of a goal or outcome that the user or customer wants to achieve. It’s the smallest piece of work that can give value back to the customer. It’s written from the point of view of the end user, often on an index card.

Here’s an example of how a user story is typically written: “As a [persona type], I want to [action] so that [benefit].”

A user story is designed to be as simple as possible, sparing the team as well as stakeholders from having to decode a lot of technical lingo. But, that doesn’t mean the process for creating a user story is easy. A lot of information is condensed into a single sentence. And before writing a user story, the team first has to identify and create their user persona and assemble all of the product requirements

Easy Agile co-founder Nick Muldoon describes user story mapping as “a facilitated, curated conversation that brings everyone along for the journey.”

A project or product developed in an agile environment will involve a lot of user stories that are each added to the product backlog. There, they can be arranged and prioritized on a user story map according to the scheduled release or sprint.

Use cases vs. user stories: The case for use cases

While use cases are far less common in agile development, they do have some advantages to consider. After all, the true spirit of agile means questioning your assumptions and trying new methods.

1. Use cases provide a summary and planning skeleton

Use cases provide anyone involved, such as managers, leadership, product owners, developers, or stakeholders, with a summary of what the system will offer. What will the system contribute to the users and the overall business? They provide a planning skeleton to help teams prioritize, estimate timing, and execute actions.

2. Use cases provide context for each requirement

The use case provides enough detail and context to ensure everyone is on the same page. It’s an agreement between team members about what the system will and won’t do.

3. Use cases provide a look ahead at what could slow work

The alternative paths portion of use cases provides an advanced look at what could go wrong. Small bottlenecks can take up a huge amount of time and money, so the sooner you can recognize and address these issues, the better.

4. Use cases provide answers for specific issues and scenarios

Use cases answer the specific questions developers or programmers could have along the way. The use case process ensures all questions about issues or possible scenarios are answered at the outset before these questions begin to bog down work or slow down a team’s progress.

5. Use cases provide a model to think through all aspects completely

The use case model ensures developers have fully thought through all aspects of development. Use cases dig into the details of user needs, system goals, possible issues, and various business variants.

Use cases vs. user stories: Bottom line

So, use cases vs. user stories? How do you decide which is better for your team? If you have a lot of experience with agile projects and working on agile teams, you know the undeniable value of user stories. They convey what the user or customer wants to achieve so that teams are always considering the needs of the user.

That said, even though use cases are a bit dated, they can provide much-needed context surrounding how a system is used. They describe how a user interacts with a system, answering many questions in advance to help manage complicated processes. Plus, it wouldn’t be very agile to discount a solution simply because you haven’t tried it before. 😉

Using Easy Agile TeamRhythm

We’re passionate about building tools that help agile teams work better together. Easy Agile TeamRhythm is designed to help product owners and development teams bring value to customers fast and frequently. Supporting user story mapping, backlog refinement, sprint planning, and team retrospectives, you can plan and manage your work right from the user story map, then come together as a team to share actionable insights that will help you work better together each time.

TeamRhythm integrates seamlessly with your agile boards in Jira for both Scrum and Kanban methodologies. Try it yourself in our sandbox demonstration; no need for a login or installation.

A lot of people confuse user cases and stories, but actually they are different concepts. They might have some similar functions. For example, gathering information about user requirements and goals. But they are designed for different purposes. This article discusses in detail the two concepts and how they are different. The usage and practicality of the two concepts to businesses is also highlighted in the article. This article aims to serve as an aid for its readers and help them gain insight into this topic.

What is a use case?

Have you ever felt that the product you imagined and the product you developed were very different? Or the feature that you wanted is missing from the final version. Many product people can relate to these questions. This can help to understand why businesses need a use case in the first place.

In simple terms, a use case is an account of how a person who uses a certain process will achieve a goal. In technical terms, it is the description of the interaction between system and actors. The product of this process is a document containing all the steps followed by a user to achieve a goal. 

For example, you are a carpenter planning to craft a door. The use case for this scenario would consist of all the steps taken by the carpenter to achieve the goal. This whole documentation would help study the flaws and errors of the process.

Product teams utilize use cases in a variety of situations. It is used in designing, testing and development. This process also helps to develop a rough outline of how a user help manual should be designed. Errors and other flaws are also minimized through this process.

The whole process of use cases has certain key terms. These terms are the basis of the entire process and provide the backbone.

1. The actor: This is the person or group of people interacting with the system. They are the users of the system.
2. The goal: This is the outcome for which the use case was designed. It is usually the final result of this process.
3. The system: This includes all the steps followed to achieve the set goal.

The three basic terms don’t apply to every situation. Every project, model and circumstance are different in complexity. For complex products, many other terms are used in a use case. Some of the terms are:

1. Stakeholders: All the parties who have an interest in the outcome of the use case. It doesn’t have to be users only.
2. Triggers: Are all the events due to which a use case begin.
3. Preconditions: It is the combination of all factors necessary for the case to occur.

From a technical point of view, use cases are a detailed description of guidelines for developers. It gives an idea of what the developers need to include in the system. This also gives the developer a sense of direction to work in.

It’s also important to note that when creating use cases you shouldn’t just cover the ideal scenario, you should also prepare alternative paths:

• Main success scenarios [Basic Flow] – use case in which nothing goes wrong.
• Alternative paths [Alternative Flow] – these paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level.

What is a user story?

After describing use cases, let’s move on to user stories. 

User stories are a simple description of the desire of a user for a need. These stories are written from an end-user point of view. The language used for user stories is very informal and easy to understand.

In technical words, it is the description of a feature from an end-user’s point of view. This story is used in agile software development. It helps the product team in identifying their users and requirements. It also helps to break down all the complexity into simple easy to understand words.

The user story is also an easy method of recording user requirements. It helps to identify some important questions. Questions like the who, what and why of a feature. All this description is written to shift the focus from writing to discussing features. It can help simplify the whole process and increase effectiveness.

It is important for a user story to have an outline. An acronym INVEST is widely used for this purpose. It helps in checking that all the requirements have been fulfilled.

• Independent: Not depending on other projects
• Negotiable: Room should be left for further development
• Valuable: Description of the value the end-user is going to get.
• Estimable: They should be estimated so that a proper plan can be developed.
• Small: Work should be small enough to be completed in 3-5 days
• Testable: Some mechanism to check the value delivery of the process

Now that both concepts have been described in detail it might feel that they are the same. The overlap between the two concepts is visible from far away but not near. Although what is same is their importance to the product team. They both are important components of the overall development process. 

Why Create User Stories?

User stories are a simple way of defining what a user wants. Products can be explained clearly through it. A good user story will help all stakeholders in understanding the functionality of the product. It also helps in briefing the client on what the product is.

User stories can help to streamline the project

It means that a bigger goal can be divided into smaller achievable goals. This helps to achieve the project more efficiently and with less time waste. Smaller achievable goals mean little deviation from your goal. 

Brings everyone on the same page

Their simple language means they are understandable by everyone. Both technical and non-technical members use this as a medium of communication. It also helps in engaging each stakeholder. The nature of user stories ignites product discussion among different stakeholders.

Provide a sense of purpose

By clearly defining the purpose of the product, user stories provide purpose to the whole mission. It also makes achieving the task easier for the development team. Due to user stories developers know why they are producing a product. This contributes to increased motivation.

Helps defining the whole product

It gives the development team the freedom to think out of the box. The team can then organize different ideas according to their priority. The criteria for priority might depend on factors like user value and complexity. This means that even the crazy ideas aren’t excluded from the process. They can be given a lower priority and handled accordingly. 

Encourages a user focused approach

This method gives a lot of power to the end user. It means that everything is designed with the end users in mind, right from the beginning. Let it be a prototype, an MVP or a new feature, user stories help you keep the user in the middle of the focus. The stories align the product team with what users want. These stories serve as a constant reminder of serving user needs. Thus, user satisfaction is maximized due to user story.

Example of user story vs. use case

Let’s take an electric vehicle renting application as an example.

Imagine an application where you can list and rent all electric vehicle options in big cities.The users’ objective is to choose and successfully rent an electric vehicle. 

Use case example

Use Case Name: Place Rent Order

Actors:

• Shopper
• Fulfillment System
• Billing System

Basic Use Case Description: 

1. User selects items to rent
2. The User provides payment and shipping information
3. User orders the items
4. The system responds with confirmation of the order and a renting number that the user can use to check out the vehicle. 
5. The system will also provide the user with a countdown for the remainder of the renting time. 
6. The user may already have an account with the company with billing information.

Alternative flow would be:

1. User selects items to rent
2. The User provides payment and shipping information
3. User changes mind and chooses another vehicle
4. User deletes cart
5. User selects new items
6. User places order
7. The system respond with confirmation of the order and a renting number that the user can use to check out the vehicle. 

1. The system will also provide the user with a countdown for the remainder of the renting time. 
2. The user may already have an account with the company with billing information.

User story example

As a user, I want to link the credit card to my profile so that I can pay for a rent faster, easier and without cash.

As a service provider, I want to add photos of my vehicles in the application so that I can attract more users.

As a user, I want several available vehicles to be displayed so that I can choose the most suitable option for me.

The differences between a user story vs use case

User focus vs technical focus

User story is drafted to explain a user’s needs. It highlights a problem that a user faces in his day to day life. The language of this draft is very simple. It is developed to keep all the stakeholders on the same page. On the other hand, use cases are developed for the product team only. It gives the team an idea of what the software should achieve. It also highlights all the steps the developers need to follow in order to make the software. For this reason, use cases contain a lot more detail than user stories.

General vs in-depth

User story is a simplified form of many users interacting with a software. Use cases are very specific in relation to user stories. They describe specific user actions with any system.

Short vs Detailed

User stories miss out on a lot of details. This is because it gives room for discussion and improvement. This aspect of user stories is deliberate. This encourages stakeholders to initiate discussions and improve the product. Use cases on the other hand are specific. They describe in detail all the steps that a developer will follow. There is usually no room for discussion.

Use stories are developed before the user case. In most cases they are developed by user interaction. One user story can generate multiple use cases. The combination of all such use cases produces a detailed document. This document has a description of the interaction between all software and users.

The similarities of a user story and a use case

The biggest similarity between the two approaches is the key components. User stories have components like user role, goal etc. Use cases also have similar concepts. It includes actor, pre-conditions and other terms. So, both of these concepts become similar in how they approach a problem.

When to use a user story vs use case?

User stories have a lot of uses in product development. They are used before use cases to start customer focused conversations. This conversation means more room for improvement in the customer model. It helps in providing clarity to the whole concept. User stories ensure no useless detail gets into the whole process. This also ensures that goals are set from the beginning of the process. Thus, user stories increase efficiency.

There are several places when use cases can be used. They can be used to document the process of a current system. Often when existing systems are updated they can provide a lot of technical problems. Use cases help in understanding the bigger picture of the existing system. So, problems can be avoided before any changes are made.

Another use of the use case is in the development of new systems. It helps in providing a detailed description of all the steps developers need to follow. It also helps in defining user goals and easing the development process.

WRAP UP

By now you know what user stories and use cases are all about and what their use is. These concepts are instrumental to a successful product.

The most frequently asked question and confusing concept among the agile development team is “what is the difference between use case and user story?” because both serve the same purpose. The answer is that their approaches to the goal are distinct. Both use cases and user stories are frequently used in agile software development. Many organizations favor certifications that align with the KnowledgeHut Agile courses when hiring project managers just to make sure that they are aware of the difference between use cases vs user stories. Let’s compare use cases vs user stories by looking at each definitions, similarities as well as the difference between user stories and use cases with examples and applications for each.  

Use Case vs User Story: Head-to-head Comparison

Getting to the crucial question, «How are user stories different from use cases?» Obtaining agile certification is encouraged to develop knowledge in understanding use cases vs user stories, which is easy to achieve with proper guidance. 

The following table can help us understand the difference between user stories and use cases: 

What is a Use Case? 

The first author to present an article on use cases was Ivar Jacobson, who did so in 1987. A use case is a collection of interactions that occur between a user and a system to accomplish an objective. In this context, the user is an actor, and the system is a piece of equipment or a device. The decision-maker, whether they be a person, a business, or a computer program, is known as the actor. We will go over the actor in greater detail below. 

The use case mostly uses the following three terms. Let’s understand them with an example: “A person orders goods through an e-commerce website, and the seller delivers them.” 

1. Actors

An actor is a character who interacts with a system to achieve a purpose. The term «actor» comes from the Unified Modeling Language. The actor need not always be a human; they could be any computer program, hardware system, software system, business, or organization. The secondary actor, who aids the system in achieving the aim of the primary actor, is another character to be aware of in a use case. In the above example, the human is the main actor making decisions. The e-commerce program also notifies the seller to package and send the order to the buyer, here seller is the secondary actor. 

2. Goal

The process’s end result is a goal, which is selected by the user, the client, and occasionally even a piece of software. The use case’s entire process is intended to achieve the desired result. 

In the preceding example, the actor (person) opted to purchase a product (goal), hence the goal is to purchase a thing. If the product is delivered, the aim has been met. 

3. System

A system is one that accepts instructions from the actor and then executes all actions necessary to achieve the actor’s purpose. 

The e-commerce website is the system in the preceding example. Following receipt of the order, various procedures are taken, including advancing to payment, alerting the seller to pack the item and send it, tracking the order status for any delays, and ultimately delivering the product. 

Format or Template

Use cases can be written in the text in a variety of styles, including formal, informal, and Fowler styles. There is no standard way to create the content of a use case, and different styles work well in different instances, according to Martin Fowler. He provided the following basic and typical format: 

1. Title: “Goal established by the actor” 
2. Success scenario: «List of interactions or steps to attain a goal». In this context, «steps» refers to a straightforward textual description of user and system interactions. 
3. Extensions: «Departure from the primary success scenario’s set of actions.» If the aim is not achieved, more connections are made to conduct the necessary measures. 

What is a User Story?

Kent Beck first introduced user stories in the year 1997. User stories are written materials that describe a system’s features from the viewpoint of the user or client. Post-it notes, computer software, and index cards are frequently used as writing surfaces. User stories are used in many agile techniques to describe and influence software development functionality.

Format or Template

User stories are written in several formats which are listed below: Let’s look at each of them. 

1. Five W’s concept: 

The five W’s are who, when, where, what, and why. This format of the user story is constructed by putting together user stories using the responses to a series of queries that pinpoint the specifics of the suggested product. 

“As a <Who>, I want to do <what> <where> <When> so I can accomplish <why>” 

2. Evil User Story 

This also goes by the name «abuse user story.» To safeguard against hackers, this user narrative template was utilized to strengthen security for the software development application. It is written from the viewpoint of a hacker, assuming that cyberattack-related actions take place. 

“As a <anti nationalist>, I want to <copy the personal information> of voters to <demolish>government” 

3.Connextra Format: 

Connextra template is the most common and widely used template in the User story, Let’s understand this with below-stated format 

“ As a <actor>, i can do <ability>, so that <benefit received>” 

Use Case vs User Story: Similarities

User stories vs use cases: there are a few commonalities that are listed below, and these differences have caused misunderstanding about the difference between use cases and user stories. Let us look at them: 

1. The main similarity between the use case and user story is they both have a role and goal to accomplish. 
2. Both are written in everyday language that is straightforward and easy for users. 
3. Both ought to make it clearer to the reader what the software is intended to do. 
4. Use cases have comparable components with user stories, such as an actor, a sequence of occurrences, including subsequent conditions. 

Examples of User Story vs Use Case

The use case vs user story examples will help in understanding the usage of these techniques. These examples also help in understanding the use case user story differences. 

Example 1 

Title: “Passenger booking a railway ticket” 

Use case example: 

User story example: 

1. The passenger opened a train ticket booking application so that he could start booking a train ticket. 
2. Passenger checked suitable train timings so that he can book an appropriate train. 
3. Passenger selected a credit card payment option so that he can make payment with a credit card. 
4. Passenger downloaded the train ticket so that he can print the ticket copy. 
5. Passenger printed the train ticket so that he can travel in the train with the ticket. 

Example 2 

Title: “A/C holder depositing cash in ADWM (Automated Deposit cum Withdrawal Machine)” 

Use case example: 

Possible extensions from step-4 to step-5. 

Step-4: ADWM counts the cash deposited 

1. ADWM rejects the damaged notes. 
2. Instructs the A/c holder to replace damaged notes. 
3. The A/c holder takes out the damaged notes. 
4. A/s holders deposit new cash in ADWM. 

Step-5: ADWM displays the amount deposited 

User story example 

1. The A/c holder visits the nearby ADW machine so that he can start depositing cash. 
2. The A/c holder selects the cash deposit option, so that machine opens the door to deposit 
3. ADW machine counts the amount deposited so that it can display the actual cash deposited. 
4. A/c holder enters his account number details, so that cash will be deposited in his account. 
5. ADW machine print deposit slips, so that account holder can get confirmation. 
6. A/c holder collects deposit slips so that he can leave the place with confirmation of accomplishment. 

The user story vs use case examples may be found in many daily tasks. There is a large curriculum to study and comprehend. 

In product development, the user journey vs use case is extensively utilized, mostly in agile development approaches. Let’s discuss their other uses: 

Use case

1. Use cases are utilized for the description of the software requirements specification (SRS), which serves as an alternate framework for the functional requirements. 
2. Used for utilizing the entity-control-boundary method to derive the design from the requirements. 
3. Utilized as a behavioral modeling tool in the Unified Modeling Language (UML). 
4. Use case is utilized as the driving factor in Object Oriented Software Engineering (OOSE). 

User story

To begin customer-focused interactions, user stories are utilized before use cases. User stories provide an overview of potential software project features. 

In scrum, the product owner prioritizes user stories to identify those that are crucial to the system. Based on these discussions, user stories may be enhanced to provide more information. Notes, attachments, and acceptance requirements are examples of this. 

Conclusion

We have seen the use case and user story differences with individual definitions and also with suitable examples. Once you understand the topic “difference use case and user story”, you can begin to determine what function they can play in your project which helps in using both concepts appropriately in your projects. 

Frequently Asked Questions (FAQs)

1. Are use cases and user stories the same?

They are not the same since they have distinct objectives. Difference between a use case and a user story is an important topic to know in agile software development. 

2. Does Agile use use cases?

Use cases are a part of agile software development. 

3. Can a use case include multiple user stories?

There is a chance that a single user story will give rise to many use cases. But a single use case cannot include multiple user stories. 

4. User stories are different than use cases in what way?

When compared to use cases, both are distinct, but user stories are simpler to understand.

So what to do if the flow is too big to be represented in a single chart? We can accommodate the use of Wireflows and User flows into documents. These documents will contain the Low – Medium fidelity wireframes. Instead of the arrows, navigation works through unique screen IDs and indicators in the wireframes. Each action (buttons, menus, etc.) will point to other screen IDs. This type of documentation serves its purpose by user scenario, use case, feature, etc.

Our experience.

Use cases, user stories, and flow charts are essential parts of the mobile app design and development. We have encountered that user stories are usually provided by the product owner to communicate the user and business needs. Technical leads and UI/UX designers develop user flows based on the user stories and requirements. UI/UX designers then apply the use cases and transform them into graphical flow charts. All of these documentation becomes essential to current and future versions of the product. 

The use cases and flow charts, in our experience, are documentation that goes through several parties involved in the process:

• The Product owner takes the use cases to validate the user stories.
• The Technical Leads and developers use the use cases and flow charts as documentation to verify the functionality of the implementation.
• The UI UX designers develop wireframes and mockups based on the use cases.
• The SQA team take the use cases to validate the expected functionality vs. the implementation.

Use cases are time-consuming to create, but in our experience, they are certainly needed and useful as reference documentation and guidance for developers, designers, and testers. There are multiple ways to document a use case; there is no correct answer in which one to choose; It will depend on which one adapts better to your process and product. Choose the best deepening on the size of the case to document. If the feature or situation is not yet fully defined, it is best first to elaborate on the use case, and when the use case is approved, it translates into a flow chart or document.

What are the objectives of having case scenarios and flows documented?

Analyze and Document Requirements

It helps to identify not covered scenarios, errors, or side scenarios.

It validates User Stories.

It helps to understand the evolution of the features.

As a final thought, consider the needs of the business, the needs of the product, and the team’s needs (Development, SQA, etc.) Ensure you have all the elements required in your documentation to support the team and have documentation that can be expandable in a progressive way.