ГОСТ Р 59194-2020. Национальный стандарт Российской Федерации. Управление требованиями. Основные положения
(утв. и введен в действие Приказом Росстандарта от 18.11.2020 № 1129-ст)
Примечание
Документ введен в действие с 01.06.2021.
Приказом Федерального агентства
по техническому регулированию
и метрологии
от 18 ноября 2020 г. № 1129-ст
1 РАЗРАБОТАН Акционерным обществом «Научно-исследовательский центр „Прикладная Логистика“ (АО НИЦ „Прикладная Логистика“)»
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 482 «Поддержка жизненного цикла экспортируемой продукции военного и продукции двойного назначения»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 ноября 2020 г. № 1129-ст
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Настоящий стандарт устанавливает основные цели, задачи и принципы управления требованиями на всех стадиях жизненного цикла изделий машиностроения, приборостроения и их составных частей.
Применение требований стандарта к другим видам изделий определяется по усмотрению организации-разработчика.
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ 2.051 Единая система конструкторской документации. Электронные документы. Общие положения
ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов
ГОСТ 15.016 Система разработки и постановки продукции на производство. Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов
ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.301 Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению
ГОСТ 34.201 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
ГОСТ 34.602 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
ГОСТ Р 51904 Программное обеспечение встроенных систем. Общие требования к разработке и документированию
ГОСТ Р 56136 Управление жизненным циклом продукции военного назначения. Термины и определения
ГОСТ Р 57193-2016 Системная и программная инженерия. Процессы жизненного цикла систем
ГОСТ Р 57412 Компьютерные модели в процессах разработки, производства и эксплуатации изделий. Общие положения
ГОСТ Р 58300 Управление данными об изделии. Термины и определения
ГОСТ Р 58301 Управление данными об изделии. Электронный макет изделия. Общие требования
ГОСТ Р 59193-2020 Управление конфигурацией. Основные положения
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины, определения и сокращения
3.1 Термины и определения
В настоящем стандарте применены термины по ГОСТ Р 56136, ГОСТ Р 58300 и ГОСТ Р 59193, а также следующие термины с соответствующими определениями:
<1> Здесь и далее знаком «*» отмечены терминологические статьи и пункты, к которым даны пояснения в приложении А.
| валидация объекта: Подтверждение на основе представления объективных свидетельств того, что объект удовлетворяет потребностям заинтересованных сторон. Примечание — Валидация, как правило, выполняется при завершении разработки объекта и передаче результатов заказчику (головному разработчику для СЧ). [ГОСТ Р 59193-2020, пункт 3.1.1] |
|---|
3.1.3 валидация требований: Подтверждение того, что разработанные требования позволят создать объект, удовлетворяющий потребностям заинтересованных сторон*.
верификация объекта: Подтверждение на основе представления объективных свидетельств того, что объект разработан в соответствии с заданными требованиями.
[ГОСТ Р 59193-2020, пункт 3.1.2]
3.1.5 верификация требований: Проверка содержания и оформления требований на соответствие установленным критериям качества*.
3.1.6 версия требований: Содержание (одного или совокупности) требований к объекту (в том числе атрибутов требований), зафиксированное в конкретный момент времени или с определенной целью.
3.1.7 доказательный документ; ДД: Документ, утвержденный в установленном порядке и содержащий объективные свидетельства выполнения требований к объекту.*
| документация (данные) конфигурации: Комплект документов и/или данных, в которых содержится описание конфигурации объекта. [ГОСТ Р 59193-2020, пункт 3.1.3] |
|---|
3.1.9 заинтересованная сторона: Физическое лицо или организация (подразделение организации), которое(ая) выполняет по отношению к объекту какую-либо роль и, в связи с этим, имеет потребности (интересы, ожидания), связанные с объектом*.
3.1.11 исходное (заданное) требование: Требование, полученное в результате анализа потребностей заинтересованной стороны.
3.1.12 метод оценки соответствия; МОС: Способ проверки соответствия объекта требованиям*.
| объект конфигурации; ОКнф: Составная часть изделия, значимая для выполнения установленных требований и рассматриваемая в процедурах управления конфигурацией как единое целое. Примечания 1 Объектом конфигурации на разных этапах разработки и стадиях жизненного цикла может быть финальное изделие в целом и составная часть изделия (система, агрегат, узел, деталь, программа для ЭВМ, в т.ч. встроенное программное обеспечение), документ (информационный набор, база данных и т.п.), интерфейс, материал, объекты, связанные с процессами жизненного цикла (стенд, оснастка, средство технического обслуживания и ремонта, инфраструктура, средство обеспечения производства и эксплуатации, система обучения, система сопровождения программных средств и т.п.). 2 Экземпляр изделия, являющегося ОКнф, как правило, получает уникальный идентификатор (индивидуальный или групповой), позволяющий отслеживать его характеристики в ходе жизненного цикла. [ГОСТ Р 59193-2020, пункт 3.1.8] |
|---|
3.1.14 ограничение: Составная часть требования или самостоятельное требование, описывающее внешнее ограничивающее условие (связанное с внешними по отношению к объекту воздействующими факторами), наложенное на объект, его конструкцию, процесс разработки, изготовления, эксплуатации, ремонта или утилизации.
3.1.15 проектное (системное) требование: Требование, полученное в результате анализа и декомпозиции исходных требований, а также в результате деятельности по проектированию и конструированию.
3.1.16 прослеживаемость требования: Свойство требования, указывающее на возможность проследить источник (источники) требования (потребность заинтересованной стороны, исходное или проектное требование, принятое техническое решение) или отследить все дочерние требования.
3.1.17 спецификация исходных требований: Структурированная совокупность согласованных и взаимосвязанных исходных требований к объекту, относящихся к одной или нескольким заинтересованным сторонам, и описание условий и/или ограничений, для которых эти требования применимы.
3.1.18 спецификация проектных требований: Структурированная совокупность согласованных и взаимосвязанных проектных требований к объекту, условиям его применения/работы и к взаимодействию с другими объектами.
3.1.19 статус выполнения требований: Формальный признак, присваиваемый версии требований по результатам верификации или валидации объекта, обозначающий степень соответствия объекта этим требованиям на конкретной стадии (этапе) жизненного цикла.
3.1.20 статус готовности требований: Формальный признак, присваиваемый версии требований в ходе ее жизненного цикла, обозначающий состояние готовности требований к дальнейшему использованию по назначению.
3.1.21 требование: Требуемая (ожидаемая) количественная или качественная характеристика или свойство объекта, а также связанные ограничения и условия*.
3.1.22 управление требованиями: Совокупность видов инженерной и управленческой деятельности по формированию требований к изделию, их анализу, структурированию, документированию, взаимному согласованию, утверждению, учету выполнения, а также согласованное и контролируемое изменение требований при необходимости.
3.1.23 условие: Составная часть требования, которая указывает на обстоятельство или событие, при котором применяется требование.
3.2 Сокращения
В настоящем стандарте использованы следующие сокращения:
АС УДИ — автоматизированная система управления данными об изделии;
МОС — метод оценки соответствия;
ПМИ — программа и методика испытаний;
ТТЗ — тактико-техническое задание;
УК — управление конфигурацией;
ЭВМ — электронная вычислительная машина;
ЭМИ — электронный макет изделия.
4.1 В составе УТ выделяют два вида деятельности*:
- разработка требований — инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию и его СЧ, основанная на анализе потребностей заказчика и других заинтересованных сторон;
- контроль требований — управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон). Эта деятельность является частью процесса УК в соответствии с ГОСТ Р 59193, выполняемого в отношении требований.
4.2 Управление требованиями осуществляют совместно заказчик и поставщик изделия.
Для координации деятельности по УТ, при необходимости, разрабатывают программу УТ, в котором перечисляют решаемые задачи УТ, методы их решения (с указанием применяемых документов по стандартизации), ответственных исполнителей, способы обмена данными, планируемые результаты, взаимосвязи с процессом УК.
4.3 Требования задают к изделию в целом и к его СЧ (системам, агрегатам, узлам, деталям, программам для ЭВМ, в т.ч. встроенному ПО), к документам (информационным наборам, базам данных и т.п.), материалам, интерфейсам, объектам, связанным с процессами ЖЦ (далее: объекты).
4.4 Требования могут быть представлены в форме*:
- базы данных (совокупности информационных объектов и наборов) в автоматизированной системе;
- документа (бумажного или электронного по ГОСТ 2.051).
Требования могут быть представлены в составе функционального ЭМИ в АС УДИ по ГОСТ Р 58301.
4.5 Все требования к одному объекту, необходимые для решения определенной задачи в ходе ЖЦ, составляют спецификацию требований к объекту*.
При разработке нового объекта формируют:
- спецификацию исходных (заданных) требований к объекту — для формализации потребностей всех заинтересованных сторон и создания базы для валидации объекта;
- спецификацию проектных (системных) требований к объекту — для разработки конструкторской, технологической, эксплуатационной и ремонтной документации на объект и создания базы для верификации объекта.
4.6 В модели ЖЦ объекта по ГОСТ Р 56136 выделяют КР двух типов, на которых выполняется работа с требованиями:
- контрольные рубежи, на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности);
- контрольные рубежи, на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения).
Общий порядок разработки и применения требований приведен в разделе 5.
5 Общий порядок разработки и применения требований
5.1 Общий порядок формирования требований к объекту*
5.1.1 Исходные требования к объекту получают в результате анализа:
- потребностей в отношении разрабатываемого объекта всех заинтересованных сторон;
- требований к объектам данного типа, заданных в документах по стандартизации.
Потребности заинтересованных сторон и требования документов по стандартизации могут быть связаны с назначением и функционированием объекта, процессом его разработки, изготовления, испытаний, эксплуатации, ремонта и утилизации.
В качестве потребностей заинтересованных сторон также рассматриваются требования к рассматриваемому объекту как СЧ другого объекта (см. 5.1.5).
5.1.2 Для разрабатываемых объектов на основании утвержденной спецификации исходных требований разрабатывают спецификацию проектных требований, обусловленных принятыми при проектировании и в результате анализа исходных требований техническими решениями.
Для неразрабатываемых объектов на базе утвержденной спецификации исходных требований выбирают ранее разработанное техническое решение или покупное комплектующее изделие.
5.1.3 Проектные требования включают формализованное описание функций объекта, технические характеристики, описание принципов и режимов работы, условий эксплуатации, характеристики взаимодействия с внешними объектами (интерфейсы) и другие необходимые для дальнейшей разработки сведения об объекте в целом и процессах его ЖЦ*.
Проектные требования определяют такие характеристики объекта в целом, которые позволят обеспечить удовлетворение исходных требований, но (по возможности) не предписывают применение конкретных технических решений (если такие решения не обусловлены ограничениями, установленными в исходных требованиях).
5.1.4 Проектные требования к сложному объекту являются основой для разработки архитектуры (вариантов архитектуры) объекта в ходе проектирования. На основании проектных требований к объекту в целом и выбранного варианта архитектуры объекта разрабатывают требования к СЧ объекта*.
5.1.5 Требования к СЧ должны соответствовать 5.1.3. Требования к СЧ являются исходными данными для формирования спецификации исходных требований к СЧ (см. 5.1.1).
5.2 Задание сведений для верификации и валидации объекта
5.2.1 Спецификация исходных требований является базой для валидации объекта. Спецификация проектных требований является базой для верификации объекта.
5.2.2 С целью подготовки к верификации и валидации объекта для каждого требования (группы требований) указывают следующие сведения:
- КР в модели ЖЦ объекта, на котором должна быть выполнена проверка;
- МОС на данном КР;
- критерии успешности проверки требований на КР (диапазоны значений характеристик, описание вариантов правильного функционирования и т.п.);
- вид (виды) ДД, в которых должны быть задокументированы результаты проверки и которые будут официально подтверждать соответствие объекта требованиям.
Если верификация объекта выполняется на нескольких КР (одинаковыми или разными методами), то перечисленные выше сведения указывают для каждого КР.
5.2.3 Применяемые МОС, виды ДД и критерии успешности проверки, а также способы задания для требований перечисленных сведений устанавливают в программе УТ или в документах по стандартизации организации.
5.2.4 Утвержденная спецификация требований к объекту должна использоваться для разработки ПМИ по ГОСТ 19.301 для валидации или верификации объекта*.
5.3 Проверка, согласование и утверждение требований
5.3.1 Требования (каждое требование в отдельности и спецификация требований в целом) имеют свой ЖЦ, в котором выделяют стадии и события, связанные с изменением статуса готовности требований. Стадии ЖЦ требований, применяемые статусы готовности требований и события, приводящие к изменению статуса готовности, устанавливают в программе УТ или в документах по стандартизации организации*.
5.3.2 По окончании разработки спецификацию требований к объекту проверяют, согласовывают и утверждают. Утверждение отдельных требований выполняют только при внесении изменений в утвержденную спецификацию. Порядок проверки, согласования и утверждения требований устанавливают в документах по стандартизации организации.
5.3.3 При проверке требований выполняют их валидацию и верификацию.
5.3.4 При валидации требований проверяют:
- полноту покрытия спецификацией требований всех потребностей заинтересованных сторон, исходных требований и/или принятых технических решений;
- правильность выражения требованием потребности заинтересованной стороны, отражения принятого технического решения и/или декомпозиции родительского требования;
- наличие и правильность связи с потребностью заинтересованной стороны, родительским требованием или принятым техническим решением (см. 6.2.4 - 6.2.6);
- непротиворечивость требований в спецификации.
При валидации требований используют результаты компьютерного моделирования по ГОСТ Р 57412, испытаний, опыта эксплуатации аналогов и другие методы.
5.3.5 При верификации требований проверяют:
- соответствие формулировки каждого требования критериям качества, установленным в документах по стандартизации организации (см. 6.1);
- соответствие спецификации требований в целом критериям качества, установленным в документах по стандартизации организации (см. 6.1);
- правильность заполнения атрибутов требований, установленных в документах по стандартизации организации (см. 6.2);
- правильность классификации требований и установления связей между требованиями и (см. 6.2);
- наличие и правильность оформления сведений для верификации и валидации объекта (см. 5.2).
Полный перечень проверок требований устанавливают в документах по стандартизации организации.
5.3.6 После успешного прохождения проверки требования (спецификацию требований в целом) утверждают. Утверждение требований выполняют с применением электронной подписи или собственноручной подписи в удостоверяющем листе или в бумажном документе, содержащем требования.
5.4 Применение требований при верификации и валидации объекта
5.4.1 По результатам верификации или валидации объекта требованиям присваивают статус, указывающий что требование выполнено (статус выполнения).
5.4.2 С одним требованием может быть связано множество статусов выполнения, относящихся к разным КР и конфигурациям. При этом каждый статус выполнения должен содержать ссылки на КР, проверенную конфигурацию объекта, МОС, а также на утвержденный ДД (комплект ДД), на основании которого принято решении о выполнении (не выполнении) требования.
5.4.3 Виды и порядок присвоения статусов выполнения требованиям устанавливают в документах по стандартизации организации. Примерами значений статуса выполнения могут быть:
- требование выполнено;
- требование выполнено с учетом разрешения на отклонение;
- требование не выполнено (или отсутствует необходимый ДД).
6 Общие требования к содержанию и оформлению требований
6.1 Содержание требований и спецификации требований
6.1.1 Содержание требований должно соответствовать правилам, установленным в документах по стандартизации организации.
Основные правила разработки содержания требований включают:
- правильно сформулированное требование может быть проверено в ходе разработки и/или при предъявлении изделия заказчику;
- правильно сформулированное требование должно описывать функцию, которую изделие должно выполнять, или характеристику, которой изделие должно обладать (а не возможности, которыми должны обладать пользователи/операторы изделия);
- правильно сформулированное требование должно включать (или ссылаться на) описание условий и ограничений, при которых оно имеет смысл*;
- правильно сформулированное требование не должно диктовать определенное техническое решение или ограничивать диапазон таких решений (без специальной необходимости, вызванной установленными ограничениями).
Основные характеристики требований, на основании которых могут быть заданы правила формулирования требований в документах по стандартизации организации, приведены в Б.1 (приложение Б).
6.1.2 Для требований, выраженных текстовым утверждением, в документах по стандартизации организации должны быть установлены правила построения предложений, с указанием: рекомендуемого порядка слов, использования определенных ключевых слов и выражений (например, выражающих обязательность требования), использования определенных словоформ, перечня запрещенных для использования слов и выражений и т.п. Некоторые примеры таких правил приведены в Б.2 (приложение Б).
6.1.3 Спецификация требований в целом должна соответствовать требованиям, установленным в документах по стандартизации организации. Некоторые характеристики спецификации требований, на основании которых могут быть заданы правила формирования спецификации требований в конкретном проекте, приведены в Б.3 (приложение Б).
6.2 Атрибуты требований и связи между требованиями
6.2.1 Обязательные атрибуты для требований и их возможные значения (при наличии) устанавливают в документах по стандартизации организации. Некоторые примеры атрибутов требований приведены в Б.4 (приложение Б).
6.2.2 Каждое требование должно быть уникально идентифицировано для обеспечения прослеживаемости в ходе разработки. Уникальный идентификатор требования не изменяется в ходе ЖЦ объекта, в том числе при внесении изменений в требование. Все изменения одного и того же требования производятся путем создания новой версии требования.*
Требования к идентификатору требования и идентификатору версии требования устанавливают в документах по стандартизации организации.
6.2.3 Между требованиями к одному объекту, а также между требованиями к разным (взаимосвязанным, взаимодействующим) объектам устанавливают связи, выполняющие разные функции:
- связи подчиненности, описывающие, что одно требование получено из другого (родительского) требования (путем декомпозиции или в результате деятельности по проектированию и конструированию);
- связи классификации, описывающие, что требования относятся к одному типу/группе — как правило, такие связи устанавливаются путем задания классифицирующего свойства в атрибуте требования или путем установления связи со специализированным объектом (разделом, папкой в автоматизированной системе).
Классификация и группирование требований могут соответствовать положениям ГОСТ 15.016, ГОСТ 19.201, ГОСТ 34.602 и т.п.
6.2.4 В случае наличия документов, описывающих потребности заинтересованных сторон (например, отчет о научно-исследовательской работе), или применения документов по стандартизации при задании требований к объекту, для исходных требований должны быть установлены ссылки на эти документы (пункты документов).
6.2.5 Каждое проектное требования к объекту должно быть связано с утвержденными исходным требованием к этому объекту и/или с техническим решением по объекту, принятым в ходе разработки.
6.2.6 Каждое требование к СЧ должно быть связано с утвержденным проектным требованием к объекту в целом или с техническим решением по объекту, принятыми в ходе разработки.
7.1 Требования являются частью документации конфигурации и подлежат контролю в процедурах УК в соответствии с ГОСТ Р 59193.
7.2 Требования должны быть связаны с соответствующим объектом конфигурации и должны иметь уникальный идентификатор, присваиваемый по правилам, установленным в организации.
7.3 Разработанные на КР требования подлежат проверке в рамках аудита документации конфигурации в соответствии с ГОСТ Р 59193-2020 (раздел 6).
7.4 После успешного завершения аудита требования становятся частью утвержденной конфигурации объекта по ГОСТ Р 59193 Спецификацию исходных требований к объекту включают в утвержденную требуемую конфигурацию объекта. Спецификацию проектных требований к объекту включают в утвержденную проектную конфигурацию объекта.
7.5 Изменение требований, включенных в утвержденную конфигурацию, производят по правилам управления изменениями, установленным в ГОСТ Р 59193-2020 (раздел 7).
7.6 Под изменением требований понимают:
- изменение версии требований в утвержденной спецификации требований;
- удаление требования(й) из утвержденной спецификации требований (с заменой или без замены);
- добавление новых требований в утвержденную спецификацию требований.
7.7 При анализе требований и оценке вариантов изменения по ГОСТ Р 59193-2020 (подраздел 7.5), а также при определении необходимости изменения всех подчиненных конфигураций используют прослеживаемость требований.
7.8 Всем изменениям утвержденных требований присваивают класс изменения. Определение класса изменения требований выполняют по ГОСТ Р 59193-2020 (подраздел 7.6).
7.9 В случае изменения требования с присвоенным статусом выполнения возможны следующие варианты в зависимости от класса изменения (см. 7.8):
- для изменения первого класса необходимо повторно выполнять проверку конфигураций объекта, для которых установлено, что требование выполнено, на соответствие измененному требованию;
- для изменений второго класса нет необходимости в повторных проверках конфигураций объекта, для которых установлено, что требование выполнено (все статусы выполнения переносятся на новую версию требования автоматически).
ПОЯСНЕНИЯ К ТЕРМИНОЛОГИЧЕСКИМ СТАТЬЯМ И ПУНКТАМ СТАНДАРТА
| Пункт стандарта | Пояснение |
|---|---|
| 3.1.2 | Настоящий стандарт по терминологии и составу задач в целом соответствует [1]. Соответствие терминов настоящего стандарта и терминов [1] приведено в таблице А.2. В этом пункте и далее по тексту стандарта термин «объект» используется для обозначения объекта, к которому задаются требования. Объектом может быть финальное изделие (в том числе комплекс и т.п.), СЧ (в том числе система, агрегат, сборочная единица, деталь, комплект и т.п.), программа для ЭВМ (в том числе встроенное ПО), интерфейс, материал, объекты, связанные с процессами ЖЦ. Объект, к которому задаются требования, как правило, в процедурах УК по ГОСТ Р 59193 является ОКнф (см. 3.1.13) |
| 3.1.3 и 3.1.5 | Следует отличать валидацию и верификацию требований к объекту от валидации и верификации самого объекта. Валидация объекта представляет собой демонстрацию заказчику того, что объект удовлетворяет его потребностям и соответствует исходным требованиям. Валидация исходных (заданных) требований проводится на более раннем этапе для того, чтобы удостовериться, что эти исходные требования охватывают все значимые потребности всех заинтересованных сторон и правильно их выражают (формулируют) и следование таким требованиям позволит в будущем корректно выполнить валидацию объекта. Верификация объекта заключается в проверке того, что объект разработан в соответствии с заданными требованиями. Верификация требования заключается в проверке того, что сами требования разработаны в соответствии с предъявленными к ним требованиями (требования к формулированию, оформлению, структурированию и другим характеристикам требований как объекта разработки) |
| 3.1.7 | В качестве ДД могут выступать конструкторские по ГОСТ 2.102, технологические, эксплуатационные документы, а также техническая документация: отчеты, акты и протоколы испытаний, заключения о соответствии и т.п. |
| 3.1.9 | Потребности заинтересованной стороны затем преобразуются в требования. Заинтересованной стороной может быть (перечень не полный и может быть расширен): заказчик, головной исполнитель программы, поставщик, разработчик, головной разработчик, изготовитель, головной изготовитель, эксплуатирующая организация, надзорные и регулирующие органы, ремонтные органы и др. Одна организация может совмещать роли, выполняемые в отношении объекта, и, следовательно, выражать потребности нескольких заинтересованных сторон (разными заинтересованными сторонами могут быть разные подразделения одной организации). Заинтересованными в объекте сторонами также являются организации (заказчики, разработчики, изготовители и т.д.), имеющие отношение к объектам, взаимодействующим с рассматриваемым |
| 3.1.12 | В зависимости от стадии (этапа) ЖЦ объекта возможно применение следующих МОС (перечень может быть расширен): - анализ документации; - расчет или компьютерное моделирование; - эксперимент с образцом или физическим макетом; - анализ опыта эксплуатации прототипа; - испытания опытного образца и его СЧ; - анализ опыта эксплуатации образца |
| 3.1.21 | Требования могут быть установлены с использованием текстовых положений (утверждений), иллюстраций, графиков, таблиц, ссылок на нормативные документы, в виде информационной модели изделия, 3D геометрической модели изделия, 2D схемы или других видов компьютерных моделей по ГОСТ Р 57412. Требования могут относиться как к самому объекту, так и к процессам его ЖЦ |
| 4.1 | Разработке требований соответствуют технические процессы ЖЦ, описанные в ГОСТ Р 57193-2016 (пункты 6.4.2, 6.4.3). Контролю требований соответствует процесс УК, применяемый к разработке требований, в соответствии с ГОСТ Р 57193-2016 (пункт 6.3.5) |
| 4.4 | Полномасштабное решение задач УТ в соответствии с требованиями настоящего стандарта возможно только при представлении требований к изделию и его СЧ в форме базы данных в автоматизированной системе. В этом случае применяемая для УТ автоматизированная система (например, АС УДИ) управляет каждым отдельным требованием и связями между требованиями, обеспечивающими прослеживаемость. Многие задачи контроля требований могут быть решены автоматизировано с использованием функций АС УДИ. Решение задач УТ без применения автоматизированных систем, как правило, осуществляется путем разработки и управления изменениями соответствующих документов, что представляет собой трудоемкую задачу. Требования, представленные в форме базы данных, при необходимости (для согласования, передачи, вывода на печать и т.п.) могут быть преобразованы в документ, в том числе странично-ориентированный. Такой документ рассматривается как производный по отношению к исходной базе данных и не подлежит самостоятельному изменению. Внесение изменений в производный документ выполняется только путем изменения исходной базы данных и последующего формирования на ее основе новой версии документа. Примерами документов с требованиями являются ТЗ на изделие по ГОСТ 15.016, по ГОСТ 19.201 - для программных изделий, по ГОСТ 34.602 — для автоматизированных систем, проектные конструкторские документы по ГОСТ 2.102; «Спецификация системы/подсистемы», «Спецификации требований к ПО» и «Спецификация требований к интерфейсу», в соответствии с ГОСТ Р 51904 и др. Кроме того, проектные требования могут быть представлены в виде конструкторского документа(ов) по ГОСТ 2.102, программного документа по ГОСТ 19.101, документа по ГОСТ 34.201 и т.п. (например, пояснительные записки, схемы и т.п.) |
| 4.5 | Спецификация требований может включать информационные наборы с требованиями по разделам (вложенные спецификации) или включать один или несколько (множество) документов с требованиями |
| 5.1 | Процесс разработки требований и технических решений итеративно повторяется как на уровне одного объекта, так при переходе от требований к объекту к требованиям к его СЧ, как показано на рисунке А.1 |
| 5.1.3 | При разработке проектных требований объект рассматривается как «черный ящик», т.е. объект, внутренняя структура которого неизвестна, но о функциях которого можно судить по его реакциям на внешние воздействия (см. [2]) |
| 5.1.4 | При разработке требований к СЧ, данная СЧ рассматривается как «черный ящик», см. примечание к 5.1.3 |
| 5.2.4 | Требования, представленные в форме базы данных в автоматизированной системе, могут использоваться для автоматизированного формирования соответствующих технических документов (ПМИ по ГОСТ 19.301, планов испытаний, матриц проверки соответствия и т.п.) |
| 5.3.1 | В ЖЦ требований (спецификации требований) могут быть выделены следующие стадии: - разработка требований (спецификации) — по окончании данной стадии разработчик требований (спецификации) присваивает статус готовности, сообщающий о завершении разработки и готовности к проверке; - проверка и согласование требований (спецификации) — по окончании данной стадии требования (спецификация) получают статус готовности, сообщающий о готовности требований (спецификации) к использованию по назначению (для разработки ПМИ, проектирования и т.п.); - пересмотр требований — по окончании данной стадии требования получают статус готовности, сообщающий о замене требования на новую версию или об аннулировании требования |
| 6.1.1 | Примеры ограничений, влияющих на задание требований: - интерфейсы, реализованные в составе взаимодействующих объектов; - ограничения физических размеров (например, контроллер должен помещаться в ограниченном пространстве крыла самолета), - законы страны, в которой предполагается разработка, изготовление и/или эксплуатация объекта, - установленные сроки и/или бюджет разработки/приобретения; - существующая технологическая платформа, - ограничения или возможности пользователя или оператора |
| 6.2.2 | Новая версия требования создается при изменении содержания и/или атрибутов требования. Версии требования отражают только изменение одного требования (с одним идентификатором) с течением времени, но не должны использоваться для описания вариантов требования (для этих целей создаются требования с разными идентификаторами) |
Рисунок А.1 — Требования к объекту и их связь с требованиями к составным частям объекта
Соответствие терминов настоящего стандарта и ISO/IEC/IEEE 29148:2018
| Термин из подраздела 3.1 настоящего стандарта | Аналогичный термин из [1] |
|---|---|
| 3.1.2 валидация объекта | 3.1.36 validation |
| 3.1.3 валидация требований | 3.1.25 requirements validation |
| 3.1.4 верификация объекта | 3.1.37 verification |
| 3.1.5 верификация требований | 3.1.26 requirements verification |
| 3.1.9 заинтересованная сторона | 3.1.28 stakeholder |
| 3.1.14 ограничение | 3.1.7 constraint |
| 3.1.16 прослеживаемость требования | 3.1.23 requirements traceability |
| 3.1.17 спецификация исходных требований | 3.1.29 stakeholder requirements specification |
| 3.1.18 спецификация проектных требований | 3.1.33 system requirements specification |
| 3.1.21 требование | 3.1.19 requirement |
| 3.1.23 условие | 3.1.6 condition |
| 4.1 разработка требований | 3.1.21 requirements engineering |
| 4.1 контроль требований | 3.1.22 requirements management |
ИСХОДНЫЕ ДАННЫЕ ДЛЯ ЗАДАНИЯ ТРЕБОВАНИЙ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ ТРЕБОВАНИЙ В КОНКРЕТНОМ ПРОЕКТЕ (ОРГАНИЗАЦИИ)
Б.1 Основные характеристики требований
Для каждого отдельного требования могут быть выделены следующие характеристики:
- актуальность требования — характеристика требования, означающая, что требование должно быть актуальным на данной стадии (этапе) ЖЦ и уровне разработки объекта;
- атомарность требования — характеристика требования, означающая, что требование должно формулироваться таким образом, чтобы дальше его нельзя было разбить на несколько требований или уточнить на данной стадии (этапе) ЖЦ объекта без потери завершенности;
- выполнимость требования — характеристика требования, означающая, что требование возможно выполнить в ходе данного проекта в рамках существующих или разрабатываемых технологий и бюджета;
- единичность требования — характеристика требования, означающая, что требование должно относиться только к одному свойству, характеристике или условию применения объекта. Не допускается дублирование требований;
- завершенность требования — характеристика требования, означающая, что требование должно быть полностью описано в одном определении, в котором должна содержаться вся необходимая информация;
- непротиворечивость требования — характеристика требования, означающая, что требование не должно противоречить другим требованиям и ограничениям, предъявляемым к объекту, а также утвержденной на данном этапе конфигурации объекта;
- однозначность требования — характеристика требования, означающая, что требование должно трактоваться только единообразно всеми субъектами процесса УТ. Формулировка требования не должна содержать отрицательных и составных утверждений. Требование должно выражать объективные факты;
- прослеживаемость требования — характеристика требования, означающая, что с каждым требованием должен быть связан источник (документы и/или данные, описывающие принятые технические решения, и/или родительское требование или потребность заинтересованной стороны;
- обязательность требования — характеристика требования, означающая, что невыполнение данного требования окажет/не окажет влияние на целевые характеристики изделия или параметры проекта в целом;
- проверяемость требования — характеристика требования, означающая, что выполнение требования возможно однозначно проверить известными методами;
- законность требования — требование не должно противоречить законодательству;
- абстрактность требования — формулировка требования не должна навязывать определенные технические решения, характерные для более низких уровней требований.
Б.2 Основные правила формулирования текстовых требований
Текстовое требование — это утверждение, которое объясняет или выражает потребность и связанные с ней ограничения и условия. Данное утверждение записывается в виде текста и должно включать субъект, его функцию (действие) и дополнение (объект, значение, ограничение).
Субъект требования идентифицирует тот объект, к которому задано требование (например, система, ПО и т.д.). Функция описывает некоторую полезную деятельность, которую должен выполнять субъект (например, работать на высоком уровне мощности, создать условия для...).
1 Когда сигнал x получен [Условие], система [Субъект] должна установить [Действие] разряд у сигнала [Объект] в течение двух секунд [Ограничение].
2 При погодных условиях 1 [Условие], радиолокационная система [Субъект] должна определить цели в радиусе [Действие или Ограничение] 100 морских миль [Значение].
3 Система выставления счетов [Субъект] должна выводить клиентские счета, находящиеся на рассмотрении [Действие], в порядке, в котором счета должны быть выплачены [Значение].
Необходимо установить конкретные ключевые слова и термины, обозначающие обязательность требования, например:
- «Для обязательного требования при описании функции необходимо использовать слово „должен“ и его грамматические формы»;
- «Необязательные требования, утверждения о существующих фактах и целях являются не обязательными положениями, поэтому при их описании необходимо использовать слово „предлагается“ и его грамматические формы»;
- «При формулировании требований избегайте отрицательных утверждений типа „не должен“. Избегайте применения пассивного залога, типа „он должен быть выбран“.»
При формулировании требований рекомендуется избегать неясных, неоднозначных и неформальных терминов, таких как:
- прилагательные в превосходной степени (такие как «лучший», «самый»);
- субъективные формулировки (такие как «удобный для пользователя», «простой в использовании», «экономически эффективный»);
- неясные местоимения (такие как «он», «оно», «это», «то»);
- неоднозначные наречия и прилагательные (такие как «почти всегда», «существенный», «минимальный»);
- бессрочные и непроверяемые термины (такие как «предоставить поддержку», «но не ограничиваясь», «как минимум»);
- сравнительные фразы (такие как «лучше, чем», «более высокого качества»);
- выражения «если возможно», «в случае необходимости», «в зависимости от обстоятельств».
Б.3 Основные характеристики спецификации требований
- полнота спецификации — спецификация требований должна включать все требования к одному объекту, значимые для данной стадии (этапа) ЖЦ;
- непротиворечивость спецификации — характеристика спецификации, означающая, что в ней не существует требований, противоречащих друг другу;
- отсутствие избыточности — характеристика спецификации, означающая, что каждое требование в спецификации сформулировано только один раз (нет повторов);
- модульность спецификации — характеристика спецификации, означающая, что требования, близкие друг к другу по смыслу, содержатся в спецификации в одном разделе (имеют одинаковое основное классифицирующее свойство);
- структурированность спецификации — наличие ясной и четкой структуры в спецификации и ясной системы классификации требований.
Возможными атрибутами требования могут быть:
- идентификатор требования — уникальное обозначение требования;
- идентификатор версии требования — обозначение или номер версии требования;
- автор требования — указание на физическое лицо, сформулировавшее данное требование, фиксируемое в целях обеспечения прослеживаемости требования;
- тип требования — область, к которой относится требование: функциональность, производительность, качество, окружение, интерфейс, ограничение и т.п. Типы требований могут быть сформулированы, например, в соответствии с разделами ТТЗ/ТЗ по ГОСТ 15.016, ГОСТ 19.201, ГОСТ 34.602 и т.п.;
- источник требования — указание обозначения документа (например, документа по стандартизации), его структурного элемента или обозначения другого требования, на основании которого сформулировано данное требование (данный атрибут используется только в тех случаях, когда в применяемой автоматизированной системе невозможно или нецелесообразно установить связи на источники требования другим способом);
- заинтересованная сторона — указание на заинтересованную сторону (или несколько) к которой относится требование, позволяющее соотнести требование с конкретными потребностями;
- обязательность требования (обязательное, рекомендуемое, желательное);
- приоритет требования (например, шкала от 1 до 10);
- уровень риска — относительное значение риска, сопоставленное с требованием в результате анализа рисков. Основные риски связаны с потенциальными финансовыми потерями, потенциальной упущенной выгодой, утратой доверия заинтересованных сторон, влиянием окружающей среды, вопросами жизни и безопасности, государственными стандартами, законами и т.п.;
- обоснование — описание причин необходимости требования, опираясь на результаты анализа альтернатив, моделирования, симуляции и другие существенные и объективные данные;
- степень сложности — предполагаемая степень сложности выполнения требования (например, легко, сложно, стандартно).