Software & System Requirements Engineering in Practice. Часть 4

Следующая глава Quality Attribute Requirements книги Software & System Requirements Engineering in Practice посвящена, по сути, нефункциональным требованиям (NFR). Довольно интересная и информативная глава, особенно с учетом того, что о NFR не так уж много информации... В книге их называют как NFR, так и QAR, а также архитектурными (архитектурно значимыми) требованиями, делая особый упор на то, что решение по таким требованиям должен принимать архитектор.
Что же такого в NFR, что отличает их от функциональных требований и требует особого отношения?

• FR описывает возможность системы, которая либо есть, либо отсутствует. NFR, как правило, определяет допустимый диапазон характеристик ("параметр Х должен принимать значения не более/менее, чем А");
• NFR определяются не только заинтересованными лицами, но и следуют из нормативных документов и стандартов, а их реализуемость сильно зависит от ограничений выбранной технологии;
• Взаимозависимость NFR часто не очевидна и также тесно взаимосвязана с особенностями реализации. NFR часто невозможно протестировать, пока система не будет реализована;
• Бывает, что атрибуты качества субъективны или их трудно выразить словами.

Все это требует особого отношения к NFR и специфического подхода к работе. Авторы не советуют слишком торопиться с определением NFR - как правило, работа над ними начинается, когда существенная часть функциональных требований уже зафиксирована. Так мы избежим необоснованных оценок. Но и затягивать начало работы не стоит, т.к. требования к качеству определяют архитектуру.
Работа с NFR также основана на работе с заинтересованными лицами. Это позволяет в последствии приоритезировать NFR и разрешать конфликты. Для сбора информации предлагается использовать сценарии особого типа Quality attribute Scenario (QAS). Такой сценарий предназначен для описания ситуации, в которой для пользователя проявляется качество системы (или его отсутствие).
Интересным также представляется инструмент Global Analysis, позволяющий на самой ранней стадии зафиксировать потребности и предположения (Factors) выявить проблемные точки и противоречия (Issues) и наметить пути решения противоречий (Strategies). Инструмент предназначен для фиксации именно предварительной информации и не обязывает ни к какому формализму, поэтому может быть интересен как простая форма первичного анализа сырой или непроверенной информации. Для визуализации авторы предлагают использовать диаграмму целей (goal model).


Часть 3
Часть 2
Часть 1