Документация в бизнес-анализе: что создаёт аналитик
Документация — главный «продукт» бизнес-анализа. Именно она остаётся после проекта и используется для разработки, тестирования, приёмки. Что входит в эту документацию?
В этой статье — какие документы создаёт бизнес-аналитик, чем они отличаются, что важно в них включить. Если хотите получить полный пакет документации — поможем.
Техническое задание (ТЗ)
ТЗ — главный документ для разработки. Он описывает, что нужно сделать, какие функции должны быть, как система должна работать.
Что входит в ТЗ
- Общее описание: цель проекта, назначение системы;
- Требования к системе: функциональные и нефункциональные;
- Архитектура: как система должна быть устроена;
- Интерфейсы: пользовательские и программные;
- Требования к данным: структура, форматы, хранение;
- Требования к безопасности: защита, аутентификация;
- Этапы разработки: что делать в первую очередь;
- Критерии приёмки: как проверяется готовность.
Форматы ТЗ
- По ГОСТ 34: для государственных и крупных корпоративных проектов;
- Agile-формат: ТЗ в виде User Stories, эпиков, критериев приёмки;
- Гибридный: сочетание структурированного документа и гибкого описания.
Функциональные требования
Функциональные требования (FR) описывают, что система должна делать: функции, операции, действия.
Как описывать
- Сценарии использования (Use Cases): как пользователь взаимодействует с системой;
- User Stories: короткие истории от лица пользователя;
- Спецификации: детальное описание каждой функции;
- Диаграммы: UML Use Case, Sequence Diagram.
Пример
FR-001: Система должна позволять пользователю зарегистрироваться с помощью email и пароля.
FR-002: Система должна отправлять письмо для подтверждения email после регистрации.
Нефункциональные требования
Нефункциональные требования (NFR) описывают, КАК система должна работать. Их часто забывают, а потом возникают проблемы: система медленная, небезопасная, не масштабируется.
Категории NFR
- Производительность: скорость отклика, время загрузки;
- Масштабируемость: способность выдерживать нагрузку;
- Безопасность: защита данных, аутентификация;
- Надёжность: доступность, устойчивость к сбоям;
- Удобство: usability, доступность;
- Сопровождаемость: лёгкость поддержки и обновления.
Пример
NFR-001: Время загрузки главной страницы не должно превышать 2 секунды.
NFR-002: Система должна выдерживать 10 000 одновременных пользователей.
User Stories
User Story — короткое описание функциональности от лица пользователя. Формат:
«Как [роль], я хочу [действие], чтобы [результат]»
Пример: «Как покупатель, я хочу добавить товар в корзину, чтобы оплатить его позже».
Критерии приёмки
К каждой User Story пишутся критерии приёмки (Acceptance Criteria) — конкретные условия, при которых история считается выполненной.
Пример критериев для истории «Добавить товар в корзину»:
- Кнопка «Добавить в корзину» есть на странице товара;
- После нажатия товар появляется в корзине;
- Счётчик корзины увеличивается на 1;
- Если товар уже в корзине — увеличивается количество, а не добавляется новая позиция;
- Уведомление о добавлении показывается пользователю.
Формат INVEST
Хорошая User Story соответствует INVEST:
- Independent — независимая;
- Negotiable — обсуждаемая;
- Valuable — ценная для пользователя;
- Estimable — оцениваемая;
- Small — маленькая;
- Testable — проверяемая.
BPMN-схемы
BPMN-схемы — визуальные модели бизнес-процессов. Они показывают, как работает процесс, кто участвует, какие решения принимаются.
В документации BPMN-схемы используются для:
- Описания текущих процессов (As-Is): как работает сейчас;
- Описания целевых процессов (To-Be): как должно быть;
- Описания сценариев: что происходит в разных ситуациях;
- Согласования: все участники видят процесс одинаково.
Подробнее о BPMN — в отдельной статье (ссылка в конце).
RACI-матрица
RACI-матрица — инструмент распределения ролей и ответственности в проекте. Она показывает, кто что делает.
Что означает RACI
- R — Responsible: кто выполняет работу;
- A — Accountable: кто принимает окончательное решение;
- C — Consulted: с кем консультируются;
- I — Informed: кого информируют.
Зачем нужна RACI
- Убирает неопределённость: кто за что отвечает;
- Помогает избежать «все отвечают, значит, никто не отвечает»;
- Помогает при приёмке: понятно, кто согласовывает;
- Помогает в коммуникации: понятно, кого информировать.
RACI-матрица часто включается в ТЗ или проектные документы.
Наши рекомендации
Какой пакет документов вы получаете
- Техническое задание: полное описание системы;
- Функциональные требования: что система делает;
- Нефункциональные требования: как система работает;
- User Stories: пользовательские истории с критериями;
- BPMN-схемы: визуальные модели процессов;
- RACI-матрица: роли и ответственность;
- Оценка трудозатрат: бюджет и сроки.
📌 Итоговый вывод
Документация — главный результат бизнес-анализа. Без неё проект превращается в хаос.
Что нужно знать:
- ТЗ: главный документ для разработки;
- Функциональные требования: что система делает;
- Нефункциональные требования: как система работает;
- User Stories: короткие истории с критериями приёмки;
- BPMN-схемы: визуальные модели процессов;
- RACI-матрица: роли и ответственность;
- Главное: документация должна быть полной, однозначной и согласованной.
Также рекомендуем: что такое бизнес-анализ, сбор требований, BPMN, методы, ошибки, все статьи о бизнес-анализе.