Ответ.

История вопроса:

Изначально фокус при формализации требований был на функциональных возможностях, но со временем стало ясно, что критерии «невидимые» на первый взгляд (производительность, безопасность, отказоустойчивость и др.) критично важны для успешного внедрения и жизнеспособности продуктов. Их игнорирование приводило к сбоям и непредсказуемому поведению ПО после запуска.

Проблема:

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

Решение:

Системный аналитик проводит сессии с бизнесом, ИТ и специалистами по эксплуатации для выявления реальных ограничений, фиксирует числовые метрики (например, SLA, TPS, показатели latencies), описывает нефункциональные требования в явном виде в спецификациях и далее обеспечивает их тестируемость через связывание с тест-кейсами и архитектурными артефактами проекта.

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

Использование количественных (измеримых!) характеристик.
Включение этапа формализации и обоснования через согласование с ключевыми ИТ-экспертами.
Связывание требований с методами их тестирования.

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

Можно ли оставлять группы требований просто как «Система должна быть доступна 24/7» без детализации?

Нет, нужно обязательно уточнять параметры доступности (например, 99.95%) и условия восстановления.

Достаточно ли указать «скорость отклика должна быть быстрой»?

Нет, подобные формулировки нерабочие. Нужно указывать, например: Response time < 3 секунды при 95% запросов с нагрузкой X.

Формализованы ли нефункциональные требования, если прописаны только в общем ТЗ без дальнейшей детализации?

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

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

Оставление размытых формулировок, не позволяющих проводить тестирование.
Копирование требуемых показателей из других проектов без анализа специфики.
Игнорирование консультаций с IT/SRE и эксплуатации.

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

Негативный кейс: Проект e-banking запустили с требованием "доступность 24/7, быстрая работа", без уточнения SLA.

Плюсы:

Быстрая подготовка требований

Минусы:

Частые сбои, неразрешимые споры с аутсорсером
Клиентские претензии

Положительный кейс: Аналитик проработал с отделом эксплуатации, зафиксировал 99.9% uptime, Max Response 2 сек, описал сценарии деградации.