GORE - История изменений

Admin: /* Модель требования */

2016-08-02T19:44:27Z

‎Модель требования

Admin в 19:44, 2 августа 2016

2016-08-02T19:44:11Z

Admin в 14:03, 25 июля 2016

2016-07-25T14:03:33Z

Admin в 11:15, 11 января 2016

2016-01-11T11:15:42Z

Admin в 16:34, 29 ноября 2015

2015-11-29T16:34:22Z

Admin в 19:32, 25 ноября 2015

2015-11-25T19:32:47Z

Admin: Новая страница: «'''Целеориентированная системная инженерия''' (goal-oriented requirements engineering, GORE) подразумевает бо…»

2015-11-25T19:15:28Z

Новая страница: «'''Целеориентированная системная инженерия''' (goal-oriented requirements engineering, GORE) подразумевает бо…»

Новая страница

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

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

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

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

[[Категории:Дисциплины]]

@@ Строка 8: / Строка 8: @@
 == Модель требования ==
-'''Модель требования''' — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д.
+'''Модель требования''' — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и т.д.
 Использующая такие модели инженерия требований — [[Инженерия требований#Моделеориентированная инженерия требований|моделеориентированной инженерией требований]].

@@ Строка 1: / Строка 1: @@
-'''Целеориентированная инженерия требований''' (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, концептуальное моделирование (см., например, [http://mis.sauder.ubc.ca/rigim2008/ (1)] и [http://www.cin.ufpe.br/~rigim09/ (2)] и там темы и работы авторов из оргкомитета).
+'''Целеориентированная инженерия требований''' (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как [[стейкхолдер|стейкхолдеры]], цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, [http://www.cin.ufpe.br/~rigim09/ концептуальное моделирование].
-Это даёт возможность:
+== Назначение ==
 * более точно документировать происхождение требований,
 * обосновывать выбор требований,
 * связывать выбор проектных решений (архитектурных решений) с требованиями.
 '''Модель требования''' — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д.
 Использующая такие модели инженерия требований — [[Инженерия требований#Моделеориентированная инженерия требований|моделеориентированной инженерией требований]].
 Пересекаются два основных языка: [[Сценарий использования|use cases]] и собственно целеориентированные языки. Cм. например:
 * [http://ailev.livejournal.com/800769.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.
 * чего хотят в URN=GRL+UCM? [http://www.cs.toronto.edu/km/GRL/from-r2a/fromr2a/straw01.pdf Перехода от инженерии требований к архитектурному проектированию]

@@ Строка 10: / Строка 10: @@
 Использующая такие модели инженерия требований — [[Инженерия требований#Моделеориентированная инженерия требований|моделеориентированной инженерией требований]].
-Пересекаются два основных языка: use cases и собственно целеориентированные языки. Cм. например:
+Пересекаются два основных языка: [[Сценарий использования|use cases]] и собственно целеориентированные языки. Cм. например:
 * [http://ailev.livejournal.com/800769.html редактор нотации пользовательских требований]
 * [http://ailev.livejournal.com/810548.html список нотаций для работы социотехника в инженерии требований].

@@ Строка 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 Перехода от инженерии требований к архитектурному проектированию]
 * [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]
-* [http://www.omg.org/spec/BMM/1.1/Beta2/PDF/ OMG BMM], где дается тот же анализ "целей-средств"
+* [[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://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).

← Предыдущая		Версия 16:34, 29 ноября 2015
Строка 1:		Строка 1:
−	'''Целеориентированная ~~системная~~ инженерия''' (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, концептуальное моделирование (см., например, [http://mis.sauder.ubc.ca/rigim2008/ (1)] и [http://www.cin.ufpe.br/~rigim09/ (2)] и там темы и работы авторов из оргкомитета).	+	'''Целеориентированная инженерия требований''' (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, концептуальное моделирование (см., например, [http://mis.sauder.ubc.ca/rigim2008/ (1)] и [http://www.cin.ufpe.br/~rigim09/ (2)] и там темы и работы авторов из оргкомитета).

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