exam

Нефункциональные требования к ПО.

Нефункциональные требования (Non‑functional Requirements, NFR) описывают, как должна работать система: её характеристики, ограничения и условия эксплуатации. В отличие от функциональных требований они не добавляют новых функций, но определяют качество работы ПО.

Ключевое отличие от функциональных требований

  • Функциональные: отвечают на вопрос «Что система должна делать?» (например, «система должна позволять пользователю сбрасывать пароль»).
  • Нефункциональные: отвечают на вопросы «Как система должна это делать?» и «Насколько хорошо?» (например, «процесс сброса пароля не должен занимать более 2 минут»).

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

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

  1. Производительность (Performance):
    • скорость отклика системы;
    • время выполнения операций;
    • пропускная способность (количество операций в единицу времени);
    • использование ресурсов (CPU, память, дисковое пространство).
    Примеры:
    • «Время отклика интерфейса при загрузке главной страницы не должно превышать 2 секунд при ширине канала 10 Мбит/с».
    • «Поиск по каталогу должен выдавать результаты не дольше чем за 1 секунду».
    • «Система должна поддерживать не менее 1 000 одновременных подключений».
  2. Надёжность (Reliability):
    • стабильность работы;
    • устойчивость к сбоям;
    • время восстановления после сбоев.
    Пример: «Доступность системы должна составлять не менее 99,9 % времени в месяц (допускается не более 43,8 минут простоя в месяц)».
  3. Масштабируемость (Scalability):
    • способность системы справляться с ростом нагрузки (пользователей, данных, транзакций) без существенной потери производительности.
    Пример: «Система должна обеспечивать линейное увеличение производительности при добавлении вычислительных ресурсов до 20 серверных узлов».
  4. Безопасность (Security):
    • защита данных от несанкционированного доступа;
    • аутентификация и авторизация пользователей;
    • шифрование данных (при передаче и хранении);
    • соответствие стандартам безопасности (PCI DSS, GDPR и т. д.).
    Примеры:
    • «Все пароли должны храниться в зашифрованном виде с использованием алгоритма bcrypt».
    • «Система должна поддерживать двухфакторную аутентификацию для администраторов».
    • «Данные при передаче между клиентом и сервером должны быть зашифрованы с использованием TLS 1.3».
  5. Удобство использования (юзабилити) (Usability):
    • интуитивность интерфейса;
    • доступность для людей с ограниченными возможностями (соответствие стандарту WCAG);
    • минимизация количества действий для выполнения типовых задач.
    Примеры:
    • «Новый пользователь должен выполнить типовую задачу за не более чем 3 клика без предварительного обучения».
    • «Интерфейс должен быть адаптирован для пользователей с нарушениями зрения (поддержка экранных дикторов, контрастные темы)».
  6. Совместимость и переносимость (Compatibility & Portability):
    • работа на разных платформах, устройствах, браузерах;
    • интеграция с другими системами и сервисами.
    Примеры:
    • «Система должна корректно отображаться в последних версиях Chrome, Firefox, Safari и Edge».
    • «Интерфейс должен быть адаптирован под мобильные устройства (разрешение от 320 px)».
    • «Система должна интегрироваться с 1С через REST API».
  7. Сопровождаемость (Maintainability):
    • лёгкость внесения изменений и исправлений;
    • модульность архитектуры;
    • наличие документации и логов.
    Пример: «Код должен быть документирован в соответствии со стандартами компании, включая комментарии к публичным методам».
  8. Локализация и интернационализация (Localization & Internationalization):
    • поддержка разных языков;
    • корректное отображение форматов даты, времени, валюты, чисел.
    Пример: «Система должна поддерживать русский и английский языки с возможностью добавления новых локалей без изменения кода».
  9. Эксплуатационные требования:
    • простота установки и развёртывания;
    • мониторинг и логирование;
    • резервное копирование и восстановление данных.
    Примеры:
    • «Процесс установки системы должен занимать не более 30 минут силами одного администратора».
    • «Система должна автоматически создавать резервные копии базы данных каждые 24 часа».

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

Чтобы требования были полезными, их нужно формулировать конкретно и измеримо.

Плохо:

  • «Система должна быть быстрой».
  • «Интерфейс должен быть удобным».
  • «Система должна быть надёжной».

Хорошо:

  • «Время загрузки главной страницы не должно превышать 1,5 секунд при нагрузке до 500 одновременных пользователей».
  • «Пользователь должен находить нужный раздел не более чем за 2 клика».
  • «Доступность системы должна составлять 99,95 % в течение календарного месяца».

Роль нефункциональных требований в разработке ПО

Нефункциональные требования влияют на:

  • архитектуру системы (выбор технологий, баз данных, серверов);
  • бюджет и сроки (реализация высокой надёжности или масштабируемости требует дополнительных ресурсов);
  • пользовательский опыт (скорость, удобство, безопасность напрямую влияют на удовлетворённость);
  • конкурентные преимущества (система, которая работает быстрее и стабильнее аналогов, привлекает больше пользователей).

Грамотно сформулированные нефункциональные требования помогают создать продукт, который не только выполняет нужные функции, но и удобен, безопасен и эффективен в реальной эксплуатации.