Что такое use case? Теория и примеры
Use case (также юзкейс, сценарий использования) – это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.
Юзкейсы содержат следующие сведения:
Юзкейсы не содержат детали реализации, а также описания пользовательского интерфейса или экранов.
В общем, в юзкейсе описывается не каким образом программа делает что-либо, а что именно она делает. Именно этого подхода и нужно придерживаться, создавая юзкейсы.
В отличие от user story, которая излагается от имени какого-то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:
Элементы use case
Юзкейсы могут содержать следующие элементы (их количество зависит от сложности сценария):
Как написать use case?
Шаги в юзкейсе описываются максимально понятно. Что касается самих шагов, они могут быть следующими:
Пример use case
В этом юзкейсе изложен сценарий входа пользователя в школьную систему.
| Название use case | Login |
| Описание use case | Пользователь входит в систему, чтобы получить доступ к ее функционалу. |
| Акторы | Родители, Ученики, Учитель, Админ |
| Предусловия | Система должна быть подсоединена к сети |
| Постусловия | После успешного входа пользователю отсылается уведомление на mail id |
| Основные сценарии | Номер | Шаги |
| Акторы/пользователи | 1 | Ввод username Ввод пароля |
| 2 | Проверить имя пользователя и пароль | |
| 3 | Разрешить на вход в систему | |
| Расширения | 1a | Неверное имя пользователя Система выбрасывает сообщение об ошибке |
| 2b | Неверный пароль Система выбрасывает сообщение об ошибке | |
| 3c | Неверный пароль введен 4 раза Приложение закрывается |
Юзкейс-диаграммы
Для визуализации юзкейсов используют диаграммы. В них система обозначается прямоугольником, use case — овалом, актор — схематическим человечком.
Пример диаграммы для юзкейсов входа в школьную систему:
Зачем нужны use case?
Давайте рассмотрим, в чем ценность юзкейсов для участников проекта разработки ПО.
В юзкейсе отражается конечная бизнес-ценность, понятная заказчику. Реализация сценария использования в системе очевидна даже для нетехнического специалиста. Наличие готового use case позволяет заказчику своевременно дать старт дальнейшей работе тестировщиков и разработчиков.
В сценарии использования указываются основной и альтернативные потоки событий. Вся информация в нем подается максимально структурированно и понятно, в привязке к конечному результату. Это удобно для понимания запутанных требований. Если сценарий поведения пользователя в системе сложный, use case просто необходим.
Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки, которые сложно найти, например, при юнит-тестировании.
Use case что это такое
Use Case (вариант использования, ВИ, Прецедент, юскейс) — это сценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.
В общем случае, с помощью Use Case может описываться взаимодействие двух или большего количества участников, имеющее конкретную цель:
В разработке ПО эту технику часто применяют для проектирования и описания взаимодействия пользователя и системы, поэтому название Use Case часто воспринимает как синоним требования человека-пользователя к решению определенной задачи в системе. В статье мы будем рассматривать использование Use Case для описания взаимодействия пользователя с системой.
Исторически требования к функционированию системы описывались в виде отдельных функций. Ивар Якобсон в середине 1990-х годов предложил Use Case как альтернативу и дополнение описания функциональности системы. Описание требований к системе не в виде отдельных функций, а в виде описания контекста и последовательности действий пользователя помогает сформировать набор функциональных требований, который будет обеспечивать полноту и неизбыточность требований.
Мы можем сформулировать набор функциональных требований:
FRQ1 Система должна предоставить пользователю возможность ввести код бронирования
FRQ2 Система должна сохранить сведения о регистрации пассажира на рейс
FRQ3 Система должна предоставить пользователю возможность распечатать посадочный талон
Пока это разрозненные требования, мы не можем проверить их набор на полноту и соответствие целям пользователей, так как мы не видим:
1) контекста выполнения этих функций,
2) роли пользователя, которому должна быть доступна функция,
3) целей этого пользователя при использовании системы.
Use Case задаёт формат, в котором все эти важные факторы описываются и учитываются. И перечисленные выше функциональные требования можно объединить в один Use Case, описывающий цель пользователя.
Пример базовой части Use Case.
Регистрация пассажира на рейс
Описание решения задачи пользователя в системе в виде Use Case должно определять:
Основной поток действий Use Case описывает успешную последовательность событий, необходимую для достижения конкретной цели основного действующего лица.
Предусловие — условия, которые должны выполняться, чтобы сценарий вообще мог начаться. Мы не будем проверять это условие в процессе работы сценария, так как мы предварительно договорились, что оно истинно.
Результат — или «гарантия успеха» — след, который оставляет сценарий. Наличие результата говорит нам, что и Пассажир достиг своей цели.
Этот Use Case пишется для проектирования решения, его потребителем будет команда разработки.
Назначение Use Case для разных участников проекта
Конечно, для разработки функциональных требований к системе мы пишем целый набор Use Case, учитывающих цели пользователей нескольких ролей. Этот набор позволяет обеспечить полноту требований пользователей к системе. Набор Use Case является набором требований более высокого уровня абстракции, чем набор отдельных функциональных требований, и в то же время полностью покрывает пользовательские требования к функциональности. Поэтому он более удобен в работе.
Рассмотрим преимущество работы с набором Use Case для людей, выполняющих разные роли в проекте.
Use Case для руководителя проекта
Сам по себе Use Case — это естественный способ описывать диалог, он понятен человеку без подготовки, Use Case обычно не содержит деталей реализации и пишется на языке целей пользователей. Поэтому Use Case удобно согласовывать с Заказчиком как «единицу поставки»: элемент планирования работы над системой и сдачи проекта.
В отличие от планирования работы и сдачи результатов в виде отдельных функций (сохранять, предоставлять доступ) или элементов архитектуры (платформа, подсистема хранения данных, подсистема обработки данных, подсистема пользовательского интерфейса), согласование работ на основе Use Case гораздо прозрачнее для заказчика. Во-первых, каждый Use Case несет конечную бизнес-ценность, понятную заказчику, во-вторых, даже технически неподкованный заказчик может убедиться в наличии реализации того или иного Use Case в системе, в отличие от наличия отдельных подсистем или функций, никак не отображающихся на пользовательском интерфейсе.
То, что набор Use Case состоит из меньшего количества элементов — обычно от 5 до 20, — чем набор отдельных функциональных требований, экономит время на согласование проекта с заказчиком, а то, что заказчику понятна бизнес-ценность каждого Use Case, сильно упростит выставление приоритетов между ними.
Use Case для тестировщика
Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев — test case, — так как они описывают в каком контексте должно производиться каждое действие пользователя. Use Case, по умолчанию, являются тестируемыми требованиями так как в них всегда указана цель, которой нужно достигнуть и какие шаги надо для этого воспроизвести.
Use Case для аналитика и менеджера продукта
Для аналитика и менеджера продукта, как наиболее частых авторов, Use Case это отличный инструмент:
В процессе проектирования взаимодействия с системой в виде Use Case и согласования их с заказчиком, аналитик и руководитель проекта узнают много сопутствующей информации: роли пользователей, внутренние правила работы потенциальных пользователей, которые влияют на логику Use Case и являются бизнес-правилами. В процессе расстановки приоритетов и выявления критичности тех или других Use Case формируются требования к пользовательскому интерфейсу. При определении частоты выполнения того или иного действия пользователя в системе, описанного в виде Use Case, формируются требования к производительности системы.
Так как Use Case полностью покрывают набор таких функциональных требований, и в то же время согласуются с бизнес-целями заказчика, они позволяют проследить связь от бизнес-целей заказчика до отдельной функции и связанных нефункциональных требований, т.е. обеспечить трассировку.
Use Case не обеспечивают полноту всех функциональных требований, если в систему должна быть заложена сложная бизнес-логика, т.е. обработка информации в системе зависит не только и не столько от действий пользователей, сколько от внутренних правил взаимодействия объектов.
Например, работа с системами типа «тасктрекер» задается достаточно простыми и стандартными Use Case: «Создать задачу», «Назначить задачу», «Пометить задачу, как выполненную». Однако тасктрекеров существует огромное множество, и это оправдано тем, что в каждом есть свои возможности по заданию жизненных циклов задач, их типов и взаимосвязей. И эту внутреннюю логику работы с задачами нет смысла описывать в виде Use Case.
То же касается бухгалтерских программ, систем поддержки принятия решения, профессиональных систем для проектирования и дизайна. Use Case важны для них, но не покроют и пятой части требований к функциональности.
Если эта техника вас заинтересовала, ознакомьтесь с материалами от классиков Use Case:
Как и зачем писать Use Cases
Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.
Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.
Что такое Use Case
На собеседовании порой можно услышать следующее определение «Это такая UML-диаграмма с человечками и овалами». Давайте разберемся, что это такое, и рассмотрим несколько простых примеров.
Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.
Мне нравится определение из книги Коберна (советую, ее, кстати, всем аналитикам): «Вариант использования фиксирует соглашение между участниками системы о ее поведении. Вариант использования описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях».
В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.
Текст vs диаграмма/схема
Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:
Конечно, если в вашем проекте очевидны дополнительные преимущества от использования диаграмм — надо их использовать.
Кому и в каких случаях нужны сценарии
— Разработчикам. Очень удобно, когда ветвистое требование описано при помощи основного и альтернативного потока событий. Все четко и понятно: кто, когда и что вызывает, и что получается в результате. В моем последнем проекте менеджер исповедовал подход: минимум описаний, максимум общения. Но для нескольких сложных сценариев разработчики сами просили сделать подробное описание, и юзкейсы отлично подошли.
— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.
— Тестировщику. Почти готовый тест-кейс 🙂
— Всей проектной команде. Если сценарий нужно согласовать, а на каждом совещании пара-тройка альтернативных вариантов сценария звучит иначе, поможет строго описанный поток событий.
А также другим участникам процесса.
В каких случаях они нужны:
— Если вам нужна качественная, полная спецификация требований — юзкейсы прекрасно в этом помогут. Есть такие системы, для разработки и поддержки которых спецификация требований, содержащая модель данных, описание интерфейса, интеграции с другими системами и юзкейсы — очень хороший вариант.
— Для поддержки системы. Чтоб выявить ошибку, разобраться, на каком шаге что пошло не так.
— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.
Как их описывать
Давайте рассмотрим пару примеров, они говорят сами за себя.
Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):
| Действующие лица | Администратор, Система | ||
| Цель | Изменить статус учетной записи пользователя на «активный». | ||
| Предусловие | Учетная запись пользователя не активна. | ||
| Действующие лица | Пользователь, Система |
| Цели | Пользователь: авторизоваться в системе и начать работать; Система: идентифицировать пользователя и его права. |
