GORE — различия между версиями

Версия 17:03, 25 июля 2016

Целеориентированная инженерия требований (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, концептуальное моделирование (см., например, (1) и (2) и там темы и работы авторов из оргкомитета).

Это даёт возможность:

• более точно документировать происхождение требований,
• обосновывать выбор требований,
• связывать выбор проектных решений (архитектурных решений) с требованиями.

Модель требования — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д.

Использующая такие модели инженерия требований — моделеориентированной инженерией требований.

Пересекаются два основных языка: use cases и собственно целеориентированные языки. Cм. например:

• редактор нотации пользовательских требований
• список нотаций для работы социотехника в инженерии требований.

Основная идея целеориентированности в инженерии требований: "требования возникают из-за того, что люди что-то хотят, у них есть цели. Давайте обсудим цели в сочетании со средствами их достижения. Заодно запишем, чьи эти цели — и при разбирательстве развилок в выборе средств будет появляться много-много традиционно выглядящих требований".

Сюда можно отнести:

• URN (User requirements notation, в которой целеориентированный язык GRL, goal requirements language). Хотя основной упор в литературе и делается на use case maps (подозрительно напоминающая OMG BPMN нотация), в последние годы есть публикации и по GRL.
• чего хотят в URN=GRL+UCM? Перехода от инженерии требований к архитектурному проектированию
• подход агентского программирования i*, в котором тоже предложена неформальная нотация для инженерии требований (имеющая множество вариантов): список литературы обрывается на 2005 году, но это далеко не конец истории.
• NOMOS, подход к целеориентированному моделированию требований в техническом регулировании (требования+права): работы Alberto Siena
• OMG BMM, где дается тот же анализ "целей-средств"
• карты действий и результатов Голдратта (напомню, что оригинальный язык там такой: Strategy and Tactics tree, и кроме этих Strategy и Tactic указываются разные Assumptions), которые сводятся к более-менее структурированному представлению тех же means-ends (целей-средств) с их каким-то обоснованием (но про собственно обоснования — позже, ибо карты действий и результатов Голдратта появляются не столько в начале жизненного цикла, сколько ближе к его концу — и тем самым попадают больше в "обоснования").
• Goal-oriented software engineering — это опять про то же самое: как справиться с нефункциональными требованиями в программной инженерии, тут же аспект-ориентированная инженерия требований и так далее все про инженерию требований. В основе этого подхода — The tradeoffs among goals, soft-goals, tasks and resources are represented in a soft-goal interdependence graph (SIG).
• в ArchiMate 2.0 (вышел 31 января 2012г.) требования к архитектуре задаются дополнением целеполагания (motivational) и полностью соответствуют подходу GORE.