Сценарии использования информационной системы

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой.

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

Один сценарий использования имеет несколько потоков: основной и альтернативные.

Выделение сценариев

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

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

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

Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется деловыми актерами (людьми, или системами, внешними к бизнесу) для достижения своих целей. Деловой сценарий использования описывает процесс, ценный для клиента, описывает что именно делает процесс.
Системный сценарий использования обычно описывается на уровне функций системы и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает что актер может сделать взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования началась с глагола (например, создайте ваучер, выберите платежи, отмените ваучер)

Степень формализма выполняемого проекта и стадия, на которой он находится, прямо влияют на степень детальности и проработанности вариантов использования. Определяют следующие степени детальности при написании вариантов использования:

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

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

Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

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

Структура сценария использования

Сценарии использования включают в себя следующие разделы:

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

Пример:

UC-1. Регистрация в личном кабинете

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”.

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

Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.
Альтернативные сценарии, в которых процесс развития событий на каком-либо шаге чем-либо заметно отличается от основного, то есть имеет место ветвление.

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка “добавил товар в корзину” неверная.

Правильно: “нажимает на кнопку “Добавить товар в корзину” и далее- реакцию системы на действия пользователя.

Пользователь	Система
Какое физическое действие произвел пользователь?	Как отреагировала система?
Нажимает “Добавить в корзину”	Система добавляет выбранный товар в корзину. В иконке “Корзина” система выводит маркер- кол-во добавленного товара в корзину. Изменяет кнопку “Добавить в корзину” у выбранного товара на кнопку “Перейти в корзину”
Пользователь нажимает “перейти в корзину”	Система переводит пользователя в корзину, где отображается добавленный товар.

Альтернативные сценарии

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария.

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пользователь	Система
Какое физическое действие произвел пользователь?	Как отреагировала система?
Пользователь нажал кнопку “Зарегистрироваться”	Система вывела форму регистрации, поле “email”
Пользователь вводит данные в поле “email”	3. Система производит проверку введенных данных на валидацию. Данные проходят по условиям валидации Если данные не прошли проверку валидации, запускается альтернативный сценарий №1.
	Система производит поиск введенных данных “email” по учетным записям в системе. Учетных записей с такими данными “email” не найдено. Если в системе найдена учетная запись с таким логином, запускается альтернативный сценарий №2
	Система отправляет пользователю код подтверждения на email Система выводит пользователю поле “код подтверждения” Сценарий “ввод кода подтверждения” вынесен в отдельный сценарий. — обязательно указываем, если какой-либо функционал выносим в отдельный кейс, более подробный.
Пользователь вводит корректный код подтверждения в поле “код подтверждения”	Система производит проверку кода подтверждения. Код введен верно. Пользователь зарегистрирован. Альтернативный сценарий с неверным кодом подтверждения выносим в сценарий “Ввод кода подтверждения”

Пример альтернативного сценария

Альтернативный сценарий №1

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации.

Система выводит информер с указанием запрещенных символов.
Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

Источник

В прошлый раз мы выяснили ограничения применимости спецификации требований. Сегодня поговорим об альтернативе — модели сценариев использования.

Что такое сценарии использования

Сценарий использования – описание поведения системы в процессе выполнения ею определённой операции. Под операцией часто понимают выполнение системой команды или запроса пользователя, но ограничиваться только взаимодействия системы с пользователями было бы крайне неверно.

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

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

Превращение пользовательских историй в сценарии

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

Но при переходе от историй к сценариям использования нам нужно выполнить переход от прототипа к реальной системе, и описываемые сценарии использования должны быть реализованы в реальном железе и программном коде.
Много ли вы видели концепт-каров, воплощённых затем в реальный автомобиль? Часто новый автомобиль отличается от исходного концепта так сильно, что проследить связь не всегда удаётся. Ниже приведён один из таких примеров от лидеров автопрома – концерна Toyota. Вот уж кто денег на ветер не бросает и точно знает, что делает. Но разница видна сразу.

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

С чего начать?

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

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

Базовая история

При рассмотрении каждой функциональности следует сначала найти так называемую базовую историю. Как правило, она позволяет достичь результата самым оптимальным способом. «Оптимальность» тут следует понимать в контексте потребностей пользователей и бизнеса. В одном случае оптимальность будет связана со скоростью выполнения операции, в другом – с точностью получаемого результата, в третьем – с требуемыми ресурсами и т.д.

Последовательность действий системы (алгоритм выполнения операции), описанная в базовой истории, называют базовым путём выполнения данной операции.

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

Фильтрация историй

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

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

Переход к вариантам использования

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

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

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

Чаще цветовое кодирование используется при сопровождении модели, когда удалённые сценарии помечаются одним цветом, новые – другим, а изменённые – третьим. Также и в описании сценария новые, изменённые и удалённые формулировки помечаются теми же цветами.

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

Единичность — сценарий описывает один и только один вариант поведения системы.

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

Непротиворечивость — сценарий не противоречит другим сценариям.

Связность (последовательность) – сценарий дополняет другие сценарии и составляет с ними единую картину будущей системы.

Атомарность — сценарий нельзя разделить на более мелкие сценарии без потери конкретного полезного результата.

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

Актуальность — сценарий не стал устаревшим с течением времени.

Реализуемость — сценарий может быть реализован в рамках проекта.

Недвусмысленность — сценарий выражает действия и факты (вехи), а не субъективные мнения; не содержит жаргонизмов или терминов, понятных только некоторым из участников проекта; возможна одна и только одна его интерпретация.

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

Проверяемость — полнота реализации сценария может быть проверена на каждом шаге сценария.

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

условия доступа к вызову сценария (кто/что имеет право вызвать сценарий);

значения показателей качества, предъявляемые к исходным данным, и условия выполнения сценария;

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

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

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

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

Модель сценариев использования – очень гибкий инструмент анализа и проектирования. Из-за этого эту модель предпочтительнее применять при использовании гибких методологий, при больших объёмах требований или в командах с большим количеством взаимодействий.

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

Отдельно нужно упомянуть о важнейшей роли сценариев при проектировании, реализации и тестировании разрабатываемой системы. Достаточно указать, что сценарии лежат в центре представления архитектуры Филиппа Крачтена («модель 4+1»).

P.S. В довесок ссылка на статью Александра Шамрая «Советы для написания хороших сценариев использования». Однако следует иметь в виду, что в этой статье речь идёт о сценариях взаимодействия пользователя с системой, несколько подменяя определение сценария, введённое в стандарте UML, и при этом искажая суть сценария. Однако, если иметь в виду этот момент, то остальное описание будет весьма полезным.

Источник

Без технической душноты исследуем сценарии «пользователь <—> система». Для продактов, дизайнеров и аналитиков — оставили готовый шаблон

Всем привет! Я Ната, UX/UI дизайнер в Red Collar. В этой статье я расскажу о методологии, которая улучшит коммуникацию внутри команды, а значит и работу над продуктом — Use Case или «юзкейсе», а также поделюсь шаблоном для тех, кто сталкивается с ней впервые.

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

Польза юзкейсов — единое представление о продукте

Если в команде более 5 человек, а проект длится более 3 месяцев, то может возникнуть дискоммуникация. Например:

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

Сценарии юзкейсов — как игра в теннис между пользователем и системой

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

Методология была разработана в 80-х Иваром Якобсоном. Для всех желающих погрузиться в тему глубже есть бесплатная книга Use-Case 2.0, также другие ссылки по теме оставлю внизу статьи.

Для наглядности юзкейс можно сравнить с игрой в теннис, где один игрок это пользователь, другой — система. Удар ракеткой это действие, которое совершает пользователь, после чего мяч переходит системе, и далее система ему отвечает. Разница только в том, что в юзкейсе пользователь или система могут подряд совершить несколько действий.

Юзкейсы существуют в двух равнозначных видах: UML-диаграмма или текстовый документ. По желанию их можно совмещать

«Основной юзкейс» — сценарий успеха: участники + действия + результат + доп. условия

Единого формата для написания юзкейсов не существует. Каждая компания сама определяет для себя формат и уровень детализации. Опишу основной принцип написания.

Основные элементы юзкейса:

1. Понятный заголовок, желательно, чтобы он содержал результат юзкейса. Пример, «Создание заявки».

2. Действующие лица или участники. Можно выделить такие варианты:

«Пользователь и система». Например, при авторизации.
«Несколько пользователей и система». Например, если мы описываем общение в чате.
«Система и система». Например, если мы описываем внутренние процессы внутри системы.
«Несколько систем и система».

3. Описание последовательности действий в виде сценария.

4. Результат, то есть то, к чему должны прийти пользователь или система.

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

Пример простого юзкейса

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

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

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

Пример развернутого юзкейса с пояснениями

«Альтернативный юзкейс» — сценарий ошибки

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

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

Пример юзкейса с альтернативными сценариями внутри основного

Чеклист для написания юзкейсов

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

Вначале сделайте единый шаблон и заведите словарь

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

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

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

Советы, которые ускорят написание юзкейсов:

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

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

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

Всем крутых продуктов!

Ната Нефедьева

Шаблон юзкейса + дополнительные материалы

Подготовила для вас шаблон юзкейса, открыт всем в гуглдоке.

1. Статьи и бесплатные книги о юзкейсах от создателя методологии Ивара Якобсона — даст более полное представление об инструменте «из первых рук» (en)

2. Короткое видео с простым объяснением инструмента от бизнес-аналитика + ссылка в описании к видео на их шаблон юзкейсов (en)

3. Короткое видео о юзкейсах для новичков от UX/UI дизайнер в Siemens (ru)

4. Статья от Usability.gov с краткой информации о юзкейсах и примером их заполнения (en)

5. Статья от системного аналитика, где подробно рассказывается о методологии и опыте ее применения в QIWI (ru)

Источник

Анна Вичугова | Анна Гасраталиева

Алгоритм описания функциональных требований к системе в формате Use Case

Существуют разные формы представления функциональных требований: пользовательская история (user story), каноническая форма с привязкой к CRUDL-операциям и модели данных (классический формат описания требований), а также описание сценариев использования (Use Case).

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

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

В связке с понятием варианта использования идёт термин Use case scenario, который переводится как сценарий варианта использования или пользовательский сценарий.

Технически, разница есть, то есть Use case это не тоже самое, что Use case scenario. Например, «Купить Товар» — Use case, и у него есть Use case scenario (пошаговое описание того, как именно купить товар: 1. Выбрать товар, 2. Добавить в корзину, 3. Оплатить).

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

В этой статье мы будем придерживаться термина UC, иногда заменяя его на другие, чтобы упростить восприятие статьи читателем.

Итак, Use case (UC) — это популярная форма представления функциональных требований к ПО в виде пошагового сценария взаимодействия актора (пользователя или внешнего сервиса) с проектируемой системой, включая описание метаданных этого взаимодействия: области применения, предусловия, триггеры, постусловия, релевантные бизнес-правила и пр.

Давайте рассмотрим на примере, как описать UC и избежать ошибок в работе с этим методом.

Алгоритм описания функциональных требований к системе

Типовую последовательность разработки функциональных требований в форме UC можно представить следующим образом:

Определить Акторов — тех, кто взаимодействует с системой
Выявить и составить список UC — задач, которые стейкхолдеры смогут решить с помощью системы
Для каждого юскейса определить приоритет — важность UC по отношению к другим вариантам использования
Для каждого важного юскейса определить контекст применения, конечную цель и результат
Описать основной поток каждого UC с высоким приоритетом в виде последовательности шагов, которая приведёт к достижению его цели — пользовательского сценария (use case scenario)
Дополнить основной поток расширениями, исключениями и циклами
Собрать воедино результаты шагов 4−6, детально описав каждый юскейс с высоким приоритетом как алгоритм взаимодействия пользователя с системой

Теперь давайте рассмотрим каждый шаг поподробнее.

1. Определить акторов, которые взаимодействуют с системой

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

Например, если рассматривать мобильный телефон как систему, то актором будет человек — пользователь мобильного телефона. Результат этого шага можно оформить в виде таблицы или диаграммы ролей.

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

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

Рекомендуем называть UC в формате «Инфинитив + Объект», где «Инфинитив» — это инфинитив глагол в совершенного вида с большой буквы, а «Объект» — это существительное, обозначающее объект управления с большой буквы.

Из названия вариант использования должно быть сразу понятно, какую именно задачу пользователя он решает. Например, «Подписать Документ», «Оформить Заказ», «Оплатить Товар», «Сделать Звонок» и так далее.

Для повышения наглядности можно сделать это в табличном виде или UML-диаграммы вариантов использования (она же Use case diagram, диаграмма прецедентов).

Обычно для продуктов и проектов в сфере B2C исходные данные для этого извлекаются из изучения интересов, потребностей и пользовательского опыта людей (клиентов, экспертов предметной области) и конкурентного анализа, а также CJM-карты.

Для B2B-продуктов и проектов исходными данными для юскейсов, как правило, являются отраслевые и корпоративные регламенты, описание бизнес-процессов и запросы стейкхолдеров.

Давайте сформируем реестр юскейсов. Например, ранее для пользователя мобильного телефона мы определи функциональные возможности «Сделать звоноки» и «Отправить СМС». Они реализуют единую пользовательскую потребность: «Связаться с другим человеком», поэтому их можно объединить в один юскейс.

Юскейсы «Поиграть в казуальную Игру» и «Посмотреть фотографии» относятся к потребности «Скоротать время».

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

3. Для каждого UC определить его приоритет

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

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

Самым простым методом приоритизации, который часто применяется на практике, считается метод MoSCoW. Он получил своё название не в честь российской столицы, а как сокращение следующих 4 категорий:

Must — то, что необходимо сделать в любом случае. Считается, что без реализации этих требований решение не будет работать или при отсутствии этих фич продукт не будет нужен потребителям. Чаще всего этот приоритет называется 1-я очередь и обозначается цифрой 1
Should — требования 2-ой очереди, которые должны быть реализованы после тех, что отнесены к группе Must. Это приоритет номер 2
Could — желательные требования, которые можно сделать, если останется время и будут ресурсы. Это приоритет номер 3
Would — требования, которые хотелось бы реализовать, но пока их можно проигнорировать или перенести на следующие итерации без вреда для продукта. Это приоритет номер 4

В нашем примере с мобильным телефоном приоритизировать юскейсы можно так, как показано в таблице 2.

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

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

4. Для каждого высокоприоритетного (Must или Should) UC определить контекст применения, конечную цель и результат

Это можно оформить в виде списка или таблицы, например в Notion:

5. Раскрыть содержание основного потока каждого юскейса высокого приоритета в виде пользовательского сценария

Напомним, что пользовательский сценарий — это последовательность шагов, которая приведёт к достижению конечной цели юскейса, получению нужного актору результата.

Основную часть пользовательского сценария составляет так называемый happy path (основной поток), который представляет собой пошаговый алгоритм выполнения сценария без логических операторов XOR (исключающее или), используемых для ветвления потока управления в результате проверки каких-либо условий.

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

1. Пользователь даёт команду совершить звонок
2. Система запрашивает номер телефона вызываемого абонента
3. Пользователь сообщает номер абонента
4. Система убеждается в корректности указанного номера телефона
5. Система вызывает абонента с указанным номером телефона
6. Система убеждается, что звонок начался
7. Система передаёт голос собеседников в ходе разговора

Для наглядности можно нарисовать эту линейную последовательность шагов в виде простого процесса в нотациях EPC, BPMN (рис.1), UML activity или sequence, а также блок-схемы алгоритма по ГОСТ 19.701−90.

Последовательность шагов в виде BPMN-диаграммы

На практике подавляющая часть сценариев описывается только текстовым описанием. Пример такого описания мы разберём с вами ниже.

6. Дополнить линейную последовательность основного потока в описании UC расширениями, исключениями и циклами

На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.

Вместо BPMN для отображения логики сценария нашего юскейса можно использовать любую другую нотацию (EPC, UML activity diagram, IDEF3 или даже простого текстового алгоритма).

Расширенная BPMN-диаграмма юскейса с исключениями и альтернативными потоками

7. Собрать воедино результаты выполнения трёх предыдущих шагов, детально описав каждый UC как алгоритм взаимодействия пользователя с системой

На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:

Имя
Приоритет
Область действия
Контекст
Актор
Цель
Предусловия
Результат (постусловие)
Основной поток
Расширения или альтернативные потоки
Бизнес-правила

Давайте разберем каждый элемент этой структуры поподробнее.

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

Пример 1. UC «Сделать Звонок»

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

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

Как структурировать UC из набора
исходных ФТ

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

Если у клиента есть промо-код на скидку по конкретному курсу, сумма в договоре будет снижена на размер скидки.

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

FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору
FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность удалить курсы из договора
FRQ4 Система должна предоставить пользователю с ролью «Клиент» оплатить сумму по заключенному договору через шлюз онлайн-оплаты
FRQ5 Система должна предоставить пользователю с ролью «Клиент» снизить сумму по заключенному договору с применением промо-кода на скидку

Формируем описание в формате UC, применяя алгоритм:

Шаг 1. Определяем акторов. Судя по требованиям, с системой взаимодействует клиент и шлюз оплаты.

Шаг 2. Сформируем реестр юскейсов. Для этого мы можем, например, представить имеющийся набор функциональных требований в виде UML-диаграммы вариантов использования (UML Use case diagram).

Исходная UML-диаграмма use case

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

Упрощённая UML-диаграмма use case

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

При формировании реестра юскейсов для пользователя мобильного телефона мы можем выделить такие функциональные возможности как «Сделать Звонок» и «Отправить СМС». Оба этих юскейса отражают непосредственное взаимодействие актора с системой, направленное на достижение определённой бизнес-цели, это системный юскейс.

Функциональные возможности «Сделать звонок» и «Отправить СМС» относятся к одной потребности пользователя «связаться с другим человеком», которая будет состоять из двух системных юскейсов: «Позвонить Человеку» и «Отправить СМС». Показать эту трассировку (связь) можно с помощью реестра вариантов использования.

Реестр вариантов использования:

Шаг 3. Определить приоритеты системных юскейсов

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

Шаги 4−7. Эти шаги (описать основной поток и расширения для каждого из приоритетных юскейсов) мы представим в виде примера описания одного из юскейсов (UC «Оплатить Договор», см. ниже). По аналогии будет описан и UC «Заключить Договор».

Пример 2. UC «Оплатить Договор»

Для нашего примера вариант использования «Оплатить Договор» может выглядеть так:

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

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

Рассмотренная табличная форма описания UC является не единственной возможной. Бывают ещё и другие форматы, например, таблица в две колонки, юскейс в стиле RUP и так далее.

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

Пример 3. UC «Обновить Анкету»

Достоинства и недостатки UC как формы представления требований

Основными преимуществами UC являются следующие:

Нисходящая и восходящая трассировка (от системного уровня к бизнесу) улучшает понятность требований для Заказчика и команды реализации: UC несёт конечную бизнес-ценность, детально описывает структуры данных и бизнес-логику их обработки, позволяет убедиться в реализации
Вариант использования можно использовать как единицу поставки при планировании, реализации, тестировании и приёмке работ;
Набор связанных друг с другом вариантов использования позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей
Детальный шаблон представления UC позволяет полностью описать взаимодействие актора с системой, включая контекст, предшествующие, сопутствующие и результирующие события, а также ссылки к бизнес-правилам и нефункциональным требованиям (ограничения и некоторые атрибуты качества)
UC — отличная база для формирования тестовых сценариев (test cases) для проверки того, работает ли реализованная система как ожидалось

Обратной стороной этих достоинств являются следующие недостатки:

Плохо подходят для документирования требований, основанных не на взаимодействии с системой, а на выполнении расчётов и преобразованиях уже имеющихся в системе данных. Например, построение графиков и отчётов, вычисления, описание математических алгоритмов
Субъективность: качество изложения как самого UC, так и их реестра (ширина, глубина детализации уровней абстракции) зависит от навыков аналитика
На детальную проработку каждого UC уходит много времени. Например, у меня это занимает в среднем от 30 минут; добиться существенного повышения скорости работы можно за счёт повторного использования типовых юскейсов (опытный аналитик или отдел могут создать библиотеку своих юскейсов)
Проектирование системы только по UC исключает другие потенциально ценные методики документирования и анализа требований, такие как каноническая форма представления функциональных требований с привязкой с CRUD-операциям или популярная в Agile-проектах форма User Story по INVEST с критериям приёмки (Acceptance Criteria)

Откуда взялся такой формат как Use Case

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

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

FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору

В 1986 году Ивар Якобсон (шведский учёный, который вместе с Гради Бучем и Джеймсом Рамбо стоял у истоков ООП и UML) предложил альтернативную форму представления функциональных возможностей системы. Вместо описания функциональных требований к системе в виде отдельных функций Якобсон предложил объединить их по контексту, а затем превратить в набор вариантов использования (ВИ), который будет обеспечивать полноту и неизбыточность требований.

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

В 2001 году Алистер Коберн, эксперт в разработке ПО, расширил и уточнил идеи Якобсона, выпустив книгу «Современные методы описания функциональных требований к системам» (Writing Effective Use Cases). Книга получилась достаточно подробной, содержащей множество примеров. Помимо техник описания самих UC, работа Коберна включает также связанные вопросы о контексте, границах и основных компонентах проектируемой системы, то есть так называемый scope системы.

Эти и другие аспекты работы с требованиями были изложены в книге ещё одного автора, широко известного в системном и бизнес-анализе. В 2003 году Карл Вигерс (Karl Wiegers) написал 2-е издание своей книги «Разработка требований к программному обеспечению» (Software Requirements), где рассмотрены не только техники разработки требований, но и вопросы управления ими, включая сбор, документирование, трассировку, работу с изменениями и анализ рисков. Эта книга почти вдвое объёмнее труда Коберна и больше подходит для начинающих аналитиков.

UC рассматривает проектируемое ПО как «чёрный ящик», описывая взаимодействие с системой с точки зрения внешнего наблюдателя: ЧТО система должна сделать, чтобы актор достиг своей цели, а НЕ КАК это должно быть сделано.

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

Несмотря на повсеместное распространение гибких методологий разработки ПО, UC как подход к описанию функциональных требований очень активно применяется на практике. В отличие от пользовательских историй (User Story), другой популярной формы представления требований, UC охотно принимают в реализацию — в основном благодаря структурированному формату и детальной проработке бизнес-логики с привязкой к модели данных.

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

В завершение статьи хотелось бы напомнить: если ваш юскейс решает проблемы разработки ПО, то есть создаёт общее понимание требований у заказчика и всей проектной команды, то вы написали хороший юскейс. Следование формату само по себе не самоценно.

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

Анна Вичугова

Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
Сертифицированный бизнес-аналитик (CBAP 2020, международная сертификация IIBA)
Сертифицированный специалист Business Studio (2010, 2012, 2013, 2018)
Сертифицированный специалист и администратор СЭД Directum (2011

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19.***, 34.***, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

Анна Гасраталиева

Системный аналитик, выпускающий редактор Systems. Education

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

Источник

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

Что такое Use Case

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

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

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

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

В каких ситуациях может помочь Use Case

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

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

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

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

Качественно составленный Use Case может решать разные задачи. Например:

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

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

Из каких элементов состоит Use Case

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

Actor — человек, который пользуется созданной системой. В качестве примера можно привести какой-нибудь интернет-магазин, где в качестве actor выступают продавцы, покупатели, поставщики и все те, кто взаимодействует с этим интернет-магазином.
Primary actor — это человек, у которого получается достигнуть поставленных целей с помощью созданного программного продукта. Если вернуться к тому же интернет-магазину, то primary actor в нем может быть производитель вещей, у которого получается реализовывать эти вещи с помощью функционала онлайн-площадки.
Stakeholder — человек, который заинтересован в том, чтобы созданы ПП выполнял те или иные действия. В интернет-магазине это может быть какой-нибудь партнер, получающий доход от приведенных покупателей, или подключенная к магазину платежная платформа, через которую совершаются онлайн-платежи.

Также к элементам юзеркейса относятся:

Овнеры магазинов ФБ акков про свой бизнес и тренды в арбитраже. ФБ аккаунты для арбитража трафика

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

А еще в любом Use Case должны быть прописаны альтернативные пути — события, к которым прибегают в том случае, если кейс не сработал.

Какими должен качественный быть Use Case

Высокое качество юзеркейса определяют следующие критерии:

Правильная детализация. При составлении Use Case нет смысла описывать каждый шаг пользователей и состояние элементов ПП в этот момент. Главная задача юзеркейса — всего лишь дать общую картину.
Простота изложения. Чтобы содержимое юзеркейса было понятным даже новым членам команды, его необходимо писать максимально простым языком. Не стоит использовать для Use Case сложные термины и вставки кода.
Единый стиль. Старайтесь использовать для всех юзеркейсов один и тот же шаблон. Это поможет сэкономить время на изучении ПП.

Важен контекст. В каждом юзеркейсе должны быть уточнения по поводу тех или иных действий. Так разработчики смогут разобраться в том, какая задача перед ними стоит.
Целенаправленность. Не стоит использовать юзеркейса для того, чтобы описать весь путь пользователя. Лучше представить конкретные шаги (регистрация, покупка, отправка заявки и так далее).

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

Какую пользу несет Use Case для определенных специалистов в команде

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

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

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

Как составить Use Case

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

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

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

Есть пара советов, которые помогут в составлении юзеркейсов. Во-первых, для экономии времени следует разработать шаблон. Такой подход позволит выработать единый стиль и экономить время при разработке других кейсов.

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

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

Пример 1: регистрация на сайте

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

Номер шага	Действующее лицо	Действие
1	Пользователь	Пользователь нажимает на кнопку регистрации
2	Система	Открывает форма регистрации
3	Пользователь	Пользователь заполняет форма, указывает данные, подтверждает регистрацию
4	Система	Идет проверка корректности заполнения, пользователь вносится в базу данных, на почту отправляется письмо со ссылкой для активации акк
5	Пользователь	Пользователь открывает письмо, переходит по ссылке
6	Система	Система активирует аккаунт, высылает инструкцию по работе с сервисом

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

Пример 2: регистрация в интернет-магазине по сложной схеме

цель: зарегистрироваться в интернет-магазине;
действующее лицо: незарегистрированный пользователь;
триггер: пользователь увидел рекламу интернет-магазина и решил зарегистрироваться;
результат: у пользователя появляется аккаунт с бонусной системой.

Шаги юзеркейса выглядят следующим образом:

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

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

Пример 3: кейс по взаимодействию с сайтом вуза на примере диаграммы

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

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

Эксперты отвечают

ССергей Галоген

Что такое сценарий Use Case?

Сценарий или спецификация ВИ (use case scenario or specification) – тестовое формальное описание последовательности действий, которые происходят внутри ВИ для достижения некой цели актера.

ЮЮрий Булуй

Можно ли считать юзеркейс фукнцией?

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

Вывод

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

Приходилось сталкиваться с Use case?

1 голос

Да — 100%

Нет — 0%

Источник

Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.

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

Прежде чем разработать сценарий, нужно ответить на три вопроса:

1. Кто те люди, что заходят на ваш сайт?

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

2. Почему они заходят к вам?

На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.

3. Какие цели при этом преследуют и как их достигают?

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

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

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

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

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

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

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

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

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

Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:

Создаются с помощью объединения похожих пользовательских историй и отсечения лишнего и несущественного. Такой подход обобщает множество пользовательских историй в несколько сценариев. Например, таких: «Пользователь готовит деньги заранее, ищет через форму поиска, имеет ограниченный бюджет — сразу использует фильтры, принимает решение долго, несколько раз заходит в корзину и сравнивает товары».

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

Составляются уже с позиции персонажа (персоны покупателя). Еще меньше абстракции и больше конкретики. Каждой группе ЦА сопоставляется персонаж, далее прописывается его путь достижения цели.

Могут добавляться ограничения: например, проработка только варианта заказа с планшета или со смартфона.

Опишите пользовательский опыт по шагам: кто, каким образом и в какой последовательности делает. Это должен быть наиболее детализированный и технически проработанный вариант.

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

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

Описание варианта использования от uxexperience.net

«Общение» пользователя и терминала по приему платежей:

Фрагмент презентации компании «Собака Павлова» о пользовательских сценариях.

Еще сценарий от uxforthemasses.com:

Источник

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF

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

К наиболее часто используемым методам относят метод «сценариев» и в последнее время он обретает все большую популярность [1].

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

Метод «сценариев» получил широкое распространение в 60-70-е гг. XX в. Первоначально этот метод предполагал подготовку текста,содержащего логическую последовательность событий или возможные варианты решения проблемы, развернутые во времени.Однако позднее обязательное требование временных координатбыло снято, и сценарием стали называть любой документ, содержащий анализ рассматриваемой проблемы и предложения по еерешению или по развитию системы, независимо от того, в какойформе он представлен.

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

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

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

Сопоставление и оценка возможных сценариев развития ситуации способствует принятию подчас единственно верного решения[2].

Прогнозная оценка чаще всего представляется в виде трех возможных вариантов сценариев:

1) оптимистического;

2) пессимистического;

3) ожидаемого, наиболее вероятного.

Выделяют следующие этапы проведения (составления) сценария:

1. Формулирование проблемы:

а) производится сбор и анализ информации;

б) выполняются согласование со всеми участниками проекта решения сути задачи и ее формулирование.

2. Определение и группировка сфер влияния:

а) выделяются критические точки среды бизнеса;

б) производится оценка их возможного влияния на будущее фирмы.

3. Определение показателей будущего развития объекта.

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

4. Формулирование и отбор согласующихся наборов предположений:

а) развитие определяется исходя из сегодняшнего положения и всевозможных изменений;

б) различные альтернативные предположения о будущем комбинируются в наборы;

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

— высокая сочетаемость, совместимость предположений, входящих в набор;

— наличие большого числа значимых переменных;

— высокая вероятность событий, относящихся к набору предположений.

5. Сопоставление намеченных показателей будущего состояния сфер(фирмы) спредположениями об их развитии:

а) сравниваются результаты этапов 3 и 4;

б) завышенные и заниженные показатели состояния корректируются при помощи данных этапа 4.

Для более точного прогноза необходимо сокращать интервал прогнозирования, то есть делить его на несколько фрагментов, составляя несколько сценариев.

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

В настоящее время известны различные реализации метода «сценариев», такие как:

— получение согласованного мнения;

— повторяющаяся процедура независимых сценариев;

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

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

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

Метод повторяющегося объединения независимых сценариевсостоит в составлении независимых сценариев по каждому из аспектов, оказывающих существенное влияние на развитие ситуации, и повторяющемся итеративном процессе согласования сценариев развития различных аспектов ситуации.

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

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

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

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

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

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

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

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

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

Рассмотрим практическое применение метода «сценариев» на примере оценки рисков инвестиционных проектов.

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

Метод «сценариев»(имитационная модель оценки риска проекта) заключается в следующем:

На основе экспертной оценки по каждому проекту строят три возможных сценариев развития:

а) пессимистический;

б) наиболее вероятный (наиболее реальный);

в) оптимистический.

Для каждого сценария рассчитывается соответствующий показатель чистой текущей стоимости — NPV, т.е. получают три величины: NPVП (для пессимистического сценария); NPVВ (для наиболее вероятного сценария); NPVО (для оптимистичного сценария).

Для каждого проекта рассчитывается наибольшее изменение величины NPV — размах вариации,(NPV) = NPV0 — NPVП и среднеквадратичное отклонение:

σ_NPV=,

где – чистая приведённая стоимость проекта для каждого из рассматриваемых сценариев; – средневзвешенная величина по вероятностям реализации каждого из трёх сценариев:

Из сравниваемых проектов считается более рискованным тот, у которого больше размах вариации, (NPV) или среднеквадратичное отклонение NPV.

Рассмотрим применение количественных вероятностных оценок. В этом случае каждому варианту (сценарию) — пессимистическому, наиболее вероятному и оптимистическому присваиваются вероятности их осуществления Р_k; далее для каждого проекта рассчитывается вероятное значение NPV, взвешенное по присвоенным вероятностям, и среднее квадратичное отклонение от него:

σ_NPV=,

где – чистая приведённая стоимость проекта для каждого из трёх рассматриваемых сценариев; – средневзвешенная величина по вероятностям реализации каждого из трёх сценариев:

Из сравниваемых проектов проект с большим значением среднего квадратичного отклонения считается более рискованным.

По описанной методике разработана информационная система на языке Vusual Basic. Рассмотрим основные особенности ее функционирования напримере анализа двух взаимоисключающих проектов A и B, имеющих одинаковую продолжительность реализации, одинаковые величины капитальных вложений и ежегодных денежных поступлений; величины цены капитала для проектов также равны. В то же время проекты отличаются риском (вероятностью реализации различных сценариев).

Исходные данные и результаты расчетов приведены в таблице ниже.

Программой рассчитывается среднее значение чистой текущей стоимости для каждого проекта:

Программой рассчитываетсясреднее квадратичное отклонение величин чистой текущей стоимости для каждого проекта:

σ_NPV,A=

=2,43 млн.руб.

σ_NPV,В==

=2,10 млн.руб.

Результаты расчетов и исходные данные выводятся на экран монитора (таблица 1).

Таблица 1 — Показатели проектов и вероятность реализации различных сценариев

Показатель, млн руб.	Проект A	Проект B
	Вероятность		Вероятность
Величина инвестиций	-15,0	1	-15,0	1
Экспериментальная оценка дисконтированных доходов от реализации проекта при различных сценариях:
пессимистический	13,7	0,2	12,9	0,1
наиболее вероятный	18,4	0,7	18,4	0,5
оптимистический	22,6	0,1	20,3	0,4
Оценка NPV (расчёт):
пессимистический	-1,3	0,2	-2,1	0,1
наиболее вероятный	3,4	0,7	3,4	0,5
оптимистический	7,6	0,1	5,3	0,4
Размах вариации	8,9		7,4
Среднеквадратичное отклонение	2,43	2,10

В результате получаем, что проект A характеризуется большим, чем у проекта B размахом вариации, а также большим значением среднеквадратичного отклонения NPV, следовательно, он более рискован, чем проект B.

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

Библиографический список

Метод сценария: примеры и история URL: http://fb.ru/article/281994/metod-stsenariya-primeryi-i-istoriya (01.12.2017)

Метод сценариев URL: http://lib.sale/teoriya-upravleniya-besplatno/metod-stsenariev.(01.12.2017)

URL: http://decision-make.ru/index.php?action=full_article&id=63(01.12.2017)

Метод сценариев URL: http://studme.org/1405100318633/menedzhment/metod_stsenariev(01.12.2017)

Метод сценариев (имитационная модель оценки риска проекта) URL: http://knigi.news/invest/metod-stsenariev-imitatsionnaya-model-otsenki-17406.html(01.12.2017)

Источник