Ответ.

Функциональные требования описывают, что система должна делать: бизнес-операции, процессы, пользовательские сценарии — то есть функционал.

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

Почему важно различать:

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

Ключевые особенности:

• Функциональные требования — поведение системы.
• Нефункциональные требования — качество и ограничения.
• Оба типа должны быть явно зафиксированы и согласованы.

Вопросы с подвохом.

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

Нет, это нефункциональный параметр (usability). Функциональное требование — это наличие, например, кнопки "Сохранить", нефункциональное — скорость её отклика и простота использования.

Можно ли пренебречь нефункциональными требованиями, если они не указаны заказчиком явно?

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

“Система должна уметь обрабатывать 1000 запросов в минуту”. Это функциональное требование?

Нет, это нефункциональное требование — характеристика производительности.

Типовые ошибки и анти-паттерны

• Смещение акцента только на функционал ("главное, чтобы работало, скорость потом").
• Неявная формулировка нефункциональных требований — "должно быть быстро", "надёжно", "безопасно".
• Игнорирование тестирования нефункциональности.

Пример из жизни

Негативный кейс: Система полностью реализовала заявленный бизнес-функционал, но при большой нагрузке начинала "тормозить", т.к. производительность не учли вообще. Плюсы:

• Быстрая разработка, точное выполнение заявленных сценариев. Минусы:
• Система не пригодна для эксплуатации в условиях реальной нагрузки, компании пришлось экстренно дорабатывать архитектуру.

Положительный кейс: Аналитик совместно с архитектором и заказчиком зафиксировали в требованиях предельную нагрузку, критерии отклика, провели нагрузочное тестирование. Плюсы:

• Продукт стабильно работал и выдерживал рост пользователей.
• Планы развития предусматривали масштабирование. Минусы:
• На старте проектирования пришлось больше времени уделить обсуждению и дополнительным тестам.