Написание спецификации требований к мобильному приложению
Спецификация требований (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:
Scenario: Успешная запись на занятие
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 дней. Стоимость рассчитывается после анализа объёма функциональности.