Как покрыть юз кейсы функциональными и нефункциональными требованиями
архитектуранефункциональные требованияпроектированиефункциональные требованияюз кейсы
Что проверяют
Умеете ли вы превратить сценарий использования в проверяемые требования, а не оставить его рассказом. Системному или бизнес-аналитику обычно дают сценарий вроде «Регистрации» или «Оформления заказа» и просят вывести из него требования обоих видов. Следом спрашивают, как проверить нефункциональное требование и где его хранить, если оно касается всей системы.
Как отвечать
- структура юз кейса: актор, предусловия, основной успешный сценарий, альтернативные потоки и исключения, постусловия. Требования выводятся из каждого шага, а не только из основного потока;
- функциональные требования: что система делает на шаге. Например: «Система проверяет уникальность email и при совпадении показывает сообщение со ссылкой на восстановление пароля». Самые ценные требования обычно прячутся в исключениях: пропала сеть, истекла сессия, данные не прошли валидацию;
- нефункциональные требования: насколько хорошо система это делает. Чтобы ничего не пропустить, пройдитесь по модели качества ISO/IEC 25010 или FURPS+: производительность, надёжность, безопасность, удобство, совместимость, сопровождаемость;
- измеримость: не «поиск работает быстро», а «95% запросов поиска выполняются не дольше 1 секунды при нагрузке 200 запросов в секунду». Для каждого NFR понятно, чем его проверят: нагрузочный тест, аудит безопасности, юзабилити-тест;
- где хранить: требования, специфичные для сценария, привязываются к юз кейсу, а общие, вроде доступности 99,9% или правил логирования, выносятся в отдельный раздел и даются ссылкой;
- трассировка: матрица «юз кейс, требование, тест-кейс» показывает, что каждое требование покрыто проверкой. Для структуры документа сегодня опираются на ISO/IEC/IEEE 29148, который заменил IEEE 830.
Где спотыкаются
Пишут NFR без чисел и условий. «Система должна быть удобной» нельзя ни проверить, ни принять, ни оспорить.
Описывают только основной поток. Альтернативные сценарии и ошибки всплывают на тестировании или в проде, когда их дороже всего добавлять.
Копируют одинаковый набор NFR в каждый юз кейс. Документ раздувается, а при изменении одного числа в десяти местах остаются старые значения.