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

## 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 МСК с уведомлением за 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 функциональными требованиями — от трёх до четырёх недель. Включает анализ бизнес-процессов, структурированные интервью, написание, два раунда ревью и итоговое согласование. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта. Получите консультацию эксперта бесплатно.