"ГОСТ Р 59194-2020. Национальный стандарт Российской Федерации. Управление требованиями. Основные положения"
(утв. и введен в действие Приказом Росстандарта от 18.11.2020 N 1129-ст)

1 РАЗРАБОТАН Акционерным обществом "Научно-исследовательский центр "Прикладная Логистика" (АО НИЦ "Прикладная Логистика")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 482 "Поддержка жизненного цикла экспортируемой продукции военного и продукции двойного назначения"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 ноября 2020 г. N 1129-ст

4 ВВЕДЕН ВПЕРВЫЕ

Настоящий стандарт устанавливает основные цели, задачи и принципы управления требованиями на всех стадиях жизненного цикла изделий машиностроения, приборостроения и их составных частей.

Применение требований стандарта к другим видам изделий определяется по усмотрению организации-разработчика.

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 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 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

В настоящем стандарте применены термины по ГОСТ Р 56136, ГОСТ Р 58300 и ГОСТ Р 59193, а также следующие термины с соответствующими определениями:

3.1.1

3.1.2* <1>

--------------------------------

<1> Здесь и далее знаком "*" отмечены терминологические статьи и пункты, к которым даны пояснения в приложении А.

3.1.3 валидация требований: Подтверждение того, что разработанные требования позволят создать объект, удовлетворяющий потребностям заинтересованных сторон*.

3.1.4

3.1.5 верификация требований: Проверка содержания и оформления требований на соответствие установленным критериям качества*.

3.1.6 версия требований: Содержание (одного или совокупности) требований к объекту (в том числе атрибутов требований), зафиксированное в конкретный момент времени или с определенной целью.

3.1.7 доказательный документ; ДД: Документ, утвержденный в установленном порядке и содержащий объективные свидетельства выполнения требований к объекту*.

3.1.8

3.1.9 заинтересованная сторона: Физическое лицо или организация (подразделение организации), которое(ая) выполняет по отношению к объекту какую-либо роль и, в связи с этим, имеет потребности (интересы, ожидания), связанные с объектом*.

3.1.10

3.1.11 исходное (заданное) требование: Требование, полученное в результате анализа потребностей заинтересованной стороны.

3.1.12 метод оценки соответствия; МОС: Способ проверки соответствия объекта требованиям*.

3.1.13

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 условие: Составная часть требования, которая указывает на обстоятельство или событие, при котором применяется требование.

В настоящем стандарте использованы следующие сокращения:

АС УДИ - автоматизированная система управления данными об изделии;

ДД - доказательный документ;

ЖЦ - жизненный цикл;

КР - контрольный рубеж;

МОС - метод оценки соответствия;

ОКнф - объект конфигурации;

ПМИ - программа и методика испытаний;

ПО - программное обеспечение;

СЧ - составная часть;

ТЗ - техническое задание;

ТТЗ - тактико-техническое задание;

УТ - управление требованиями;

УК - управление конфигурацией;

ЭВМ - электронная вычислительная машина;

ЭМИ - электронный макет изделия.

4.1 В составе УТ выделяют два вида деятельности*:

- разработка требований - инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию и его СЧ, основанная на анализе потребностей заказчика и других заинтересованных сторон;

- контроль требований - управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон). Эта деятельность является частью процесса УК в соответствии с ГОСТ Р 59193, выполняемого в отношении требований.

4.2 Управление требованиями осуществляют совместно заказчик и поставщик изделия.

Для координации деятельности по УТ, при необходимости, разрабатывают программу УТ, в котором перечисляют решаемые задачи УТ, методы их решения (с указанием применяемых документов по стандартизации), ответственных исполнителей, способы обмена данными, планируемые результаты, взаимосвязи с процессом УК.

4.3 Требования задают к изделию в целом и к его СЧ (системам, агрегатам, узлам, деталям, программам для ЭВМ, в т.ч. встроенному ПО), к документам (информационным наборам, базам данных и т.п.), материалам, интерфейсам, объектам, связанным с процессами ЖЦ (далее: объекты).

4.4 Требования могут быть представлены в форме*:

- базы данных (совокупности информационных объектов и наборов) в автоматизированной системе;

- документа (бумажного или электронного по ГОСТ 2.051).

Требования могут быть представлены в составе функционального ЭМИ в АС УДИ по ГОСТ Р 58301.

4.5 Все требования к одному объекту, необходимые для решения определенной задачи в ходе ЖЦ, составляют спецификацию требований к объекту*.

При разработке нового объекта формируют:

- спецификацию исходных (заданных) требований к объекту - для формализации потребностей всех заинтересованных сторон и создания базы для валидации объекта;

- спецификацию проектных (системных) требований к объекту - для разработки конструкторской, технологической, эксплуатационной и ремонтной документации на объект и создания базы для верификации объекта.

4.6 В модели ЖЦ объекта по ГОСТ Р 56136 выделяют КР двух типов, на которых выполняется работа с требованиями:

- контрольные рубежи, на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности);

- контрольные рубежи, на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения).

Общий порядок разработки и применения требований приведен в разделе 5.

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.1 Спецификация исходных требований является базой для валидации объекта. Спецификация проектных требований является базой для верификации объекта.

5.2.2 С целью подготовки к верификации и валидации объекта для каждого требования (группы требований) указывают следующие сведения:

- КР в модели ЖЦ объекта, на котором должна быть выполнена проверка;

- МОС на данном КР;

- критерии успешности проверки требований на КР (диапазоны значений характеристик, описание вариантов правильного функционирования и т.п.);

- вид (виды) ДД, в которых должны быть задокументированы результаты проверки и которые будут официально подтверждать соответствие объекта требованиям.

Если верификация объекта выполняется на нескольких КР (одинаковыми или разными методами), то перечисленные выше сведения указывают для каждого КР.

5.2.3 Применяемые МОС, виды ДД и критерии успешности проверки, а также способы задания для требований перечисленных сведений устанавливают в программе УТ или в документах по стандартизации организации.

5.2.4 Утвержденная спецификация требований к объекту должна использоваться для разработки ПМИ по ГОСТ 19.301 для валидации или верификации объекта*.

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.1 По результатам верификации или валидации объекта требованиям присваивают статус, указывающий что требование выполнено (статус выполнения).

5.4.2 С одним требованием может быть связано множество статусов выполнения, относящихся к разным КР и конфигурациям. При этом каждый статус выполнения должен содержать ссылки на КР, проверенную конфигурацию объекта, МОС, а также на утвержденный ДД (комплект ДД), на основании которого принято решении о выполнении (не выполнении) требования.

5.4.3 Виды и порядок присвоения статусов выполнения требованиям устанавливают в документах по стандартизации организации. Примерами значений статуса выполнения могут быть:

- требование выполнено;

- требование выполнено с учетом разрешения на отклонение;

- требование не выполнено (или отсутствует необходимый ДД).

6.1.1 Содержание требований должно соответствовать правилам, установленным в документах по стандартизации организации.

Основные правила разработки содержания требований включают:

- правильно сформулированное требование может быть проверено в ходе разработки и/или при предъявлении изделия заказчику;

- правильно сформулированное требование должно описывать функцию, которую изделие должно выполнять, или характеристику, которой изделие должно обладать (а не возможности, которыми должны обладать пользователи/операторы изделия);

- правильно сформулированное требование должно включать (или ссылаться на) описание условий и ограничений, при которых оно имеет смысл*;

- правильно сформулированное требование не должно диктовать определенное техническое решение или ограничивать диапазон таких решений (без специальной необходимости, вызванной установленными ограничениями).

Основные характеристики требований, на основании которых могут быть заданы правила формулирования требований в документах по стандартизации организации, приведены в Б.1 (приложение Б).

6.1.2 Для требований, выраженных текстовым утверждением, в документах по стандартизации организации должны быть установлены правила построения предложений, с указанием: рекомендуемого порядка слов, использования определенных ключевых слов и выражений (например, выражающих обязательность требования), использования определенных словоформ, перечня запрещенных для использования слов и выражений и т.п. Некоторые примеры таких правил приведены в Б.2 (приложение Б).

6.1.3 Спецификация требований в целом должна соответствовать требованиям, установленным в документах по стандартизации организации. Некоторые характеристики спецификации требований, на основании которых могут быть заданы правила формирования спецификации требований в конкретном проекте, приведены в Б.3 (приложение Б).

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):

- для изменения первого класса необходимо повторно выполнять проверку конфигураций объекта, для которых установлено, что требование выполнено, на соответствие измененному требованию;

- для изменений второго класса нет необходимости в повторных проверках конфигураций объекта, для которых установлено, что требование выполнено (все статусы выполнения переносятся на новую версию требования автоматически).

Для каждого отдельного требования могут быть выделены следующие характеристики:

- актуальность требования - характеристика требования, означающая, что требование должно быть актуальным на данной стадии (этапе) ЖЦ и уровне разработки объекта;

- атомарность требования - характеристика требования, означающая, что требование должно формулироваться таким образом, чтобы дальше его нельзя было разбить на несколько требований или уточнить на данной стадии (этапе) ЖЦ объекта без потери завершенности;

- выполнимость требования - характеристика требования, означающая, что требование возможно выполнить в ходе данного проекта в рамках существующих или разрабатываемых технологий и бюджета;

- единичность требования - характеристика требования, означающая, что требование должно относиться только к одному свойству, характеристике или условию применения объекта. Не допускается дублирование требований;

- завершенность требования - характеристика требования, означающая, что требование должно быть полностью описано в одном определении, в котором должна содержаться вся необходимая информация;

- непротиворечивость требования - характеристика требования, означающая, что требование не должно противоречить другим требованиям и ограничениям, предъявляемым к объекту, а также утвержденной на данном этапе конфигурации объекта;

- однозначность требования - характеристика требования, означающая, что требование должно трактоваться только единообразно всеми субъектами процесса УТ. Формулировка требования не должна содержать отрицательных и составных утверждений. Требование должно выражать объективные факты;

- прослеживаемость требования - характеристика требования, означающая, что с каждым требованием должен быть связан источник (документы и/или данные, описывающие принятые технические решения, и/или родительское требование или потребность заинтересованной стороны;

- обязательность требования - характеристика требования, означающая, что невыполнение данного требования окажет/не окажет влияние на целевые характеристики изделия или параметры проекта в целом;

- проверяемость требования - характеристика требования, означающая, что выполнение требования возможно однозначно проверить известными методами;

- законность требования - требование не должно противоречить законодательству;

- абстрактность требования - формулировка требования не должна навязывать определенные технические решения, характерные для более низких уровней требований.

Текстовое требование - это утверждение, которое объясняет или выражает потребность и связанные с ней ограничения и условия. Данное утверждение записывается в виде текста и должно включать субъект, его функцию (действие) и дополнение (объект, значение, ограничение).

Субъект требования идентифицирует тот объект, к которому задано требование (например, система, ПО и т.д.). Функция описывает некоторую полезную деятельность, которую должен выполнять субъект (например, работать на высоком уровне мощности, создать условия для...).

Необходимо установить конкретные ключевые слова и термины, обозначающие обязательность требования, например:

- "Для обязательного требования при описании функции необходимо использовать слово "должен" и его грамматические формы";

- "Необязательные требования, утверждения о существующих фактах и целях являются не обязательными положениями, поэтому при их описании необходимо использовать слово "предлагается" и его грамматические формы";

- "При формулировании требований избегайте отрицательных утверждений типа "не должен". Избегайте применения пассивного залога, типа "он должен быть выбран".

При формулировании требований рекомендуется избегать неясных, неоднозначных и неформальных терминов, таких как:

- прилагательные в превосходной степени (такие как "лучший", "самый");

- субъективные формулировки (такие как "удобный для пользователя", "простой в использовании", "экономически эффективный");

- неясные местоимения (такие как "он", "оно", "это", "то");

- неоднозначные наречия и прилагательные (такие как "почти всегда", "существенный", "минимальный");

- бессрочные и непроверяемые термины (такие как "предоставить поддержку", "но не ограничиваясь", "как минимум");

- сравнительные фразы (такие как "лучше, чем", "более высокого качества");

- выражения "если возможно", "в случае необходимости", "в зависимости от обстоятельств".

- полнота спецификации - спецификация требований должна включать все требования к одному объекту, значимые для данной стадии (этапа) ЖЦ;

- непротиворечивость спецификации - характеристика спецификации, означающая, что в ней не существует требований, противоречащих друг другу;

- отсутствие избыточности - характеристика спецификации, означающая, что каждое требование в спецификации сформулировано только один раз (нет повторов);

- модульность спецификации - характеристика спецификации, означающая, что требования, близкие друг к другу по смыслу, содержатся в спецификации в одном разделе (имеют одинаковое основное классифицирующее свойство);

- структурированность спецификации - наличие ясной и четкой структуры в спецификации и ясной системы классификации требований.

Возможными атрибутами требования могут быть:

- идентификатор требования - уникальное обозначение требования;

- идентификатор версии требования - обозначение или номер версии требования;

- автор требования - указание на физическое лицо, сформулировавшее данное требование, фиксируемое в целях обеспечения прослеживаемости требования;

- тип требования - область, к которой относится требование: функциональность, производительность, качество, окружение, интерфейс, ограничение и т.п. Типы требований могут быть сформулированы, например, в соответствии с разделами ТТЗ/ТЗ по ГОСТ 15.016, ГОСТ 19.201, ГОСТ 34.602 и т.п.;

- источник требования - указание обозначения документа (например, документа по стандартизации), его структурного элемента или обозначения другого требования, на основании которого сформулировано данное требование (данный атрибут используется только в тех случаях, когда в применяемой автоматизированной системе невозможно или нецелесообразно установить связи на источники требования другим способом);

- заинтересованная сторона - указание на заинтересованную сторону (или несколько) к которой относится требование, позволяющее соотнести требование с конкретными потребностями;

- обязательность требования (обязательное, рекомендуемое, желательное);

- приоритет требования (например, шкала от 1 до 10);

- уровень риска - относительное значение риска, сопоставленное с требованием в результате анализа рисков. Основные риски связаны с потенциальными финансовыми потерями, потенциальной упущенной выгодой, утратой доверия заинтересованных сторон, влиянием окружающей среды, вопросами жизни и безопасности, государственными стандартами, законами и т.п.;

- обоснование - описание причин необходимости требования, опираясь на результаты анализа альтернатив, моделирования, симуляции и другие существенные и объективные данные;

- степень сложности - предполагаемая степень сложности выполнения требования (например, легко, сложно, стандартно).