Требования - История изменений

Admin: Перенаправление на Категория:Требования

2017-09-20T17:29:58Z

Перенаправление на Категория:Требования

Внесённые изменения

Admin: /* Стандарты представления требований */

2017-01-09T22:00:15Z

‎Стандарты представления требований

Admin: /* Состояния требований по OMG Essence */

2016-11-18T13:02:57Z

‎Состояния требований по OMG Essence

Admin: /* Жизненный цикл требований стейкхолдеров */

2016-11-17T08:38:58Z

‎Жизненный цикл требований стейкхолдеров

Admin: /* Рабочие продукты требований */

2016-10-19T09:59:00Z

‎Рабочие продукты требований

Admin: /* Рабочие продукты требований */

2016-10-18T20:14:33Z

‎Рабочие продукты требований

Admin в 10:03, 18 августа 2016

2016-08-18T10:03:29Z

Admin: /* Требования к системе */

2016-08-02T19:52:40Z

‎Требования к системе

Admin: /* Требования к продукту */

2016-08-02T19:33:06Z

‎Требования к продукту

Admin в 21:29, 1 августа 2016

2016-08-01T21:29:06Z

@@ Строка 89: / Строка 89: @@
 ** [[ArchiMate]]
 ** MBRD
-** OMG BMM
+** [[OMG BMM]]
 ** Planguage
 * [[ISO 15926]]

@@ Строка 147: / Строка 147: @@
 * '''Актуальность''' -  Требование не стало устаревшим с течением времени.
-== Состояния требований по [[OMG Essence]] ==
+== Состояния ==
-# Начаты (concieve) – согласована потребность в системе.
+[[OMG Essence]] определяет следующие состояния для альфы "Требования" и [[Практика контрольных вопросов|контрольные вопросы]] для проверки каждого состояния:
-# Ограничены (bounded) – назначение и тема новой системы ясны.
+{| class="wikitable" style="font-size: 9pt;"
-# Непротиворечивы (coherent) – требования обесечивают непротиворечивое описание существенных характеристик новой системы.
+! style="text-align: center; font-weight: bold; width:4%" | №
-# Приемлемы (acceptable) – требования описывают систему, которая будет принята стейкхолдерами.
+! style="text-align: center; font-weight: bold; width:10%" | Состояние
-# Отвечены (addressed) – достаточное количество требований было отвечено, чтобы удовлетворить потребность в новой системе способом, приемлемым для стейкхолдеров.
+! style="text-align: center; font-weight: bold; width:10%" | State
-# Удовлетворены (fulfilled) – требования, которые были адресованы, полностью удовлетворяют потребность в новой системе. ''Проблема: все требования проходят по ЖЦ асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.''
+! style="text-align: center; font-weight: bold; width:16%" | Описание состояния
 [[Категория:Концепции]]
 [[Категория: Альфы]]

@@ Строка 99: / Строка 99: @@
 # '''Разработать [[Концепция системы|Концепцию функционирования]] (operational concept) и другие концепции жизненного цикла''' (определить набор сценариев, определить взаимодействия пользователей и системы)
 # '''Преобразовать потребности стейхколдеров в требования стейкхолдеров''' (идентифицировать ограничения на инженерные решения, идентифицировать требования стейкхолдеров и все функции для требований качества, гармонизировать требования стейкхолдеров)
-# '''Анализировать требования стейкхолдеров''' (анализировать полное множество требований стейкхолдеров, определить критические [[Показатели эффективности|показатели результативности]], которые позволят оценить технические достижения, получить обратную связь от стейкхолдеров – валидировать, устранить все проблемы и противоречия со стейкхолдерами)
+# '''Анализировать требования стейкхолдеров''' (анализировать полное множество требований стейкхолдеров, определить критические [[MOE|показатели результативности]], которые позволят оценить технические достижения, получить обратную связь от стейкхолдеров – валидировать, устранить все проблемы и противоречия со стейкхолдерами)
 # '''Управлять определением потребностей стейкхолдеров и требованиями''' (получить явное согласие на требования стейкхолдеров, поддерживать трассировку потребностей и требований, обеспечивать сведения по базисам)

@@ Строка 117: / Строка 117: @@
 Важно понимать, что:
 # требования системной инженерии — '''определения “чёрного ящика”, которые могут даже не содержать слово “требования” в своих рабочих продуктах и не содержать слов, обозначающих деонтическую модальность''' — быть без слов “должно”, “возможно”, “обязательно” и т.д.
-# '''требования совсем необязательно являются бумажными документами-текстами'''. Они вполне могут храниться в какой-то БД (в рамках какой-то “информационной системы управления требованиями” — [[DOORS]], [[IRqA]] и т.д.) в виде отдельных пронумерованных текстовых описаний или в виде компьютерной модели, численной или логической.
+# '''требования совсем необязательно являются бумажными документами-текстами'''. Они вполне могут храниться в какой-то БД (в рамках какой-то “информационной системы управления требованиями” — [[DOORS]], [[IRQA]] и т.д.) в виде отдельных пронумерованных текстовых описаний или в виде компьютерной модели, численной или логической.
 == Управление требованиями и инженерия требований ==

@@ Строка 117: / Строка 117: @@
 Важно понимать, что:
 # требования системной инженерии — '''определения “чёрного ящика”, которые могут даже не содержать слово “требования” в своих рабочих продуктах и не содержать слов, обозначающих деонтическую модальность''' — быть без слов “должно”, “возможно”, “обязательно” и т.д.
-# '''требования совсем необязательно являются бумажными документами-текстами'''. Они вполне могут храниться в какой-то БД (в рамках какой-то “информационной системы управления требованиями” — DOORS, IRqA и т.д.) в виде отдельных пронумерованных текстовых описаний или в виде компьютерной модели, численной или логической.
+# '''требования совсем необязательно являются бумажными документами-текстами'''. Они вполне могут храниться в какой-то БД (в рамках какой-то “информационной системы управления требованиями” — [[DOORS]], [[IRqA]] и т.д.) в виде отдельных пронумерованных текстовых описаний или в виде компьютерной модели, численной или логической.
 == Управление требованиями и инженерия требований ==

← Предыдущая		Версия 10:03, 18 августа 2016
Строка 156:		Строка 156:

	[[Категория:Концепции]]		[[Категория:Концепции]]
−	[[Категория: ~~Альфа~~]]	+	[[Категория: Альфы]]

@@ Строка 36: / Строка 36: @@
 * проверяемость
 * и т.д.
 == Модальность ==

@@ Строка 15: / Строка 15: @@
 Требования к продукту от разных стейкхолдеров могут быть противоречивы, разрознены и неполны. Обычно от инженера по требованиям требуется документировать (в тексте или какой-то модели) требования стейкхолдеров, а затем завизировать эти требования у них — чтобы подтвердить правильность понимания.
-Каждый клиент мнит себя инженером (а иногда не мнит, а является ещё и инженером, более знающим, чем инженеры команды проекта). Такой клиент не только будет формулировать требования стейкхолдера, а также требования к системе, но обязательно попытается сформулировать конкретные инженерные решения “прозрачного ящика” (например, из каких частей должна составлять система, какое в ней должно быть использовано оборудование). Формально высказывания о “прозрачном ящике” не называются требованиями, поэтому некоторые авторы предлагают называть их '''“ограничениями”''' (свободы творчества инженерной команды). Неплохо бы понимать в каждом проекте, что является требованиями, а что является ограничениями. Прежде всего вы должны удовлетворить требования. И '''если придуманное вами инженерное решение лучше того, которое требует клиент в своих ограничениях, попытаться убедить клиента снять эти ограничения'''. Но нужно понимать, что иногда эти ограничения отражают какой-то опыт клиента, неизвестный команде, или они появляются из неинженерных (политических, финансовых, логистических и т.д.) соображений. Поэтому по поводу ограничений '''нужно каждый раз понимать, почему они были прописаны''', почему клиент без них не может обойтись (см. [[GORE]]).
+Каждый клиент мнит себя инженером (а иногда не мнит, а является ещё и инженером, более знающим, чем инженеры команды проекта). Такой клиент не только будет формулировать '''требования стейкхолдера''', а также '''требования к системе''', но обязательно попытается сформулировать '''конкретные инженерные решения''' “прозрачного ящика” (например, из каких частей должна составлять система, какое в ней должно быть использовано оборудование).
 Требование к требованиям стейкхолдеров: их понятность самим стейкхолдерам. Стейкхолдеры нуждаются в требованиях, которые сфокусированы их '''нуждами'''.

← Предыдущая		Версия 21:29, 1 августа 2016
Строка 142:		Строка 142:

	[[Категория:Концепции]]		[[Категория:Концепции]]
		+	[[Категория: Альфа]]