Use case example word

A use case template is an effective tool used in software designing and for any type of management. A use case defines what has to happen upon a particular action so that it would be completed successfully. It easily outlines all that is required for a particular process to succeed. This document also outlines all the people involved in it.

Different Types of Use Cases:

There are two different types of use cases;

Business use cases

This type of use case explains a business process. It specifies in the appropriate sequential order the actions required to deliver an observable result to the end-user. It is used in a less technology-oriented manner. The business process being explained and the associated actors are the critical elements in a business use case.

System use cases

A system use case explains particular processes within a system that have to be completed to get the end-user objective. It is more explained than a business use case.

Who can make use cases?

The use case methodology is used by product management, product development, and product testing domains. Product managers and developers use it for specifying how the system will react to user activities.

Usually, product managers document user-focused use cases that are primarily concerned with the user and their goals. On the other hand, developers document product-focused use cases. The user-focused use cases are passed to developers during the product development process for guiding decision-making. Technical and design elements are added by product developers to give crucial context. The development team through this set of improved use cases get insight that it requires to start designing, creating, and testing the product and its features.

Format of Use case:

There is no standard format for use case. There are many different types of formats that you can use on the basis of the nature of your requirements. The main thing is to make sure that the use case is easily understandable. You can use any type of format or you can even make a format of your own but it should contain all the necessary information. You can also find use case templates online with different designs. Some templates will be in the form of a table. On the other hand, the others will be descriptive and filled with text.

However, none of them is wrong and none of them is right, the right one is that serves your purpose best. A table is all you need in case you are defining actions in technical terms. You will need a more descriptive format in case you are writing about complex processes.

It is important to use a similar format to write all the use cases in your company. After establishing the format, people will become used to writing in that manner. Your use cases will look disorganized if you change the format. Also, it will be harder to understand for readers.

Furthermore, for your specific organization, you can create a unique type of use case. But, there are some common terms that are used in almost all Use Case templates;

• Use Case Name
• Summary
• Actors
• Preconditions
• Flow
• Level
• Trigger
• Stakeholders

Actors

In the use case, the people or elements who are involved in the process are known as actors. To understand all the parts, let’s take a use case example. For instance, a person creates a support request on a website for electronic products then in such a situation the following actors are present;

Primary actor

The individual who is responsible for the event for which the Use Case exists is known as the primary actor. In our example, the primary actors will be the individual who makes the support request on the company’s websites.

Secondary actor

A person or group of people that is required to complete the process successfully is known as the secondary actor. Someone will require to be provided support by a customer support representative if someone generates a request for support on the website. This indicates that another person will have to get involved. In most companies, when a customer generates a support ticket, it will generally deliver to the people who have the task of helping customers. In our example, the delivery to the secondary actor is a necessary part of the case. Otherwise, the customer will never get the support that they need.

Trigger

A trigger simply explains the exact action that results in the Use Case. In most use case templates, you can find this section. In our example, the trigger is when the customer clicks the button on the website to create a support ticket. This click starts the use case within the support system.

Preconditions

The preconditions are the situations that have to be met to make sure that the use case can be fulfilled. The case cannot run its course if these conditions are not met. The preconditions are the following in our example;

• The individual who creates the request requires having an active internet connection.
• The website has to be accessible by the customer
• The support agent should have an active internet connection

Preconditions should be defined properly. In case, preconditions are poorly defined then the action that is designed may not work at all.

Flow

You have to explain the flow of the process that begins when a use case is started. The flow needs to detail the following;

• How the communication will flow
• Who the information will be displayed to
• What they need to do
• When the primary actor will end up

When writing the flow, there are 3 things that you have to mention;

1. Basic flaw
   If all the conditions are met, the basic flow is the best case scenario of what should happen in the use case. You have to define the flow of the use case in case you are designing the software or the process.
   
2. Alternates
   Mention the alternate routes through which the action can be done. In the use case example, the alternate flow is that the client can be contacted over the phone. They can also ask someone to come to their home to assist them with the product. Here you should mention all the possible routes that can be taken to the use case.
   
3. Exceptions
   This defines what happens when a failure occurs in the flow. Likewise basic flow, exceptions are also important to define. In the case of failure, any good system needs to have precautions in place. You will be easily able to define what needs to be done by knowing all the exceptions.
   

Level

It is essential to classify the use case with a level so that you describe the urgency which it requires to be dealt with. The level usually depends on the type of a company. Moreover, you have to make sure that whoever reads the use case realizes its importance.

Stakeholders

The project manager will tell you how essential this section is in a use case template. There are several stakeholders in our example;

• The Customer Support Department
• The Sales Department

Writing a use case:

Here are the steps to follow for writing a use case;

• Identify the target audience for the product.
• Choose a user from that list.
• Then, identify what user wants to do with the product. Make a separate use case for every action.
• For each use case when the user uses the product, identify the typical flow of events.
• Explain the fundamental course in the use case description. It would be better to provide examples of what the user performs and the system responds so that they are aware of both.
• When the fundamental process has been presented, consider alternative courses of action and add them to “expand” the use case.
• Find out connections among the use cases then extract them and mark as typical use cases for courses.

What are the benefits of a use case?

Let us discuss below the benefits of a use case;

Don’t need technical knowledge

A use case is an effective communication tool as it is not written in technical language. Without getting into the specifics of the software or application development, it lets you as the user know the functions of a system. The actions that a user takes within the system to get their goal, it indicates them. Therefore, there is no need to determine how to program or be familiar with technical tools that are used behind the scenes.

Assists you in asking intelligent questions

Use cases present areas of doubt within the functionality of a system by specifying step-by-step interactions between a user and a system. It is a powerful analytical tool that makes the users able to raise informed inquiries into the system’s shortcomings or areas of concern.

Assists in the valuation of the system

In order to identify the complexity and cost of the specific system, use cases explain the requirements and goals of a system.

The design process gets facilitated

The required requirements can be identified earlier in the design process by making an objective use case.

During the development of a system, it prevents scope creep

In terms of functionality and requirements, use cases determine a system’s boundaries. By having the developers make the system within the boundaries, associated scope creep with the aspects can be avoided.

The creation of premature design gets prevented

Use cases pay attention to what should be done by the system and how it should be done as they are objectives. Use cases make sure that efficient and results-based designs are created by prioritizing the results/goals/objectives.

Conclusion:

In conclusion, a use case template is a helpful tool while designing software or any other type of project. It is used as a planning tool that makes sure the users and customers have the best experience possible.

Faqs (Frequently Asked Questions)

Когда какая-либо IT-компания начинает разработку программного продукта, ей приходится задумываться о том, как быстрее и проще начать реализацию проекта и создать прототип, с помощью которого можно передать все функциональные возможности ПП. Что такое Use Case, для чего он нужен, чем он может помочь в разработке — расскажет наша статья.

---

Что такое Use Case

Use Case — это сценарный план взаимодействия пользователя с программным продуктом, в котором четко прописаны шаги для достижения того или иного результата. Последовательность действий, при этом, может быть расписана не для одного, а для нескольких юзеров.

В юзеркейсах для программных продуктов прописываются разные манипуляции. Это может быть покупка товаров через мобильное приложение, отправка данных, рассылка электронных писем и так далее.

Главной задачей юзеркейса является улучшение коммуникации среди членов команды при разработке программы или мобильного приложения. Пишутся эти кейсы на этапах проектирования и при планировании внедрения каких-либо функций.

Вообще, отвечать за составление юзеркейсов должны системные аналитики, имеющие опыт в ведении переговоров с заказчиками и проведении анализа ЦА. Но так как у многих компаний бюджет не всегда позволяет нанимать для этого сторонних специалистов, разработкой Use Case могут заниматься тестировщики, дизайнеры, разработчики ПП и даже продакт-менеджеры.

---

В каких ситуациях может помочь Use Case

Грамотно составленный юзеркейс может помочь в тех случаях, когда:

• при проведении подготовительных работ разработчики не могут правильно составить ТЗ;
• после долгих обсуждений функциональных возможностей команда отклонилась от первоначальной идеи продукта;
• команда разработчиков неправильно поняла начальный сценарий взаимодействия юзера и ПП;
• команда разработчика неправильно внедрила ту или иную функцию;
• в процессе тестирования программы появляется много непредвиденных ошибок;
• к команде подключились новые специалисты, которых нужно в кратчайшие сроки посвятить в курс дела.

Также Use Case незаменим в тех случаях, когда один и тот же кейс по-своему реализован в разных местах, тем самым затягивая процесс разработки ПП.

---

В чем польза юзеркейса

Качественно составленный Use Case может решать разные задачи. Например:

• облегчение коммуникации между разнопрофильными членами команды (дизайнеры, тестировщики, разработчики, менеджеры, аналитики);
• фиксирование принятых решений, что позволяет в дальнейшем не сбиваться с курса;
• быстрое возвращение к заданному сценарию с целью проверки его корректности на разных этапах разработки;
• упрощение порядка передачи информации между членами команды;
• определение самых важных аспектов сценария взаимодействия.

Use Case играет важную роль, когда необходимо подготовить прототип ПП, который покажет особенности и преимущества проекта.

---

Из каких элементов состоит Use Case

В зависимости от сложности сценария, юзеркейсы могут содержать порядок действий следующих лиц:

1. Actor — человек, который пользуется созданной системой. В качестве примера можно привести какой-нибудь интернет-магазин, где в качестве actor выступают продавцы, покупатели, поставщики и все те, кто взаимодействует с этим интернет-магазином.
2. Primary actor — это человек, у которого получается достигнуть поставленных целей с помощью созданного программного продукта. Если вернуться к тому же интернет-магазину, то primary actor в нем может быть производитель вещей, у которого получается реализовывать эти вещи с помощью функционала онлайн-площадки.
3. Stakeholder — человек, который заинтересован в том, чтобы созданы ПП выполнял те или иные действия. В интернет-магазине это может быть какой-нибудь партнер, получающий доход от приведенных покупателей, или подключенная к магазину платежная платформа, через которую совершаются онлайн-платежи.

Также к элементам юзеркейса относятся:

• понятный заголовок, содержащий конечный результат Use Case;
• описание последовательности действий;
• результат, к которому должен привести юзеркейс;
• предусловия — это то, что должно произойти до или после запуска кейса;
• триггеры, влияющие на запуск кейса.

А еще в любом Use Case должны быть прописаны альтернативные пути — события, к которым прибегают в том случае, если кейс не сработал.

---

Какими должен качественный быть Use Case

Высокое качество юзеркейса определяют следующие критерии:

1. Правильная детализация. При составлении Use Case нет смысла описывать каждый шаг пользователей и состояние элементов ПП в этот момент. Главная задача юзеркейса — всего лишь дать общую картину.
2. Простота изложения. Чтобы содержимое юзеркейса было понятным даже новым членам команды, его необходимо писать максимально простым языком. Не стоит использовать для Use Case сложные термины и вставки кода.
3. Единый стиль. Старайтесь использовать для всех юзеркейсов один и тот же шаблон. Это поможет сэкономить время на изучении ПП.

1. Важен контекст. В каждом юзеркейсе должны быть уточнения по поводу тех или иных действий. Так разработчики смогут разобраться в том, какая задача перед ними стоит.
2. Целенаправленность. Не стоит использовать юзеркейса для того, чтобы описать весь путь пользователя. Лучше представить конкретные шаги (регистрация, покупка, отправка заявки и так далее).

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

---

Какую пользу несет Use Case для определенных специалистов в команде

Для каждого из участников команды юзеркейс несет свою ценность. Например, для заказчика Use Case полезен тем, что на простой языке отображает конечную бизнес-ценность. Как правило, сценарий взаимодействия составляется таким образом, чтобы даже далекие от программной разработки пользователи могли понять, что написано в кейсе. Чем проще для заказчика будет составлен юзеркейс, тем быстрее он с ним ознакомиться и даст добро на продолжение разработки.

Для разработчика же ценность заключается в другом. В первую очередь речь идет о структурированных блоках информации, что упрощает создание ПП. Особенно это касается сложных проектов с жесткими требованиями. Также структурированная информация привязывается к конечному результату, благодаря чему разработки гораздо проще понять, что должно получиться в итоге.

Польза в юзеркейсах есть и для разработчиков. Во-первых, благодаря Use Case они могут тестировать программные продукты по заранее заданному сценарию. Это экономит время и избавляет от необходимости искать способы проверки на ошибки. Во-вторых, грамотно составленный кейс помогает находить в программе минусы, которые вряд ли удастся найти с помощь unit-тестирования.

---

Как  составить Use Case

Как говорилось ранее, составлять юзеркейсы нужно на этапах проектирования ПП. Также кейс пересматривается в тот момент, когда команда начинает внедрять новые или улучшать уже имеющиеся фичи. При этом писать юзеркейсы стоит только после того, как будет составлен путь пользователя.

Чтобы составить юзерйкейс, необходимо выполнить следующие действия:

1. В первую очередь определяем, какие пользователи будут работать с программным продуктом. Помочь в этом может обычный анализ рынка и ЦА.
2. Выявляем определенную группу пользователей, которые будут работать с ПП.
3. Рисуем портрет группы пользователей и приблизительно определяем, что они будут делать разрабатываемой программе. Каждое действие в рамках ПП — потенциальный Use Case.
4. Определяем последовательность действий для каждого юзеркейса.
5. Приблизительно описываем основной путь пользователя.
6. Прогнозируем ответ системы на действия пользователя.
7. Разрабатываем альтернативные пути для расширения юзеркейса.
8. Повторяем перечисленные шаги для каждой группы пользователей.

Есть пара советов, которые помогут в составлении юзеркейсов. Во-первых, для экономии времени следует разработать шаблон. Такой подход позволит выработать единый стиль и экономить время при разработке других кейсов.

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

Чтобы читатели могли ознакомиться с приблизительным видом кейсов, мы решили разобрать несколько примеров.

---

Пример 1: регистрация на сайте

Результат кейса: пользователь создает аккаунт с личным кабинетом.

Номер шага	Действующее лицо	Действие
1	Пользователь	Пользователь нажимает на кнопку регистрации
2	Система	Открывает форма регистрации
3	Пользователь	Пользователь заполняет форма, указывает данные, подтверждает регистрацию
4	Система	Идет проверка корректности заполнения, пользователь вносится в базу данных, на почту отправляется письмо со ссылкой для активации акк
5	Пользователь	Пользователь открывает письмо, переходит по ссылке
6	Система	Система активирует аккаунт, высылает инструкцию по работе с сервисом

Это из самых простых кейсов. Как правило, большая часть юзеркейсов имеют более сложно схему взаимодействия.

---

Пример 2: регистрация в интернет-магазине по сложной схеме

• цель: зарегистрироваться в интернет-магазине;
• действующее лицо: незарегистрированный пользователь;
• триггер: пользователь увидел рекламу интернет-магазина и решил зарегистрироваться;
• результат: у пользователя появляется аккаунт с бонусной системой.

Шаги юзеркейса выглядят следующим образом:

1. Пользователь нажимает на кнопку регистрации.
2. Система открывает форму регистрации, запрашивает контактные данные и платежные реквизиты.
3. Пользователь заполняет поля, отправляет на проверку.
4. Система проверяет инфу на корректность, вносит пользователя в базу, отправляет письмо со ссылкой активации.
5. Пользователь открывает письмо, переходит по ссылке.
6. Система активирует аккаунт.

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

---

Пример 3: кейс по взаимодействию с сайтом вуза на примере диаграммы

Некоторым специалистам проще делать юзеркейсы в  виде диаграммы. Они удобны и практичны, однако в них нельзя отследить последовательность действий. Один из примеров – диаграмма юзеркейса, в котором прописаны шаги разных групп пользователей в рамках сайта ВУЗа.

Как видно на рисунке, студенты могут просматривать темы и записываться на курсовые проекты. Руководители могут просматривать уже имеющиеся и вносить новые темы. Система же отвечает за предоставление информации и внесения указанных сведений в базу данных.

---

Эксперты отвечают
 

Вывод

Use Case — это инструмент, созданный для упрощения взаимодействия с разрабатываемым ПП. Перед созданием этого инструмента стоит тщательно изучить все материалы, заранее подготовить список разделов и обсудить все шаги с членами команды. Если юзеркейс будет составлен правильно, появится возможность не только наладить коммуникации, но и упростить процессе ведения технической и пользовательской документации.

• Что такое юзкейс
• Из чего состоит
• Как написать
• Пример
• Диаграммы
• Польза для команды

Что такое юзкейс

Use case (также юзкейс, сценарий использования) – это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Юзкейсы содержат следующие сведения:

• кто использует сайт или приложение
• что пользователь хочет сделать
• цель пользователя
• шаги, которые делает пользователь, чтобы совершить определенное действие
• описание того, как сайт или приложение реагируют на действия пользователя.

Юзкейсы не содержат детали реализации, а также описания пользовательского интерфейса или экранов.

В общем, в юзкейсе описывается не каким образом программа делает что-либо, а что именно она делает. Именно этого подхода и нужно придерживаться, создавая юзкейсы.

В отличие от user story, которая излагается от имени какого-то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:

• покупка товара в магазине (Покупатель – Продавец);
• отправка письма по электронной почте (Отправитель – Почтовый клиент);
• запрос страницы браузером (браузер – веб-сервер).

Элементы use case

Юзкейсы могут содержать следующие элементы (их количество зависит от сложности сценария):

• Актор (actor) — тот, кто использует систему. Если взять за пример онлайн-магазин, там может быть несколько акторов: покупатели, продавцы, компании, занимающиеся доставкой, компании, проводящие платежи.
• Стейкхолдер (stakeholder) — тот, кто заинтересован в определенном поведении системы. Зачастую это не конечный пользователь, а кто-то, получающий выгоду от функционирования системы. В случае с онлайн-магазином это может быть партнер — платежная платформа.
• Первичное действующее лицо (primary actor) — человек или система, чьи цели достигаются при помощи нашего продукта. В онлайн-магазине это может быть основной дистрибьютор, чьи товары продаются на этой онлайн-платформе.
• Предусловия и постусловия — что должно быть в наличии или должно произойти до и после запуска сценария использования.
• Триггеры — события, запускающие юзкейс.
• Успешный сценарий — юзкейс, при котором все идет по плану, без ошибок и неожиданностей.
• Альтернативные пути — вариации основного успешного сценария на случай, если что-то пойдет не так на уровне системы.

Как написать use case?

Шаги в юзкейсе описываются максимально понятно. Что касается самих шагов, они могут быть следующими:

1. Определите, кто будет использовать сайт.
2. Выберите одного из этих пользователей.
3. Определите, что этот пользователь хочет делать на сайте. Все, что пользователь делает на сайте, становится юзкейсом.
4. Для каждого use case определите нормальный ход событий.
5. Опишите основной путь пользователя: что именно делает пользователь и каков ожидаемый ответ системы.
6. Далее рассмотрите альтернативные варианты развития событий и добавьте их, чтобы «расширить» use case.
7. Повторите шаги 2-6 для всех остальных пользователей.

Пример use case

В этом юзкейсе изложен сценарий входа пользователя в школьную систему.

Название use case	Login
Описание use case	Пользователь входит в систему, чтобы получить доступ к ее функционалу.
Акторы	Родители, Ученики, Учитель, Админ
Предусловия	Система должна быть подсоединена к сети
Постусловия	После успешного входа пользователю отсылается уведомление на mail id

Основные сценарии	Номер	Шаги
Акторы/пользователи	1	Ввод username Ввод пароля
	2	Проверить имя пользователя и пароль
	3	Разрешить на вход в систему
Расширения	1a	Неверное имя пользователя Система выбрасывает сообщение об ошибке
	2b	Неверный пароль Система выбрасывает сообщение об ошибке
	3c	Неверный пароль введен 4 раза Приложение закрывается

Юзкейс-диаграммы

Для визуализации юзкейсов используют диаграммы. В них система обозначается прямоугольником, use case — овалом, актор — схематическим человечком.

Пример диаграммы для юзкейсов входа в школьную систему:

Зачем нужны use case?

Давайте рассмотрим, в чем ценность юзкейсов для участников проекта разработки ПО.

1. Заказчики

В юзкейсе отражается конечная бизнес-ценность, понятная заказчику. Реализация сценария использования в системе очевидна даже для нетехнического специалиста. Наличие готового use case позволяет заказчику своевременно дать старт дальнейшей работе тестировщиков и разработчиков.

1. Разработчики

В сценарии использования указываются основной и альтернативные потоки событий. Вся информация в нем подается максимально структурированно и понятно, в привязке к конечному результату. Это удобно для понимания запутанных требований. Если сценарий поведения пользователя в системе сложный, use case просто необходим.

1. Тестировщики

Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки,  которые сложно найти, например, при юнит-тестировании.