ТЗ на мобильное приложение: экраны, роли, сценарии и требования

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

Структура документа

1. Цель и контекст
2. Роли пользователей
3. Пользовательские сценарии
4. Список экранов и их содержимое
5. Административная панель
6. Интеграции
7. Нефункциональные требования
8. Платформы и устройства
9. Критерии приёмки
10. Что не входит в проект

Цель и контекст

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

Роли

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

Сценарии

Сценарий — это последовательность действий пользователя ради цели. Пример формулировки:

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

Для каждого сценария полезно описать и альтернативные ветки: нет сети, оплата не прошла, пользователь закрыл приложение на середине.

Экраны

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

• Онбординг и запрос разрешений
• Вход и восстановление доступа
• Пустые состояния: нет заказов, ничего не найдено
• Ошибки и отсутствие подключения
• Настройки, язык, выход из аккаунта, удаление аккаунта

Административная панель

Опишите так же подробно, как приложение. Кто из сотрудников туда входит, что меняет, какие отчёты нужны, кто отправляет уведомления. Если админку описать фразой «управление контентом», оценки разных команд сильно разойдутся.

Интеграции

Таблица: система, направление обмена, какие данные, частота. Например, учётная система, платёжные сервисы, SMS-шлюз для кодов, карты, CRM. Если у системы есть документация API, приложите её или ссылку на поставщика.

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

• Поддерживаемые версии iOS и Android
• Языки интерфейса: узбекский, русский, при необходимости английский
• Ожидаемое число пользователей и пиковая нагрузка
• Требования к скорости загрузки ключевых экранов
• Безопасность: хранение персональных данных, шифрование, сроки сессии
• Аналитика: какие события отслеживать

Критерии приёмки

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

Что не входит

Явно перечислите, что исполнитель не делает: наполнение контентом, перевод текстов, продвижение, оплата сторонних сервисов. Это защищает обе стороны.

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

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

Если сами собрать ТЗ сложно, его можно заказать как отдельный этап аналитики — с интервью и прототипом. Мы делаем такой этап и передаём документ, с которым можно идти к любой команде.