MMaketa · шаблон ТЗ

Шаблон технического задания на мобильное приложение

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

Обновлено 1 сентября 2026 · студия demda.pro

Забрать файлом

Без регистрации и без формы «оставьте почту». .docx — если правите в Word и согласовываете с юристом, .md — если ведёте документацию в репозитории.

Зачем читать разбор. Шаблон говорит, что заполнить, а страница-разборпочему именно это и какие формулировки снимают споры на приёмке. Если времени мало, прочитайте хотя бы разделы 6 и 10: на состояния экрана приходится больше всего доработок «сверх ТЗ», а без критериев приёмки документ не работает вообще.

Техническое задание на разработку мобильного приложения

  • Проект: название
  • Заказчик: организация или ФИО
  • Исполнитель: организация
  • Редакция: номер от дата
  • Кто отвечает за документ со стороны заказчика: ФИО, контакт

Заполняйте по порядку. Если на вопрос нет ответа — так и напишите: «решение не принято, срок принятия — дата». Пустой раздел хуже честного «не решили»: пустой будет молча решён за вас.

1. Что это и зачем

Приложение одним абзацем: что делает и для кого

Метрика успеха: цифра и срок

Например: «за первый месяц — 200 регистраций и 50 оформленных заказов». Без цифры этот раздел не имеет смысла.

Чего в первой версии НЕ будет:

Самый ценный список в документе. Чем он длиннее, тем меньше шансов на срыв срока.

2. Пользователи и роли

РольЧто доступноКак человек получает эту роль
Гость
Клиентсам регистрируется / заводит менеджер

3. Платформы и устройства

  • Платформы: iOS / Android / обе, минимальные версии ОС:
  • Устройства: телефоны / планшеты. Планшет — отдельная раскладка и отдельные деньги.
  • Ориентация: только вертикальная / обе
  • Работа без интернета: не нужна / просмотр сохранённого / полноценная
  • Где публикуемся: App Store / Google Play / RuStore / APK на сайте
  • Кто отвечает за публикацию и на чьём аккаунте разработчика:

4. Экраны и переходы

Макет: ссылка на кликабельный макет

Переходы в макете работают — откройте и пройдите сценарий. Если макета ещё нет, он собирается за вечер без дизайнера.

ЭкранНазначениеКуда ведёт
Главная

Не описывайте расположение элементов словами — это видно на макете, а дублирование создаёт противоречия при следующей правке.

5. Функциональные требования

Пишите сценариями пользователя. У каждого — пометка «обязательно» или «желательно». Формулировка должна быть такой, чтобы на приёмке можно было сказать «сделано» или «не сделано» и не поспорить.

5.1 Название сценария — обязательно
Кто, что делает, что происходит в результате, что человек видит после.

5.2 — желательно

Ограничения данных:

ПолеОграничение
Названиедо 120 символов
Телефонформат +7XXXXXXXXXX

6. Состояния, ошибки и пустота

Раздел, из-за отсутствия которого возникает больше всего доработок «сверх ТЗ». Заполните по каждому важному экрану.

СитуацияЧто показываем и что можно сделать дальше
Данных ещё нет
Идёт загрузка
Нет интернета
Ошибка сервера
Форма заполнена неверно
Данные не влезают (длинное название, нет фото)
Повторное нажатие кнопки
Нет прав

7. Интеграции и внешние сервисы

СервисЧто делаемКто даёт доступыК какому числуЧто если сервис недоступен
Оплатазаказчикдата
Пуш-уведомления

Срыв сроков в мобильной разработке чаще происходит из-за ожидания доступов, чем из-за кода. Поэтому колонка «к какому числу» — обязательная.

8. Данные, приватность и требования площадок

  • Какие персональные данные собираем и зачем:
  • Политика обработки данных: ссылка; должна быть доступна публично до подачи в стор
  • Удаление аккаунта: экран в приложении + публичная страница — требуется правилами Google Play для приложений с регистрацией
  • Запрашиваемые разрешения и обоснование каждого: камера / геопозиция / уведомления / галерея
  • Возрастной рейтинг, проверка возраста, родительское согласие:
  • Аналитика: инструмент; попадают ли туда персональные данные

Требования площадок и законодательства меняются. Перед стартом сверьтесь с актуальными правилами App Store, Google Play и RuStore, а формулировки про персональные данные согласуйте с юристом: шаблон даёт структуру, а не юридическую консультацию.

9. Дизайн

  • Дизайн: готовый макет в Figma / заказываем у исполнителя / делаем на системных компонентах без дизайна
  • Логотип, цвета, шрифты: есть гайдлайн / нет; у кого исходники
  • Тёмная тема: нужна / не нужна. «Нужна» примерно удваивает работу по интерфейсу.
  • Иконка приложения и экран запуска: кто делает
  • Языки интерфейса:

10. Приёмка

  • Как принимаем: сборка на устройстве заказчика, прохождение сценариев раздела 5
  • Срок проверки: N рабочих дней. Формат замечаний:
  • Что считается ошибкой: расхождение с настоящим ТЗ или с макетом. Всё, чего нет в ТЗ и в макете, — новая задача и оценивается отдельно.
  • Классы ошибок и сроки исправления — таблица ниже.
  • Что передаётся: исходный код и где лежит, сборки, доступы к сторам, инструкция на публикацию, документация на API
  • Гарантия: срок; что в неё не входит
  • Порядок изменений: как оформляется новая задача, кто оценивает, что происходит со сроком
КлассОпределениеСрок
Блокирующаяпользоваться невозможно
Серьёзнаясценарий работает с обходом
Косметическаяне мешает работе

Раздел 4 закрывается ссылкой, а не описанием

Соберите экраны мышкой, свяжите переходами и вставьте в шаблон одну ссылку. Бесплатно, в браузере, без регистрации.