Техническое задание на мобильное приложение — это документ, по которому команда может оценить проект, а заказчик — принять результат. В хорошем ТЗ есть цель продукта, роли пользователей, ключевые сценарии, список экранов, интеграции, нефункциональные требования (платформы, безопасность, требования App Store, Google Play и 152-ФЗ) и критерии приёмки. Для MVP хватает 10–15 страниц, для продукта с личным кабинетом, оплатой и своим бэкендом — 30–60.
Ниже — структура, которую мы используем на этапе аналитики, что писать в каждом разделе, какие требования чаще всего забывают и как понять, что ТЗ готово к оценке.
Зачем ТЗ, если есть бриф и макеты
Бриф отвечает на вопрос «что мы хотим», ТЗ — «что именно будет сделано и как это проверить». Разница видна на смете: по брифу студия может назвать только вилку, по ТЗ — цену и срок, которые попадут в договор.
ТЗ решает три задачи:
- Оценка. Команда видит все экраны, роли и интеграции и считает их, а не угадывает. Расхождение между оценками разных подрядчиков по одному ТЗ резко сокращается.
- Границы проекта. Всё, чего нет в документе, — новая задача. Это защищает обе стороны: заказчик не платит за то, чего не просил, студия не делает бесплатно то, что не было оценено.
- Приёмка. У каждого сценария есть критерий «готово». Спор «мы так не договаривались» превращается в сверку с документом.
Макеты ТЗ не заменяют. Они показывают, как выглядит экран, но не описывают, что происходит при ошибке оплаты, кто видит чужие заказы и сколько хранятся данные.
Структура ТЗ на мобильное приложение
Мы собираем ТЗ из девяти разделов. Порядок важен: каждый следующий опирается на предыдущий.
| Раздел | Что внутри | Кто заполняет |
|---|---|---|
| 1. Цели и метрики | Зачем продукт, какую проблему решает, как поймём, что запуск удался | Заказчик |
| 2. Аудитория и роли | Кто пользуется, какие роли и права | Заказчик + аналитик |
| 3. Пользовательские сценарии | Пошаговые сценарии для каждой роли | Аналитик |
| 4. Экраны и навигация | Список экранов, переходы, состояния | Аналитик + дизайнер |
| 5. Функциональные требования | Правила, расчёты, статусы, уведомления | Аналитик |
| 6. Интеграции и бэкенд | API, платежи, CRM, карты, push, админка | Техлид |
| 7. Нефункциональные требования | Платформы, производительность, безопасность, законы, требования сторов | Техлид |
| 8. Контент и аналитика | Тексты, медиа, события аналитики | Заказчик + аналитик |
| 9. Этапы и приёмка | Что входит в каждый этап, критерии готовности | Вместе |
1. Цели и метрики
Одна-две фразы о проблеме и 3–5 измеримых целей. «Удобное приложение для клиентов» — не цель. «Перевести 30% повторных заказов из звонков в приложение за полгода» — цель: из неё понятно, что критичны быстрый повторный заказ, push-уведомления и история заказов, а лента новостей может подождать.
Здесь же — что точно не входит в первую версию. Этот список экономит больше бюджета, чем любой другой раздел ТЗ.
2. Аудитория и роли
Перечислите всех, кто работает с системой: покупатель, курьер, менеджер, администратор. Для каждой роли — что она может видеть и делать. Ошибка на этом этапе стоит дорого: роль «менеджер филиала», найденная в середине разработки, меняет модель данных, API и половину экранов админки.
3. Пользовательские сценарии
Сценарий — это путь пользователя к результату, а не список кнопок:
Покупатель открывает приложение → видит последние заказы → нажимает «Повторить» → проверяет состав и адрес → оплачивает сохранённой картой → получает push о статусе.
Для каждого сценария опишите и негативные ветки: нет интернета, оплата отклонена, товар закончился, сессия истекла. На них приходится заметная часть объёма разработки, и именно их чаще всего нет в ТЗ.
4. Экраны и навигация
Список экранов с назначением и основными элементами, схема переходов и состояния каждого экрана: загрузка, пусто, ошибка, нет доступа. Количество экранов — главный драйвер сметы: MVP — это обычно 5–10 экранов, продукт с личным кабинетом и оплатой — 15–30 (подробнее о бюджетах — в статье про стоимость MVP мобильного приложения).
Если макетов ещё нет, хватит прототипа или даже схемы на бумаге. Дизайн можно делать после ТЗ — это отдельный этап UX/UI дизайна.
5. Функциональные требования
Всё, что приложение делает «под капотом»: правила расчёта цены и скидок, жизненный цикл заказа и его статусы, кто и когда получает уведомление, что происходит с данными при удалении аккаунта. Удобный формат — таблица «условие → действие → результат». Формулировки должны быть проверяемыми: не «быстрый поиск», а «результаты поиска появляются после ввода трёх символов».
6. Интеграции и бэкенд
Для каждой внешней системы — что передаём, в какую сторону, как часто и что делаем при её недоступности:
- Платежи: эквайринг, СБП, сохранённые карты, возвраты. Отдельно — нужны ли покупки внутри приложения: цифровой контент и подписки в iOS и Android по правилам сторов обычно продаются через их платёжные системы.
- Учёт и CRM: 1С, amoCRM, Bitrix24 — какие сущности синхронизируются.
- Карты и геолокация: провайдер карт, нужна ли фоновая геолокация (её сторы проверяют особенно строго).
- Push-уведомления: через APNs и Firebase Cloud Messaging, какие события их вызывают.
- Авторизация: телефон и SMS, почта, вход через сервисы. Если в приложении есть вход через сторонние аккаунты, Apple требует предложить и вариант с сопоставимой приватностью — обычно это Sign in with Apple.
- Админка: что меняет оператор без участия разработчиков — каталог, баннеры, тексты, статусы.
Если бэкенда ещё нет, это самый крупный блок после мобильной разработки. Если он есть — к ТЗ нужна документация API или доступ к тестовому стенду.
7. Нефункциональные требования
Раздел, который чаще всего пуст, а потом превращается в «срочные доработки перед релизом»:
- Платформы и версии ОС. Например, iOS 15+ и Android 8+. Каждая старая версия — дополнительное тестирование. Здесь же — выбор подхода: нативно, Flutter или Kotlin Multiplatform (сравнение — в статье Flutter или Kotlin Multiplatform).
- Магазины приложений. App Store, Google Play, нужна ли публикация в RuStore и AppGallery. От кого публикуемся — от аккаунта заказчика или студии.
- Требования сторов. Удаление аккаунта прямо из приложения (обязательно в App Store и Google Play), политика конфиденциальности, описание собираемых данных, обоснование доступа к камере, геолокации и контактам. Как проходит ревью — в материале про публикацию в App Store и Google Play.
- Персональные данные. Если приложение собирает данные граждан РФ, по 152-ФЗ их первичный сбор и хранение должны идти в базах данных на территории России. Это влияет на выбор хостинга и сторонних сервисов, поэтому решается до архитектуры, а не после.
- Безопасность. Хранение токенов, шифрование, блокировка после неудачных попыток входа, требования службы безопасности заказчика.
- Производительность и офлайн. Что работает без сети, сколько пользователей одновременно, допустимое время отклика.
8. Контент и аналитика
Кто и когда готовит тексты, фото, юридические документы и описания для сторов. И какие события фиксирует аналитика: регистрация, первый заказ, отказ на шаге оплаты. Список событий в ТЗ — единственный способ после запуска понять, где теряются пользователи, а не гадать.
9. Этапы и критерии приёмки
Разбейте проект на этапы с результатом, который можно потрогать: сборка в TestFlight, демо на тестовом стенде, публикация. Для каждого сценария — критерий приёмки и окружение, в котором его проверяют. Здесь же — гарантийный срок, порядок исправления ошибок и передача исходников.
Частые ошибки в ТЗ
- Описан интерфейс, но не логика. Есть кнопка «Оформить заказ», но не сказано, что будет, если товар закончился между корзиной и оплатой.
- Нет ролей и прав. Админка оценена как «одна страница», а на деле нужны три уровня доступа.
- «Как у конкурента». Ссылка на чужое приложение — хорошая иллюстрация, но не требование: команда не видит бэкенда и правил, которые за ним стоят.
- Всё в первой версии. Чат, лента, бонусы, рефералка и тёмная тема в MVP удваивают бюджет и откладывают проверку гипотезы.
- Забыты требования сторов и законов. Удаление аккаунта, политика конфиденциальности, локализация данных — каждое из этих требований может остановить релиз на несколько недель.
- Нет критериев приёмки. Без них последний месяц проекта уходит на споры, а не на запуск.
Чек-лист: ТЗ готово к оценке, если…
- Есть 3–5 измеримых целей и список того, что не входит в первую версию.
- Перечислены все роли и их права.
- Для каждой роли описаны сценарии, включая ошибки и пустые состояния.
- Есть полный список экранов и схема переходов.
- Для каждой интеграции понятно, что передаётся и что происходит при сбое.
- Указаны платформы, версии ОС и магазины для публикации.
- Учтены требования App Store и Google Play и 152-ФЗ.
- Перечислены события аналитики.
- Проект разбит на этапы с критериями приёмки.
Если хотя бы три пункта пустые, точной оценки не будет — только вилка «от и до» с большим разбросом.
Как мы составляем ТЗ в DailyCode
ТЗ — первый этап каждого проекта по разработке мобильных приложений:
- Бриф. Созвон и анкета: цели, аудитория, ограничения по бюджету и срокам. Подписываем NDA, если нужно, — до первого обсуждения.
- Аналитика (1–2 недели). Аналитик описывает роли, сценарии и экраны, техлид — архитектуру, интеграции и нефункциональные требования. Предлагаем, что вынести во второй этап.
- Смета и договор. По ТЗ считаем стоимость и срок и фиксируем их в договоре. ТЗ становится приложением к нему.
- Разработка спринтами по 2 недели. В конце каждого — демо и сборка в TestFlight или APK. Изменения требований оформляем письменно и оцениваем до начала работ.
Если у вас уже есть бриф или черновик ТЗ — пришлите его нам: посмотрим, чего не хватает для точной оценки, и назовём ориентир по бюджету и срокам.
Частые вопросы
Кто должен писать ТЗ — заказчик или студия?
Цели, аудиторию, бизнес-правила и ограничения формулирует заказчик — их никто, кроме него, не знает. Техническую часть — архитектуру, интеграции, нефункциональные требования, оценку — пишет студия. На практике заказчик приносит бриф или черновик, а финальное ТЗ собирается вместе на этапе аналитики за 1–2 недели и становится приложением к договору.
Сколько стоит составление ТЗ на мобильное приложение?
Если ТЗ пишет студия, это отдельный этап аналитики — обычно 1–2 недели работы аналитика и техлида, и его стоимость входит в смету проекта. До начала этапа стоит договориться, остаётся ли документ у вас, если дальше вы решите работать с другой командой: хорошее ТЗ пригодно для оценки любым подрядчиком.
Можно ли начать разработку без ТЗ?
Можно, если работать по времени и материалам — короткими спринтами с приоритизированным бэклогом. Но фиксированную цену и срок без ТЗ не назовёт ни одна добросовестная команда: оценивать нечего. Для MVP компромисс — короткое ТЗ на 10–15 страниц с ключевыми сценариями и списком экранов, а детали уточняются в спринтах.
Нужно ли оформлять ТЗ по ГОСТ 34.602?
Для коммерческого мобильного приложения — нет. ГОСТ 34.602-2020 написан для автоматизированных систем и обычно требуется в госзаказе и крупных корпоративных тендерах. Если он обязателен, структуру ГОСТа можно заполнить тем же содержанием — целями, функциями, требованиями и порядком приёмки, — что и в обычном ТЗ.
Что делать, если требования изменились по ходу разработки?
Это нормально — продукт уточняется, когда появляются первые сборки. Изменения фиксируются письменно, команда оценивает их влияние на срок и бюджет, и после согласования они оформляются дополнительным соглашением или переносятся во второй этап. Чем подробнее исходное ТЗ, тем проще отделить «уточнение» от «новой функции».