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

Admin: /* Программное обеспечение */

2018-12-20T21:16:00Z

‎Программное обеспечение

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

2018-01-08T03:26:39Z

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

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

2017-03-10T15:29:14Z

‎Кто должен делать требования?

Admin в 15:27, 10 марта 2017

2017-03-10T15:27:59Z

Admin: /* Другие практики с использованием моделеориентированных требований */

2016-11-14T13:16:32Z

‎Другие практики с использованием моделеориентированных требований

Admin: /* Стандарты инженерии требований */

2016-08-23T19:54:46Z

‎Стандарты инженерии требований

Admin: /* Программное обеспечение */

2016-08-15T20:30:55Z

‎Программное обеспечение

Admin: /* Программное обеспечение */

2016-08-15T20:29:03Z

‎Программное обеспечение

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

2016-07-25T14:02:47Z

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

2016-07-25T13:03:51Z

@@ Строка 53: / Строка 53: @@
 === Программное обеспечение ===
-* [[Modelica]] - объектно-ориентированный язык и интерпретатор
+* [[Modelica]]
-* [[Julia]]  - язык программирования для системных требований
+* [[DOORS|IBM Rational DOORS]]
-* [https://www.threesl.com 3SL Cradle] - система управления требованиями и проектированием
+* [https://www.threesl.com 3SL Cradle]
 === Другие практики с использованием моделеориентированных требований ===

@@ Строка 44: / Строка 44: @@
 В [[Инженерия предприятия|инженерии предприятий]] (enterprise engineering) модели требований (к предприятию/к архитектуре предприятия) часто называют '''мотивационными моделями''' (motivation не только «движущая сила, побуждение», но и обоснование – reason, justification).
-'''Моделеориентированность''' (как шаг к формальным требованиям) '''хороша для проведения проверок самих требований (хотя она не поможет найти пропущенное требование)'''. Требования должны документироваться и затем использоваться для проведения испытаний (проверок и приёмок) как чеклисты.
+'''Моделеориентированность''' (как шаг к формальным требованиям) '''хороша для проведения проверок самих требований (хотя она не поможет найти пропущенное требование)'''. Требования должны [[документирование|документироваться]] и затем использоваться для проведения испытаний ([[Проверки и приемки|проверок и приёмок]]) как [[Практика контрольных вопросов|чеклисты]].
 === Примеры языков для моделей требований ===

@@ Строка 22: / Строка 22: @@
 == Инженер по требованиям ==
 === Кто должен делать требования? ===
-# Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: “вы предоставьте нам подробные требования, иначе мы и пальцем не пошевелим”. Должен разочаровать: это неверная позиция. '''Заказчик может представить только свои нужды, а не требования к системе'''. Если у заказчика есть инженеры (или заказ на разработку системы делает инженерная фирма), то есть шанс получить “требования стейкхолдера”. Но это ещё не требования к системе.
+# Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: "вы предоставьте нам подробные требования, иначе мы и пальцем не пошевелим". Это неверная позиция. '''Заказчик может представить только свои нужды, а не требования к системе'''. Если у заказчика есть инженеры (или заказ на разработку системы делает инженерная фирма), то есть шанс получить "требования стейкхолдера". Но это ещё не требования к системе.
 # '''Разрабатывает требования обычно команда проекта''', они не приходят извне проекта. Другое дело, что без активного участия стейкхолдеров (в том числе представителей организации заказчика) требования не подготовишь. Но в любом случае, ответственность за требования лежит на команде проекта, а не на заказчике. Заказчик же может, например, завизировать разработанные командой проекта требования — но и в этом случае, изготовленная система, которая не удовлетворит его нуждам (needs) по причине того, что требования были сформулированы командой проекта неправильно, может встретить серьёзные проблемы при приёмке/validation (хотя блестяще пройдёт проверку/verification — инженеры подтвердят сами себе, что изготовили ровно то, что планировали, хотя это не то, в чём нуждался клиент). '''За требования ответственен инженер потому что он должен сделать реверс-инжиниринг использующей системы''': часто клиент на это не способен, хотя он обычно и весьма знающ об особенностях используемой системы, но эти знания могут быть совсем не такими, на которые мог бы расчитывать инженер.

@@ Строка 1: / Строка 1: @@
-'''Инженерия требований''' (Requirements Engineering, RE) — это поддисциплина системной инженерии, занимается разработкой [[Требования|требований]].
+'''Инженерия требований''' (Requirements Engineering, RE) — поддисциплина [[Системная инженерия|системной инженерии]], которая занимается разработкой [[Требования|требований]].
-Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания “чёрного ящика”.
+Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания "чёрного ящика".
-''Проблема: все требования проходят по ЖЦ асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.''
+''Проблема: все требования проходят по [[ЖЦ]] асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.''
 Инженерия требований включает в себя:
@@ Строка 14: / Строка 14: @@
 Инженерия требований должна начинаться с [[Управление требованиями|управления требованиями]].
-'''Требование''' — это приписанное к части системы утверждение (assertion).
+'''[[Требования|Требование]]''' — это приписанное к части системы утверждение (assertion).
-'''Контрольная точка''' — это достижение этого требования к какому-то моменту.
+'''[[Гейты и вехи|Контрольная точка]]''' — это достижение этого требования к какому-то моменту.
 Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут.

@@ Строка 59: / Строка 59: @@
 === Другие практики с использованием моделеориентированных требований ===
 * '''Test driven development''' – это когда разработка системы начинается с того, что требования разрабатываются сразу в виде тестов (исполняемых!). Увы, качество разработки по TDD получается примерно такое же, как и при любых других видах разработки – что не снижает популярности этого подхода. Требования как правило разрабатываются с помощью сценариев ([[Сценарий использования|use cases]]), в которых рассказывается, что делает система в ответ на последовательности действий (сценарии) с участием разных стейкхолдеров.
-* Использование '''user story''' в формулировках по шаблону ([http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-userstory-template Mike Cohn, 2008, Advantages of the “As a user, I want” user story template, blog post]): Я как [стейкхолдер] хочу, чтобы система [формулировка требования], для того чтобы [хотелка-для-using-system].
+* Использование '''[[Пользовательские истории|user story]]''' в формулировках по шаблону ([http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-userstory-template Mike Cohn, 2008, Advantages of the “As a user, I want” user story template, blog post]): Я как [стейкхолдер] хочу, чтобы система [формулировка требования], для того чтобы [хотелка-для-using-system].
 == Целеориентированная инженерия требований ==

@@ Строка 93: / Строка 93: @@
 Взаимосвязь основных стандартов инженерии требований отражена на диаграмме:
-[[Файл:RE relation.png]]
+[[Файл:RE relation.png|center]]
 == См. также ==