Нефункциональные требования
Ключевые тезисы
- Нефункциональные требования описывают, как система должна работать, в отличие от функциональных требований, которые описывают, что система должна делать.
- Они определяют атрибуты качества, условия работы и ограничения системы.
- Нефункциональные требования всегда идут вместе с функциональными и формируются на их основе.
- Они нужны для создания удобной, надежной системы, управления ожиданиями и рисками, а также для закладки архитектурного фундамента.
Основное содержание
Определение и место в иерархии
Нефункциональные требования — это описание присущих свойств или характеристик, которые система ПО должна демонстрировать, или ограничения, которые она должна соблюдать.
В иерархии требований они находятся на одном уровне с функциональными требованиями:
- Бизнес-требования (цели создания продукта).
- Пользовательские требования (потребности пользователей).
- Функциональные требования (поведение системы) и Нефункциональные требования (качество и ограничения системы).
Виды и формулировки
Ключевое правило: избегать размытых формулировок (например, "быстро", "удобно", "надежно") и использовать конкретные, измеримые критерии.
Производительность
- Вопрос: Как быстро система реагирует и какую нагрузку выдерживает?
- Плохо: "Система должна быть быстрой".
- Хорошо: "90% поисковых запросов должны обрабатываться не более чем за 1 секунду" или "Система должна выдерживать пиковую нагрузку в 1000 одновременных пользователей".
Масштабируемость
- Вопрос: Как система справляется с ростом?
- Плохо: "Система должна расти вместе с бизнесом".
- Хорошо: "При увеличении количества пользователей на 50% в течение 6 месяцев система должна масштабироваться без изменения кода (горизонтальное масштабирование) с сохранением показателей производительности".
Надёжность и доступность
- Вопрос: Как часто система ломается и сколько времени она доступна?
- Плохо: "Система должна быть доступна всегда".
- Хорошо: "Доступность системы должна составлять 99,9% в рабочее время (с 9:00 до 18:00 по МСК). Среднее время восстановления после сбоя — не более 30 минут".
Безопасность
- Вопрос: Как защищены данные и от кого?
- Плохо: "Система должна быть безопасной".
- Хорошо: "Пароли пользователей должны храниться в хэшированном виде", "Все передаваемые данные должны шифроваться по протоколу TLS 1.2", "Более 5 неудачных попыток входа подряд блокируют учётную запись на 15 минут".
Удобство использования (Usability)
- Вопрос: Насколько удобно пользоваться системой?
- Плохо: "Интерфейс должен быть удобным".
- Хорошо: "Новый пользователь без обучения должен выполнить первичную настройку профиля не более чем за 5 минут".
Сопровождаемость и расширяемость
- Вопрос: Насколько легко вносить изменения?
- Плохо: "Код должен быть читаемым".
- Хорошо: "Система должна быть построена по модульной архитектуре. Добавление нового типа отчёта не должно требовать изменения более 5% существующего кода", "Покрытие кода юнит-тестами должно быть не менее 80%".
Совместимость
- Вопрос: С чем система должна работать?
- Плохо: "Приложение должно работать на телефонах".
- Хорошо: "Веб-приложение должно корректно работать в последних двух версиях браузеров Chrome и Safari. Мобильное приложение должно поддерживать iOS 15+ и Android 11+".
Портативность
- Вопрос: Насколько легко перенести систему в другое окружение?
- Плохо: "Систему нужно будет перенести в облако".
- Хорошо: "Развёртывание системы на новом сервере должно занимать не более 1 часа с использованием Docker-контейнеров".
Источники нефункциональных требований
- Бизнес-требования (например, "оформить заказ не более чем за 3 секунды").
- Вопросы к стейкхолдерам (например, "Сколько будет одновременных пользователей?").
- Анализ предметной области (изучение отрасли).
- Изучение аналогов/конкурентов (например, если у конкурента заказ за 2 секунды, сделать за 1.5 секунды).
- Архитектурные и операционные ограничения (уже принятые в компании технические решения).
Практические аспекты и выводы
- Трассируемость: Важно связывать нефункциональные требования с конкретными функциональными требованиями, пользовательскими историями или бизнес-целями.
- Согласование: Требуется консультация с техническими специалистами для реалистичной оценки (например, времени отклика).
- Полнота: Стремиться покрыть все рассмотренные виды требований, но понимать, что учесть абсолютно всё невозможно.
- Критерии приёмки: Чёткие нефункциональные требования формируют объективные критерии для приёмки работы заказчиком.
- Для кого документация: Нефункциональные требования пишутся в первую очередь для разработчиков и тестировщиков.