Ответ.

Исторически сложилось так, что в IT-проектах основное внимание уделялось функциональным требованиям: что система должна делать. При этом вопросы производительности, надежности, масштабируемости, доступности, безопасности и поддерживаемости (именно эти характеристики объединяются термином «нефункциональные требования», НФТ) долгое время оставались второстепенными и зачастую не формализовались вообще.

Проблема

Игнорирование либо формальное описание НФТ приводит к существенным проблемам в эксплуатации: система оказывается не готова к ожидаемым нагрузкам, не выдерживает кибератак, сложна в сопровождении и масштабировании, либо недоступна для нужного числа пользователей.

Решение

Современный системный аналитик обязан инициировать, формализовать, анализировать и документировать НФТ. Это включает:

взаимодействие с архитекторами, DevOps- и эксплуатационными командами для определения технологических и инфраструктурных ограничений;
сбор требований от бизнеса (например, по SLA);
формирование исчерпывающего перечня НФТ с конкретными пороговыми значениями;
внедрение мер по их контролю на этапе внедрения и поддержки;
фиксация требований в отдельных разделах спецификации.

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

НФТ обязательны для любых крупных проектов.
Определяются совместно с техническими и бизнес-стейкхолдерами.
Должны быть однозначными, тестируемыми и привязаны к бизнес-целям.

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

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

Качество продукта — более широкое понятие, включающее не только формализуемые параметры, но и субъективные оценки (например, UX/UI удобство). НФТ — это четко измеримые характеристики (производительность, надежность и т.д.), подлежащие автоматической валидации.

Может ли аналитик поручить определение всех нефункциональных требований архитектору?

Нет, аналитик обязан совместно с архитектором и бизнесом выявить эти требования на этапе анализа, иначе требования будут неполными или описаны только с технической стороны, без учета бизнес-потребностей.

Можно ли формулировать нефункциональные требования только в виде общих фраз ("система должна быть надежной")?

Нет, такие формулировки непригодны для контроля и тестирования. Требуется конкретизация: например, "время восстановления сервиса после сбоя не должно превышать 10 минут".

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

Формулировка требований без тестируемых критериев ("быстро", "круто", "надежно").
Пропуск целых классов НФТ (например, безопасность для внутренних систем).
Несогласованность требований между заказчиком и поддержкой.

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

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

Плюсы:

Быстрое MVP

Минусы:

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

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