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

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

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

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

• Бизнес оперирует US и погружается в сценарии вариантов использования системы.

• Разработчики работают с технической документацией — API-спецификациями, ER-диаграммами, описанием статусов.

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

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

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

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

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

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

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

• Кто является актором (пользователь, система)

• Критерии приемки мы намеренно пропустим для оптимизации примера.

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

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

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

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

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

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

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

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

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

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

Для бизнеса

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

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

• На каком статусе находится заявка

• Какие действия привели к этому статусу

• Какие следующие шаги возможны

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

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

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

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

• Понимание бизнес-контекста для каждого API

• Четкое представление, какой статус меняет конкретный эндпоинт

• Возможность видеть весь жизненный цикл заявки и место своего API в нем

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

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

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

• Каждый переход между статусами-это потенциальный тест-кейс

• Каждый API-эндпоинт в артефакте-точка проверки

• Альтернативные потоки

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

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

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

• Если API написан и протестирован-отмечаем его в артефакте

• Если все API для статуса готовы-статус можно считать реализованным

• На общих встречах открываем-артефакт и проходим по цепочке: «Что сделано? Что осталось?»

Итог

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

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

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

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