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

Admin: Перенаправление на ISO/IEC/IEEE 29148

2017-11-30T13:01:32Z

Перенаправление на ISO/IEC/IEEE 29148

Admin: typograph nazi

2017-02-09T11:16:22Z

typograph nazi

Admin в 17:03, 18 ноября 2016

2016-11-18T17:03:55Z

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

2016-08-02T19:55:01Z

Admin: /* Особенности */

2016-08-02T19:26:53Z

‎Особенности

Admin в 11:45, 20 мая 2016

2016-05-20T11:45:30Z

Admin в 08:16, 13 января 2016

2016-01-13T08:16:13Z

Admin: /* Особенности */

2016-01-13T08:16:02Z

‎Особенности

Admin в 08:15, 13 января 2016

2016-01-13T08:15:42Z

Admin в 17:20, 22 декабря 2015

2015-12-22T17:20:34Z

@@ Строка 1: / Строка 1: @@
-''' ISO/IEC/IEEE 29148:2011 Systems and software engineering — Life cycle processes — Requirements engineering '''
+#REDIRECT [[ISO/IEC/IEEE 29148]]
-−
-== Назначение ==
-Стандарт описания практик [[Инженерия требований|инженерии требований]]
-−
-== Особенности ==
-ISO 29148 мимоходом описывает требования к артефактам-требованиям и их группам — например, приводит рекомендации по формулированию текстовых огрызков, из которых состоят требования (типа "обязательность выражайте как shall, а will избегайте", "синтаксис требования — [условие] [предмет] [действие] [объект] [ограничение] или [условие] - [действие] -[значение]"), и агрегирование этих огрызков в списки-"спецификации".
-−
-Стандарт считает требования объектом и приводит пример атрибутов (это только примеры, а не жесткие требования по составу атрибутов):
-* идентификация,
-* приоритет,
-* критичность,
-* риск,
-* источник,
-* обоснование,
-* трудность,
-* тип
-** требования функциональные,
-** эксплуатационные характеристики,
-** интерфейсные,
-** [[ограничение|ограничения]] проекта,
-** нефункциональные (в том числе требования качества и требования со стороны человеческого фактора),
-** процессные.
-−
-Требования делятся на (в соответствии с [[ISO 15288]]):
-* '''требования заинтересованных сторон'''
-* '''системные требования''', включают функциональную границу системы в терминах обеспечиваемого системой поведения и свойств, определение каждой функции, реализационных ограничений, технических мер и мер качества.
-−
-Это всё вытаскивается из текста и явно не похоже на вменяемую стандартом классификацию. Похоже, что авторы стандарта хотели бы проверять не результаты этих работ (артефакты), а то, что велись сами работы (выполнялись [[:Категория:Практики|практики]]). Для максимизации состава артефактов и их возможных состояний (до и после проверок целостности, рассмотрения независимыми экспертами и заинтересованными сторонами, разных анализов и уточнений, обоснований и т.д.) этот стандарт поможет открыть практически неограниченный фронт работ.
-−
-== Основные концепции ==
-Стандарт вводит понятия:
-* база данных требований,
-* документы требований
-** спецификация требований заинтересованных сторон,
-** concept of operations,
-** operational concept (последние два в проекте стандарта определены по-разному)
-* требования к содержанию этих документов
-−
-Набор требований нужно сопровождать в ходе жизненного цикла обязательно вместе со связанными обоснованиями, решениями (decisions) и предположениями (assumptions). Требования также привязываются к базисам.
-−
-== См. также ==
-* С этим стандартом тесно связан [[ISO 24766]]:2009 — руководство по желаемым возможностям инструментов инженерии требований (Guide for requirements engineering tool capabilities).
-−
-[[Категория: Стандарты системной инженерии]]

@@ Строка 41: / Строка 41: @@
 == См. также ==
-* С этим стандартом тесно связан [[ISO 24766]]:2009 -- руководство по желаемым возможностям инструментов инженерии требований (Guide for requirements engineering tool capabilities).
+* С этим стандартом тесно связан [[ISO 24766]]:2009 — руководство по желаемым возможностям инструментов инженерии требований (Guide for requirements engineering tool capabilities).
 [[Категория: Стандарты системной инженерии]]

← Предыдущая		Версия 17:03, 18 ноября 2016
Строка 43:		Строка 43:
	* С этим стандартом тесно связан [[ISO 24766]]:2009 -- руководство по желаемым возможностям инструментов инженерии требований (Guide for requirements engineering tool capabilities).		* С этим стандартом тесно связан [[ISO 24766]]:2009 -- руководство по желаемым возможностям инструментов инженерии требований (Guide for requirements engineering tool capabilities).

−	[[Категория: Стандарты]]	+	[[Категория: Стандарты системной инженерии]]

@@ Строка 19: / Строка 19: @@
 ** эксплуатационные характеристики,
 ** интерфейсные,
-** [[ограничения]] проекта,
+** [[ограничение|ограничения]] проекта,
 ** нефункциональные (в том числе требования качества и требования со стороны человеческого фактора),
 ** процессные.

@@ Строка 19: / Строка 19: @@
 ** эксплуатационные характеристики,
 ** интерфейсные,
-** ограничения проекта,
+** [[ограничения]] проекта,
 ** нефункциональные (в том числе требования качества и требования со стороны человеческого фактора),
 ** процессные.

@@ Строка 29: / Строка 29: @@
 * '''системные требования''', включают функциональную границу системы в терминах обеспечиваемого системой поведения и свойств, определение каждой функции, реализационных ограничений, технических мер и мер качества.
-Это всё вытаскивается из текста и явно не похоже на вменяемую стандартом классификацию. Похоже, что авторы стандарта хотели бы проверять не результаты этих работ (артефакты), а то, что велись сами работы (выполнялись [[:Категория:Практики]]). Для максимизации состава артефактов и их возможных состояний (до и после проверок целостности, рассмотрения независимыми экспертами и заинтересованными сторонами, разных анализов и уточнений, обоснований и т.д.) этот стандарт поможет открыть практически неограниченный фронт работ.
+Это всё вытаскивается из текста и явно не похоже на вменяемую стандартом классификацию. Похоже, что авторы стандарта хотели бы проверять не результаты этих работ (артефакты), а то, что велись сами работы (выполнялись [[:Категория:Практики|Практики]]). Для максимизации состава артефактов и их возможных состояний (до и после проверок целостности, рассмотрения независимыми экспертами и заинтересованными сторонами, разных анализов и уточнений, обоснований и т.д.) этот стандарт поможет открыть практически неограниченный фронт работ.
-−
 == Основные концепции ==

← Предыдущая		Версия 08:15, 13 января 2016
Строка 29:		Строка 29:
	* '''системные требования''', включают функциональную границу системы в терминах обеспечиваемого системой поведения и свойств, определение каждой функции, реализационных ограничений, технических мер и мер качества.		* '''системные требования''', включают функциональную границу системы в терминах обеспечиваемого системой поведения и свойств, определение каждой функции, реализационных ограничений, технических мер и мер качества.

−	Это всё вытаскивается из текста и явно не похоже на вменяемую стандартом классификацию. Похоже, что авторы стандарта хотели бы проверять не результаты этих работ (артефакты), а то, что велись сами работы (выполнялись [[~~практики~~]]). Для максимизации состава артефактов и их возможных состояний (до и после проверок целостности, рассмотрения независимыми экспертами и заинтересованными сторонами, разных анализов и уточнений, обоснований и т.д.) этот стандарт поможет открыть практически неограниченный фронт работ.	+	Это всё вытаскивается из текста и явно не похоже на вменяемую стандартом классификацию. Похоже, что авторы стандарта хотели бы проверять не результаты этих работ (артефакты), а то, что велись сами работы (выполнялись [[:Категория:Практики]]). Для максимизации состава артефактов и их возможных состояний (до и после проверок целостности, рассмотрения независимыми экспертами и заинтересованными сторонами, разных анализов и уточнений, обоснований и т.д.) этот стандарт поможет открыть практически неограниченный фронт работ.