GORE — различия между версиями
Admin (обсуждение | вклад) |
Admin (обсуждение | вклад) |
||
| Строка 17: | Строка 17: | ||
Сюда можно отнести: | Сюда можно отнести: | ||
| − | * [http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/UCMVirtualLibraryAllPubs URN] (User requirements notation, в которой целеориентированный язык GRL, goal requirements language). Хотя основной упор в литературе и делается на use case maps (подозрительно напоминающая 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 Перехода от инженерии требований к архитектурному проектированию] | ||
* [http://istar.rwth-aachen.de/tiki-index.php?page_ref_id=200 подход агентского программирования i*], в котором тоже предложена неформальная нотация для инженерии требований (имеющая множество вариантов): [http://istar.rwth-aachen.de/tiki-index.php?page=Requirements%20Engineering список литературы] обрывается на 2005 году, но это далеко не конец истории. | * [http://istar.rwth-aachen.de/tiki-index.php?page_ref_id=200 подход агентского программирования i*], в котором тоже предложена неформальная нотация для инженерии требований (имеющая множество вариантов): [http://istar.rwth-aachen.de/tiki-index.php?page=Requirements%20Engineering список литературы] обрывается на 2005 году, но это далеко не конец истории. | ||
* NOMOS, подход к целеориентированному моделированию требований в техническом регулировании (требования+права): [https://sites.google.com/site/albertosiena/ работы Alberto Siena] | * NOMOS, подход к целеориентированному моделированию требований в техническом регулировании (требования+права): [https://sites.google.com/site/albertosiena/ работы Alberto Siena] | ||
| − | * [ | + | * [[OMG BMM]], где дается тот же анализ "целей-средств" |
* [http://praxos.ru/index.php/%D0%9A%D0%B0%D1%80%D1%82%D0%B0_%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B9_%D0%B8_%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82%D0%BE%D0%B2 карты действий и результатов] Голдратта (напомню, что оригинальный язык там такой: Strategy and Tactics tree, и кроме этих Strategy и Tactic указываются разные Assumptions), которые сводятся к более-менее структурированному представлению тех же means-ends (целей-средств) с их каким-то обоснованием (но про собственно обоснования — позже, ибо карты действий и результатов Голдратта появляются не столько в начале жизненного цикла, сколько ближе к его концу — и тем самым попадают больше в "обоснования"). | * [http://praxos.ru/index.php/%D0%9A%D0%B0%D1%80%D1%82%D0%B0_%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B9_%D0%B8_%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82%D0%BE%D0%B2 карты действий и результатов] Голдратта (напомню, что оригинальный язык там такой: Strategy and Tactics tree, и кроме этих Strategy и Tactic указываются разные Assumptions), которые сводятся к более-менее структурированному представлению тех же means-ends (целей-средств) с их каким-то обоснованием (но про собственно обоснования — позже, ибо карты действий и результатов Голдратта появляются не столько в начале жизненного цикла, сколько ближе к его концу — и тем самым попадают больше в "обоснования"). | ||
* [http://www.cs.toronto.edu/km/goal_oriented/index.html Goal-oriented software engineering] — это опять про то же самое: [http://www.utdallas.edu/~chung/BOOK/book.html как справиться с нефункциональными требованиями в программной инженерии], тут же [http://www.cs.toronto.edu/cser/aore.html аспект-ориентированная инженерия требований] и так далее все про инженерию требований. В основе этого подхода — The tradeoffs among goals, soft-goals, tasks and resources are represented in a soft-goal interdependence graph (SIG). | * [http://www.cs.toronto.edu/km/goal_oriented/index.html Goal-oriented software engineering] — это опять про то же самое: [http://www.utdallas.edu/~chung/BOOK/book.html как справиться с нефункциональными требованиями в программной инженерии], тут же [http://www.cs.toronto.edu/cser/aore.html аспект-ориентированная инженерия требований] и так далее все про инженерию требований. В основе этого подхода — The tradeoffs among goals, soft-goals, tasks and resources are represented in a soft-goal interdependence graph (SIG). | ||
Версия 14:15, 11 января 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.