Что такое Use Case и зачем они нужны?

Автор: Анна Абрамова, руководитель Сообщества аналитиков Санкт-Петербурга

Use Case (вариант использования, ВИ, Прецедент, юскейс) — это сценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.

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

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

interaction

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

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

Мы можем сформулировать набор функциональных требований:

FRQ1 Система должна предоставить пользователю возможность ввести код бронирования
FRQ2 Система должна сохранить сведения о регистрации пассажира на рейс
FRQ3 Система должна предоставить пользователю возможность распечатать посадочный талон

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

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

 

UC1 Регистрация пассажира на рейс

Пример базовой части Use Case. Регистрация пассажира на рейс

registration

Система Система регистрации пассажира на рейс
Основное действующее лицо Пассажир
Цель Зарегистрироваться на рейс
Триггер Пассажир решает зарегистрироваться на рейс и заходит на страницу регистрации сайта
Результат Информация о регистрации пассажира сохранена
У пассажира есть посадочный талон

Основной поток событий

№ шага Действующее лицо Шаг Комментарий
1 Система Запрашивает фамилию и код бронирования
2 Пассажир Вводит фамилию и код бронирования Код бронирования:  7 символов, заглавные латинские и цифры.

Например: MTDTC1

3 Система Проверяет, что приобретен билет на этот рейс на имя этого Пассажира
4 Система Сохраняет информацию о регистрации Пассажира на рейс
5 Система Подтверждает Пассажиру, что он зарегистрирован на рейс
6 Система Выводит для печати посадочный талон
7 Пассажир Отправляет посадочный талон на печать
На самом деле большую часть реального полного 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 в системе, в отличие от наличия отдельных подсистем или функций, никак не отображающихся на пользовательском интерфейсе.

RP

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

Use Case для тестировщика

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

tst

Use Case для проектировщика интерфейсов

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

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

Use Case для разработчика

Разработчик гораздо лучше понимает ограничения, которые накладываются на реализацию той или иной функции, — требование это всегда ограничение, — когда он видит не отдельное «система должна…», а контекст использования той или иной функции. Какие фукции будут выполнены, прежде чем будет вызвана эта? В каком виде и почему будут введены данные? Можно ли менять этот реализованный класс или это отразится на согласованных сценариях работы пользователя с системой?

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

Use Case для технического писателя

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

tp

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: