Данная статья поможет молодым специалистам легко начать работу со сценариями использования.
Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.
Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой.
Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя.
Один сценарий использования имеет несколько потоков: основной и альтернативные.
Выделение сценариев
Один сценарий использования должен описывать действия пользователя, которые приведут к одному большому действию- функционалу пользователя. Например, авторизоваться, добавить товар в корзину и тд.
Если мы имеем большой сценарий использования, необходимо выделить из него те части, которые мы можем вынести в отдельный самостоятельный сценарий, но в предусловии указать условия начала инициации данного сценария.
Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”
Например, если нам необходимо описать авторизацию пользователя с вводом кода подтверждения, можно выделить отдельный сценарий “Ввод кода подтверждения”, чтобы не нагружать сценарий “Авторизация”. А уже в в сценарии “ввод кода подтверждения” подробно расписать условия ввода кода, повторной отправки, работу таймера повторной отправки, неверный код подтверждения, возможные ошибки.
Уровни описания и степени детализации
Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними — в деталях.
Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется деловыми актерами (людьми, или системами, внешними к бизнесу) для достижения своих целей. Деловой сценарий использования описывает процесс, ценный для клиента, описывает что именно делает процесс.
Системный сценарий использования обычно описывается на уровне функций системы и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает что актер может сделать взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования началась с глагола (например, создайте ваучер, выберите платежи, отмените ваучер)
Степень формализма выполняемого проекта и стадия, на которой он находится, прямо влияют на степень детальности и проработанности вариантов использования. Определяют следующие степени детальности при написании вариантов использования:
Краткий (brief) вариант использования состоит (помимо названия) из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.
Краткая степень детальности применяется при начале работы над проектом; когда еще не прорабатываются детали, а верхнеуровнего описываются сценарии использования. Также, краткую степень детализации допустимо использовать при сжатых сроках написания ТЗ для кейсов с низким уровнем риска.
Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.
Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов с высоким уровнем риска.
Структура сценария использования
Сценарии использования включают в себя следующие разделы:
Название. Краткое, максимально понятное. Описывающее общее действие пользователя.
Пример:
UC-1. Регистрация в личном кабинете
UC-2. Регистрация в программе лояльности
UC-3. Добавление товара в корзину
Предусловие. Формулировка условий, при которых данный вариант использования может быть инициирован. Условие, помимо прочего, может быть упоминанием о выполнении других вариантов использования. Также в предусловии необходимо указывать, в какой части системы находится пользователь, кратко- какие действия уже выполнил.
Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”.
Данное предусловие мы можем указать для описания кейса работы пользователя в “Корзине”. Если мы описываем кейс “Добавление товара в корзину” или “Оформление заказа”, где необходимо указать всю цепочку шагов пользователя- то данное предусловие не подойдет.
Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.
Альтернативные сценарии, в которых процесс развития событий на каком-либо шаге чем-либо заметно отличается от основного, то есть имеет место ветвление.
Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”
При описании сценария использования важно соблюдать пошаговый план действий пользователя, указывая физическое действие пользователя.
Например, формулировка “добавил товар в корзину” неверная.
Правильно: “нажимает на кнопку “Добавить товар в корзину” и далее- реакцию системы на действия пользователя.
Пользователь |
Система |
Какое физическое действие произвел пользователь? |
Как отреагировала система? |
Нажимает “Добавить в корзину” |
Система добавляет выбранный товар в корзину. В иконке “Корзина” система выводит маркер- кол-во добавленного товара в корзину. Изменяет кнопку “Добавить в корзину” у выбранного товара на кнопку “Перейти в корзину” |
Пользователь нажимает “перейти в корзину” |
Система переводит пользователя в корзину, где отображается добавленный товар. |
Альтернативные сценарии
При проработке основного сценария, все варианты действий пользователя и поведения системы, отличных от основного сценария необходимо выносить в альтернативный сценарий. То есть, везде, где можно указать “если”- это и будет альтернативный сценарий.
Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария.
Рассмотрим на примере авторизации
Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации
Пользователь |
Система |
Какое физическое действие произвел пользователь? |
Как отреагировала система? |
Пользователь нажал кнопку “Зарегистрироваться” |
Система вывела форму регистрации, поле “email” |
Пользователь вводит данные в поле “email” |
3. Система производит проверку введенных данных на валидацию. Данные проходят по условиям валидации Если данные не прошли проверку валидации, запускается альтернативный сценарий №1. |
Система производит поиск введенных данных “email” по учетным записям в системе. Учетных записей с такими данными “email” не найдено.
Если в системе найдена учетная запись с таким логином, запускается альтернативный сценарий №2 |
|
Система отправляет пользователю код подтверждения на email Система выводит пользователю поле “код подтверждения” Сценарий “ввод кода подтверждения” вынесен в отдельный сценарий. - обязательно указываем, если какой-либо функционал выносим в отдельный кейс, более подробный. |
|
Пользователь вводит корректный код подтверждения в поле “код подтверждения” |
Система производит проверку кода подтверждения. Код введен верно. Пользователь зарегистрирован. Альтернативный сценарий с неверным кодом подтверждения выносим в сценарий “Ввод кода подтверждения” |
Пример альтернативного сценария
Альтернативный сценарий №1
На шаге №3 успешного сценария, введенные данные не прошли проверку валидации.
Система выводит информер с указанием запрещенных символов.
Пользователь вводит корректные данные в поле “email”.
Далее сценарий продолжается от шага №3 успешного сценария.
Сценарии использования являются важным и частым артефактом работы системных аналитиков. И я надеюсь, что данная статья немного облегчит жизнь молодой крови, только вступившей на долгий и тернистый путь системного анализа
Комментарии (11)
tas
16.11.2022 11:01+1Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс
Зачем плодить понятия? Если есть бизнес-процесс, то пусть он им и останется - в этом случае будет описание бизнес-процесса.
Системный сценарий использования описывает что актер может сделать взаимодействуя с системой.
Я бы и это тоже делал через бизнес-процессы. А вот системные сценарии пишутся для проверки требований. Это позволит во первых проверить систему на соответствие ТЗ, а во вторых - получить готовый материал для ПМИ.
AnastasiaKu Автор
16.11.2022 14:10Я думаю, здесь можно применять как описание БП, так и использовать UC. Здесь на усмотрение аналитика, который работает над документацией. Я же просто привела примеры, как можно использовать UC.
AnastasiaKu Автор
17.11.2022 13:13В данной статье я рассматривала только один артефакт- UC. Я не вела в данной статье сравнение UC и бизнес-процесса, рассуждений, когда какой артефакт лучше использовать. Эта тема достойна отдельной статьи. Поэтому не до конца понимаю вашей претензии.
AnastasiaKu Автор
16.11.2022 14:17+1Согласна, что есть правило, что сценарий использования (основной и альтернативные) должен позволять достичь цели, а ошибки - выносить в ограничения/допущения/риски. Но по опыту работы в команде, и тестировщикам и разработчикам легче ориентироваться в ТЗ, когда в основном сценарии также отработаны альтернативные сценарии с ошибками. Это мое личное наблюдение.
Считаю, что аналитикам необходимо придерживаться правил и методологий, но всегда адаптировать свое ТЗ под команду и проект. Потому что в первую очередь- ТЗ должно быть легким к прочтению и понимаю для команды.
egoorova99
18.11.2022 05:29Я часто вижу, что дополнительным пунктом выносятся ошибки и исключения, в которых описываются действия, которые приводят к невыполнению сценария. Т.е. отличие от альтернативных сценариев в том, что альтернативные сценарии позволяют достичь поставленной цели, ошибки и исключения - нет.
В данном кейсе в ошибки и исключения можно вынести сценарий, когда пытается зарегистрироваться уже зарегистрированный в системе пользователь (у вас это альтернативный сценарий №2)
NikMelnikov
При описании сценария использования важно соблюдать пошаговый план действий пользователя, указывая физическое действие пользователя.
Например, формулировка “добавил товар в корзину” неверная.
Правильно: “нажимает на кнопку “Добавить товар в корзину” и далее- реакцию системы на действия пользователя.
Почему второй вариант правильный? Кнопка - это уже конкретная реализация сценария. Или был UC с другим уровнем абстракции, где спроектировали, что будет кнопка?
AnastasiaKu Автор
В данном примере я хотела показать насколько детально необходимо описывать UC. Конечно, данный UC возможно описать либо при наличии макетов, либо при взаимной работе с дизайнером.
Я хотела сделать акцент именно на описание детальности шагов пользователя. Потому что формулировка "Добавил товар в корзину" - не объясняет, каким образом пользователь добавил товар в корзину
ValeryGL
Анастасия, в качестве примера Вы использовали один из антипаттернов :((
Описывая в юзкейсе конкретную реализацию, мы сильно ограничиваем разработчиков в том, что они могли бы предложить лучшее решение (да и вообще, приносить решение в то время, когда выявляются и описываются требования - это тоже антипаттерн)
А вообще статья интересная, очень понравилась структурированность; объяснять вещи с нуля - это супер
AnastasiaKu Автор
Спасибо за комментарий! Мое главное правило в работе- коммуникация. И при написании ТЗ я всегда обращаюсь к команде разработки- для обсуждения и выбора подходящего решения. На основании этого- в ТЗ можно зафиксировать требования именно так, как необходимо их реализовывать. Видимо, это нужно было отметить в данной статье!
Конечно же, если нет возможности обсудить с разработчиками верность решения (и реализация не однозначна), то, действительно, не стоит ограничивать разработчиков в решении.
ValeryGL
Я второй раз намекаю, что на этапе требований нужно работать с требованиями. А когда их проясните и зафиксирутете - работайте с решениями.
Иначе
выбранный молоток заставит везде видеть гвоздивыбранное решение будет ограничивать выбор и повлияет даже на требования