Написання специфікації вимог до мобільного додатка
Специфікація вимог (SRS — Software Requirements Specification) — формальніший документ, ніж ТЗ. Якщо ТЗ описує «що замовник хоче», SRS формалізує це у структуру, яку можна трасувати: від бізнес-вимоги → системної вимоги → тест-кейса. Потрібна командам з чіткими процесами або коли додаток розробляється за контрактом з SLA.
Структура SRS для мобільного додатка
Стандарт IEEE 830 задає базову структуру, але для мобільної розробки її адаптують. Ключові розділи:
1. Загальне описання
- Призначення продукту та цільова аудиторія
- Контекстна діаграма: додаток як «чорна скриня» з зовнішніми акторами (користувач, бекенд API, система платежів, push-сервіс)
- Обмеження платформи: iOS 15+ / Android 9+ (API 28+), підтримані пристрої
2. Функціональні вимоги
Кожна вимога — атомарна, верифікована, трасована:
FR-AUTH-001: Додаток має підтримувати аутентифікацію за email та паролем. FR-AUTH-002: Додаток має підтримувати Sign in with Apple на iOS (обов'язково при наявності інших OAuth-провайдерів — App Store Guideline 4.8). FR-AUTH-003: Сесія має відновлюватися автоматично при запуску додатка, якщо refresh token не істік.
Нумерація по функціональних блоках: FR-AUTH-*, FR-PAYMENT-*, FR-PROFILE-*. Трасованість: кожен FR-код посилається на User Story або бізнес-вимогу.
3. Нефункціональні вимоги
Класифіковані за ISO 25010:
-
Продуктивність:
NFR-PERF-001: Час відклику API-запитів не має перевищувати 2 секунди в 95-му перцентилі при навантаженні 500 RPS -
Безпека:
NFR-SEC-001: Токени авторизації зберігаються в iOS Keychain / Android Keystore, не в SharedPreferences -
Доступність:
NFR-ACC-001: Всі інтерактивні елементи мають accessibility labels для підтримки VoiceOver (iOS) та TalkBack (Android) -
Портованість:
NFR-PLAT-001: Додаток підтримує iPhone SE 2nd gen (4.7") та Samsung Galaxy A32 як мінімальні цільові пристрої
4. Моделі даних та бізнес-правила
Не ER-діаграма бекенда, а описання сутностей з клієнтської точки зору: які поля відображає UI, які валідації застосовуються на клієнті, які вичислюються локально.
5. Сценарії використання (Use Cases)
Формат UML Use Case або Gherkin (Given / When / Then) для складних сценаріїв. Gherkin зручна тим, що напряму перетворюється у acceptance tests:
Сценарій: Успішна запись на заняття
Given користувач авторизований
And у користувача активний абонемент з остатком > 0
When користувач вибирає заняття зі вільними місцями
And натискає "Записатися"
Then заняття з'являється в "Мої записи"
And остаток абонемента зменшується на 1
And користувач отримує push-сповіщення з підтвердженням
6. Зовнішні інтерфейси
Перелік інтеграцій з конкретними SDK та версіями:
- Firebase Cloud Messaging SDK 10.x — push-сповіщення
- Stripe iOS SDK 23.x / Stripe Android SDK 20.x — платежі
- Google Maps SDK 5.x (Android), 8.x (iOS) — картографічні функції
Відмінність SRS від ТЗ на практиці
ТЗ — робочий документ для команди, може бути неформальним. SRS — контрактний документ з чіткою нумерацією, трасованістю та acceptance criteria. SRS потрібен, якщо:
- Розробка ведеться командами на аутсорсі з фіксованою ціною по scope
- Продукт проходить сертифікацію (медичні додатки, ліцензовані фінтех)
- Команда QA працює за формальними тест-планами з трасованістю до вимог
Строки
SRS для додатка 15–25 екранів: 2–3 дні. Для складних продуктів з кількома ролями, інтеграціями та compliance-вимогами: 4–6 днів. Вартість розраховується індивідуально після аналізу обсягу функціональності.