Структура нефункциональных требований

NFR ( нефункциональным требованиям ) нужна структура для уплотнения. Анализ начинается с программных целей, которые представляют собой НФР, с которыми согласны заинтересованные стороны. Мягкие цели — это цели, которые трудно выразить, но они, как правило, представляют собой глобальные качества программной системы. Это могут быть удобство использования, производительность, безопасность и гибкость в данной системе. Если команда начинает их собирать, она часто находит их очень много. Чтобы сократить количество до управляемого количества, ценным подходом является структурирование. Существует несколько доступных фреймворков, которые полезны в качестве структуры.

Структурирование нефункциональных требований

Следующие структуры могут служить структурой для НО:

1. Моделирование цели Завершенные программные цели затем обычно разлагаются и уточняются, чтобы раскрыть древовидную структуру целей и подцелей, например, программной цели гибкости. Обнаружив древовидные структуры, вы обязательно обнаружите мешающие программные цели в разных деревьях, например, цели безопасности обычно мешают удобству использования. Эти деревья программных целей теперь образуют структуру графа программных целей. Последним шагом в этом анализе является выбор некоторых конечных программных целей, чтобы все корневые программные цели были удовлетворены.[1]

2. ИВЕНА - Комплексный подход к получению НФР В методе интегрировано дерево требований. [2]

3. Контекст организации Существует несколько моделей для описания контекста организации, например Business Model Canvas , OrgManle [3] и другие [4]. Эти модели также являются хорошей основой для определения НО.

Измерение нефункциональных требований

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

Модель SNAP состоит из четырех категорий и четырнадцати подкатегорий для измерения нефункциональных требований. Нефункциональные требования сопоставляются с соответствующими подкатегориями. Каждая подкатегория имеет размер, а размер требования представляет собой сумму размеров ее подкатегорий.

Процесс определения размера SNAP очень похож на процесс определения размера Function Point. В пределах приложения нефункциональные требования связаны с соответствующими категориями и их подкатегориями. Используя стандартизированный набор основных критериев, каждая из подкатегорий затем определяется в соответствии с ее типом и сложностью; размер такого требования представляет собой сумму размеров его подкатегорий. Затем эти размеры суммируются, чтобы получить оценку нефункционального размера программного приложения.

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

См. также

• Баллы SNAP

Ссылки

[1] Милопулос, Чанг и Ю: «От объектно-ориентированного к целеориентированному анализу требований», сообщения ACM, январь 1999 г. [CACM.f.doc [1] [2] Гетц, Рольф; Шарнвебер, Хайко: «IVENA: Комплексный подход к сбору нефункциональных требований». https://www.pst.ifi.lmu.de/Lehre/WS0102/architektur/VL1/Ivena.pdf [3] Тейх, Ирен: Учебное пособие PlanMan. Рабочий документ Postbauer-Heng, Германия, 2005 г. Доступно по запросу. [4] Тейч, Ирен: Контекст моделей организации. Рабочий документ Мешеде, Германия 2020. Доступно по запросу.