Анализ нефункциональных требований · Конспекты по бизнес-анализу

Что это#

Нефункциональные требования (non-functional requirements) описывают условия среды и качества, при которых решение должно оставаться эффективным, а также критерии, по которым судят, насколько хорошо оно работает. Их также называют атрибутами качества или требованиями к качеству обслуживания. Конкретное поведение они не описывают: это задача функциональных требований.

Руководство BABOK® строит технику вокруг трёх элементов:

Категории — виды качества, которые вы рассматриваете: производительность, доступность, надёжность, безопасность, удобство использования, масштабируемость, сопровождаемость, переносимость, совместимость, соответствие нормативным требованиям.
Измерение — как выражено каждое нефункциональное требование, чтобы его можно было проверить.
Контекст — условия, в которых требование действует: какие пользователи, какая нагрузка, какое время, какая среда.

Вигерс и Битти добавляют полезное разделение. Внешние атрибуты проявляются во время работы системы и важны в первую очередь пользователям: например, доступность, производительность, безопасность и удобство использования. Внутренние атрибуты важны прежде всего разработчикам и службе поддержки — например, модифицируемость, переносимость и тестируемость, — но и они косвенно сказываются на пользователях. Кроме того, авторы выделяют ограничения, например обязательную платформу или нормативный акт, в отдельный класс, который сужает варианты дизайна.

Когда применять#

Учебные таблицы Watermark связывают технику с задачами 7.1 «Спецификация и моделирование требований» (определение атрибутов качества обслуживания) и 8.1 «Измерение эффективности решения» (определение ожидаемых характеристик решения). На практике:

как только известны основные функции — до выбора архитектуры или вендора;
при написании критериев приёмки;
при оценке уже работающего решения.

Учебные таблицы отмечают, что нефункциональные требования сильно влияют на то, будет ли система успешной и примут ли её: они задают ограничения, которые решение должно соблюдать, и дают меры того, насколько хорошо должны выполняться функциональные требования.

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

Как это делать#

Начните с широкого списка категорий, чтобы не упустить целую область качества.
Сократите список вместе с заинтересованными сторонами. По каждой категории спросите, важна ли она здесь и для кого. Запишите, почему исключили остальные, — так советуют Вигерс и Битти.
Расставьте приоритеты в коротком списке. Вигерс и Битти предлагают попарное сравнение: для каждой пары спросите: «Если бы можно было получить только одно из двух, что важнее?» Ответ понадобится, когда два качества вступят в конфликт.
Выявите конкретные ожидания. На вопрос «Насколько надёжной она должна быть?» пользователи редко отвечают что-то полезное. Спрашивайте о реальных сценариях и, как советуют Вигерс и Битти, о том, что было бы неприемлемо: пределы часто назвать проще, чем цели.
Добавьте контекст. Укажите нагрузку, временные окна, устройства и группы пользователей, к которым относится каждое требование.
Сделайте требование измеримым. Задайте каждому нефункциональному требованию шкалу (что измеряется и в каких единицах), способ измерения, минимально допустимый уровень и целевое значение. Вигерс и Битти описывают язык Planguage Тома Гилба: в нём именно для этого есть ключевые слова SCALE, METER, MUST и GOAL.
Проверьте стоимость и компромиссы с командой разработки. Улучшение одного качества часто ухудшает другое: например, дополнительные проверки безопасности могут замедлить отклик системы.
Свяжите каждое нефункциональное требование с функциями, к которым оно относится, и с тестами, которые его проверят.

Пример#

«Мастерская», вымышленная сеть из 12 веломастерских, создаёт онлайн-запись и уведомления о статусе ремонта. В первом черновике было написано: «Сайт бронирования должен быть быстрым и всегда доступным». После анализа (значения условные):

ID	Категория	Требование и контекст	Шкала и способ измерения	Минимум	Целевое значение
`NFR-01`	Производительность	Свободное время отображается после того, как клиент выбрал мастерскую, на телефоне среднего класса в мобильной сети	Секунды до полного отображения, 95-й процентиль, ежемесячный тест	4 с	2 с
`NFR-02`	Доступность	Онлайн-запись с 06:00 до 23:00 по местному времени	% этого окна, когда сервис работает, за месяц	99%	99,5%
`NFR-03`	Удобство использования	Клиенты, которые бронируют впервые, справляются без помощи	Доля участников, выполнивших задание в модерируемом тесте	7 из 8	8 из 8
`NFR-04`	Безопасность	Телефоны клиентов видны только сотрудникам той мастерской, где сделана бронь	Тест доступа: пройден / не пройден	Пройден	Пройден
`NFR-05`	Производительность	Сообщение о статусе отправляется после того, как механик изменил статус	Минуты, по журналу сообщений	99% в течение 10 мин	99% в течение 5 мин

Сначала владелец попросил почти идеальную доступность. Команда разработки объяснила, что для этого нужен резервированный хостинг, который стоит намного дороже. Поскольку клиенты по-прежнему могут записаться по телефону, владелец согласился на целевое значение 99,5%; учебные таблицы предупреждают, что слишком жёсткие нефункциональные требования повышают стоимость разработки и могут потребовать переговоров.

Частые ошибки#

Нефункциональные требования откладывают на потом. В книге BCS предупреждают, что их часто откладывают или прорабатывают поверхностно, и связывают это с реальными провалами — например, с нехваткой мощности при запуске и неработоспособными веб-формами. → Обсуждайте качество с первых семинаров.
Расплывчатые прилагательные («удобный», «быстрый») → добавьте шкалу, способ измерения и целевое значение.
Назван механизм, а не потребность («использовать пароли») → сформулируйте потребность («контактные данные клиентов видят только уполномоченные сотрудники»), как советуют Вигерс и Битти.
«Позолота» → жёсткие целевые значения стоят денег; договоритесь, что считать достаточно хорошим.
Одно число без контекста → укажите нагрузку, условия и группу пользователей.
Конфликты не замечают → расставьте приоритеты качеств, чтобы знать, какое из них побеждает.
Забывают о внутренних качествах → спросите разработчиков и службу поддержки о сопровождаемости и тестируемости.
Спорят о качественных требованиях → учебные таблицы отмечают, что некоторые нефункциональные требования трудно измерить по шкале; договоритесь о косвенной мере или о процедуре проверки.

Шаблон#

Шаблон

| ID | Категория | Требование (что, для кого, в каких условиях) | Шкала и способ измерения | Минимум | Целевое значение | К чему относится | Обоснование / источник |
|----|----------|-----------------------------------------------------|------------------------------|---------|--------|------------|--------------------|
| NFR-01 | | | | | | | |

Чек-лист#

Категории рассмотрены, исключения объяснены
Оставшиеся качества приоритизированы относительно друг друга
У каждого нефункционального требования есть контекст, шкала, способ измерения, минимум и целевое значение
Ни один механизм реализации не выдан за требование
Стоимость и компромиссы проверены с командой разработки
Каждое нефункциональное требование связано с функциями и с тестами для проверки

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.30 «Анализ нефункциональных требований».
Watermark Learning. BABOK v3 Study Tables. 2016 (учебное пособие к Руководству BABOK). Разд. 10.30.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 14 (атрибуты качества, Planguage, компромиссы).
D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Гл. 9–10 (нефункциональные требования).