Бизнес-аналитик отвечает за полный сбор, согласование и документирование не только функциональных, но и нефункциональных требований: скорость работы системы, безопасность, масштабируемость, доступность, удобство интерфейса. Для этого он тесно взаимодействует со стейкхолдерами (особенно с бизнесом и ИТ), использует сценарии и анализирует стандарты. Он должен не только собрать явные ожидания, но и выявить скрытые требования (например, регулирование по защите данных). В итоге аналитик формализует нефункциональные требования в документации, согласовывает их с проектной и технической командой, а также контролирует соблюдение этих требований на протяжении всего проекта.
Ключевые особенности:
Достаточно ли просто описать нефункциональные требования в тексте без метрик и конкретики?
Нет, абстрактные формулировки ("быстро", "безопасно") непригодны для валидации. Требуются чёткие параметры: например, скорость отклика не более 2 секунд.
Являются ли нефункциональные требования только заботой технических специалистов?
Нет, аналитик должен выявить и формализовать такие требования совместно с бизнесом, ведь их несоблюдение приведет к неудовлетворённым ключевым интересам бизнеса.
Возможно ли отложить работу с нефункциональными требованиями до финальных этапов проекта?
Нет, такие требования зачастую критичны для архитектуры решения. Их выявление на поздних этапах ведёт к переработкам и высоким издержкам.
Негативный кейс: Описали в ТЗ ожидаемое "удобство" и "быстродействие", не зафиксировали конкретных метрик. Плюсы: Менее затратно на момент написания документа Минусы: Не смогли предъявить претензий команде, когда результат не удовлетворил заказчика
Положительный кейс: Согласовано: "Скорость загрузки страницы — до 2 секунд при нагрузке до 1000 пользователей, уровень SLA — 99,95%". Формализованы требования по защите персональных данных. Плюсы: Четкая проверка результата, снижение рисков переделок, прозрачность для всех участников Минусы: Требовало времени и согласований с ИТ и юристами