Всем привет!
Сталкивались ли вы с тем, что открывая сайт или приложение приходилось долго и мучительно искать нужный раздел? Бывало ли так, что, работая с определенной программой, приходилось пройти несколько, на первый взгляд, избыточных шагов, прежде чем удавалось добиться своей цели?
Пользовательский путь закладывается на этапе работы с требованиями. И, помимо UX/UI, важным этапом проработки является формирование сценариев использования системы. Меня зовут Анастасия Солдатова, я техлид системной аналитики, автор тг-канала Sprint аналитика, и сегодня мы с вами по полочкам разберем, как сформировать действительно эффективный сценарий использования, чтобы пользователи искренне поблагодарили за проделанную работу.
Начнем с теоретической части и для начала определим, что же такое Сценарий использования.
Сценарий использования (Use Case, UC) - это подробное описание того, как пользователь взаимодействует с системой для достижения определенной цели. Формируется UC с точки зрения юзера и описывает все шаги, которые будут выполнены в рамках конкретного сценария.
Где и для чего используется Use Case
Use Case - универсальный инструмент, который может быть полезен, вне зависимости от отрасли применения ПО. Неважно, разрабатываете ли вы сайт для интернет-магазина, ПО для медработников или приложение для курьеров сервиса "Вкусный обед", сценарии использования помогут вам детализировать требования и пошагово описать, как действует пользователь в том или ином случае.
На уровне разработки продукта Use Case полезны как с точки зрения заказчика: с помощью сценариев можно отследить "узкие горлышки" в процессе, провести обучение пользователей и оценить эффективность по итогам разработки; так и с точки зрения команды разработки: UC помогают сформировать техническое задание для разработчиков, ложатся в основу тестовых сценариев и, самое главное, на их основе формируется подробная документация по продукту.
Как и любой другой инструмент, 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 диаграмма, вариантов использования). Она отлично помогает составить общую картину со всеми участниками процесса и вариантами использования. Чаще всего, используется для определения сценариев использования системы и выявления потенциальных проблем взаимодействия между пользователями и ПО.
После того как готова диаграмма прецедентов, на её основе можем приступить к формированию сценариев использования. Как и следует из названия, UC формируется в виде сценария. Обычно он состоит из нескольких частей:
ID и Название: Название Use Case, описывающее цель пользователя.
Основное действующее лицо: Актор, с точки зрения которого формируется Use Case.
Описание: Цель пользователя и контекст, в котором он будет использовать систему.
Основной поток: Описание основных шагов, которые пользователь должен выполнить для достижения цели.
Альтернативные потоки: Описание альтернативных сценариев, которые могут возникнуть во время выполнения Use Case.
Предусловия: Описание условий, которые должны быть выполнены, прежде чем пользователь сможет выполнить Use Case.
Постусловия: Описание условий, которые будут выполнены после того, как пользователь выполнит Use Case.
Дополнительно, в некоторые Use Case можно включать поле "Триггер" - описание события, которое приводит к началу нашего сценария. Например, в сценарии "Регистрация пользователя на сайте" триггером будет то, что пользователь нажимает на кнопку "Регистрация".
Чаще всего, для описания Use Case используются стандартные шаблоны, которые на разных проектах могут быть верхнеуровневыми или более подробными. Мы с вами рассмотрим формирование полей, без которых, скорее всего, не обойдется ни один сценарий.
Пример описания Use Case
Давайте посмотрим, как может выглядеть сценарий использования для задачи "Перевод денег между счетами пользователя".
ID и Название: UC1. Перевести деньги между счетами клиента
Основное действующее лицо: Клиент банка, имеющий несколько счетов и установленное мобильное приложение
Описание: Клиент банка через мобильное приложение хочет перевести деньги с одного своего счета на другой счет в том же банке.
Основной поток:
Клиент открывает мобильное приложение и авторизуется.
Клиент выбирает счет, с которого хочет перевести деньги.
Клиент выбирает счет, на который хочет перевести деньги.
Клиент вводит сумму перевода и подтверждает операцию.
Система проверяет наличие средств на счете и выполняет перевод.
Система отправляет подтверждение перевода на электронную почту клиента.
Альтернативные потоки:
Если на счете недостаточно средств, система предложит клиенту пополнить счет или отменить операцию.
Если клиент вводит неверные данные, система выдаст сообщение об ошибке и предложит повторно ввести данные.
Предусловия: Клиент должен быть авторизован в мобильном приложении и иметь доступ к обоим счетам.
Постусловия: Перевод денег выполнен, клиент получил подтверждение перевода на электронную почту, оба счета обновлены.
Итак, с теоретической частью разобрались. В следующей статье на более интересном и объемном примере подробно разберем на практике, как строить диаграмму прецедентов, какие правила не стоит забывать при формировании сценария использования, непосредственно сформируем сценарий и обсудим разницу между "хорошим" и "плохим" Use Case.
До встречи в следующих публикациях!
