Как составить ТЗ на мобильное приложение

Техническое задание (ТЗ) — это документ, без которого ни один профессиональный разработчик не начнёт работу. Это не формальность, а контракт, фиксирующий договорённости между заказчиком и исполнителем. Хорошее ТЗ экономит до 60% времени на разработку и исключает 90% конфликтов на этапе приёмки. В этой статье мы детально разберём, как составить ТЗ на мобильное приложение, и приведём реальные примеры из практики Paladin Engineering.

По данным аналитики студии, средний объём качественного ТЗ для мобильного приложения средней сложности — 80–120 страниц. На его подготовку уходит от 2 до 4 недель, а стоимость составляет 50 000–150 000 рублей. Однако эти инвестиции возвращаются сторицей: проекты с подробным ТЗ сдаются с перерасходом не более 10%, тогда как проекты без ТЗ — в среднем 60% перерасхода.

Структура идеального ТЗ: от цели до глоссария

Любое ТЗ начинается с раздела «Общие сведения», где описываются цели создания приложения, заинтересованные стороны и ограничения проекта. Далее идёт описание целевой аудитории с портретами пользователей (персоны) и сценариями использования (CJM — Customer Journey Map). Например, для приложения доставки еды будет три основных персонажа: клиент (хочет заказать за 2 минуты), курьер (хочет видеть оптимальный маршрут) и ресторан (хочет получать заказы онлайн).

Обязательные разделы ТЗ: функциональные требования (регистрация, каталог, поиск, корзина, оплата, личный кабинет), нефункциональные требования (время отклика не более 200 мс, поддержка 5000 RPS, доступность 99,9%), требования к интерфейсу (адаптация под iPhone 14–17, Android 12–16, минимальная версия ОС), требования к безопасности (HTTPS, шифрование AES-256, OAuth 2.0, двухфакторная аутентификация), требования к интеграциям (CRM, платёжные шлюзы, CDEK), порядок тестирования и приёмки.

Как писать функциональные требования: User Stories и Use Cases

Функциональные требования удобнее всего описывать в формате User Stories (пользовательских историй) с критериями приёмки (Acceptance Criteria). Пример: «Как зарегистрированный пользователь, я хочу восстановить пароль, чтобы получить доступ к аккаунту». Критерии приёмки: пользователь вводит email, система отправляет ссылку на сброс в течение 30 секунд, ссылка действительна 24 часа, новый пароль должен содержать не менее 8 символов, включать цифру и заглавную букву.

Для каждой функциональности укажите приоритет по методике MoSCoW: Must have (без чего приложение не имеет смысла), Should have (важно, но можно отложить), Could have (желательно, но не критично), Won't have (отложено на следующие версии). Это поможет подрядчику правильно распределить ресурсы. В типовом проекте распределение такое: Must have — 40% функций, Should have — 30%, Could have — 20%, Won't have — 10%.

Раздел ТЗ	Содержание	Пример	Типичные ошибки
1. Общие сведения	Цели, задачи, участники, ограничения	Цель: увеличить долю онлайн-заказов на 40% за 6 месяцев	Размытые цели без числовых метрик
2. Описание аудитории	Персоны, CJM, сценарии	Персона «Анна, 34 года, менеджер, заказывает 2 раза в неделю»	Отсутствие сценариев ошибок (что если нет интернета?)
3. Функциональные требования	User Stories, Use Cases, Acceptance Criteria	US-001: Регистрация по номеру телефона через SMS	Слишком общие формулировки («удобный интерфейс»)
4. Нефункциональные требования	Производительность, безопасность, масштабирование	Время загрузки экрана каталога ≤ 1,5 сек	Отсутствие требований к нагрузочному тестированию
5. Прототипы и дизайн	Вайрфреймы, UI-kit, style guide	Приложение должно соответствовать Human Interface Guidelines Apple	Дизайн без указания состояний (загрузка, ошибка, пустой экран)
6. Интеграции	API, вебхуки, форматы данных	Интеграция с ЮKassa через REST API, формат JSON	Нет описания обработки ошибок интеграций

Нефункциональные требования: производительность и безопасность

Нефункциональные требования определяют, как приложение работает, а не что оно делает. Ключевые параметры: время запуска приложения (не более 3 секунд), время отклика API (не более 200 мс), поддержка одновременных пользователей (минимум 1000 для старта), размер APK/IPA (не более 150 МБ), расход батареи (не более 5% за 30 минут использования). Эти требования должны быть измеримыми и проверяемыми — иначе их невозможно протестировать.

Требования к безопасности включают: передача данных только по HTTPS с TLS 1.3, хранение паролей в захэшированном виде (bcrypt, соль), защита от SQL-инъекций и XSS-атак, шифрование персональных данных на стороне клиента (AES-256-GCM), использование токенов доступа (JWT) с ограниченным временем жизни (24 часа). При обработке платежей требуется соответствие стандарту PCI DSS Level 4.

Прототипы и UI/UX-требования

Текстовая часть ТЗ обязательно дополняется визуальными материалами: вайрфреймами (схематичное расположение элементов на экране), прототипом (кликабельный макет в Figma), UI Kit (набор всех компонентов интерфейса: кнопки, поля ввода, карточки, модальные окна) и Style Guide (цветовая палитра, типографика, иконография, отступы). Качественный прототип сокращает количество уточнений на 70% и позволяет заказчику «пощупать» продукт до начала разработки.

Важно предусмотреть в прототипе все состояния экранов: загрузка (skeleton screen), пустой экран (нет данных), ошибка (нет интернета, ошибка сервера), успех (подтверждение действия), edge cases (граничные случаи, например, очень длинное имя пользователя). Каждое состояние должно быть отражено в ТЗ, иначе разработчики будут тратить время на его придумывание.

• Ошибка №1: ТЗ пишется без участия аналитика. Самостоятельное ТЗ заказчика содержит на 50% больше неточностей и противоречий, чем написанное профессионалом.
• Ошибка №2: Отсутствие глоссария терминов. Когда заказчик говорит «корзина», а разработчик понимает «черновик заказа», возникают конфликты. Определите все термины в начале документа.
• Ошибка №3: Слишком детальное описание реализации. ТЗ должно описывать ЧТО должна делать система, а не КАК (это задача архитектора и разработчиков).
• Ошибка №4: ТЗ не обновляется после изменений. Каждое изменение требований должно фиксироваться в новой версии ТЗ с указанием даты и автора правки.
• Ошибка №5: Отсутствие приоритетов. Без MoSCoW подрядчик не знает, какие функции важнее, и рискует потратить бюджет на второстепенные задачи.

Качественное ТЗ — это инвестиция в предсказуемость проекта. Студия Paladin Engineering разработала собственный шаблон ТЗ, который включает 120+ пунктов и используется во всех проектах компании. Мы поможем составить ТЗ под ваш проект за 2–4 недели. Оставьте заявку на сайте — и наш аналитик бесплатно оценит сложность вашего проекта и сроки подготовки документации.

FAQ

Можно ли использовать шаблон ТЗ из интернета?

Шаблон — хорошая основа, но каждое приложение уникально. Использование чужого ТЗ без адаптации приводит к тому, что 30–40% требований вашего проекта не будут учтены. Лучше взять шаблон как чек-лист и доработать с аналитиком.

Сколько разделов должно быть в ТЗ?

Минимальное количество разделов — 7: общие сведения, описание аудитории, функциональные требования, нефункциональные требования, требования к интерфейсу, требования к интеграциям, порядок приёмки. Для сложных проектов добавляются разделы по безопасности, локализации и аналитике.

Как часто нужно обновлять ТЗ?

ТЗ — живой документ. Он обновляется при каждом изменении функциональности: запланированном (новая версия) или незапланированном (изменение требований). Рекомендуем фиксировать версионность: v1.0 — стартовая версия, v1.1 — первое уточнение и т.д.

Что важнее: ТЗ или прототип?

Оба документа одинаково важны. ТЗ отвечает на вопрос «что делает приложение», прототип — «как оно выглядит». Прототип без ТЗ не объясняет логику работы, а ТЗ без прототипа оставляет простор для разночтений в интерфейсе.

Как проверить качество готового ТЗ?

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