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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Что такое юзкейс
• Из чего состоит
• Как написать
• Пример
• Диаграммы
• Польза для команды

Что такое юзкейс

Use case (также юзкейс, сценарий использования) – это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Юзкейсы содержат следующие сведения:

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

Юзкейсы не содержат детали реализации, а также описания пользовательского интерфейса или экранов.

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

В отличие от user story, которая излагается от имени какого-то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:

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

Элементы use case

Юзкейсы могут содержать следующие элементы (их количество зависит от сложности сценария):

• Актор (actor) — тот, кто использует систему. Если взять за пример онлайн-магазин, там может быть несколько акторов: покупатели, продавцы, компании, занимающиеся доставкой, компании, проводящие платежи.
• Стейкхолдер (stakeholder) — тот, кто заинтересован в определенном поведении системы. Зачастую это не конечный пользователь, а кто-то, получающий выгоду от функционирования системы. В случае с онлайн-магазином это может быть партнер — платежная платформа.
• Первичное действующее лицо (primary actor) — человек или система, чьи цели достигаются при помощи нашего продукта. В онлайн-магазине это может быть основной дистрибьютор, чьи товары продаются на этой онлайн-платформе.
• Предусловия и постусловия — что должно быть в наличии или должно произойти до и после запуска сценария использования.
• Триггеры — события, запускающие юзкейс.
• Успешный сценарий — юзкейс, при котором все идет по плану, без ошибок и неожиданностей.
• Альтернативные пути — вариации основного успешного сценария на случай, если что-то пойдет не так на уровне системы.

Как написать use case?

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

1. Определите, кто будет использовать сайт.
2. Выберите одного из этих пользователей.
3. Определите, что этот пользователь хочет делать на сайте. Все, что пользователь делает на сайте, становится юзкейсом.
4. Для каждого use case определите нормальный ход событий.
5. Опишите основной путь пользователя: что именно делает пользователь и каков ожидаемый ответ системы.
6. Далее рассмотрите альтернативные варианты развития событий и добавьте их, чтобы «расширить» use case.
7. Повторите шаги 2-6 для всех остальных пользователей.

Пример use case

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

Юзкейс-диаграммы

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

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

Зачем нужны use case?

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

1. Заказчики

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

1. Разработчики

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

1. Тестировщики

Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки,  которые сложно найти, например, при юнит-тестировании.

• Что такое диаграмма вариантов использования?

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

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

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

  Назначение диаграмм вариантов использования

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

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

  Стандартная форма диаграммы прецедентов определена в унифицированном языке моделирования, как показано в примере диаграммы прецедентов ниже.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  Элементы диаграммы вариантов использования

  Актеры

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

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

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

  Люди против нечеловеческих актеров

  Время от времени на систему воздействуют различные события для выполнения определенных функций в той или иной ситуации. Например, при прохождении аудита система заранее отправляет письмо, чтобы уведомить людей; так отправка письма осуществляется системой автоматически? Этот вариант использования на самом деле запускается по времени, тогда действующим лицом является Таймер; например, этот вариант использования можно рассматривать как «автоматически отправлять письмо в 5:00 каждый день», тогда актор, который запускает это событие — отправку письма — не система, а на самом деле актор-таймер

  Первичные и второстепенные актеры

  A primary actor is an actor that uses the system to achieve a goal. Use cases document the interactions between the system and actors to achieve the goals of the primary actor. Secondary actors are the actors that the system needs to assist in order to achieve the goals of the primary actor.

  • Actors may be primary or secondary. Primary actors initiate interactions with the system.
  • Secondary actors are typically called upon by the system for help and a secondary actor never initiates the use case.

  Note that: The symbol for an actor does not differentiate between a primary actor and a secondary actor; the difference must be inferred from the use case descriptions (also called use case narratives).

  For Example:

  A bank loan officer wants to review a customer’s loan application, and part of the process involves a real-time credit rating check.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  • Используйте имя дела. Рассмотреть заявку на кредит
  • Главный актер. Кредитный специалист
  • Второстепенный актер. Система кредитного рейтинга

  Как определить актеров?

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

  • Кто будет использовать систему после ее разработки?
  • От кого или от каких других систем система должна будет получать данные?
  • Для кого или для каких других систем система будет предоставлять данные?
  • С какими другими системами будет связана система?
  • Кто будет поддерживать и администрировать систему?

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

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

  Вариант использования

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

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

  Как определить варианты использования?

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

  • Почему актеры используют систему?
  • Создает ли участник, изменяет, удаляет, получает доступ и хранит данные в системе? Если да, то как актор выполняет эти операции?
  • Уведомляет ли актор систему об определенных внешних событиях?
  • Уведомляет ли система актора об определенных внутренних событиях?

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

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

  Системная граница

  Границы системы описывают систему, группируя варианты использования в прямоугольные границы, а границы системы в Visual Paradigm обеспечивают поведение ограничения вариантов использования.

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

  Обратите внимание, что: 

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

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

  Отношение

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

  Вариант использования можно разбить на несколько вариантов использования, которые связаны отношениями <<включить>>, <<расширить>> или <<обобщить>> (описано далее в этом посте).

  Связь канала связи

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  <<Включить>> Связь

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

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

  <<Расширить>> отношения

  Если вариант использования B расширяет другой вариант использования A, то реализация A может условно включать реализацию B для выполнения своей задачи. То есть в некоторых случаях А может выполнить свою задачу без В. Однако в зависимости от описанных условий А может потребовать В. В этом случае В зависит от В. Однако в зависимости от описанных условий А может потребовать В В этом случае В зависит от А и не может существовать отдельно. По этой причине B нельзя распространить более чем на один вариант использования. Описание варианта использования A будет включать этапы выполнения, требуемые от B; эта точка называется точкой расширения.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  Отношение обобщения

  Обобщенное отношение похоже на обобщенное отношение объектно-ориентированного языка на диаграммах классов и может применяться к обобщению ролей (акторов) и вариантов использования.

  Например, в системе бронирования есть два типа методов бронирования: «забронировать билет по телефону» и «забронировать билет через Интернет», а также базовый вариант использования «забронировать билет», поэтому вы можете использовать обобщение для формирования случая, и добавьте <<essential>> к родительскому варианту использования (бронирование), чтобы указать обобщенную связь.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  Обсудите отношения в диаграмме вариантов использования

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

  Вариант использования — поток событий

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

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

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

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

  Обычный сценарий – вывод средств – основной ход событий:

  1. Пользователь вставляет кредитную карту
  2. Введите PIN-код
  3. Введите сумму вывода
  4. Снимает наличные
  5. Выйдите из системы и получите кредитную карту

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

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

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

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

  Для варианта использования «Снятие средств» в системе банкомата мы можем получить несколько альтернативных процессов следующим образом.

  Снятие – альтернативные процессы событий.

  1. Альтернативный сценарий I: Пользователь может отказаться на любом шаге основного процесса и перейти к шагу 5 основного процесса.
  2. Альтернативный процесс II: на шаге 1 основного процесса пользователь вставляет недействительную кредитную карту, система отображает ошибку и закрывает кредитную карту, и вариант использования заканчивается.
  3. Альтернативный процесс III: на шаге 2 основного процесса пользователь вводит неверный пароль, система отображает ошибку и предлагает пользователю повторно ввести пароль и вернуться к шагу 2 основного процесса; после трех неправильных вводов пароля кредитная карта конфискуется системой, и вариант использования заканчивается.
  4. …

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

  Модель вариантов использования и диаграммы вариантов использования

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

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

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

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

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

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

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

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

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

  Например:

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

  Используйте инструменты кейса

  Онлайн-версия

  Бесплатная версия бесплатного инструмента для рисования Visual Paradigm Online (VP Online) поддерживает UML, ERD и организационные диаграммы. Вы можете быстро нарисовать диаграммы вариантов использования с помощью интуитивно понятного редактора чертежей UML. В этом бесплатном инструменте UML нет рекламы, нет ограниченного периода доступа и нет ограничений, таких как количество диаграмм, количество фигур и т. д. Рисуйте UML свободно. Рисуйте UML свободно. вам принадлежат диаграммы, которые вы создаете для личных и некоммерческих целей.

  Настольная версия

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

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

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

  UML-ресурсы

  • Что такое УМЛ?
  • Почему UML-моделирование?
  • Обзор 14 типов диаграмм UML

Продолжая обучение начинающих бизнес-аналитиков, сегодня рассмотрим 2 популярные схемы описания требований в Agile-проектах. Читайте далее, чем User story отличается от Use Case, а также как они связаны с UML-диаграммой прецедентов, а также функциональными и нефункциональными требованиями к решению, которые входят в ТЗ по ГОСТ.

От потребности к решению: виды требований и способы их описания

Напомним, руководство к профессиональному своду знаний по бизнес анализу BABOK®Guide выделяет 3 основных вида требований (бизнес, стейкхолдеров и к решению), а также переходные, актуальные на момент трансформации от текущего состояния (as-is) к желаемому (as-to-be). Подробнее об этом мы говорили в отдельной статье. Аналитик плотно работает со всеми видами требований, последовательно трассируя потребности, проблемы и возможности в требования к решению через бизнес-требования и требования заинтересованных сторон (стейкхолдеров).

Если решением является информационная система или программно-аппаратный комплекс, как это бывает в большинстве случаев, то в техническое задание (ТЗ) на его разработку попадают именно требования к решению: функциональные и нефункциональные. Для этого выделяются соответствующие пункты в стандартах по разработке (ISO/IEC/IEEE 29148:2018, ГОСТ 34.602-89, ГОСТ 19.201-78) и спецификации требований к программному обеспечению (Software Requirements specification, SRS) на основе IEEE/ISO/IEC 29148-2011. На практике формирование такого комплексного ТЗ по всем правилам является длительным и итеративным процессом со множеством циклов согласования между Заказчиком и командой реализации. Поэтому, чтобы лучше понять потребности стейкхолдеров и быстрее начать работу над программным продуктом, бизнес-аналитик описывает требования к системе в виде пользовательских историй (user story), которые кратко формулируют, какие возможности она предоставляет конкретной роли.

Что такое пользовательская история и чем она хороша

Обычно user story создаются по шаблонам возможности или ограничения:

• <Роль> должен иметь возможность <возможность> в <показатель производительности> с <момент отсчета> в <условия эксплуатации>, чтобы <ценность>. Например, Администратор клиники должен иметь возможность просмотреть данные о прошлых и запланированных посещениях пациента в течение 3 секунд после определения личности клиента по номеру телефона входящего звонка, чтобы добавить новое или изменить запланированное посещение.
• <Система> должна <выполняемая функция> <объект> каждые <производительность> <единица измерения>, чтобы <ценность>. Например, CRM-система должна отправлять СМС-напоминание клиенту о предстоящем посещении за сутки перед посещением, чтобы он помнил о приеме и пришел вовремя.

Таким образом, формулировка исходных требований стейкхолдеров в виде пользовательских историй соответствует BDD-походу к разработке (Behavior-driven development), позволяя описать ожидания пользователей от проектируемой системы на понятном им языке и определить поведенческие сценарии тестирования для приемочных испытаний. User stories особенно распространены в продуктовой аналитике, но не заменяют собой формальное ТЗ по ГОСТ’ам с перечислением функций системы, о чем мы уже упоминали здесь и здесь. На практике такое представление требований часто встречается в Agile-проектах, особенно на начальном этапе бизнес-анализа при выяснении и уточнении потребностей заинтересованных сторон. Подробнее о том, как разные модели и методологии разработки ПО реализуют принципы Agile и движение по этапам SDLC, читайте в нашей отдельной статье.

Сценарий использования и UML-диаграмма Use Case

Однако, user story – далеко не единственная схема представления требований, хотя именно она больше всего подходит к описанию требований стейкхолдеров. Также для описания функциональных требований, описывающих поведение проектируемой системы в едином смысловом контексте, применяется инструмент сценариев или вариантов ее использования (Use Case). В этом случае функциональные требования к системе представляются в виде набора функций, объединенных по контексту. Например, Use Case «Запланировать посещение клиента в клинику» может включать следующие функции:

• Просмотреть историю посещений (данные о прошлых и запланированных визитах);
• Добавить новое посещение;
• Выбрать посещение;
• Просмотреть детали (дата, время, место, врач) посещения;
• Изменить детали будущего посещения;
• Удалить будущее посещение.

Все эти функции представляют собой прецеденты UML-диаграммы вариантов использования (Use Case), которые связаны различными видами отношений. При этом направленную ассоциацию от актора проведем только к тем прецедентам, которые имеют смысл с пользовательской (бизнесовой) точки зрения. Таким здесь являются «Просмотреть историю посещений», «Добавить новое посещение» и «Просмотреть детали». А то, что для просмотра деталей конкретного посещения его надо выбрать из всего списка (просмотрев историю) — это системный use case. Поэтому целевой пользовательский UC «Просмотреть детали» ссылается на «Выбрать посещение» связью include. Это означает, что в реализации «Просмотреть детали» не может быть выполнен без выполнения «Выбрать посещение». В текстовой форме представления требований в виде Use Case это было бы прописано в графе «Предусловие, что мы рассмотрим далее. О том, как разрабатывать UML-диаграмму Uce Case, мы поговорим в другой раз. А проверить свое знание основ UML вы можете, пройдя бесплатный интерактивный тест прямо на нашем сайте.

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

• Имя, в формате глагол-существительное, которое описывает достижимую цель и объяснять смысл сценария.
• Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
• Актор — действующее лицо, кто-то или что-то вне системы, влияющий на нее или находящийся под её влиянием (человек, устройство, другая система или подсистема).
• Предусловия, которые должны быть истиной для выполнения сценария.
• Активатор (триггер) – внешнее, внутреннее или временное событие, инициирующее выполнение сценария.
• Результат (постусловие) – новый объект или изменение состояния существующего объекта, который показывает, что актор достиг своей цели.
• Порядок Событий (основной поток) — типичный ход событий как ряд пронумерованных шагов.
• Альтернативные пути и дополнения use case’а могут содержать вторичные пути или другие сценарии на шаги основного.
• Бизнес-правила для определения результата в зависимости от конкретного запроса к системе, например, входных данных: «Изменение деталей или удаление возможно только для будущих посещений, дата и время которых еще не настали на момент просмотра записи».

Обычно сценарий использования по такой структуре оформляется в виде таблицы. В этом случае UML-диаграмма прецедентов (Use Case) является краткой наглядной схемой текстового представления основных функциональных возможностей взаимодействия с проектируемой системой, без детализации их выполнения. Бизнес-логика каждого прецедента описывается в пунктах сценария «Поток Событий»(Основной поток) и «Альтернативный поток». Как это сделать на практике, рассмотрим в следующей статье.

Чем User Story отличается от Use case

Подводя итог описанию рассмотренных схем представления требований, подчеркнем сходства и отличия User Story и Use case:

• обе этих схемы представления требований подходят для описания требований стейкхолдеров;
• обе схемы активно используются в ИТ-проектах, позволяя начать реализацию системы  и создать прототип, демонстрирующий ключевые функциональные возможности;
• UML-диаграмма вариантов использования (Use Case) может использоваться с обеими схемами представления требований, наглядно показывая основные функциональные возможности взаимодействия стейкхолдера с проектируемой системой, без детализации их выполнения. Однако, неподготовленному читателю такая диаграмма покажется сложной и непонятной, в отличие от простых формулировок User Story и текстового (табличного) представления Use Case.
• User Story более легковесная техника, она требует меньше времени на формулирование, а потому она активно применяется в Agile-проектах, тогда как Use Case требует больше времени на разработку и потому более подходит для проектов, где нужна высокая степень формализации подробно задокументированных требований;
• пользовательские истории требуют дальнейшей детализации для описания подробностей выполнения процессов, взаимодействия пользователя с системой, данных и бизнес-логики, тогда как Uase Case является самодостаточным;
• User Story отлично подходит для разработки поведенческих сценариев тестирования, программы и методики приемочных испытаний;
• сценарии использования, в отличие от пользовательских историй, описывают процесс и его шаги подробно, предоставляя всю необходимую информацию о взаимодействии актора с системой, включая цель, пред- и пост-условия, триггеры, основные и альтернативные потоки, а также бизнес-правила;
• User Story позволяет указать нефункциональные требования с точным заданием значений нужных показателей, например, время отклика на событие, наработку на отказ и пр.;
• Use Сase объединяет функциональные требования по контексту.

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

Подробнее узнать о сходствах, отличиях, достоинствах и недостатках, примерах применения Use Case и User Story, а также научиться описывать требования по этим схемам представления вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Разработка ТЗ на информационную систему
• UML для бизнес-аналитика

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

Что такое Use Case

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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