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