A Модель цели является элементом разработки требований, который также может более широко использоваться в бизнес-анализ. Связанные элементы включают анализ заинтересованных сторон, анализ контекста и сценарии, а также другие деловые и технические области.
Цели - это задачи, которые система должна достигать посредством сотрудничества участников в предполагаемом программном обеспечении и в среде. Моделирование целей особенно полезно на ранних этапах проекта. В проектах может учитываться, как намеченная система соответствует целям организации (см. Также), почему система нужна и как могут быть учтены интересы заинтересованных сторон.
Модель цели:
Для моделей целей в программном обеспечении используется несколько обозначений. разработка, в том числе:
Другие обозначения были предложенных исследователями, в то время как нотация структурирования целей (GSN) и GRL иногда используются для создания обоснований безопасности для удовлетворения требований регулирующего органа в отраслях, связанных с безопасностью.
Нотация моделирования целей i * предоставляет два вида диаграмм:
i * показывает каждую роль (действующего лица, агента или position) в виде большого круга, содержащего цели, задачи и ресурсы, которыми владеет эта роль. Собственность в i * означает, что роль желает удовлетворения своих целей либо для своей собственной выгоды, либо для выгоды какой-либо другой роли. Цели могут сопровождаться «препятствиями» (отрицательными целями), которые необходимо преодолеть. Нефункциональные цели можно смоделировать как «мягкие цели» в i *: они изображены в виде облаков или овалов с отступом.
Нотация моделирования целей KAOS обеспечивает способ определения целей и препятствий, подкрепленных формальным (математическим) методом анализа.
диаграмма вариантов использования UML обеспечивает простую нотацию моделирования целей. Пузырьки обозначают функциональные цели, поэтому диаграмма вариантов использования формирует простую модель цели только для функций: как пишет Кокберн, варианты использования охватывают только поведенческие требования. Роли показаны как действующие лица (человечки на диаграмме), связанные с вариантами использования, в которых они принимают участие. Сценарии использования нарисованы в виде эллиптических пузырей, представляющих желаемые поведенческие цели.
С добавлением случаев неправильного использования нотация может моделировать как желаемые цели, так и активные угрозы. Обозначение случаев неправомерного использования показывает отрицательные (возможно, враждебные) заинтересованные стороны как основные действующие лица в случаях неправомерного использования; их можно сгруппировать в правой части диаграммы. Обозначение может помочь в обнаружении подходящих смягчающих или профилактических целей, показанных как дополнительные варианты использования. Они часто имеют целью повышение безопасности, защищенности или надежности, что не является функциональной целью. Нефункциональные требования можно до некоторой степени описать в стиле варианта использования, используя случаи неправильного использования для определения отрицательных целей; но обнаруженные таким образом (положительные) цели часто являются функциональными. Например, если кража представляет собой угрозу для безопасности, то установка блокировок является смягчением; но то, что дверь может быть заперта, является функциональным требованием.
Противоположным моментом является то, что варианты использования не имеют корней когнитивной науки, в то время как i * и KAOS - корни. Действительно, литература, посвященная вариантам использования, не включает обсуждение «Намерение цели», «Уточнение цели», «Конечное средство», не упоминает Расмуссена и так далее. Может существовать склонность связывать варианты использования с целями из-за визуальной метафоры целей, а не семантики уточнения целей согласно когнитивной науке.