Составление технического задания на мобильную разработку
ТЗ без технических деталей — это документ для юриста, не для разработчика. «Приложение должно работать быстро и быть удобным» — не требование. «Список заказов должен загружаться за не более 2 секунд на 4G при 100 одновременных пользователях» — требование, от которого можно отталкиваться при проектировании.
Что отличает хорошее ТЗ для мобильной разработки
Хорошее ТЗ решает три проблемы одновременно: оценку трудозатрат разработчиком, входной контроль при приёмке и базу для тест-плана QA. Если документ не позволяет сделать хотя бы одно из трёх — он неполный.
Функциональные требования в мобильном контексте — это не «пользователь может войти в систему». Это:
- Авторизация через email + пароль, Google Sign-In (
google_sign_in/ GoogleSignIn SDK), Apple Sign-In (обязательно для iOS если есть другие соцсети — App Store Guideline 4.8) - Хранение сессии: JWT в
flutter_secure_storage/ iOS Keychain / Android Keystore, время жизни access token — 15 минут, refresh token — 30 дней - Поведение при истечении токена: тихое обновление через interceptor, не выбрасывать пользователя на экран входа при каждом запуске
Такой уровень детализации снимает десятки вопросов «а как должно работать» в процессе разработки.
Нефункциональные требования (NFR) — часто упускают
NFR для мобильного приложения:
| Параметр | Пример требования |
|---|---|
| Производительность | Запуск приложения (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 Stories
Структура ТЗ по экранам: каждый экран описывается через User Story (Как [роль], я хочу [действие], чтобы [цель]) + wireframe или ссылка на Figma + детализация поведения. Не «экран профиля», а:
Экран «Редактирование профиля»: пользователь может изменить имя (обязательно, 2–50 символов), аватар (выбор из галереи или камеры, кроппинг 1:1, максимум 5 МБ), номер телефона (валидация через SMS OTP). Изменения сохраняются по нажатию «Сохранить». При отсутствии изменений кнопка неактивна. При ошибке сети — toast с текстом ошибки, изменения не теряются.
API-контракты и зависимости
ТЗ должно фиксировать внешние зависимости:
- Перечень сторонних API и SDK (Firebase, Stripe, Google Maps, etc.) с конкретными версиями или минимальными требованиями
- Формат обмена данными с бэкендом: REST / GraphQL / WebSocket, схема авторизации (Bearer JWT, API Key, OAuth 2.0)
- Если бэкенд разрабатывается параллельно — минимальный OpenAPI 3.0 контракт, на который ориентируется мобильная команда
Что не нужно писать в ТЗ
Способ реализации — это зона ответственности разработчика, не заказчика. ТЗ описывает что должно работать, не как. «Использовать Flutter» — допустимо. «Использовать BLoC для управления состоянием» — уже не ТЗ, а технические решения, которые обсуждаются отдельно.
Процесс и сроки
Работа над ТЗ:
- Интервью с заказчиком — собираем бизнес-требования, роли пользователей, приоритеты функциональности
- Анализ конкурентов — если продукт в существующей нише, изучаем UX-паттерны лидеров
- Написание документа — функциональные требования, NFR, экраны, API-зависимости
- Согласование — итерации с заказчиком, уточнение граничных случаев
Готовое ТЗ: 2–3 дня для приложения до 20 экранов. Для сложных продуктов (маркетплейс, финтех) — 4–6 дней. Стоимость рассчитывается индивидуально.