АНАЛИТИКА

Use Case: для чего описывают сценарии использования ПО

Максим Жуков

Сооснователь ecommerce-агентства KISLOROD

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

Содержание

Что такое Use Case
Варианты использования Use Case
Кому будет полезен Use Case
Уровни описания Use Case: сценарий и степени детализации
Как аналитик пишет Use Case
Модели и диаграмма использования
Пример текстового Use Case
Этапы написания
Из чего состоит
Как определить качество юзкейса
В чем ограничения Use Case
Нужен ли вам юзкейс?

Use Case: для чего описывают сценарии использования ПО

Что такое Use Case

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

Сценарий использования описывает, кто и что может сделать с системой или что система может сделать с кем и чем.

Проще говоря, это то, что должен сделать пользователь, чтобы получить нужный результат. Например, чтобы отправить заявку, надо заполнить все формы и нажать на кнопку «Отправить».

Изначально требования к функционированию систем описывались в виде отдельных функций. Но в 1987 году Ивар Якобсон предложил сценарную технику Use Case в качестве альтернативы.

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

Варианты использования Use case

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

Примеры использования:

Запрос страницы браузером — «Браузер — Сервер».
Отправка электронного письма — «Отправитель — Почтовый клиент».
Покупка товаров в интернет-магазине — «Покупатель — Продавец».

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

Юзкейс отвечает на вопросы:

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

При этом юзкейсы не содержат описаний пользовательского интерфейса UI или экранов, а также не содержат деталей реализации программного продукта.

Пример Use Case - варианты использования

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

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

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

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

Когда могут быть использованы сценарии Use Case:

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

Кому будет полезен Use Case

1. Заказчикам и руководителям проекта

Реализация сценария использования в системе ясна любому, даже не техническому специалисту.

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

2. Аналитикам и менеджерам продукта

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

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

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

3. Разработчикам

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

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

Говоря профессиональными терминами, юзкейсы обеспечивают трассировку требований от заказчика к разработчикам.

4. Тестировщикам

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

Уровни описания Use Case: сценарий и степени детализации

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

Use Case могут быть описаны на абстрактном или на системном уровне.

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

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

Детализация документированного Use Case зависит от степени формализма и может быть:

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

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

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

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

Как аналитик пишет Use Case

Как правило, системный аналитик пишет Use Case в два этапа:

1. Сбор информации

Аналитик собирает:

бизнес-требования — чего хочет бизнес;
пользовательские требования — чего хочет от системы пользователь.

Бизнес-требования можно получить от бизнес-аналитика или собрать напрямую от заказчика с помощью брифа, опросов и обсуждений. Готовые бизнес-требования собираются в BRD — документ, в котором описаны требования бизнеса к проекту или продукту разработки.

2. Общая картина в виде диаграммы

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

Участники процесса обозначаются в виде иконок пользователя, отдельные сценарии использования пишутся в овалах, например: «Авторизоваться», «Купить», «Подписаться на рассылку». Для обозначения связей между элементами используются стрелки и пояснения текстом.

3. Подробное текстовое описание по отдельным задачам

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

Модели и диаграмма использования Use Case

Диаграмма вариантов использования — это графическое изображение возможных видов взаимодействия пользователя с системой.

Пример Use Case — модель сценария использования в ресторане

Диаграмма юзкейса показывает различные варианты использования и типы пользователей, которые есть в системе.

Система представлена прямоугольником или рамкой с границами.
Действующие лица показаны в виде иконок людей за пределами рамки с границами.
Сценарии использования (Use Case) представлены в виде текста в овалах внутри рамки.
Сплошные и пунктирные линии представляют связи между действующими лицами и прецедентами системы.

В первую очередь диаграммы Use Case используются:

для визуализации потока и поведения системы;
иллюстрации функциональности системы;
представления ключевых взаимодействий системы и пользователя.

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

Пример текстового Use Case

Рассмотрим самый простой сценарий использования, например, регистрацию на сайте.

Регистрация на сайте:

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

Этапы написания Use Case

Определить пользователей, которые могут работать с программным продуктом через анализ рынка и ЦА.
Выделить определенную группу пользователей, которые будут взаимодействовать с продуктом.
Составить портрет сегмента ЦА на основе данных из веб-аналитики и исследований.
Определить, что будут делать пользователи в рамках работы с программным продуктом — каждое такое действие будет отдельным юзкейсом.
Обозначить последовательность действий для каждого юзкейса.
Примерно описать основной путь пользователя.
Спрогнозировать ответ системы на действия пользователя.
Разработать альтернативные пути для расширения юзкейса.
Повторить последовательность для каждой группы пользователей.

Из чего состоит Use Case

Следует учесть, что не существует стандартного шаблона Use Case — для каждого проекта он будет своим: отличаться по структуре, уровню детализации и способу использования.

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

Имя сценария

Лучше всего имя сценария писать в формате глагол-существительное, например: «Пройти регистрацию», «Купить товар», «Подписаться на рассылку».

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

Цель

Цель должна кратко описывать то, чего хочет достичь пользователь.

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

Актор

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

На примере интернет-магазина — это будут продавцы, покупатели, поставщики и все те, кто взаимодействует с ним.

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

Стейкхолдер — заинтересованное лицо

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

Предварительные условия

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

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

Активаторы — триггеры

Это события, которые запускают исполнение сценария, они могут быть внешними, внутренними или временными.

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

Успешный сценарий

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

Вторичные сценарии — альтернативы

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

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

Как определить качество юзкейса

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

Разумная детализация. Сценарий должен описывать общий уровень взаимодействий — быть схематичным. При этом если внутри одного юзкейса заложен другой, то достаточно дать на него ссылку, а не описывать заново.
Контекст. Перед каждым юзкейсом необходимо давать комментарии и уточнения, чтобы читатель смог получить цельную картину сценария.
Актуальность. Если в сценарий использования вносятся изменения или коррективы, то документ должен быть обновлен.
Конкретность. Юзкейс должен описывать определенное взаимодействие, например, отправку заявки или письма, а не весь путь пользователя по сайту.
Простота изложения. Сценарий нужно описывать простым языком, без сложных технических терминов.
Единый формат документа. Для всех юзкейсов нужно использовать один стандарт. Лучше всего изначально разработать шаблон юзкейса и все новые документы создавать на его основе.

В чем ограничения Use Case

У сценариев использования есть ряд определенных ограничений.

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

Нужен ли вам юзкейс?

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

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

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

Получайте полезный контент от KISLOROD в любой из мессенджеров

При переходе в одну из указанных социальных сетей, вы автоматически соглашаетесь с политикой конфиденциальности

Спасибо, что дочитали до конца.

Если информация была полезна, поделитесь статьёй. Вам не сложно, нам приятно ;)