Написання специфікації вимог до веб-додатку

Уявіть: команда розробки три місяці пише функціонал, а на прийманні з'ясовується, що замовник мав на увазі зовсім інше. Без детальної специфікації вимог (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 EET з повідомленням за 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 };
}

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

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

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

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

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

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

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.