Системный аналитик и ТЗ: кто и как пишет требования

Когда заказчик говорит «нам нужна система для склада», разработчикам этого мало. Между пожеланием бизнеса и строкой кода стоит человек, который превращает разговоры в проверяемые требования, — системный аналитик. От качества его работы зависит, будет ли смета точной, а продукт — тем, что действительно нужно.

Кто такой системный аналитик

Это специалист на стыке бизнеса и разработки. Он понимает, как устроены процессы компании, и знает, как устроены программные системы: базы данных, API, роли и права, интеграции. Бизнес-аналитик отвечает на вопрос «что и зачем нужно компании», системный — «как это должна делать система». В небольших командах обе роли часто совмещает один человек.

Что аналитик делает до написания документа

1. Проводит интервью с пользователями будущей системы: кладовщиками, менеджерами, бухгалтером, руководителем. Каждый видит процесс со своей стороны.
2. Изучает текущие документы, таблицы, выгрузки из учётной системы, формы отчётов.
3. Рисует процесс «как есть» и находит в нём узкие места.
4. Согласует с заказчиком процесс «как будет» и границы проекта: что входит в первую версию, что откладывается.
5. Выясняет ограничения: какие системы уже работают, где хранятся данные, какие требования к безопасности.

Из чего состоит ТЗ системного аналитика

• Цели и границы системы, список ролей пользователей
• Сценарии использования: кто, что и в какой последовательности делает
• Функциональные требования, сгруппированные по модулям
• Модель данных: сущности, их атрибуты и связи
• Описание интеграций: какие данные, в какую сторону, как часто, что делать при ошибке
• Нефункциональные требования: скорость, доступность, резервное копирование, журналирование
• Макеты или прототипы ключевых экранов
• Критерии приёмки для каждой функции

Как формулируются хорошие требования

Требование должно быть однозначным и проверяемым. Плохо: «система должна быстро формировать отчёты». Хорошо: «отчёт по остаткам по всем складам формируется по нажатию кнопки, без ожидания ночной обработки, с фильтром по складу и группе товаров». Плохо: «удобный поиск». Хорошо: «поиск товара по части названия, артикулу или штрихкоду, результаты появляются по мере ввода».

Хороший аналитик избегает слов «удобно», «быстро», «и т. д.», «при необходимости». Каждое такое слово — место будущего спора при приёмке.

Артефакты, кроме текста

Текст плохо передаёт логику. Поэтому аналитик использует диаграммы процессов, схемы состояний (например, жизненный цикл заказа от «создан» до «закрыт»), диаграммы последовательности для интеграций, таблицы прав доступа «роль — действие». Разработчик быстрее понимает схему из пяти блоков, чем две страницы описаний.

Типичные ошибки

• Требования записаны со слов одного руководителя, без общения с реальными пользователями
• Описан только «счастливый путь», а ошибки и исключения забыты: что если товара нет, оплата не прошла, клиент отменил заказ
• Нет приоритетов, и всё кажется одинаково важным
• Документ не обновляется: решения, принятые в переписке, в ТЗ не попадают
• Аналитик проектирует интерфейс до мелочей, а логику данных оставляет размытой

Как заказчику проверить работу аналитика

Попросите аналитика пересказать ваш процесс своими словами на конкретном примере: один заказ от поступления до отгрузки. Пройдите по ТЗ с ключевыми сотрудниками: узнают ли они свою работу. Проверьте, есть ли у каждой функции критерий приёмки. Спросите, какие вопросы остались открытыми, — честный список открытых вопросов лучше видимости полной ясности.

Когда аналитик нужен обязательно

При разработке учётных систем, CRM под нестандартные процессы, интеграций нескольких систем, проектов с несколькими ролями и сложными правами. Для простого лендинга или бота с тремя кнопками отдельный аналитик избыточен: требования соберёт менеджер проекта. Если вы планируете систему и не уверены, хватит ли вам собственного описания, — можно начать с аналитического этапа отдельно от разработки.