Зачем, когда и как совмещать User Story с Use Case: практический пример

микросервисная архитектура, UML sequence, Use Case and User Story, формы представления требований, интеграционные сценарии, обучение разработке требований, ТЗ для аналитика, обучение аналитиков примеры курсы, Школа прикладного бизнес-анализа

Можно ли совмещать User Story и Use Case, используя обе формы представления требований в одном проекте. Разбираем на примере интернет-магазина с микросервисной архитектурой.

Что не так с User Story

Хотя User Story и Use Case как формы представления пользовательских требований принято противопоставлять друг другу, на практике их вполне можно совмещать, как я уже упоминала здесь. С User Story легко начинать, поскольку эта краткая лаконичная форма позволяет довольно быстро определить нужные пользователю функции системы с учетом его бизнес-целей. Неспроста ее так любят в Agile-проектах. Например, для покупателя интернет-магазина можно сформулировать следующую пользовательскую историю:

US-1. Я, как покупатель интернет-магазина, хочу заказать выбранные товары, чтобы купить их.

Для этой истории можно прописать критерии приемки, например, в виде чек-листа:

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

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

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

Бизнес-задача Сервис
Посмотреть данные о заказах, товарах и поставщиках товары Сервис Витрина
Управлять активными заказами Сервис Заказов
Управлять поставщиками Сервис Склад
Управлять товарами Сервис Склад
Управлять упаковкой товаров в заказ Сервис Склад
Определить время и стоимость доставки Сервис Доставка
Оплатить заказ Сервис Оплаты
Отправить уведомление об изменении статуса заказа Сервис Уведомлений

Взаимодействие между этими микросервисами реализовано через Apache Kafka и оркестрируется сервисом Оркестратор, который подписан на все события от целевых сервисов и формирует для них задания, также публикуя события в Kafka. Таким образом, US-1 декомпозируется на несколько системных вариантов использования:

  • UC-1.1 Проверить наличие товаров на складе (интеграция Сервис Заказов – Kafka – Сервис Окестратор – Kafka — Сервис Склад – Kafka — Окестратор);
  • UC-1.2 Вычислить стоимость доставки (интеграция Оркестратор – Kafka – Сервис Доставки – Kafka — Окестратор);
  • UC-1.3 Уведомить пользователя об оплате заказа (интеграция Оркестратор – Kafka – Сервис Уведомлений);

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

UML-диаграмма последовательности, UMl sequence пример, микросервисная архитектура
UML-диаграмма последовательности создания заказа в микросервисной системе интернет-магазина

Эта диаграмма создана с помощью следующего PlantUML-скрипта:

@startuml
title Сделать заказ
actor Клиент
participant Сервис_Заказов
participant Kafka
participant Сервис_Оркестратор
participant Сервис_Склад
participant Сервис_Доставки
participant Сервис_Уведомлений
Клиент -> Сервис_Заказов: сделать заказ(Заказ)
activate Сервис_Заказов
Сервис_Заказов -\ Kafka: опубликовать событие(Заказ)
activate Kafka
Сервис_Оркестратор -> Kafka: получить событие(Заказ)
activate Сервис_Оркестратор
Kafka --> Сервис_Оркестратор: событие Заказа
Сервис_Оркестратор -\ Kafka: опубликовать событие-задачу для Склада(Товары в Заказе)
Сервис_Склад -> Kafka: получить событие-задачу(Товары в Заказе)
activate Сервис_Склад
Kafka --> Сервис_Склад: событие-задача(Товары в Заказе)
Сервис_Склад -> Сервис_Склад: найти товары(Заказ)
Сервис_Склад -\ Kafka: опубликовать событие-результат(местонахождение Товаров)
Сервис_Оркестратор -> Kafka: получить событие-результат(местонахождение Товаров)
Kafka --> Сервис_Оркестратор: событие-результат(местонахождение Товаров)
alt Товары найдены
Сервис_Оркестратор -\ Kafka: опубликовать событие-задачу для Доставки(местонахождение Товаров, способ и адрес доставки)
Сервис_Доставки -> Kafka: получить событие-задачу для Доставки(местонахождение Товаров, способ и адрес доставки)
activate Сервис_Доставки
Kafka --> Сервис_Доставки: событие-задача для Доставки(местонахождение Товаров, способ и адрес доставки)
Сервис_Доставки -> Сервис_Доставки: найти оптимальный путь(местонахождение Товаров, способ и адрес доставки)
Сервис_Доставки -> Сервис_Доставки: расчитать сроки(оптимальный путь)
Сервис_Доставки -> Сервис_Доставки: расчитать стоимость(оптимальный путь)
Сервис_Доставки -\ Kafka: опубликовать событие-результат(сроки и стоимость доставки по оптимальному пути)
Сервис_Оркестратор -> Kafka: получить событие-результат(сроки и стоимость доставки по оптимальному пути)
Kafka --> Сервис_Оркестратор: событие-результат(сроки и стоимость доставки по оптимальному пути)
Сервис_Оркестратор -\ Kafka: опубликовать событие-задачу для Заказов (статус Заказа, параметры Доставки)
Сервис_Заказов -> Kafka: получить событие-задачу(статус Заказа, параметры Доставки)
Kafka --> Сервис_Заказов : событие-задача(статус Заказа, параметры Доставки)
Сервис_Заказов -> Сервис_Заказов : изменить Заказ и Доставку (статус Заказа, параметры Доставки)
Сервис_Заказов --> Клиент: статус Заказа, цена и сроки доставки
Сервис_Оркестратор -\ Kafka: опубликовать событие-задачу для Уведомления(Клиент, статус Заказа, параметры Доставки)
else Товары НЕ найдены
Сервис_Оркестратор -\ Kafka: опубликовать событие-задачу для Заказов (статус Заказа, отсутствующие Товары)
Сервис_Заказов -> Kafka: получить событие-задачу(статус Заказа, отсутствующие Товары)
Kafka --> Сервис_Заказов : событие-задача(статус Заказа, отсутствующие Товары)
Сервис_Заказов -> Сервис_Заказов : изменить Заказ(статус Заказа, отсутствующие Товары)
Сервис_Заказов --> Клиент: статус Заказа, отсутствующие Товары)
Сервис_Оркестратор -\ Kafka: опубликовать событие-задачу для Уведомления(Клиент, статус Заказа, отсутствующие Товары)
end alt
Сервис_Уведомлений -> Kafka: получить событие-задачу(Клиент,статус Заказа)
activate Сервис_Уведомлений 
Kafka --> Сервис_Уведомлений: событие-задача(Клиент, (Клиент, статус Заказа)
Сервис_Уведомлений -> Сервис_Уведомлений: отправить Уведомление(Клиент)
Сервис_Уведомлений --> Клиент: отправить Уведомление(статус Заказа)
@enduml

Далее рассмотрим текстовую форму одного из представленных интеграционных ВИ.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

Текстовая форма представления Use Case на примере интеграционного сценария

Опишем UC-1.1 в табличном виде, отразив happy path в основном потоке, а альтернативные пути – в расширениях.

Имя UС-1.1. Проверить наличие товаров на складе
Область действия Микросервисная система интернет-магазина
Актор Клиент, Сервис Заказов – Kafka – Сервис Окестратор
Цель Узнать местонахождение выбранных клиентом товаров и изменить статус Заказа
Предусловия Выбранные товары добавлены в корзину
Триггер Клиент вызвал команду «Заказать»
Результат (пост-условия) Определено местонахождения товаров на складах и изменен статус Заказа
Основной поток (Happy Path, который приведет к результату) 1.     Сервис Заказов создает Заказ в статусе «Новый»

2.     Сервис Заказов формирует сообщение для Kafka c данными о новом Заказе (Клиент, статус Заказа, Товары в Заказе, отметка времени)

3.     Сервис Заказов публикует сформированное сообщение в Kafka

4.     Сервис Заказов изменяет статус Заказа на «Принят»

5.     Сервис Оркестратор потребляет сообщение о новом Заказе из  Kafka

6.     Сервис Оркестратор формирует сообщение с событием-задачей для Сервиса Склада (Товары в Заказе и их количество)

7.     Сервис Оркестратор публикует сформированное сообщение в Kafka

8.     Сервис Склад потребляет событие-задачу о товарах из Kafka

9.     Сервис Склад определяет местонахождение товаров  (Товары и их количество)

10.   Сервис Склад формирует сообщение с событием-результатом для Оркестратора (отметка времени, количество Товара, местонахождение)

11.   Сервис Склад публикует сформированное сообщение в Kafka

12.   Сервис Оркестратор потребляет событие-результат о результатах поиска товаров на складах из  Kafka

13.   Сервис Оркестратор формирует сообщение с измененным статусом Заказа по результатам поиска (отметка времени, новый статус Заказа)

14.   Сервис Оркестратор публикует сформированное сообщение в Kafka

15.   Сервис Заказов потребляет сообщение-задачу из Kafka

16.   Сервис Заказов изменяет статус Заказа

Расширения (Альтернативные пути) 3а. Не получилось опубликовать сообщение в Kafka

3а.1 Сервис Заказов сохраняет неопубликованное сообщение в локальный лог-файл

3а.2 Сервис Заказов завершает выполнение сценария

 

5а. Не получилось обработать потребленное сообщение

5а.1 Сервис Оркестратор сохраняет необработанное сообщение в локальный лог-файл

5а.2 Сервис Оркестратор завершает выполнение сценария

 

7а. Не получилось опубликовать сообщение в Kafka

7а.1 Сервис Оркестратор сохраняет неопубликованное сообщение в локальный лог-файл

7а.2 Сервис Оркестратор завершает выполнение сценария

 

8а. Не получилось обработать потребленное сообщение

8а.1 Сервис Склад сохраняет необработанное сообщение в локальный лог-файл

8а.2 Сервис Склад завершает выполнение сценария

 

11а. Не получилось опубликовать сообщение в Kafka

11а.1 Сервис Склад сохраняет неопубликованное сообщение в локальный лог-файл

11а.2 Сервис Склад завершает выполнение сценария

 

12а. Не получилось обработать потребленное сообщение

12а.1 Сервис Оркестратор сохраняет необработанное сообщение в локальный лог-файл

12а.2 Сервис Оркестратор завершает выполнение сценария

 

13а. Товары на складах найдены в нужном количестве

13а.1 Сервис Оркестратор задает для нового статуса Заказа значение «Найден»

13а.2 Переход к шагу 14 основного потока

 

13б. Товары на складах НЕ найдены в нужном количестве

13б.1 Сервис Оркестратор задает для нового статуса Заказа значение «Не найден»

13б.2 Переход к шагу 14 основного потока

 

14а. Не получилось опубликовать сообщение в Kafka

14а.1 Сервис Оркестратор сохраняет неопубликованное сообщение в локальный лог-файл

14а.2 Сервис Оркестратор завершает выполнение сценария

 

15а. Не получилось обработать потребленное сообщение

15а.1 Сервис Заказов сохраняет необработанное сообщение в локальный лог-файл

15а.2 Сервис Заказов завершает выполнение сценария

Бизнес-правила BR1. Заказать можно только те товары, которые полностью присутствуют на складах в нужно количестве

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

User Story и Use Case
Разложение пользовательской истории на несколько вариантов использования системы

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

Основы бизнес-анализа: вход в профессию для начинающих

Код курса
INTRO
Ближайшая дата курса
26 апреля, 2024
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.

Освоить все эти и другие техники представления требований вам помогут мои курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Добавить комментарий

Поиск по сайту

Напишите нам, мы онлайн!