Можно ли совмещать 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-х связанных друг с другом интеграционных ВИ на диаграмме последовательности выглядит так:
Эта диаграмма создана с помощью следующего 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
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 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. Поэтому я люблю комбинировать обе формы представления требования, начиная с пользовательских историй, а затем декомпозировать их на варианты использования системы.
О том, как описать взаимодействие микросервисов между собой, а также с внешними системами, читайте в новой статье.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
13 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Освоить все эти и другие техники представления требований вам помогут мои курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
