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

## 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:** 

POST /api/auth/2fa/setup → { secret, qr_url, backup_codes } POST /api/auth/2fa/verify Body: { code } → { enabled: true } POST /api/auth/2fa/disable Body: { password, code } POST /api/auth/2fa/challenge Body: { code | backup_code } → { token }

 **Зберігання:** - `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() ); 

Пов'язані вимоги: FR-001 (Реєстрація), FR-002 (Вхід), NFR-SEC-003 Залежності: Бібліотека otplib або аналог, що підтримує RFC 6238

 </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 () => { // ... }); }); 

2. Коментарі до ключових рішень у коді:

// 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 }; } 

Зв'язок вимог із кодом знижує час на пошук помилок і спрощує рев'ю. У нашому досвіді це скорочує час регресійного тестування на 25%.

Як відрізнити хорошу специфікацію від поганої?

Хороша SRS проходить рев'ю у трьох груп: замовник перевіряє бізнес-правила, розробники — реалізовуваність, QA — перевірюваність. Типові проблеми неякісної специфікації:

Гарантуємо, що кожен пункт нашої SRS перевірюваний і реалізовуваний.

Що входить у нашу роботу зі створення SRS

• Документ SRS у форматі Markdown або Confluence з повним описом функціональних і нефункціональних вимог.
• Пронумеровану матрицю трасування.
• Граф залежностей вимог.
• Рев'ю документа за участю розробників і тестувальників.
• Консультації щодо уточнення вимог на всіх етапах.

Наші сертифіковані інженери мають 7+ років досвіду у веб-розробці та випустили понад 50 SRS для проєктів різної складності. За цей час ми накопичили базу готових шаблонів і рішень, що прискорює створення SRS на 20%.

Порівняння підходів до документування вимог

Терміни та вартість

Термін написання SRS для додатка з 40–60 функціональними вимогами — від трьох до чотирьох тижнів. Включає аналіз бізнес-процесів, структуровані інтерв'ю, написання, два раунди рев'ю та підсумкове узгодження. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію експерта безкоштовно.