Данная статья поможет молодым специалистам легко начать работу со сценариями использования.
Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.
Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой.
Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя.
Один сценарий использования имеет несколько потоков: основной и альтернативные.
Выделение сценариев
Один сценарий использования должен описывать действия пользователя, которые приведут к одному большому действию- функционалу пользователя. Например, авторизоваться, добавить товар в корзину и тд.
Если мы имеем большой сценарий использования, необходимо выделить из него те части, которые мы можем вынести в отдельный самостоятельный сценарий, но в предусловии указать условия начала инициации данного сценария.
Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”
Например, если нам необходимо описать авторизацию пользователя с вводом кода подтверждения, можно выделить отдельный сценарий “Ввод кода подтверждения”, чтобы не нагружать сценарий “Авторизация”. А уже в в сценарии “ввод кода подтверждения” подробно расписать условия ввода кода, повторной отправки, работу таймера повторной отправки, неверный код подтверждения, возможные ошибки.
Уровни описания и степени детализации
Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними — в деталях.
Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется деловыми актерами (людьми, или системами, внешними к бизнесу) для достижения своих целей. Деловой сценарий использования описывает процесс, ценный для клиента, описывает что именно делает процесс.
Системный сценарий использования обычно описывается на уровне функций системы и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает что актер может сделать взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования началась с глагола (например, создайте ваучер, выберите платежи, отмените ваучер)
Степень формализма выполняемого проекта и стадия, на которой он находится, прямо влияют на степень детальности и проработанности вариантов использования. Определяют следующие степени детальности при написании вариантов использования:
Краткий (brief) вариант использования состоит (помимо названия) из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.
Краткая степень детальности применяется при начале работы над проектом; когда еще не прорабатываются детали, а верхнеуровнего описываются сценарии использования. Также, краткую степень детализации допустимо использовать при сжатых сроках написания ТЗ для кейсов с низким уровнем риска.
Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.
Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов с высоким уровнем риска.
Структура сценария использования
Сценарии использования включают в себя следующие разделы:
Название. Краткое, максимально понятное. Описывающее общее действие пользователя.
Пример:
UC-1. Регистрация в личном кабинете
UC-2. Регистрация в программе лояльности
UC-3. Добавление товара в корзину
Предусловие. Формулировка условий, при которых данный вариант использования может быть инициирован. Условие, помимо прочего, может быть упоминанием о выполнении других вариантов использования. Также в предусловии необходимо указывать, в какой части системы находится пользователь, кратко- какие действия уже выполнил.
Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”.
Данное предусловие мы можем указать для описания кейса работы пользователя в “Корзине”. Если мы описываем кейс “Добавление товара в корзину” или “Оформление заказа”, где необходимо указать всю цепочку шагов пользователя- то данное предусловие не подойдет.
Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.
Альтернативные сценарии, в которых процесс развития событий на каком-либо шаге чем-либо заметно отличается от основного, то есть имеет место ветвление.
Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”
При описании сценария использования важно соблюдать пошаговый план действий пользователя, указывая физическое действие пользователя.
Например, формулировка “добавил товар в корзину” неверная.
Правильно: “нажимает на кнопку “Добавить товар в корзину” и далее- реакцию системы на действия пользователя.
Пользователь | Система |
Какое физическое действие произвел пользователь? | Как отреагировала система? |
Нажимает “Добавить в корзину” | Система добавляет выбранный товар в корзину. В иконке “Корзина” система выводит маркер- кол-во добавленного товара в корзину. Изменяет кнопку “Добавить в корзину” у выбранного товара на кнопку “Перейти в корзину” |
Пользователь нажимает “перейти в корзину” | Система переводит пользователя в корзину, где отображается добавленный товар. |
Альтернативные сценарии
При проработке основного сценария, все варианты действий пользователя и поведения системы, отличных от основного сценария необходимо выносить в альтернативный сценарий. То есть, везде, где можно указать “если”- это и будет альтернативный сценарий.
Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария.
Рассмотрим на примере авторизации
Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации
Пользователь | Система |
Какое физическое действие произвел пользователь? | Как отреагировала система? |
Пользователь нажал кнопку “Зарегистрироваться” | Система вывела форму регистрации, поле “email” |
Пользователь вводит данные в поле “email” | 3. Система производит проверку введенных данных на валидацию. Данные проходят по условиям валидации Если данные не прошли проверку валидации, запускается альтернативный сценарий №1. |
Система производит поиск введенных данных “email” по учетным записям в системе. Учетных записей с такими данными “email” не найдено.
Если в системе найдена учетная запись с таким логином, запускается альтернативный сценарий №2 | |
Система отправляет пользователю код подтверждения на email Система выводит пользователю поле “код подтверждения” Сценарий “ввод кода подтверждения” вынесен в отдельный сценарий. - обязательно указываем, если какой-либо функционал выносим в отдельный кейс, более подробный. | |
Пользователь вводит корректный код подтверждения в поле “код подтверждения” | Система производит проверку кода подтверждения. Код введен верно. Пользователь зарегистрирован. Альтернативный сценарий с неверным кодом подтверждения выносим в сценарий “Ввод кода подтверждения” |
Пример альтернативного сценария
Альтернативный сценарий №1
На шаге №3 успешного сценария, введенные данные не прошли проверку валидации.
Система выводит информер с указанием запрещенных символов.
Пользователь вводит корректные данные в поле “email”.
Далее сценарий продолжается от шага №3 успешного сценария.
Сценарии использования являются важным и частым артефактом работы системных аналитиков. И я надеюсь, что данная статья немного облегчит жизнь молодой крови, только вступившей на долгий и тернистый путь системного анализа
