Бизнес и Системная Аналитика — это инженерно-технический процесс глубокой переработки продуктовых требований в детальные спецификации, готовые для передачи в разработку.
Цели и Назначение
Главная цель этого этапа — устранить техническую неопределенность. Разработчик не должен тратить время на додумывание бизнес-логики или проектирование базы данных на ходу. Он должен получить инструкцию, по которой можно писать код.
Задачи аналитики
Декомпозиция: Превращение крупных требований в атомарные задачи.
Формализация: Превращение продуктовых требований в четкие функциональные и нефункциональные требования.
Техническое проектирование: Определение того, как новая фича впишется в существующую систему.
Выявление корнер кейсов: Продумывание сценариев ошибок, сбоев и нестандартного поведения пользователя.
Входные данные
Процесс аналитики начинается при наличии следующих артефактов от Продакт-менеджера:
-
Продуктовые требования: Описание проблемы, цели и сценариев использования.
-
Дизайн-концепции: Визуализация того, как интерфейс должен вести себя (если применимо).
Роли и зоны ответственности
В идеальном процессе участвуют две роли, хотя часто их совмещает один специалист (“Системный аналитик” или “Бизнес аналитик”).
Бизнес-аналитик (Business Analyst — BA)
Фокус: Процессы и Бизнес-логика.
-
Уточнение требований: Выявляет скрытые бизнес-правила (например, “Что делать с заказом, если товар закончился на складе в момент оплаты?”).
-
Моделирование процессов (BPMN): Описывает работу команды в виде понятных схем: кто что делает, в каком порядке, какие решения принимаются и какие документы/системы участвуют.
-
Матрица ролей: Определяет, кто и к каким данным имеет доступ.
Системный аналитик (System Analyst — SA)
Фокус: Данные, Технологии, ФТ и НФТ.
-
Разработка Функциональных Требований (ФТ): Описывает поведение системы (что система должна делать).
-
Определение Нефункциональных Требований (НФТ): Описывает ограничения и атрибуты качества (как система должна работать).
-
Проектирование API и данных: Продумывает, какие данные будем хранить, как они связаны между собой, и по каким адресам (API-ручкам) к этим данным можно будет обратиться.
Простыми словами
Перед тем как что-то делать, нужно договориться:
- Что вообще мы храним — какие есть сущности: пользователи, заказы, товары и т.д.
- Какие у них поля — у пользователя: имя, телефон, email; у заказа: сумма, статус, дата.
- Как это лежит в базе — какие таблицы в базе данных будут, что к чему привязано.
- Как к этому обращаться снаружи — какие будут адреса (API-ручки):
GET /api/products— получить список товаров,
POST /api/orders— создать заказ и т.п.Что такое API
API — это технический набор договорённостей, как к сервису можно «приходить с запросами».
- Есть адреса (ручки) вроде
GET /api/products— «обратись сюда, если хочешь список товаров».- Есть правила, какие данные можно передавать и что вернётся в ответ.
Для фронтенда и других систем API — это условно перечень правил, в которых четко прописано, что можно попросить у бэкенда и в какой форме.
По сути, на этом шаге рисуют:
- логическую схему данных,
- и список адресов, по которым к этим данным можно попасть,
чтобы потом разработчики не гадали, куда что класть и как это доставать.
Артефакт и содержание
На выходе работы аналитиков мы получаем итоговые требования, достаточные для начала разработки. Главным артефактом является Техническое Задание (Спецификация или просто дополненная страничка в Confluence), которое включает в себя:
Функциональные Требования
Это детальное описание поведения системы. Если в Discovery было написано “Пользователь может оплатить заказ”, то здесь SA расписывает:
-
Сценарии: Пошаговое описание взаимодействия
(Пример: Система получает запрос → Система валидирует(проверяет) данные → Система обращается к платежному шлюзу). -
Бизнес-правила и Валидация: Точные алгоритмы проверок
(например, “Сумма заказа должна быть > 0”). -
Статусная модель: Диаграмма переходов состояний (State Diagram) для объектов
(например, жизненный цикл Заказа: Новый → Оплачен → Отменен). -
Алгоритмы: Описывает сложную логику в виде пошаговых схем: какие действия выполняются, в каком порядке и при каких условиях.
(например, расчет динамического ценообразования).
Нефункциональные Требования
Это требования к атрибутам качества системы. Их часто упускают на Discovery, и задача аналитика — выявить и зафиксировать их на этапе Delivery.
-
Производительность: «Сервис должен отвечать быстро: не дольше 200 миллисекунд, даже если за одну секунду к нему обращаются примерно 1000 раз (1000 запросов в секунду).»
-
Надежность и Доступность: “Сервис должен быть доступен 99.9% времени”.
-
Безопасность: “Все персональные данные должны храниться в зашифрованном виде”.
-
Масштабируемость: “Архитектура должна позволять горизонтальное масштабирование при росте нагрузки”. То есть не улучшать технические характеристики текущего, а подключать больше серверов с ростом нагрузки.
-
Логирование и Мониторинг: “Все ошибки критического уровня должны отправляться в определённую систему с указанием уникального номера запроса”.
Технические Модели и Контракты
-
Контракты API (Swagger / OpenAPI): Формальное описание API: какие есть адреса (ручки), какие данные им можно отправлять и что именно вернётся в ответ, включая возможные ошибки.
-
Схема Базы Данных (ER-Diagram): Наглядная схема таблиц в базе данных: какие таблицы есть, какие у них поля и как они связаны друг с другом.
-
Диаграммы последовательности (Sequence Diagrams): Картинки, на которых по шагам показано, как разные части системы обмениваются запросами и ответами друг с другом.
Заключение
Послесловие
Как правило, когда от PO поступают требования, мы заводим в спринт задачу на аналитику (таску в Jira). По её итогам аналитик формулирует требования и презентует их на груминге для дальнейшей декомпозиции, о которой мы поговорим далее.
Если же вводных данных недостаточно (задача заблокирована), мы заводим отдельную задачу на ресёрч (спайку на аналитика), итогом которой может стать снятие блока с аналитики и возможность продолжить проработку требований.
Что дальше?
➡️Разберём процессы Декомпозиции и Делегирования требований