Часто мобильные команды сталкиваются с неоднозначными требованиями: заказчик говорит одно, разработчик понимает другое, и в итоге — переработки и срывы сроков. По оценкам, до 30% времени уходит на уточнение требований, а каждый исправленный баг на поздних стадиях обходится в 3–10 раз дороже, чем на этапе спецификации. Мы решаем эту проблему, создавая SRS — формальный документ, который трассирует каждое бизнес-требование до тест-кейса. SRS обязательна, если приложение разрабатывается по контракту с SLA, продукт проходит сертификацию или команда QA работает с формальными тест-планами.
Согласно стандарту IEEE 830, SRS отличается от ТЗ четкой структурой и трассируемостью. Каждое требование имеет уникальный идентификатор, что позволяет автоматизировать проверку покрытия и избежать конфликтов. Такой подход гарантирует, что ни одно требование не потеряется. SRS обходится в 10 раз дешевле, чем устранение дефектов на этапе тестирования.
Отличие SRS от ТЗ
SRS (Software Requirements Specification) — это не просто ТЗ. Если ТЗ описывает пожелания заказчика в произвольной форме, то SRS по стандарту IEEE 830 формализует требования в структуру с нумерацией, трассировкой и проверяемыми критериями. Каждое требование атомарное, верифицируемо и имеет код (например, FR-AUTH-001). Такой подход исключает двусмысленность и снижает количество переработок в среднем на 40%.
Почему SRS критична для проектов с фикс-прайс?
При фиксированной стоимости ошибка в требованиях приводит к убыткам. SRS позволяет зафиксировать объем работ на контрактном уровне: если появляется новое требование, это change request, а не бесплатная доработка. Кроме того, трассировка требований упрощает приемку: заказчик проверяет каждый пункт по тест-кейсам. По нашим данным, проекты с SRS сдают в срок на 30% чаще.
Как правильно структурировать SRS для мобильного приложения?
Общее описание — спецификация требований к
Назначение продукта, целевая аудитория, контекстная диаграмма с внешними акторами: пользователь, бэкенд API, платежная система, push-сервис. Ограничения платформ: современные версии iOS и Android (две последние мажорные версии), поддерживаемые устройства.
Функциональные требования
Каждое требование атомарное, верифицируемое, трассируемое. Пример на Gherkin:
Scenario: Успешная запись на занятие Given пользователь авторизован And у пользователя активный абонемент с остатком > 0 When пользователь выбирает занятие со свободными местами And нажимает "Записаться" Then занятие появляется в "Мои записи" And остаток абонемента уменьшается на 1 And пользователь получает push-уведомление с подтверждением Нумерация по функциональным блокам: FR-AUTH-, FR-PAYMENT-, FR-PROFILE-*.
Нефункциональные требования
Классифицируются по ISO 25010:
- Производительность: NFR-PERF-001: время отклика API ≤ 1 секунда в 99-м перцентиле при 500 RPS.
- Безопасность: NFR-SEC-001: токены хранятся в iOS Keychain / Android Keystore.
- Доступность: NFR-ACC-001: все интерактивные элементы имеют accessibility labels.
- Портируемость: NFR-PLAT-001: поддержка минимальных устройств — iPhone SE 2nd gen, Samsung Galaxy A32.
Модели данных и бизнес-правила
Описание сущностей с клиентской точки зрения: какие поля отображает UI, валидации на клиенте, локальные вычисления.
Сценарии использования (Use Cases)
Формат UML или Gherkin для сложных сценариев. Gherkin напрямую превращается в acceptance tests.
Внешние интерфейсы
Перечень интеграций с конкретными SDK:
- Firebase Cloud Messaging SDK 10.x — push-уведомления
- Stripe iOS SDK 23.x / Android SDK 20.x — платежи
- Google Maps SDK 5.x (Android), 8.x (iOS)
| Тип требования | Пример ID | Описание |
|---|---|---|
| Функциональное | FR-AUTH-001 | Аутентификация по email и паролю |
| Нефункциональное | NFR-PERF-001 | Время отклика API ≤ 1 сек в 99% перцентиле |
| Безопасность | NFR-SEC-001 | Хранение токенов в Keychain/Keystore |
| Критерий | SRS | ТЗ |
|---|---|---|
| Структура | По IEEE 830, нумерация требований | Произвольная |
| Трассируемость | От бизнес-требования до тест-кейса | Отсутствует |
| Верификация | Каждое требование проверяемо | Часто неоднозначно |
| Использование в суде | Да, как контрактный документ | Нет |
Типичные ошибки при составлении SRS
- Смешение функциональных и нефункциональных требований в одном пункте. - Использование неверифицируемых формулировок ("удобный интерфейс"). - Отсутствие трассировки на бизнес-требования.Как написать SRS своими руками: пошаговый план
- Соберите все бизнес-требования и user stories.
- Определите внешние акторы и границы системы.
- Разбейте каждую user story на атомарные функциональные требования.
- Классифицируйте нефункциональные требования по ISO 25010.
- Опишите сценарии на Gherkin.
- Проверьте трассируемость каждого требования к источнику.
Почему стоит заказать SRS у нас?
Более 5 лет мы разрабатываем мобильные приложения и создаём спецификации для клиентов из финтеха, медицины и логистики. Наш опыт — 50+ проектов с нулевыми переработками из-за неоднозначных требований. SRS, которую мы готовим, проходит внутренний ревью и сразу готова к передаче команде разработки. Закажите написание SRS — свяжитесь с нами для оценки вашего проекта.
Что входит в работу?
В рамках подготовки SRS мы предоставляем:
- Документ в формате Word/PDF с полной структурой по IEEE 830
- Таблицу трассировки требований
- Глоссарий терминов
- Шаблон для приёмочных тестов на основе Gherkin-сценариев (20+ сценариев)
- Консультацию по доработке требований после согласования
Получите консультацию — свяжитесь с нами для уточнения деталей.