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

Шаблон. Разбор каждого раздела — https://maketa.pro/kak/tz-na-prilozhenie/

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

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

---

## 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>
- **Гарантия:** <срок; что в неё не входит>
- **Порядок изменений:** <как оформляется новая задача, кто оценивает,
  что происходит со сроком>

---

*Шаблон подготовлен студией demda.pro (https://demda.pro/). Пользуйтесь свободно,
в том числе в коммерческих проектах. Разбор каждого раздела — на странице
«Техническое задание на мобильное приложение: что в нём должно быть»:
https://maketa.pro/kak/tz-na-prilozhenie/*

*Макет экранов для раздела 4 собирается за вечер в Maketa: https://maketa.pro/app/*