Мы разрабатываем мобильные приложения под ключ более 5 лет — за это время составили свыше 50 технических заданий. Самая частая боль заказчиков — расплывчатые требования. Фраза «приложение должно работать быстро и быть удобным» не позволяет разработчику оценить трудозатраты, а QA — подготовить тест-план. Конкретика вроде «список заказов должен загружаться за не более 2 секунд на 4G при 100 одновременных пользователях» даёт точку отсчёта. Правильное ТЗ сокращает бюджет на 20–30% за счёт снижения числа вопросов в процессе разработки. В этой статье расскажем, что включить в ТЗ, чтобы избежать переделок.
Что должно быть в техническом задании для мобильного приложения?
Хорошее ТЗ решает три задачи: позволяет разработчику оценить трудозатраты, даёт критерии приёмки для заказчика и служит основой для тест-плана QA. Если документ не закрывает хотя бы одну из этих задач — он неполный.
Функциональные требования — это не «пользователь может войти в систему». Конкретика:
- Авторизация через email + пароль, Google Sign-In (
google_sign_in/ GoogleSignIn SDK), Apple Sign-In (обязательно для iOS, если доступны другие соцсети — согласно App Store Review Guidelines section 4.8). - Хранение сессии: JWT в
flutter_secure_storage/ iOS Keychain / Android Keystore, время жизни access token — 15 минут, refresh token — 30 дней. - Поведение при истечении токена: тихое обновление через interceptor, не выбрасывать пользователя на экран входа при каждом запуске.
Такой уровень детализации снимает десятки уточнений в процессе.
Какие нефункциональные требования критичны для мобильного приложения?
NFR часто упускают, но именно они влияют на UX. Пример таблицы:
| Параметр | Пример требования |
|---|---|
| Производительность | Запуск приложения (cold start) — не более 3 секунд на iPhone XR и Pixel 5 |
| Сетевой таймаут | HTTP-запросы: connect timeout 10s, receive timeout 30s |
| Офлайн | Последние 50 записей доступны без интернета |
| Размер приложения | IPA не более 50 МБ до загрузки ресурсов (App Thinning) |
| Поддерживаемые версии | iOS 15+, Android 8.0+ (API 26+) |
| Локализация | ru, en — обязательно; de, fr — в следующей версии |
| Доступность | Поддержка Dynamic Type (iOS) и font scale (Android) |
Без NFR разработчик сделает, как ему удобнее, а не как нужно для пользователя.
Как описать экран в ТЗ?
Каждый экран описывается через User Story (Как [роль], я хочу [действие], чтобы [цель]) + wireframe или ссылка на Figma + детализация поведения. Не «экран профиля», а:
Экран «Редактирование профиля»: пользователь может изменить имя (обязательно, 2–50 символов), аватар (выбор из галереи или камеры, кроппинг 1:1, максимум 5 МБ), номер телефона (валидация через SMS OTP). Изменения сохраняются по нажатию «Сохранить». При отсутствии изменений кнопка неактивна. При ошибке сети — toast с текстом ошибки, изменения не теряются.
Пример полного описания экрана: «Список заказов загружается из API с пагинацией (по 20 элементов). Поддержка pull-to-refresh. При пустом списке — заглушка с кнопкой «Создать заказ». При ошибке сети — retry-кнопка и сообщение. Если данные обновляются — показать skeleton-loader.»
Сравнение плохого и хорошего ТЗ
| Аспект | Плохой пример | Хороший пример |
|---|---|---|
| Экран | «Экран профиля» | Полное описание поведения с валидацией |
| Производительность | «Быстро» | «Cold start < 3 сек, время отклика API < 1 сек» |
| Офлайн | «Работает без интернета» | «Последние 50 записей доступны офлайн» |
| Авторизация | «Вход через соцсети» | «Google Sign-In, Apple Sign-In, email+пароль с JWT» |
Правильное ТЗ сокращает количество правок в 3 раза по сравнению с расплывчатым.
Какие API-контракты и зависимости фиксировать?
В ТЗ стоит указать внешние зависимости:
- Перечень сторонних API и SDK с конкретными версиями (Firebase, Stripe, Google Maps).
- Формат обмена с бэкендом: REST, GraphQL или WebSocket, схема авторизации (Bearer JWT, API Key, OAuth 2.0).
- Если бэкенд разрабатывается параллельно — минимальный OpenAPI 3.0 контракт для мобильной команды.
Чего не стоит писать в ТЗ
Способ реализации — зона ответственности разработчика. ТЗ описывает, что должно работать, а не как. «Использовать Flutter» — допустимо. «Использовать BLoC для управления состоянием» — техническое решение, обсуждаемое отдельно.
Процесс работы и сроки
- Интервью с заказчиком — сбор бизнес-требований, ролей, приоритетов.
- Анализ конкурентов — изучение UX-паттернов лидеров ниши.
- Написание документа — функциональные требования, NFR, экраны, API-зависимости.
- Согласование — итерации с заказчиком, уточнение граничных случаев.
Готовое ТЗ: 2–3 дня для приложения до 20 экранов. Для сложных продуктов (маркетплейс, финтех) — 4–6 дней. Стоимость рассчитывается индивидуально.
Что входит в нашу работу
Составляем ТЗ, которое закрывает все этапы: функциональные и нефункциональные требования, user stories, API-контракты, wireframe-схемы. Результат — готовый документ в Markdown или Google Docs. Дополнительно консультируем по интерпретации требований для мобильной платформы. Опыт — более 5 лет и 50+ проектов, гарантируем снятие неопределённости на этапе оценки.
Один из недавних кейсов: для клиента из сферы доставки мы составили ТЗ, которое позволило сократить время разработки на 30% и сэкономить около $1.8k–2.6k за счёт исключения спорных моментов. Свяжитесь с нами, чтобы получить консультацию по вашему проекту и узнать, как мы можем помочь составить чёткое ТЗ для вашей мобильной разработки.