Добрый день, дорогие читатели!

В практике системного анализа довольно часто можно встретить требования в формате пользовательских историй (User Stories, далее US). Пользовательские истории предоставляют стейкхолдеры или бизнес-аналитики как входные данные. Так или иначе, US становятся одним из ключевых артефактов требований для реализации фичей.

Дальше начинается привычная работа аналитика: мы примеряем US на процессы системы — готовим документацию, проектируем API, формируем статусную модель, проектируем модель данных, готовим варианты использования (Use Cases), чтобы разложить US в сценарии системы. В результате появляется некий объем спецификаций и артефактов, которые затем раскидываются в задачи на разработку и размещаются в структуре базы знаний проекта.

И в этот момент возникает типичная ситуация:

Бизнес оперирует US и погружается в сценарии вариантов использования системы.
Разработчики работают с технической документацией — API-спецификациями, ER-диаграммами, описанием статусов.
Тестировщики по той же технической документации составляют тест-кейсы, стараясь покрыть все шаги процессов.

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

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

Собираем требования

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

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

№	Название	Описание
US-1	Расчет стоимости инфраструктуры	Я как потенциальный клиент желаю рассчитать стоимость облачной инфраструктуры под мои задачи, чтобы понять - подходит ли мне этот провайдер и уложусь ли я в бюджет
US-2	Оформление заявки на основе расчета	Я как зарегистрированный и верифицированный клиент желаю оформить заявку на развертывание инфраструктуры на основе ранее сделанного расчета, чтобы не вводить параметры заново и быстро перейти к оплате
US-3	Автоматический скоринг и согласование заявки	Я как система биллинга желаю автоматически оценивать риски новых заявок и определять необходимость ручного согласования, чтобы ускорить обработку надежных клиентов и минимизировать риски невозврата платежей
US-4	Выставление счета и оплата	Я как клиент, оформивший одобренную заявку желаю получить счет и оплатить его удобным для меня способом, чтобы активировать заказанную инфраструктуру и начать работу
US-5	Автоматическая активация инфраструктуры	Я как система провайдера облачной инфраструктуры желаю автоматически развертывать ресурсы после подтверждения оплаты, чтобы клиент получил доступ без задержек и ручного вмешательства

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

Кто является актором (пользователь, система)
Критерии приемки мы намеренно пропустим для оптимизации примера.

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

Выделяем основные статусы

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

№	Статус	Описание
1	QUOTE_CREATED	Расчет сохранен, сформировано коммерческое предложение
2	ORDER_SUBMITTED	Заявка оформлена, ожидает скоринга
3	UNDER_REVIEW	Заявка на ручном согласовании менеджера
4	APPROVED	Заявка одобрена (авто или менеджером)
5	REJECTED	Заявка отклонена (с указанием причины)
6	INVOICE_ISSUED	Счет сформирован и отправлен клиенту
7	PAID	Оплата успешно получена
8	EXPIRED	Счет не оплачен в срок, заявка аннулирована
9	PROVISIONING	Идет развертывание инфраструктуры
10	ACTIVE	Инфраструктура активна, доступы предоставлены
11	FAILED	Ошибка при развертывании, создан тикет в поддержку

Готовим варианты использования

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

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

Объединяем артефакты

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

Развертка вариантов использования по статусной модели с маппингом на API

В результате проделанной работы мы получили артефакт, который можно назвать "Развертка вариантов использования по статусной модели с маппингом на API".

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

Уровень	Что мы видим в артефакте
Бизнес-логика	Шаги сценариев, сгруппированные по статусам
Состояния системы	Статусная модель как "скелет" артефакта
Техническая реализация	API-эндпоинты, привязанные к конкретным Use Cases

В чем польза такой развертки?

Для бизнеса

Бизнес мыслит сценариями и шагами пользователя. Технические артефакты для них — "черный ящик".

Решение: Артефакт показывает бизнесу, как их сценарии "разворачиваются" в статусную модель. Они видят:

На каком статусе находится заявка
Какие действия привели к этому статусу
Какие следующие шаги возможны

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

Для разработчиков

Разработчики получают разрозненные входные данные: Use Cases (в Confluence), статусную модель (в Jira), API-спецификацию (в Swagger). Связи между ними приходится держать в голове.

Решение: Артефакт дает разработчику:

Понимание бизнес-контекста для каждого API
Четкое представление, какой статус меняет конкретный эндпоинт
Возможность видеть весь жизненный цикл заявки и место своего API в нем

Для тестировщиков

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

Решение: Артефакт становится основой для тест-дизайна:

Каждый переход между статусами-это потенциальный тест-кейс
Каждый API-эндпоинт в артефакте-точка проверки
Альтернативные потоки

Для менеджеров

Сложно отслеживать статус разработки и понимать, какие сценарии уже реализованы, а какие нет.

Решение: Артефакт можно использовать как чек-лист готовности:

Если API написан и протестирован-отмечаем его в артефакте
Если все API для статуса готовы-статус можно считать реализованным
На общих встречах открываем-артефакт и проходим по цепочке: "Что сделано? Что осталось?"

Итог

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

Он не заменяет существующие артефакты (User Stories, Use Cases, OpenAPI), но связывает их воедино, создавая общий язык для всей команды. Это особенно ценно в проектах со сложной бизнес-логикой и большим количеством участников.

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

Спасибо за внимание!

Объединяем уровни абстракции: обобщаем артефакты анализа для общего видения концепта задачи