Ми розробляємо мобільні застосунки під ключ більше 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% і зекономити близько 200 000 гривень за рахунок виключення спірних моментів. Зв'яжіться з нами, щоб отримати консультацію щодо вашого проєкту і дізнатися, як ми можемо допомогти скласти чітке ТЗ для вашої мобільної розробки.