Добрый день, дорогие читатели!
В практике системного анализа довольно часто можно встретить требования в формате пользовательских историй (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-эндпоинты, привязанные к конкретным Use Cases |
В чем польза такой развертки?
Для бизнеса
Бизнес мыслит сценариями и шагами пользователя. Технические артефакты для них — "черный ящик".
Решение: Артефакт показывает бизнесу, как их сценарии "разворачиваются" в статусную модель. Они видят:
На каком статусе находится заявка
Какие действия привели к этому статусу
Какие следующие шаги возможны
Это особенно ценно на демо и приемочных встречах — вместо абстрактных обсуждений мы смотрим в один документ и говорим на одном языке.
Для разработчиков
Разработчики получают разрозненные входные данные: Use Cases (в Confluence), статусную модель (в Jira), API-спецификацию (в Swagger). Связи между ними приходится держать в голове.
Решение: Артефакт дает разработчику:
Понимание бизнес-контекста для каждого API
Четкое представление, какой статус меняет конкретный эндпоинт
Возможность видеть весь жизненный цикл заявки и место своего API в нем
Для тестировщиков
Тестировщики составляют тест-кейсы на основе технической документации, но часто пропускают сценарии, потому что не видят полной картины переходов между статусами.
Решение: Артефакт становится основой для тест-дизайна:
Каждый переход между статусами-это потенциальный тест-кейс
Каждый API-эндпоинт в артефакте-точка проверки
Альтернативные потоки
Для менеджеров
Сложно отслеживать статус разработки и понимать, какие сценарии уже реализованы, а какие нет.
Решение: Артефакт можно использовать как чек-лист готовности:
Если API написан и протестирован-отмечаем его в артефакте
Если все API для статуса готовы-статус можно считать реализованным
На общих встречах открываем-артефакт и проходим по цепочке: "Что сделано? Что осталось?"
Итог
Артефакт, который мы построили, не требует сложных инструментов или фреймворков. Это просто структурированная таблица (или граф), но она решает реальную проблему: разрыв между бизнес-требованиями, логикой системы и технической реализацией.
Он не заменяет существующие артефакты (User Stories, Use Cases, OpenAPI), но связывает их воедино, создавая общий язык для всей команды. Это особенно ценно в проектах со сложной бизнес-логикой и большим количеством участников.
Я построила такой артефакт в тот момент, когда нужно было выровнять в понимании процессов и стейкхолдеров, и всех причастных к реализации.
Спасибо за внимание!
