В прошлом посте мы разобрали, на какие классы и группы делятся нефункциональные требования.  Сегодня — поговорим о том, откуда их брать, как собирать и как формулировать.  Обычно заказчики и пользователи хорошо понимают, что должно делать ПО.  А вот качество решений и ограничения часто остаются зоной ответственности аналитика.  Поэтому именно аналитик определяет нефункциональные требования и обсуждает их со стейкхолдерами.  Разберём подходы 👇  🔹 Подход 1. Использование шаблонов и стандартов  Если компания часто работает с определённым типом НФТ (например, безопасность или производительность), логично опираться на готовые стандарты.  Пример:  скорость отклика ≤ 2 секунд,  не менее 1000 запросов в минуту.  👉 Унифицированные шаблоны делают требования понятными и стабильными.  🔹 Подход 2. Интервью и анализ документации  Один из самых популярных методов.  Интервью со стейкхолдерами помогают выявить скрытые НФТ.  Документация даёт подсказки по существующим процессам.  ⚠️ Осторожно с формулировками вроде: «Сделайте так же, как в другом процессе».  Всегда проверяйте логику и адаптируйте её под новый контекст.  🔹 Подход 3. Приоритизация  НФТ могут конкурировать или противоречить друг другу.  Пример:  Высокая скорость загрузки страницы (0.002 сек).  Максимальная безопасность данных.  Эти требования конфликтуют (кеширование ускоряет, но снижает безопасность).  👉 Решение — определить приоритет.  Например: сначала безопасность, затем скорость с оптимизацией.  🔹 Подход 4. Использование методологий  Методологии помогают формализовать процесс:  BABOK — даёт инструменты (например, моделирование процессов).  AgileBA — предлагает практики:  Подключение стейкхолдеров к сбору требований.  Постепенное уточнение через короткие итерации.  Тесная работа с командой разработки.  📝 Чек-лист: что спросить у заказчика, чтобы выявить НФТ  Как быстро система должна реагировать на действия пользователя?  Сколько одновременно пользователей она должна выдерживать?  Какие есть требования к безопасности и хранению данных?  Насколько важно бесперебойное функционирование (24/7, рабочие часы)?  На каких устройствах и платформах должно работать ПО?  Есть ли ограничения по интеграциям (API, внешние сервисы)?  Какие стандарты или регламенты обязательны для соблюдения?  💡 Вывод: грамотный сбор и формулировка нефункциональных требований — это баланс между ожиданиями заказчика, реальностью разработки и стратегией компании.