GORE — различия между версиями
Admin (обсуждение | вклад) м |
Admin (обсуждение | вклад) м |
||
| Строка 1: | Строка 1: | ||
| − | '''Целеориентированная инженерия требований''' (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения | + | '''Целеориентированная инженерия требований''' (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как [[стейкхолдер|стейкхолдеры]], цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, [http://www.cin.ufpe.br/~rigim09/ концептуальное моделирование]. |
| − | + | == Назначение == | |
| + | GORE даёт возможность: | ||
* более точно документировать происхождение требований, | * более точно документировать происхождение требований, | ||
* обосновывать выбор требований, | * обосновывать выбор требований, | ||
* связывать выбор проектных решений (архитектурных решений) с требованиями. | * связывать выбор проектных решений (архитектурных решений) с требованиями. | ||
| + | == Модель требования == | ||
'''Модель требования''' — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д. | '''Модель требования''' — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д. | ||
Использующая такие модели инженерия требований — [[Инженерия требований#Моделеориентированная инженерия требований|моделеориентированной инженерией требований]]. | Использующая такие модели инженерия требований — [[Инженерия требований#Моделеориентированная инженерия требований|моделеориентированной инженерией требований]]. | ||
| + | == Нотации == | ||
Пересекаются два основных языка: [[Сценарий использования|use cases]] и собственно целеориентированные языки. Cм. например: | Пересекаются два основных языка: [[Сценарий использования|use cases]] и собственно целеориентированные языки. Cм. например: | ||
* [http://ailev.livejournal.com/800769.html редактор нотации пользовательских требований] | * [http://ailev.livejournal.com/800769.html редактор нотации пользовательских требований] | ||
* [http://ailev.livejournal.com/810548.html список нотаций для работы социотехника в инженерии требований]. | * [http://ailev.livejournal.com/810548.html список нотаций для работы социотехника в инженерии требований]. | ||
| − | + | == Ссылки == | |
| − | + | ||
| − | + | ||
* [http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/UCMVirtualLibraryAllPubs URN] (User requirements notation, в которой целеориентированный язык GRL, goal requirements language). Хотя основной упор в литературе и делается на use case maps (подозрительно напоминающая [[OMG BPMN]] нотация), в последние годы есть публикации и по GRL. | * [http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/UCMVirtualLibraryAllPubs URN] (User requirements notation, в которой целеориентированный язык GRL, goal requirements language). Хотя основной упор в литературе и делается на use case maps (подозрительно напоминающая [[OMG BPMN]] нотация), в последние годы есть публикации и по GRL. | ||
* чего хотят в URN=GRL+UCM? [http://www.cs.toronto.edu/km/GRL/from-r2a/fromr2a/straw01.pdf Перехода от инженерии требований к архитектурному проектированию] | * чего хотят в URN=GRL+UCM? [http://www.cs.toronto.edu/km/GRL/from-r2a/fromr2a/straw01.pdf Перехода от инженерии требований к архитектурному проектированию] | ||
Версия 22:44, 2 августа 2016
Целеориентированная инженерия требований (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, концептуальное моделирование.
Содержание
Назначение
GORE даёт возможность:
- более точно документировать происхождение требований,
- обосновывать выбор требований,
- связывать выбор проектных решений (архитектурных решений) с требованиями.
Модель требования
Модель требования — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д.
Использующая такие модели инженерия требований — моделеориентированной инженерией требований.
Нотации
Пересекаются два основных языка: 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.