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

Глава об управлении требованиями книги Software & System Requirements Engineering in Practice не открывает чего-то нового, не дает целостной картины процесса управления, но ряд весьма любопытных советов там определенно есть. Вообще есть впечатление, что для авторов это рутина, о которой много где написано хорошо и подробно, а потому нечего повторять сказанное. Они ограничиваются небольшим кругом ключевых аспектов и рядом своих практических рекомендаций, что ничуть не менее полезно, чем целостное изложение. Такими рекомендациями являются и список атрибутов требований, и содержание плана управления требованиями, и характерные отличия управления требованиями в продуктовых линейках по сравнению с отдельными продуктами. Интересна также таблица, отвечающая на вопрос, кому и зачем нужны трассировки. В общем есть, что припрятать для будущей работы.

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

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

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



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

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