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

Основной автор этой статьи, по-видимому, тесно связан с ее темой. Возможно, потребуется очистка для соответствия политике Википедии в отношении контента, в частности нейтральной точки зрения . Пожалуйста, обсудите подробнее на странице обсуждения . ( Декабрь 2017 г. ) ( Узнайте, как и когда удалять это сообщение )

Эта статья не содержит достаточного контекста для тех, кто не знаком с предметом . Пожалуйста, помогите улучшить статью, предоставив больше контекста для читателя . ( Ноябрь 2021 г. ) ( Узнайте, как и когда удалить это сообщение )

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

Следующие структуры могут быть использованы в качестве структуры для NFR:

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

2. IVENA ^[1] - Интегрированный подход к приобретению NFR. Метод включает интегрированное дерево требований. [2]

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

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

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

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

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

• Баллы SNAP

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