ТЗ на личный кабинет: чек-лист для заказчика

Начните с цели и границ первой версии

Запишите проблему без названия технологии. Например: «Клиенты звонят менеджерам, чтобы узнать статус заказа и получить счёт». Тогда первая версия кабинета должна закрыть просмотр статуса и получение документов. Чат и программа лояльности могут остаться за пределами запуска.

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

Роли, организации и доступ к данным

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

OWASP рекомендует проверять разрешения на каждом запросе и по умолчанию запрещать доступ. Скрытая кнопка в интерфейсе не заменяет проверку на сервере. Поэтому ТЗ должно описывать доступ к объекту, а не только видимость раздела.

Регистрация, проверка телефона и второй фактор

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

Опишите срок действия кода, лимит попыток, повторную отправку, ошибки провайдера и смену номера. Для второго фактора отдельно согласуйте подключение, резервный способ восстановления и действия поддержки. Рекомендации OWASP подчёркивают значение безопасного восстановления и защиты от перебора; конкретный механизм выбирается по рискам продукта.

• Как создаётся учётная запись: самостоятельно или по приглашению?
• Что происходит с повторной регистрацией того же контакта?
• Как восстанавливается доступ при потере телефона?
• Когда завершаются активные сессии?
• Какие события попадают в журнал безопасности?

Опишите сценарий так, чтобы его можно было проверить

Возьмём скачивание счёта. Предусловие: пользователь вошёл и имеет доступ к заказу. Действие: выбирает документ. Ожидаемый результат: получает актуальный файл нужного заказа. Исключения: файл ещё не готов, внешний сервис недоступен, доступ отозван.

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

Интеграции и нефункциональные требования

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

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

Что передать команде для начала оценки

Соберите один пакет: краткую цель, роли, сценарии, примеры документов, список интеграций и приоритеты. Непрояснённые вопросы вынесите отдельно. Это позволяет оценить, где достаточно обсуждения, а где нужен исследовательский этап.

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

• Цель и критерий полезности продукта.
• Роли и матрица доступа.
• Сценарии с исключениями.
• Состав первой версии и отложенные функции.
• Условия приёмки и передачи материалов.