Какие знаешь виды нефункциональных требований?

Виды нефункциональных требований

Нефункциональные требования описывают, как система должна работать, её качественные характеристики, а не что она должна делать. Это как важнейшие требования к системе, часто более критичные чем функциональность.

Основные категории нефункциональных требований

1. Требования производительности (Performance)

Определение: Описывают, насколько быстро система должна обрабатывать данные и отвечать на запросы.

Метрики:

• Response Time: время ответа сервера (должно быть < 200ms)
• Throughput: пропускная способность (запросов в секунду)
• Latency: задержка от запроса до ответа
• Batch Processing: время обработки больших объёмов данных

Примеры из практики:

1. REST API:
   - GET /orders -> ответ < 200ms (p95)
   - POST /orders -> ответ < 500ms (p95)
   - GET /analytics -> < 2 сек (p95)

2. Веб-страница:
   - First Contentful Paint < 1.5 сек
   - Largest Contentful Paint < 2.5 сек
   - Time to Interactive < 3.5 сек

3. Batch processing:
   - Обработка 1 млн заказов за ночь < 4 часа
   - ETL pipeline должен завершиться до 8 утра

Как я тестирую:

• Load testing (JMeter, k6)
• APM tools (New Relic, DataDog)
• Browser DevTools для frontend
• Database query analysis (EXPLAIN, slow query logs)

2. Требования надёжности (Reliability)

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

Метрики:

• Availability (Uptime): процент времени, когда система доступна
  • 99% = 87.6 часов downtime/год
  • 99.9% = 8.76 часов downtime/год (Three Nines)
  • 99.99% = 52 минуты downtime/год (Four Nines)
  • 99.999% = 5 минут downtime/год (Five Nines)
• MTBF (Mean Time Between Failures): среднее время между сбоями
• MTTR (Mean Time To Recovery): среднее время на восстановление
• Failure Rate: количество сбоев на единицу времени

Примеры из практики:

Система платежей:
- Availability: 99.999% (5 nines) -> максимум 26 секунд downtime в месяц
- MTBF: 720 часов (месяц без сбоев)
- MTTR: максимум 5 минут

Система логистики:
- Availability: 99.9% (3 nines) -> 43 минуты downtime в месяц
- MTBF: 168 часов (неделя без сбоев)
- MTTR: максимум 30 минут

Как я обеспечиваю:

• Redundancy (дублирование компонентов)
• Load balancing (распределение нагрузки)
• Database replication (репликация БД)
• Automatic failover (автоматическое переключение)
• Health checks (проверка живых компонентов)

3. Требования масштабируемости (Scalability)

Определение: Система должна расти без переписания архитектуры.

Типы масштабирования:

• Vertical Scaling: больше мощности в одной машине (CPU, RAM)
• Horizontal Scaling: больше машин (более надёжно и гибко)

Метрики:

• Max concurrent users: максимальное количество одновременных пользователей
• Max requests/sec: максимальное количество запросов в секунду
• Data volume: объём данных, который система должна хранить
• Growth rate: скорость роста данных и пользователей

Примеры из практики:

Система логистики:
- Текущие показатели: 10,000 пользователей, 100 запросов/сек
- Требования масштабирования:
  - Горизонтальное: должна выдержать 10x (100,000 пользователей, 1000 req/sec) без переписания кода
  - Вертикальное: может быть и вертикальное масштабирование (добавить RAM, CPU в БД)
- Data volume:
  - Сейчас: 500GB
  - Через 2 года: 5TB
  - Система должна хранить это без проблем

Как я обеспечиваю:

• Microservices (каждый сервис масштабируется независимо)
• Database sharding (распределение данных по сервам)
• Caching (Redis, Memcached для уменьшения нагрузки на БД)
• Async processing (очереди для обработки фоновых задач)
• CDN (распределённая сеть для быстрого доступа)

4. Требования безопасности (Security)

Определение: Система должна защищать данные от несанкционированного доступа.

Области безопасности:

• Authentication (Аутентификация): проверка личности пользователя

  • Пример: двухфакторная аутентификация (2FA, MFA)
  • Password requirements: минимум 12 символов, спецсимволы

• Authorization (Авторизация): проверка прав доступа

  • Role-based access control (RBAC)
  • Пример: менеджер может видеть только свои заказы

• Encryption (Шифрование): защита данных в покое и в движении

  • In transit: HTTPS/TLS 1.3
  • At rest: AES-256 для чувствительных данных

• Compliance: соответствие нормативам

  • GDPR (защита данных)
  • PCI DSS (для платежей)
  • SOC 2 (для облачных сервисов)

Примеры из практики:

Система платежей:
- Все платежные данные храниться в зашифрованном виде (AES-256)
- SSL/TLS 1.3 для всех соединений
- Двухфакторная аутентификация для всех пользователей
- Логирование всех операций с платежами (аудит)
- Соответствие PCI DSS v3.2.1

Система логистики:
- Шифрование личных данных водителей
- Role-based access control (водитель видит только свои маршруты)
- HTTPS для мобильного приложения
- Соответствие GDPR

Как я обеспечиваю:

• Security by design (с самого начала)
• Regular security audits (проверки уязвимостей)
• Penetration testing (попытка взлома)
• Code review с фокусом на безопасность
• OWASP Top 10 prevention (SQL injection, XSS, CSRF и т.д.)

5. Требования к удобству использования (Usability)

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

Метрики:

• Task completion rate: процент пользователей, успешно выполнивших задачу
  • Должно быть > 95% на первый раз
• Time to complete task: время выполнения задачи
  • Создание заказа: < 2 минуты
• Error rate: процент ошибок пользователей
  • Должно быть < 2%
• User satisfaction: рейтинг удовлетворенности (NPS, SUS)

Примеры из практики:

Мобильное приложение для водителей:
- Минимум 4.5 звёзд на App Store (95%+ положительные отзывы)
- Время принятия заказа: < 20 секунд
- Error rate при доставке: < 1%
- Users should complete delivery in < 10 тапов

Веб-интерфейс для менеджеров:
- Users должны разобраться в интерфейсе без обучения (SUS > 70)
- Создание отчёта: < 30 секунд
- Поиск заказа: < 10 секунд

Как я обеспечиваю:

• User research (интервью, анкеты)
• Usability testing (A/B testing, user testing sessions)
• Accessibility (для людей с инвалидностью)
• Mobile-first design
• Intuitive information architecture

6. Требования поддерживаемости (Maintainability)

Определение: Система должна быть простой для модификации и расширения в будущем.

Метрики:

• Code coverage: процент кода, покрытого тестами
  • Должно быть >= 90%
• Cyclomatic complexity: сложность функций (max 10)
• Technical debt: объём старого/плохого кода
• Mean time to fix: среднее время исправления ошибки

Примеры из практики:

Проект логистики:
- Code coverage: 92%
- Cyclomatic complexity: < 8 для всех функций
- Документация: есть для всех public API
- Technical debt: < 5% от кода
- Time to fix критическую ошибку: < 1 часа

Как я обеспечиваю:

• Clean code principles (readable, documented)
• SOLID принципы (S, O, L, I, D)
• Automated testing (unit, integration, e2e)
• Documentation (код + wiki)
• Code review process
• Refactoring cycles

7. Требования совместимости (Compatibility)

Определение: Система должна работать с различными окружениями и системами.

Типы совместимости:

• Browser compatibility: поддержка разных браузеров

  • Chrome, Firefox, Safari, Edge (last 2 versions)

• OS compatibility: поддержка разных операционных систем

  • Windows, Mac, Linux

• Device compatibility: поддержка разных устройств

  • Desktop, tablet, mobile
  • Разные размеры экранов

• API compatibility: обратная совместимость версий

  • v1 и v2 API должны работать параллельно

Примеры из практики:

Мобильное приложение:
- iOS: 12.0+ (охватывает 99% пользователей)
- Android: 8.0+ (охватывает 98% пользователей)
- Поддержка offline mode (работает без интернета)

Веб-приложение:
- Chrome 90+, Firefox 88+, Safari 14+, Edge 90+
- Responsive: 320px до 2560px ширины
- JavaScript disabled: основные функции работают

Как я обеспечиваю:

• Cross-browser testing
• Responsive design (mobile-first)
• Feature detection (graceful degradation)
• Version management (semver для API)

8. Требования доступности (Accessibility)

Определение: Система должна быть доступна для людей с инвалидностью.

Стандарты:

• WCAG 2.1 (Web Content Accessibility Guidelines)
  • Level A (basic), Level AA (recommended), Level AAA (advanced)

Требования:

• Поддержка screen readers
• Keyboard navigation
• High contrast (для слабовидящих)
• Alt text для изображений
• Captions для видео

Примеры из практики:

Веб-приложение:
- Compliance с WCAG 2.1 Level AA
- Все images имеют alt text
- Keyboard-only navigation (Tab, Enter, Arrows)
- Color contrast: 4.5:1 для текста
- Form labels связаны с inputs

Как я обеспечиваю:

• Accessibility audit
• Manual testing с screen reader (NVDA, JAWS)
• Automated tools (Axe, Lighthouse)
• Training для команды

9. Требования к локализации (Localization)

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

Требования:

• Languages: поддержка нескольких языков

  • Русский, Английский, Испанский и т.д.

• Formatting: правильное форматирование для региона

  • Даты: DD.MM.YYYY (Россия) vs MM/DD/YYYY (USA)
  • Числа: 1.000,50 (Германия) vs 1,000.50 (USA)
  • Валюта: RUB, USD, EUR

Примеры:

Система для международного использования:
- 15 языков поддержки
- Правильное форматирование дат, денег, чисел
- RTL поддержка для арабского
- Цены в местной валюте

10. Требования к восстанавливаемости (Recoverability)

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

Метрики:

• Recovery Point Objective (RPO): максимум данных, которые можно потерять

  • Пример: RPO = 1 час (потеря до 1 часа данных допустима)

• Recovery Time Objective (RTO): максимум времени на восстановление

  • Пример: RTO = 30 минут (система должна быть восстановлена за 30 мин)

Примеры:

Э-коммерц платформа:
- RPO = 5 минут (бэкапы каждые 5 минут)
- RTO = 15 минут (восстановление за 15 минут)
- Geo-redundancy (бэкапы в разных городах)

Критическая платёжная система:
- RPO = 1 минута
- RTO = 5 минут
- Multiple backup sites (active-active)

Таблица приоритизации нефункциональных требований

Как я определяю нефункциональные требования

1. Анализ бизнес-целей → Какие требования критичны для успеха?
2. Анализ пользователей → Что им важно (скорость, надёжность)?
3. Анализ конкуренции → Какие стандарты в индустрии?
4. Оценка затрат → Сколько денег на каждое требование?
5. Приоритизация → Что критично, что nice-to-have?
6. Тестирование → Как проверять, что требования выполнены?

В проекте логистики я определил иерархию:

1. Critical: Availability 99.9%, Security (GDPR), Performance <500ms
2. High: Scalability 10x, Usability, Monitoring
3. Medium: Accessibility, Localization, Documentation
4. Low: Nice-to-have улучшения

Это дало нам ясный фокус и помогло распределить ресурсы правильно.