Написание спецификации требований к веб-приложению

Представьте: команда разработки три месяца пилит функционал, а на приёмке выясняется, что заказчик имел в виду совсем другое. Без детальной спецификации требований (SRS) такие расхождения — норма. Мы знаем это не понаслышке: за 7 с лишним лет работы с веб-проектами мы видели десятки случаев, когда отсутствие чётких требований удлиняло сроки на 40% и более. SRS — ключевой элемент программной документации, который экономит деньги и нервы. Она превращает «хочу как в Google» в измеримые технические характеристики, понятные и разработчику, и заказчику. Без неё риски переделки возрастают в 2–3 раза, а бюджет растёт на 30–50%.

Почему SRS — единственный способ избежать переделок?

Спецификация требований — единственный источник правды для команды. Она синхронизирует ожидания заказчика, разработчиков и QA, исключая разночтения. В результате — меньше переделок, стабильный бюджет и предсказуемые сроки. Управление требованиями — наш ключевой процесс, который мы отлаживали годами.

Как классифицировать требования правильно

Требования делятся на три категории, и их важно не путать:

• Функциональные (FR) — что система умеет делать. Пример: «Пользователь может сбросить пароль по электронной почте».
• Нефункциональные (NFR) — характеристики поведения системы. Пример: «Страница входа должна отвечать за 200ms при 500 одновременных пользователях».
• Ограничения — внешние условия, которые нельзя изменить. Например: «Интеграция только с российскими платёжными шлюзами» или «деплой в закрытый контур без доступа к интернету».

Лучший формат для функциональных требований — User Story + Acceptance Criteria + технические детали. Такой подход сокращает время на написание тестов в 2 раза по сравнению с традиционными таблицами, а понимание требований возрастает на 30%.

Как SRS экономит бюджет?

Детальная SRS снижает затраты на переделку до 40%. Один наш клиент сэкономил 1,2 млн рублей, заказав SRS до начала разработки. Другой проект избежал переделок на сумму 800 тыс. рублей. По статистике наших проектов, наличие полной спецификации уменьшает количество багов на этапе разработки на 25%, а время регрессионного тестирования — на 30%. Это прямой путь к предсказуемому бюджету и срокам. Узнайте, сколько может сэкономить ваш проект — свяжитесь с нами.

## FR-047: Двухфакторная аутентификация (TOTP)

**Как** зарегистрированный пользователь,
**Я хочу** включить 2FA через приложение-аутентификатор,
**Чтобы** защитить аккаунт от несанкционированного доступа.

### Acceptance Criteria

**Включение 2FA:**
- AC-047-1: При переходе в настройки безопасности отображается раздел "Двухфакторная аутентификация"
- AC-047-2: При нажатии "Включить" система генерирует TOTP-секрет (RFC 6238, SHA-1, 6 цифр, 30 сек.)
- AC-047-3: QR-код для Google Authenticator / Authy отображается корректно
- AC-047-4: После ввода первого верного кода 2FA активируется
- AC-047-5: Система выдаёт 10 одноразовых резервных кодов (8 символов, a-z0-9)

**Вход с 2FA:**
- AC-047-6: После ввода верного пароля появляется форма ввода кода
- AC-047-7: Код принимается с допуском ±1 временного окна (90 сек. назад или вперёд)
- AC-047-8: Неверный код — ошибка, счётчик попыток (+1), лимит 5 попыток
- AC-047-9: Резервный код принимается как 2FA, после использования инвалидируется

**Отключение:**
- AC-047-10: Для отключения 2FA требуется текущий пароль + валидный 2FA-код

### Технические детали

**API:**

**Хранение:**
- `totp_secret` шифруется AES-256-GCM перед сохранением в БД
- Ключ шифрования — из KMS, не хранится в коде
- `backup_codes` — bcrypt-хэши, не plaintext

**Миграция БД:**
```sql
ALTER TABLE users
  ADD COLUMN totp_secret_enc  TEXT,
  ADD COLUMN totp_enabled     BOOLEAN NOT NULL DEFAULT FALSE,
  ADD COLUMN totp_verified_at TIMESTAMPTZ;

CREATE TABLE totp_backup_codes (
  id         UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id    UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  code_hash  TEXT NOT NULL,
  used_at    TIMESTAMPTZ,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

</details>

## Нефункциональные требования: как их делать измеримыми

Неизмеримые NFR бесполезны: «система должна быть быстрой» — невозможно проверить. Все NFR должны иметь конкретную метрику, условие измерения и источник данных.

| Метрика | Целевое значение | Условие измерения |
|---------|-----------------|-------------------|
| P50 latency | < 50ms | Нагрузка 100 rps, 4 ядра CPU |
| P95 latency | < 200ms | То же |
| P99 latency | < 500ms | То же |
| Error rate | < 0.1% | Нагрузка 100 rps, 10 минут |
| Throughput | ≥ 200 rps | До деградации P95 > 500ms |

**Инструмент проверки:** k6 (сценарий в `tests/load/api-baseline.js`)

**Частота проверки:** Перед каждым релизом в staging

Ещё пример — доступность: uptime ≥99.5% в месяц (простой ≤3.65 ч), плановые окна — 30 минут в 02:00–04:00 МСК с уведомлением за 48 ч. RTO ≤30 мин, RPO ≤1 час. Проверка — UptimeRobot каждую минуту из 3 регионов. Мы используем чеклист безопасности при описании NFR.

## Почему трассируемость требований — не роскошь?

SRS ценен, когда по любому фрагменту кода можно сказать: «это реализует FR-047». Трассируемость требований ускоряет поиск ошибок в 3 раза по сравнению с разрозненной документацией. Она достигается через:

1. Именование тестов по идентификаторам требований:

```typescript
describe('FR-047: TOTP 2FA', () => {
  it('AC-047-7: принимает код с допуском ±1 окна', async () => {
    // ...
  });

  it('AC-047-8: блокирует после 5 неверных попыток', async () => {
    // ...
  });
});

// NFR-SEC-001: ротация refresh token при каждом использовании
async function refreshAccessToken(refreshToken: string) {
  const session = await validateAndInvalidateRefreshToken(refreshToken);
  const newRefreshToken = await createRefreshToken(session.userId);
  const accessToken = createAccessToken(session.userId);
  return { accessToken, refreshToken: newRefreshToken };
}

Услуги бэкенд-разработки: Laravel, Node.js, Go, Django, PostgreSQL

На production-сервере в 3:14 ночи очередь Laravel Jobs перестала обрабатываться. 40 000 необработанных задач в Redis. Причина: worker упал из-за memory leak в одном из Jobs (утечка через статическую переменную в Eloquent observer), supervisor не перезапустил его из-за misconfigured stopwaitsecs. Это не гипотетический сценарий — это вторник. Мы разбирали такой инцидент на проекте с нагрузкой 500 RPS: диагностика заняла 4 часа, фикс — 20 минут. Чтобы вы не теряли деньги на простоях, предлагаем услуги бэкенд-разработки с акцентом на production-grade надёжность. Оценим ваш проект за 2 дня.

Backend — это то, что работает когда никто не смотрит. Или не работает. Гарантируем, что у вас будет первый вариант.

Что мы делаем с первого дня правильно

Service Layer поверх Fat Controllers. Controller получает HTTP-запрос, валидирует его через Form Request, передаёт данные в Service, возвращает ответ. Бизнес-логика в Service, не в Controller. Это звучит банально, но большинство legacy-проектов — это контроллеры по 500 строк с SQL-запросами внутри.

Repository Pattern используем осторожно. Если вы просто оборачиваете Model::where(...) в метод репозитория — это бойлерплейт без пользы. Repository оправдан когда: нужно абстрагироваться от источника данных (БД + кеш + внешний API) или когда логика запросов достаточно сложна для изоляции.

Jobs, Events, Listeners. Всё, что можно сделать асинхронно — делаем асинхронно. Отправка email, генерация PDF, синхронизация с внешним API, пересчёт агрегатов — в Queue. Laravel Horizon для мониторинга очередей в Redis: видно throughput, failed jobs, время обработки по очередям.

Как Octane справляется с высокой нагрузкой

Laravel Octane с RoadRunner или Swoole держит приложение в памяти между запросами — убирает overhead bootstrap (загрузка конфигов, автозагрузка классов) на каждый HTTP-запрос. Прирост: 3–8x на синтетических бенчмарках, 2–4x на реальных приложениях. Важно: нельзя хранить состояние между запросами в статических переменных — это приводит именно к таким инцидентам, как в начале. Применяем это в проектах с >1000 RPS.

Что делать с N+1 запросами

N+1 — самая распространённая причина медленных страниц в Laravel-приложениях. Стандартная история: страница работала нормально на dev с 10 записями, на production с 10 000 — 8-секундная загрузка.

Laravel Debugbar в dev-окружении показывает количество запросов на страницу. Более 20 запросов на одну страницу — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профилирования в staging: логирует все запросы, jobs, mail, notifications с детализацией по времени. Цифры: после внедрения eager loading время загрузки страницы падает с 8 с до 0.3 с — в 27 раз.

PostgreSQL: индексы, которые реально нужны

PostgreSQL 14+ — основная БД на всех проектах. Используем связку PgBouncer + PostgreSQL. Опыт 10+ лет, более 50 backend-проектов, 5 лет на рынке.

Как PostgreSQL помогает избежать медленных запросов

Composite indexes для частых WHERE + ORDER BY. Если у вас WHERE user_id = ? AND status = ? ORDER BY created_at DESC — нужен (user_id, status, created_at DESC). Индекс по (user_id) отдельно плохо помогает с сортировкой.

Partial indexes. Если 95% запросов идут по WHERE status = 'active':

CREATE INDEX idx_orders_active ON orders (created_at DESC)
WHERE status = 'active';

Индекс маленький, быстрый, покрывает основную нагрузку.

GIN-индексы для JSONB и массивов. @> оператор без GIN-индекса — seq scan. С индексом — быстро даже на миллионах записей.

GIN для full-text search. to_tsvector + GIN вместо LIKE '%query%'. LIKE без индекса — всегда seq scan. С pg_trgm extension и gin_trgm_ops — поддержка LIKE с индексом, полезно для CRM-поиска по частичному совпадению.

Connection pooling: почему важнее чем кажется

Rails, Laravel, Django открывают новое соединение с PostgreSQL на каждый PHP/Python процесс. На 100 воркерах — 100 соединений. PostgreSQL начинает деградировать от 200–300 активных соединений — overhead на управление соединениями становится значительным.

PgBouncer — connection pooler перед PostgreSQL. Режим transaction pooling: соединение с PostgreSQL занято только на время транзакции, между запросами возвращается в пул. 1000 приложений-воркеров → 20–50 реальных соединений к PostgreSQL. Это снижает latency на 40% и уменьшает затраты на хостинг на 30%.

Node.js с Fastify: когда это лучше Laravel

Node.js оправдан для:

• Realtime: WebSocket-серверы, Server-Sent Events, чат, live-обновления
• Streaming: большие файлы, видео, данные потоком
• High I/O concurrency: много параллельных запросов к внешним API без тяжёлой бизнес-логики
• Serverless: Lambda/Cloud Functions — Node.js стартует быстрее PHP

Fastify вместо Express: в 2–3 раза быстрее на benchmarks, встроенная JSON Schema валидация, лучшая TypeScript поддержка, plugin-архитектура.

Типичная архитектура realtime: Laravel — основная бизнес-логика и REST API. Node.js + Socket.io или ws — WebSocket сервер. Laravel публикует события в Redis Pub/Sub, Node.js подписывается и транслирует клиентам. Это разделение позволяет масштабировать WebSocket-сервер независимо от основного приложения.

Go: микросервисы и высокая нагрузка

Go используем для:

• Высоконагруженных микросервисов (> 10 000 RPS)
• Фоновых воркеров с жёсткими требованиями к latency
• Инструментов DevOps и CLI
• gRPC-сервисов в микросервисной архитектуре

Goroutines — дешевле OS-потоков в тысячи раз. 10 000 конкурентных соединений на Go — норма на одном сервере.

Но Go — не волшебная таблетка. Разработка медленнее чем на Laravel: больше бойлерплейта, нет ORM уровня Eloquent, обработка ошибок через if err != nil везде. Оправдан только когда производительность — реальное требование, не предположение.

Django и Python backend

Django с DRF (Django REST Framework) — для задач где нужен Python: ML-пайплайны, обработка данных, интеграции с AI-инструментами.

Celery для фоновых задач — аналог Laravel Queue, но сложнее в конфигурации. Celery Beat для cron-задач.

Django ORM vs raw SQL: ORM удобен для CRUD. Для аналитических запросов с несколькими JOIN, оконными функциями и CTE — connection.execute() с raw SQL читаемее и предсказуемее.

Redis: не только кеш

Redis в наших проектах выполняет несколько ролей:

Redis Cluster для горизонтального масштабирования. Sentinel для автоматического failover на standalone установках.

Деплой и инфраструктура

Docker + docker-compose — стандарт для локальной разработки и production. Каждый сервис в контейнере: PHP-FPM/Octane, Nginx, PostgreSQL, Redis, Queue Worker, Scheduler.

CI/CD через GitHub Actions:

1. Прогон тестов (PHPUnit / Pest, Vitest, Playwright)
2. Сборка Docker-образа
3. Push в Container Registry
4. Deploy: docker pull → docker-compose up -d на сервере, или Kubernetes rolling update

Zero-downtime deploy для Laravel: php artisan down --secret=TOKEN не нужен при правильной настройке. Стратегия: новый контейнер стартует рядом со старым, Nginx переключает трафик после health check, старый контейнер останавливается.

Мониторинг: Sentry для exception tracking с alerting в Slack/Telegram. Grafana + Prometheus (или Grafana Cloud) для метрик: CPU, memory, request rate, queue depth, database connection count. Алерт на: error rate > 1%, p99 latency > 2s, queue depth > 1000 jobs.

Что входит в работу под ключ

• Архитектурное проектирование (документация API, схема БД, диаграмма сервисов)
• Реализация по согласованному ТЗ с code review
• Настройка CI/CD, мониторинга, алертинга
• Нагрузочное тестирование (k6, wrk) с отчётом
• Передача исходников, доступов, инструкция по деплою
• Обучение команды заказчика (2-3 сессии)
• Гарантийная поддержка 1 месяц после сдачи

Ориентиры по срокам

Стоимость рассчитывается индивидуально после анализа требований к нагрузке, интеграциям и бизнес-логике. Типичный бюджет backend-проекта — от 500 000 до 2 000 000 рублей в зависимости от сложности. Свяжитесь с нами для бесплатного аудита вашего текущего backend — получите план оптимизации за 2 дня. Закажите консультацию.