Какие знаешь категории NFR?

Категории Non-Functional Requirements (NFR): Полный справочник

NFR (Non-Functional Requirements) — это требования к тому, КАК система работает, а не ЧТО она делает. За 10+ лет я видел, что именно NFR часто игнорируют, а потом платят дорогой ценой. Расскажу о всех важных категориях и как я их документирую.

Определение NFR

Functional Requirement (FR): "Система должна позволить пользователю создать заказ"

Non-Functional Requirement (NFR): "Создание заказа должно занять < 2 секунд", "Система должна обслуживать 10K одновременных пользователей"

FR отвечает на "Что?", NFR отвечает на "Как хорошо?"

Категория 1: Performance (Производительность)

Это требования о скорости и эффективности.

1.1 Response Time (Время ответа)

Определение: Сколько времени занимает операция?

Примеры:

• "GET /api/products должен ответить за < 200ms"
• "Search по 1M товарам должен ответить за < 500ms"
• "File upload 100MB должен закончиться за < 5 минут"

Как я документирую:

PERFORMANCE: Response Time
├─ API endpoints: < 200ms (p95)
├─ Search: < 500ms (p95)
├─ File uploads: < 5min for 100MB
└─ Page load: < 2 seconds (First Contentful Paint)

p95 означает: 95% запросов ответят за это время. 5% могут быть медленнее.

1.2 Throughput (Пропускная способность)

Определение: Сколько операций в секунду система может обработать?

Примеры:

• "Система должна обработать 1000 заказов в секунду"
• "API должна обслуживать 10,000 запросов в секунду"
• "Database должна выполнить 50,000 select queries в секунду"

Как я рассчитываю:

Если у нас 100K пользователей и каждый делает 1 request в 10 сек:
Торoughput = 100,000 / 10 = 10,000 RPS (requests per second)

1.3 Latency (Задержка)

Определение: Минимальное время для простой операции.

Примеры:

• "Latency between user click and response: < 100ms"
• "Network latency from user to server: < 50ms"

1.4 Scalability (Масштабируемость)

Определение: Как система работает при увеличении нагрузки?

Требования:

• "System должна обслуживать 10K одновременных пользователей без деградации"
• "При увеличении пользователей на 100%, response time не должен увеличиться более чем на 50%"
• "Database должна масштабироваться до 1TB данных"

Категория 2: Reliability & Availability (Надёжность и доступность)

2.1 Availability (Доступность)

Определение: Какой % времени система должна быть доступна?

Уровни:

99% availability   = 87.6 часов downtime в год (неприемлемо)
99.9% availability = 8.76 часов downtime в год (нормально для стартапа)
99.95% availability = 4.38 часов downtime в год (good для production)
99.99% availability = 52 минут downtime в год (excellent, очень дорого)

Как я документирую: "System SLA: 99.9% availability (max 8.76 hours downtime/year)"

Влияние на архитектуру:

• 99% → Монолит на одном сервере OK
• 99.9% → Нужен backup server (failover)
• 99.95% → Нужна распределённая система с реплицированием
• 99.99% → Нужна multi-region архитектура

2.2 Reliability (Надёжность)

Определение: Система должна работать без сбоев.

Метрики:

• MTBF (Mean Time Between Failures) = Среднее время между сбоями
  • "Система не должна иметь сбоев более чем раз в месяц"
• MTTR (Mean Time To Repair) = Среднее время восстановления
  • "Если сервис упал, должен быть восстановлен за < 5 минут"

Требования:

• "Если database connection разорвалась, приложение должно реконнектиться автоматически"
• "При network failure, система должна gracefully деградировать, не рушиться"

2.3 Recoverability (Восстанавливаемость)

Определение: Как быстро восстановиться после сбоя?

Требования:

• "Восстановление из backup должно занять < 1 часа"
• "После сбоя, no data loss за последние 5 минут"
• "Automatic failover должен произойти < 30 секунд"

Категория 3: Security (Безопасность)

3.1 Authentication (Аутентификация)

Требования:

• "All API requests must include valid JWT token"
• "Password must be hashed with bcrypt (not plaintext)"
• "Session timeout after 1 hour of inactivity"

3.2 Authorization (Авторизация)

Требования:

• "User can only see their own data"
• "Admins can see all data"
• "Role-based access control (RBAC) for different roles"

3.3 Encryption (Шифрование)

Требования:

• "All data in transit must use HTTPS/TLS"
• "Sensitive data (passwords, credit cards) must be encrypted in database"
• "Backups must be encrypted"

3.4 Compliance (Соответствие стандартам)

Требования:

• "GDPR compliant: ability to delete user data on request"
• "PCI DSS: credit card data encrypted and not stored"
• "SOC 2 compliant"

Категория 4: Usability (Удобство использования)

4.1 Accessibility (Доступность)

Требования:

• "Must work on screen readers for blind users"
• "Keyboard navigation must be possible"
• "Color contrast ratio must be 4.5:1 per WCAG guidelines"
• "All images must have alt text"

4.2 User Experience (Опыт пользователя)

Требования:

• "Page load time < 2 seconds"
• "Forms should not require more than 3 steps"
• "Error messages should be clear and actionable"
• "Undo functionality for critical operations"

4.3 Support (Поддержка)

Требования:

• "Help documentation for all features"
• "Error messages should suggest solutions"
• "Support response time < 2 hours"

Категория 5: Maintainability (Поддерживаемость)

5.1 Code Quality

Требования:

• "Test coverage >= 80%"
• "Code reviews required for all PRs"
• "Code must follow style guide (linting)"
• "No hardcoded secrets in code"

5.2 Documentation

Требования:

• "All APIs must have OpenAPI/Swagger documentation"
• "Database schema must be documented"
• "Architecture decision records (ADRs) for major changes"
• "README with setup instructions"

5.3 Deployability

Требования:

• "Must support blue-green deployment"
• "Rollback must be possible within 5 minutes"
• "Database migrations must be backward compatible"
• "Automated deployment (CI/CD)"

5.4 Monitoring

Требования:

• "All errors must be logged and monitored"
• "Alert if error rate > 1%"
• "Performance metrics: response time, CPU, memory"
• "Dashboard for system health"

Категория 6: Scalability (Масштабируемость) - подробнее

6.1 Horizontal Scalability (Масштабирование в ширину)

Требование: "System должна обслуживать больше пользователей добавлением серверов"

Как обеспечить:

• Stateless application (не хранить state на сервере)
• Load balancer для распределения трафика
• Message queues для async обработки

6.2 Vertical Scalability (Масштабирование в высоту)

Требование: "System должна работать на более мощном сервере"

Как обеспечить:

• Optimize database queries
• Reduce memory usage
• Improve CPU efficiency

6.3 Data Scalability

Требования:

• "Database должна обслуживать 1TB данных"
• "Queries должны быть < 500ms даже с 1B records"

Как обеспечить:

• Database sharding (разбить данные по серверам)
• Proper indexing
• Archive old data

Категория 7: Interoperability (Совместимость)

7.1 Browser Compatibility

Требования:

• "Must work on Chrome, Firefox, Safari, Edge"
• "Must work on mobile browsers (iOS Safari, Chrome Android)"
• "Support for IE11 deprecated (do not test)"

7.2 Device Compatibility

Требования:

• "Mobile responsive: works on 320px width"
• "Works on tablets and desktops"
• "Mobile-first design"

7.3 API Compatibility

Требования:

• "Must be compatible with external systems (Salesforce, Stripe)"
• "Backward compatibility for API v1 (sunset in 2 years)"
• "Support both JSON and XML formats"

Категория 8: Cost (Стоимость)

8.1 Infrastructure Cost

Требования:

• "Monthly infrastructure cost < $10,000"
• "Cost per user < $0.01/month"

8.2 Development Cost

Требования:

• "MVP should be developed in 3 months by 3 people"
• "Cost per feature should not exceed $50,000"

8.3 Operational Cost

Требования:

• "Support team should be < 5 people for 100K users"
• "Automation should reduce manual work by 80%"

Таблица всех категорий NFR

Категория          | Примеры требований
───────────────────┼──────────────────────────────────────────
Performance        | Response time, Throughput, Latency
Reliability        | Availability, MTBF, MTTR
Security           | Authentication, Encryption, GDPR
Usability          | Accessibility, UX, Support
Maintainability    | Code quality, Documentation, Testing
Scalability        | Horizontal, Vertical, Data scaling
Interoperability   | Browser, Device, API compatibility
Cost               | Infrastructure, Development, Operations

Как я документирую NFR

Пример документа:

=== NON-FUNCTIONAL REQUIREMENTS ===

1. PERFORMANCE
   - API response time: < 200ms (p95)
   - Page load time: < 2 seconds
   - Search throughput: 1000 queries/second

2. RELIABILITY
   - Availability: 99.95% (max 4.38 hours downtime/year)
   - MTTR (Mean Time To Recovery): < 5 minutes
   - No data loss: RPO <= 5 minutes

3. SECURITY
   - All data in transit: HTTPS/TLS 1.2+
   - Passwords: bcrypt hashing
   - API: JWT authentication
   - GDPR compliant

4. SCALABILITY
   - Support 100K concurrent users
   - Database up to 1TB
   - Horizontal scaling via load balancer

5. COST
   - Infrastructure: < $10K/month
   - Development: 3 months MVP

Ошибки, которых я избегаю

Ошибка 1: NFR слишком нечёткие

Плохо: "System should be fast"
Хорошо: "Response time < 200ms for 95% of requests"

Ошибка 2: NFR невыполнимы

Плохо: "100% availability" (невозможно достичь)
Хорошо: "99.99% availability"

Ошибка 3: NFR игнорируются при разработке

Не нужно говорить NFR, потом удивляться почему slow.
Нужно документировать и включить в acceptance criteria.

Ошибка 4: NFR не проверяются

Нельзя просто написать и забыть.
Нужно:
- Load test for performance
- Security audit
- Accessibility testing
- Monitoring for reliability

Результат хорошо документированных NFR

• Ясные ожидания (разработчик знает, какие нужны параметры)
• Тестируемость (QA может проверить, соответствует ли требованиям)
• Успешный проект (система работает как нужно, не только функционирует)
• Счастливые users (система быстрая, безопасная, удобная)

NFR часто забывают, а потом платят дорогой ценой (переделка, рефакторинг, security incidenty). Business Analyst, который правильно документирует NFR, спасает проект.