"ГОСТ Р 70921-2023. Национальный стандарт Российской Федерации. Системная и программная инженерия. Требования и оценка качества систем и программной продукции (SQuaRE). Концепция требований к качеству"
(утв. и введен в действие Приказом Росстандарта от 14.09.2023 N 846-ст)

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

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 "Информационные технологии"

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

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО/МЭК 25030:2019 "Системная и программная инженерия. Требования и оценка качества систем и программной продукции (SQuaRE). Концепция требований к качеству" (ISO/IEC 25030:2019 "Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality requirements framework", NEQ)

5 ВВЕДЕН ВПЕРВЫЕ

6 Федеральное агентство по техническому регулированию и метрологии не несет ответственности за патентную чистоту настоящего стандарта

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

Требования к качеству необходимы:

- для определения системы, включая договорные соглашения и объявление тендера;

- планирования проекта, включая технико-экономический анализ;

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

- оценки системы, включая объективную оценку и сертификацию качества.

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

Это может привести к тому, что системы не будут соответствовать ожиданиям пользователей и будут низкого качества, а также к перерасходу времени и средств на доработку системы. Поэтому требования к качеству системы должны четко указываться на как можно более ранней стадии процесса разработки или приобретения, чтобы обеспечить критический вклад в разработку или приобретение.

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

Требования к качеству могут быть разделены на характеристики/подхарактеристики с использованием моделей качества, определенных в семействе стандартов ГОСТ Р ИСО/МЭК 2501n. Показатели этих характеристик/подхарактеристик, которые определены в семействе стандартов ГОСТ Р ИСО/МЭК 2502n, могут использоваться для определения требования к качеству и оценки качества целевой системы или данных.

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

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

Рисунок 1 иллюстрирует организацию серии SQuaRE, представляющую семейство стандартов, далее называемых разделами. Серия SQuaRE состоит из пяти основных разделов и одного дополнительного.

Деления внутри серии SQuaRE следующие:

- ГОСТ Р ИСО/МЭК 2500n - раздел управления качеством. Стандарты, которые формируют этот раздел, определяют все общие модели, термины и определения, используемые во всех других стандартах серии SQuaRE. Раздел также предоставляет требования и рекомендации по планированию и управлению проектом;

- ГОСТ Р ИСО/МЭК 2501n - раздел моделей качества. Стандарты, которые формируют этот раздел, обеспечивают модели качества для систем/программной продукции, качества при использовании (КПИ), данных и ИТ-услуг. Также приведены практические рекомендации по использованию модели качества;

- ГОСТ Р ИСО/МЭК 2502n - раздел измерения качества. Стандарты, которые формируют этот раздел, включают эталонную модель измерения качества системы/программной продукции, определения показателей качества и практические рекомендации по их применению. В этом разделе представлены внутренние показатели качества программного обеспечения, внешние показатели качества программного обеспечения, показатели КПИ и показатели качества данных. Определены и представлены элементы показателей качества, формирующие основу для показателей качества;

- ГОСТ Р ИСО/МЭК 2503n - раздел требований к качеству. Стандарты, которые формируют этот раздел, помогают определить требования к качеству. Эти требования к качеству могут быть использованы в процессе управления качеством. Стандарты, которые формируют этот раздел, помогают определить требования к качеству. Эти требования к качеству могут быть использованы в процессе контроля качества;

- ГОСТ Р ИСО/МЭК 2504n - раздел оценки качества. Стандарты, которые формируют этот раздел, содержат требования, рекомендации и руководящие принципы для оценки системы/программной продукции, независимо от того, выполняются ли они независимыми оценщиками, покупателями или разработчиками. Также представлена поддержка документирования показателей в качестве модуля оценки.

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

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

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

- тестировщики: проверяют и подтверждают, что систему/программную продукцию/данные соответствуют ожидаемому качеству;

- руководители проектов: планируют, контролируют и регулируют достижение ожидаемого качества;

- независимые оценщики: оценивают систему/программную продукцию/данные в соответствии с объективными критериями.

Настоящий стандарт соответствует техническим процессам (см. [1]), которые являются актуальными для выявления потребностей заинтересованных сторон в качестве, а также для определения, анализа и поддержания требований к качеству. В настоящем стандарте модели качества, определенные в ГОСТ Р ИСО/МЭК 25010 (см. приложение Б) (см. также [2]), используются для классификации требований к качеству (см. приложение В) и обеспечения основы для их количественной оценки с точки зрения показателей качества в соответствии с разделом показателей качества ГОСТ Р ИСО/МЭК 2502n.

Взаимосвязь между этапами требований к качеству и процессами, связанными с определенными требованиями (см. [1]), приведена в приложении Г. Процессы документирования требований к качеству приведены в приложении Д. Переход от требований к качеству при использовании к требованиям к качеству продукции приведен в приложении Е. В приложении Ж приведен пример взаимосвязи между характеристиками качества продукции. Приложения И, К, Л содержат примеры отслеживания требований к качеству на этапах разработки, матрицы заинтересованных сторон и целей и уровня качества, требуемого для различной продукции информационно-коммуникационных технологий (ИКТ) соответственно. В приложении М описаны требования к качеству ИТ-услуг.

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

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

ГОСТ Р 56921/ISO/IEC/IEEE 29119-2:2013 Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования

ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р ИСО/МЭК 25000 Системная и программная инженерия. Требования и оценка качества систем и программных средств (SQuaRE). Руководство

ГОСТ Р ИСО/МЭК 25010 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов

ГОСТ Р ИСО/МЭК 25022 Системы и разработка программного обеспечения. Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерение качества при использовании

ГОСТ Р ИСО/МЭК 25023 Системная и программная инженерия. Требования и оценка качества систем и программной продукции (SQuaRE). Измерения качества системы и программной продукции

ГОСТ Р ИСО/МЭК 25040 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

В настоящем стандарте применены термины по ГОСТ Р ИСО/МЭК 25000, а также следующие термины с соответствующими определениями:

3.1 ось классификации (classification axis): Общий диапазон позиционирования систем и программного обеспечения для их категоризации с определенной точки зрения.

Примечание - См. [3].

3.2 контекст использования (context of use): Условия и ограничения, при которых продукция ИКТ используется конкретными пользователями в конкретной среде для достижения конкретных целей в рамках более широкой информационной системы.

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

3.3 развертывание требований (развертывание) (deployment of requirements, deployment): Назначение требований вместе с декомпозицией системы.

3.4 вывод требований (вывод) (derivation of requirements, derivation): Разработка и перевод требований из одного типа требований в другой на том же системном уровне.

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

3.5 требования, основанные на домене (domain-based requirement): Требования, исходящие из домена приложения.

3.6 функциональное требование (functional requirement): Требование, определяющее функцию, которую должна выполнять система или системный компонент.

Примечание - См. [4].

3.7 требование к ИКТ (ICT requirement): Требование, вытекающее из внедрения некоторых информационно-коммуникационных технологий (ИКТ) и технических решений в процессе проектирования.

Примечание - Технические решения в области ИКТ включают веб-технологии, облачные серверы и т.д.

3.8 ИКТ-продукция (ICT product): Продукция, которая использует информационно-коммуникационные технологии (ИКТ) и может быть частью информационной системы.

Примечание - На рисунке 3 показано, из чего состоит продукция ИКТ и как она связана с информационной системой.

3.9

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

Примечание - На рисунке 3 показано, из чего состоит информационная система.

3.11 основной пользователь (primary user): Пользователь, который взаимодействует с системой для достижения основных целей.

3.12 продукция (product): Артефакт, который создается, поддается количественной оценке и может быть доставлен пользователю либо как конечная продукция сама по себе, либо как составной элемент.

Примечание - Продукция включает в себя продукцию ИКТ, программную продукцию и программные компоненты.

3.13 качество при использовании (quality in use): Степень, в которой результаты и последствия использования продукции, системы или услуги отвечают потребностям пользователей или других заинтересованных сторон в конкретных условиях использования.

3.14

3.15 требование к качеству (quality requirement): Требование к качественным свойствам или атрибутам продукции ИКТ, данных или услуг, которые удовлетворяют потребностям, вытекающим из цели, для которой предназначена эта продукция ИКТ, данные или услуга.

Примечание - Требования к качеству в настоящем стандарте не охватывают требования к качеству услуг.

3.16 требование (requirement): Заявление, которое переводит или выражает потребность и связанные с ней ограничения и условия.

Примечание - См. [1].

3.17 вторичный пользователь (secondary user): Пользователь, который взаимодействует с продукцией для поддержки основных пользователей.

Пример - Поставщик контента, системный менеджер, администратор, менеджер по безопасности, сопровождающий, установщик.

Примечание - Адаптировано из [5].

3.18 акционер (stakeholder): Заинтересованное лицо или организация, имеющие право, долю, претензии или заинтересованность в системе или в обладании ее характеристиками, которые отвечают их потребностям и ожиданиям.

Примечания

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

2 Адаптировано из [1].

3.19 технические требования к качеству продукции (technical product quality requirement): Требования к качеству продукции в отношении его технически определенных свойств, которые используются в процессах его разработки и обслуживания.

3.20

3.21

3.22

В настоящем стандарте применены следующие сокращения.

ИКТ - информационно-коммуникационные технологии;

ССТ - спецификация системных требований;

СТЗС - спецификация требований заинтересованных сторон;

СТПО - спецификация требований к программному обеспечению;

ТКД - требования к качеству данных;

ТКП - требования к качеству продукции;

ТКПИ - требования к качеству при использовании;

ТКx - требования к качеству типа x [где x - это Д (данные), П (продукция) или ПИ (при использовании)].

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

Концепция требований к качеству включает их целевые объекты, для которых должны быть определены требования к качеству, и важные соображения по ним.

ТКПИ определяют требуемые уровни качества с точки зрения заинтересованных сторон. Эти требования вытекают из потребностей различных заинтересованных сторон. ТКПИ относятся к результату использования продукции в конкретных условиях, и могут использоваться в качестве целевых показателей для проверки продукции.

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

Примечания

1 ТКП также можно использовать для указания атрибутов поставляемых, неисполняемых программной продукции, таких как документация и руководства.

ТКД определяют уровни качества, требуемые для данных, связанных с ИКТ-продукцией. К ним относятся требования, вытекающие из ТКПИ и ТКД входной и выходной продукции. ТКД можно использовать для проверки и валидации со стороны данных.

2 Многие ТКД могут быть получены из ТКП для целевой продукции, в то время как некоторые ТКД, такие как целостность данных, могут быть получены непосредственно из ТКПИ.

Объем трех типов требований к качеству показан на рисунке 2. ТКПИ определяют для информационной системы, которая включает в себя не только продукцию ИКТ, но и ее пользователей и соответствующие среды (например, механизмы, контролируемые/регулируемые продукцией ИКТ, и бизнес-процессы, в которых используется продукция ИКТ). ТКП определяют для продукции ИКТ или его составляющих (включая вспомогательную продукцию ИКТ, аппаратные средства, средства связи, программное обеспечение и, в некоторых случаях, программные компоненты), а ТКД определяют для данных внутри продукции ИКТ.

Рисунок 2 описывает только область применения каждого типа требований к качеству, не описывая системную иерархию, которая формально определена на рисунке 3.

Примечания

1 В приложении М описывается, как следует относиться к требованиям к качеству ИТ-услуг.

2 К пользователям относятся первичные пользователи, вторичные пользователи и косвенные пользователи (см. таблицу 2).

3 "Система систем" может рассматриваться как информационная система, которая рекурсивно включает в себя некоторые вспомогательные информационные системы.

4 Продукция ИКТ включает в себя программное обеспечение, а также может включать данные, аппаратные средства, средства связи и другую продукцию ИКТ в качестве своих компонентов.

Требования к качеству определяют с использованием моделей качества и показателей качества. В таблице 1 показано, какие стандарты могут быть использованы для определения каждого типа требований к качеству.

ГОСТ Р ИСО/МЭК 25022, ГОСТ Р ИСО/МЭК 25023 (см. также [6]) предоставляют перечень показателей качества в табличной форме, классифицированных по качественным характеристикам и подхарактеристикам. Для каждого показателя качества в таблицах приведена следующая информация.

Примечание - Каждый показатель качества, указанный в ГОСТ Р ИСО/МЭК 25022, может использоваться для измерения эффективности, результативности, удовлетворенности и отсутствия риска в конкретных условиях использования. Каждый показатель качества, указанный в ГОСТ Р ИСО/МЭК 25023, может использоваться для измерения внутренних свойств (обычно статических показателей промежуточной продукции), внешних свойств (обычно путем измерения поведения кода при выполнении) или и того, и другого. Каждый показатель качества, указанный в [6], может использоваться для измерения присущих или зависящих от системы свойств.

Два типа требований к продукции ИКТ следует рассматривать на основе их источников: требования, основанные на предметной области, которые выводятся непосредственно из потребностей заинтересованных сторон в их предметной области посредством процессов анализа требований, и требования к ИКТ, которые применяют в процессе проектирования. Требования к качеству имеют такие же типы.

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

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

В [3] приведена основа для категоризации продукции ИКТ, включая примерный набор классификационных осей, которые организованы иерархически с четырьмя осями на первом уровне: Архитектура/структура, Свойства, Операционная среда, Данные и заинтересованные стороны целевой системы. Эти оси могут быть использованы для определения того, какие характеристики качества имеют более высокий приоритет. Классификационные оси, важные для определения приоритета, могут включать:

- функцию (и ее проблемный фрейм);

- критичность системы и данных;

- характеристики заинтересованных сторон.

Примечание - Примеры требуемого уровня качества для различных ИТ-решений приведены в приложении Л.

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

Примечания

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

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

2 С точки зрения ИКТ продукции существует три типа данных: входные и/или выходные данные, данные, которыми обмениваются его компоненты, и данные конфигурации.

3 Ниже приведен пример взаимозависимости между продукцией ИКТ и данными, а также взаимосвязи между их ТКП и ТКД:

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

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

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

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

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

Основным источником требований к качеству являются пользователи, от которых исходят первые запросы на информационную систему, на основе которых выявляют и документируют целевые объекты. Затем они превращаются в ТКП и ТКД для целевых объектов. Другие заинтересованные стороны, такие как разработчики и регулирующие органы, также предъявляют некоторые требования к качеству к целевым объектам. Наконец, другие лица предъявляют некоторые требования в качестве ограничений к целевым объектам, включая нецелевую продукцию ИКТ, программное обеспечение и данные, которые подключены к целевым объектам или используются в них, а также используемые аппаратные средства и средства связи.

Примечание - ТКПИ могут ссылаться на набор функций, к каждой из которых присоединены некоторые ТКП, например, коэффициент полезного действия пользовательской задачи может ссылаться на функцию для автоматизации некоторой части задачи с требованием к ее поведению во времени. Аналогичным образом, при развертывании на более низком уровне целей, ТКП могут также получать набор функций, к каждой из которых привязаны некоторые ТКП (см. 6.5.3).

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

Примечание - Примеры взаимосвязи между характеристиками качества продукции приведены в приложении Ж.

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

Требования к качеству следует выявлять, определять, анализировать и поддерживать с использованием процессов, связанных с требованиями, указанными в [1]: процесс определения потребностей и требований заинтересованных сторон и процесс определения системных требований, посредством которого потребности заинтересованных сторон должны быть выявлены и преобразованы в системные требования представлен на рисунке 5.

Примечание - В настоящем стандарте как система, так и программная продукция рассматриваются как продукция ИКТ.

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

Процесс определения системных требований создает набор измеримых системных требований, которые определяют, с точки зрения поставщика, какими характеристиками, атрибутами, функциональными и эксплуатационными свойствами должна обладать система, чтобы удовлетворить требования заинтересованных сторон. ТПК и ТКД как часть системных требований также определяются и анализируются для удовлетворения требований заинтересованных сторон с использованием модели и показателей качества продукции и данных.

Примечания

1 Подробная взаимосвязь с [1] и [7] соответственно описана в приложениях Г и Д. [7] связывает два вышеупомянутых процесса работы требованиями, с процессами, описанными в ГОСТ Р ИСО/МЭК 12207, который определяет процессы жизненного цикла программного обеспечения.

2 Итерации и рекурсии при разработке требований описаны в [7].

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

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

4 Как определено в [7], требования заинтересованных сторон могут быть задокументированы в спецификации требований заинтересованных сторон (СТЗС), а требования к системе и программному обеспечению могут быть задокументированы соответственно в спецификации системных требований (ССТ) и спецификации требований к программному обеспечению (СТПО).

Этот пункт приведен в соответствии с подготовкой к определению потребностей и требований заинтересованных сторон в процессе определения потребностей и требований заинтересованных сторон (см. [1], 6.4.2, а также приложение Г).

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

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

Примечание - Заинтересованная сторона может рассматриваться как роль, и поэтому у одного человека или организации может быть более одной роли. Более того, предполагается, что заинтересованная сторона не должна принадлежать к определенному типу организаций. Например, в случае разработки потребительской продукции покупатели и разработчики могут принадлежать к одной и той же категории, поэтому необходимо учитывать любые риски для людей, на которых влияет система.

Этот пункт относится к определению потребностей заинтересованных сторон для процесса определения потребностей и требований заинтересованных сторон (см. [1], 6.4.2, а также приложение Г).

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

Примечания

1 В приложении А приведен рекомендуемый процесс выявления потребностей в качестве.

2 Требования к качеству в данном случае в основном связаны с качеством при использовании.

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

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

4 Поскольку разные заинтересованные стороны имеют разные потребности в целевой системе, потребности заинтересованных сторон могут быть непоследовательными и/или неполными; поэтому для определения, анализа и поддержания набора требований заинтересованных сторон рассматриваются все потребности.

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

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

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

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

На рисунке 6 представлен обзор шагов по определению всех типов требований к качеству.

Примечания

1 С инженерной точки зрения определение ТПКИ предшествует определению ТКП/ТКД, что вполне разумно для разработки продукции, изготовленной на заказ, но в действительности для потребительских товаров часто имеет место что сначала определяются ТКП/ТКД, а затем определяются ТПКИ для оценки целевых объектов в конкретных операционных ситуациях.

Для повторения этапов определения ТКП технические ТКП должны быть определены таким образом, чтобы их можно было использовать в качестве целей для проверки на различных этапах разработки.

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

2 В действительности рекурсивное применение шагов часто выполняется одновременно. Например, в следующей рекурсии могут рассматриваться вспомогательная ИКТ продукция и данные, которые составляют целевую продукцию ИКТ (6.5.4). Во время рекурсивного применения шагов следует также учитывать, что некоторые функциональные требования являются производными от некоторых требований к качеству (6.5.3).

Шаги относятся к следующим процессам и действиям (см. [1], а также приложение Г):

- процесс определения требований;

- трансформация потребностей заинтересованных сторон в требованиях заинтересованных сторон;

- анализ требований заинтересованных сторон;

- процесс определения системных требований:

- подготовка к определению системных требований;

- определение системных требований;

- анализ системных требований.

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

Обычно эти шаги применяют итеративно и рекурсивно. Когда применяют к целевому объекту рекурсивно, их следует применять ко всей ИКТ-продукции и данным в пределах рассматриваемого объекта, для достижения качества целевого объекта.

Требования к качеству для целевого объекта должны быть определены следующими шагами:

а) определение целевых объектов, которыми необходимо управлять для достижения их качества. Для этого необходимо определить целевой объект и его границы, качество которого должно быть определено и управляемо.

Примечания

1 Продукция ИКТ (целевой объект ТКП), может представлять собой произвольную комбинацию программной продукции, данных, аппаратных средств и средств связи. Продукция ИКТ включает в себя систему, включающую множество элементов продукции ИКТ, систему типа клиент/сервер, пользовательский ПК-терминал, мобильный терминал, пакетное программное обеспечение, систему управления базой данных и так далее.

2 Данные, относящиеся к ИКТ продукции, могут быть целевым объектом ТКД (6.5.3).

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

б) выбор характеристик качества, которые будут указаны в требованиях. Для этого необходимо для каждой потребности заинтересованных сторон в качестве определить, на какие характеристики (или подхарактеристики) качества она классифицируется. Для каждого ТКПИ, ТКП и ТКД на более высоком уровне системной иерархии определить, какие характеристики качества (с указанием способов их реализации) требуются целевым объектам. Для этого следует использовать модель качества, определенную в ГОСТ Р ИСО/МЭК 25010 для классификации ТКПИ и ТКП. Аналогично, для ТКД следует использовать модель качества (см. [2]).

Примечания

1 ГОСТ Р ИСО/МЭК 25010 (см. также [2]) может настраивать модель качества, предоставляя основу для сопоставления и настройки между индивидуальной моделью и стандартной моделью. Пример сопоставления индивидуальной модели и стандартной модели представлен в приложении Б.

2 Требования к качеству на более высоком уровне системной иерархии включают дополнительные ТКП и ТКД, полученные на основе требований к ИКТ (6.5.1).

3 При выводе требований к качеству целевого объекта из ТКПИ, ТКП и ТКД на более высоком уровне системной иерархии исчерпывающее изучение всех характеристик/подхарактеристик модели качества может предотвратить пропуск важных требований к качеству.

4 Пример получения ТКП из ТКПИ приведен в приложении Е;

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

- целевой объект;

- характеристика/подхарактеристика качества;

- пользователь и задача (только для ТКПИ);

- цель качества с условиями.

Примечание - В таблице 3 показан пример "государственных ТКП" для конкретной системы.

г) определение приоритетов требований к качеству. Для этого необходимо определить приоритетность полученных требований к качеству на основе их важности и влияния для заинтересованных сторон (важность и влияние приведены в 8.1).

Примечание - В отличие от функциональных требований, существует множество способов реализации ТКПИ/ТКП/ТКД на более высоком уровне системной иерархии, поэтому требования к качеству, вытекающие из них, могут быть выбранными комбинациями из нескольких кандидатов, и они также могут иметь некоторый диапазон приемлемых значений. Поэтому необходимо определить приоритетность производных требований к качеству с учетом их уровня важности и влияния, чтобы их можно было соответствующим образом отобрать и определить;

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

- требования к качеству;

- целевой объект;

- выбранная характеристика;

- пользователь и задача (только для ТКПИ);

- цель качества с условиями;

- показатель качества;

- целевое значение;

- допустимый диапазон значений.

Чтобы указать показатель качества, следует использовать ГОСТ Р ИСО/МЭК 25022 для ТКПИ, ГОСТ Р ИСО/МЭК 25023 для ТКП.

Примечания

1 Для ТКД следует использовать [6].

2 В приложении В приведен пример определения требований к качеству.

3 [8] определяет формат и синтаксис, которые должны использоваться при документировании требований пользователя, включая требования к качеству, связанные с использованием, которые могут включать требования к качеству при использовании.

4 Поскольку большинство показателей качества с методами измерения уже определены в ГОСТ Р ИСО/МЭК 25022, ГОСТ Р ИСО/МЭК 25023 и [6], показатели качества, используемые в требованиях к качеству, не обязательно определяются с нуля и могут быть взяты из действующих стандартов.

5 Заинтересованные стороны могут иметь разные целевые значения в зависимости от их деловых или инженерных потребностей.

6 Регулирующие органы могут устанавливать минимальные/максимальные пределы для некоторых целевых значений;

е) анализ требований к качеству. Для этого необходимо проанализировать требования к качеству, чтобы подтвердить их со следующих точек зрения:

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

- согласуются ли они с другими требованиями и ограничениями к качеству;

- поддаются ли они проверке;

- являются ли они выполнимыми и устраняют ли обнаруженные проблемы.

Примечание - Компромиссы в отношении требований к качеству приведены в 6.5.5 и приложении Ж.

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

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

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

ж) управление требованиями к качеству. Для управления требованиями к качеству необходимо:

- получить четкое согласие по ТКПИ и ТКП/ТКД от заинтересованных сторон. ТКПИ и ТКП/ТКД должны быть одобрены всеми группами заинтересованных сторон;

- установить и поддерживать прослеживаемость между определенными требованиями к качеству и их источниками (потребности в качестве, ТКПИ, ТКП и ТКД на более высоком уровне);

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

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

Примечания

1 Требования к качеству служат двум целям:

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

- предоставить критерии приемлемости.

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

а) оценка каждого требования к качеству и расстановка приоритетов по следующим пунктам:

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

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

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

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

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

Двунаправленная прослеживаемость между требованиями к качеству и компонентами ИКТ должна поддерживаться и подтверждаться на протяжении всего жизненного цикла продукции:

- с элементами реализации продукции, артефактами проектирования и оценки;

- требованиями заинтересованных сторон и системными требованиями.

Примерами реализации отслеживания ТКП/ТКД в жизненном цикле разработки продукции являются:

- функциональные требования: требование безопасности и функция контроля доступа, которая его реализует;

- архитектура: требование отказоустойчивости и архитектура, которая его реализует;

- ТКП/ТКД для развернутых компонентов: требования к времени отклика для программного обеспечения и требования к времени отклика для компонентов программного обеспечения;

- политики процесса проектирования: требование безопасности и политика безопасного кодирования, которая его реализует.

Примечание - В приложении И приведен пример отслеживания требований к качеству на этапах разработки.

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

Примечания

1 ГОСТ Р ИСО/МЭК 25040 содержит требования и рекомендации для процесса оценки с использованием требований к качеству.

Тестирование может проводиться на различных этапах разработки и отражать различные требования к качеству. Например, тестирование программного обеспечения и системы может выполняться на основе ТКП/ТКД, приемочное тестирование - на основе ТКПИ, а модульное и интеграционное тестирование - на технических ТКП/ТКД.

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

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

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

3 Процесс тестирования или тестирования программного обеспечения определен и объяснен в ГОСТ Р 56921.

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

Этот процесс разработан для дополнительной интеграции в [1].

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

Существует два основных этапа этого процесса, а именно:

1) определение контекста проекта;

2) определение потребностей в качестве каждой заинтересованной стороны.

На этом этапе процесса контекст проекта определяется с учетом нескольких факторов, таких как необходимые допущения, основные характеристики предметной области проекта, ограничения проекта и перечень заинтересованных сторон, как показано на рисунке А.1. Этот перечень заинтересованных сторон имеет решающее значение для выполнения остальной части процесса, поскольку он будет использоваться на втором этапе для определения требований к качеству продукции ИКТ. Возможно, на данном этапе перечень заинтересованных сторон будет неполным. В процессе анализа появятся новые заинтересованные стороны.

Входные данные: Нет

Выходные данные: Общие предположения проекта

Первым шагом этого этапа является рассмотрение следующих допущений в конкретном контексте проекта:

- клиент/пользователь является специалистом в своей области бизнеса;

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

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

- любое другое необходимое допущение с точки зрения качества, имеющее отношение к проекту.

Инженер по качеству должен учитывать все эти факторы перед началом процесса и должен адаптироваться к ним, чтобы адекватно определить правильные требования к качеству. Как указано ниже, процесс определения требований к качеству основан на определении потребностей в качестве, которые поддерживают бизнес-потребности различных выявленных заинтересованных сторон. Чем более тщательно инженер по качеству определяет необходимые допущения проекта, тем лучше он может сотрудничать с клиентом/пользователем и определить потребности в качестве различных заинтересованных сторон. Таким образом, инженер по качеству, ответственный за определение потребностей заинтересованных сторон в качестве, должен иметь в виду этот перечень допущений для завершения спецификации требований к качеству системы/программного обеспечения.

Входные данные: Общие предположения проекта

Выходные данные: Характеристики предметной области проекта, бизнес-потребности

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

Следовательно, выполнение этого шага позволит инженеру по качеству лучше понять различные аспекты области, в которой будет осуществляться проект, и облегчить общение с различными заинтересованными сторонами, что важно для определения требований к качеству системы/программного обеспечения.

Входные данные: Характеристики предметной области проекта, потребности бизнеса

Выходные данные: Бюджетные, технические, организационные и другие ограничения

На этом этапе инженер по качеству должен использовать свое понимание предметной области проекта, полученное на предыдущем этапе, чтобы определить ограничения проекта. В этом шаге должны участвовать как заказчик/пользователь, так и различные заинтересованные стороны в команде поставщиков продукции ИКТ.

Этот шаг используется для определения трех основных категорий ограничений:

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

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

- организационные ограничения, которые определяются в первую очередь структурой компании клиента/пользователя и различными правилами взаимодействия, которые существуют внутри нее. Поэтому деятельность по определению требований к качеству продукции ИКТ должны учитывать эти ограничения, чтобы они могли быть хорошо интегрированы в выполнение проекта и далее в бизнес-модель, поддерживаемую продукцией ИКТ.

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

Входные данные: характеристики предметной области проекта, ограничения

Выходные данные: Перечень заинтересованных сторон

Заключительный шаг первой фазы процесса имеет целью составление списка заинтересованных сторон проекта. Как только инженер по качеству получит лучшее представление о проекте и его ограничениях, очень важно определить все заинтересованные стороны: заказчика/пользователя и поставщика. Отсутствие некоторых заинтересованных сторон может негативно сказаться на качестве конечной продукции ИКТ, что, как следствие, может привести к провалу проекта.

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

Инженер по качеству должен тесно сотрудничать с заказчиком/пользователем, чтобы определить его технические и нетехнические потребности.

Примечание - Как определено в ГОСТ Р ИСО/МЭК 25010, заинтересованными сторонами продукции ИКТ являются пользователи и другие заинтересованные стороны (например, разработчик, регулирующий орган и общество), а пользователей можно разделить на три категории: первичные, вторичные и косвенные.

Кроме того, инженер по качеству должен учитывать заинтересованные стороны поставщика продукции ИКТ. Этот список заинтересованных сторон будет иметь важное значение для определения требований к качеству продукции ИКТ на следующем этапе процесса. Как только список заинтересованных сторон будет составлен и согласован с заказчиком/пользователем, инженер по качеству должен иметь возможность перейти к следующему этапу процесса.

Целью этого этапа является определение требования к качеству каждой заинтересованной стороны, из числа выявленных на предыдущем этапе. Первые шаги на этом этапе определяют потребности в качестве каждой из выявленных заинтересованных сторон. Впоследствии эти потребности используются в процессе определения требований к качеству и показателей. Все требования каждой заинтересованной стороны анализируются для разрешения конфликтов, проведения анализа рисков и их согласования с заинтересованной стороной, как показано на рисунке А.2.

Следовательно, шаги этого этапа необходимо выполнять в цикле для каждой заинтересованной стороны, определенном на предыдущем этапе процесса (действия, описанные в А.3.2 - А.3.4).

Входные данные: Список заинтересованных сторон, Характеристики предметной области проекта

Выходные данные: Контексты использования, связанные с выявленными заинтересованными сторонами

Этот шаг должен быть выполнен в сотрудничестве с заинтересованной стороной. Его цель состоит в том, чтобы определить контекст использования продукции ИКТ, специфичный для данной заинтересованной стороны или группы пользователей. Чтобы достичь этого, инженер по качеству должен определить:

- цель, которую пользователь хочет достичь с помощью продукции ИКТ;

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

- характеристики пользователя;

- технические, физические и организационные условия использования.

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

Чтобы определить контекст использования, инженер по качеству может использовать большое количество методов, которые позволяют ему получать эту информацию:

- опрос;

- наблюдение;

- интервью;

- любой другой инструмент, который соответствует ситуации.

В некоторых случаях предпочтительнее комбинировать несколько из этих методов, чтобы получить больше информации и иметь более прочную основу для последующего определения требований к качеству системы/программного обеспечения.

Требования к документированию контекста использования каждой заинтересованной стороны для обеспечения его прослеживаемости и принятия общего промышленного формата представлены в [9].

Примечания

1 [9] может использоваться не только для документирования, но и для определения типа собираемой информации.

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

2 Анализ целей высокого уровня не показывает этих конкретных потребностей в качестве.

Входные данные: Контекст использования, ограничения

Выходные данные: Потребности в качестве

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

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

Инженер по качеству обязан документировать все потребности в качестве в формате, позволяющем проследить их происхождение.

Входные данные: Потребности в качестве, потребности бизнеса

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

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

Как только этот этап будет завершен, инженер по качеству должен иметь возможность приступить к следующему этапу, который является центральным в этом процессе. Этот шаг позволяет ему определить требования к качеству продукции ИКТ для каждой заинтересованной стороны, используя потребности в качестве, которые он определил ранее.

Примечание - Контекст, упомянутый в А.2.3, включает понимание бизнес-модели, в которую включена продукция ИКТ, или, по крайней мере, части бизнес-модели, в которой будет работать анализируемая продукция ИКТ.

В данном приложении приведен пример сопоставления потребностей в качестве с характеристиками качества ГОСТ Р ИСО/МЭК 25010.

Некоторые потребности в качестве не могут быть сопоставлены непосредственно с конкретными характеристиками модели, но их необходимо указать и конкретизировать. Следующий процесс описывает, как определить требования к качеству на основе моделей качества, сочетающих в себе несколько характеристик/подхарактеристик модели ГОСТ Р ИСО/МЭК 25010.

Для каждой потребности в качестве, которая не может быть заявлена и указана напрямую, уникальная характеристика качества может быть сформирована путем сопоставления потребности с ГОСТ Р ИСО/МЭК 25010, существующие характеристики/подхарактеристики могут быть использованы при этом в качестве строительных блоков.

Примечания

1 Новые характеристики/показатели могут отличаться от простого объединения/добавления их компонентов. Они выражают новые качественные характеристики, которые должны быть включены в продукцию.

2 Поддерживая дисциплину правильного использования характеристик/подхарактеристик и показателей, модели могут быть расширены и адаптированы к различным и многочисленным ситуациям. Основные характеристики, предложенные ГОСТ Р ИСО/МЭК 25010 могут быть использованы в качестве строительных блоков для представления более сложных характеристик качества, если это требуется для продукции.

Первые потребности в качестве выявляются с помощью приложения А.

Затем потребности в качестве, определенные выше, сопоставляются с некоторыми характеристиками/подхарактеристиками качества. Но потребность в качестве высокого уровня, такая как QN1, не может быть напрямую сопоставлена с какой-либо одной характеристикой/подхарактеристикой в моделях качества ГОСТ Р ИСО/МЭК 25010 (и ее показатели, определенные в ГОСТ Р ИСО/МЭК 25022, ГОСТ Р ИСО/МЭК 25023 (см. также [6]). В этой ситуации может быть использован набор подхарактеристик для определения требований к качеству для удовлетворения потребности.

Чтобы определить требования к качеству для QN1 может быть использована комбинация вспомогательных характеристик из модели качества при использовании и их показатели, представленные в таблице Б.1.

Примечание - Требования к качеству по некоторым характеристикам/подхарактеристикам могут иметь разные показатели и целевые значения в зависимости от интересов различных заинтересованных сторон. Такая ситуация может быть разрешена с помощью технических и бизнес-решений.

На рисунке В.1 изображена структура для определения требований к качеству с примером требований к завершенности.

Требования примера, показанного на рисунке В.1, могут быть указаны следующим образом:

В таблице Г.1 показана взаимосвязь между этапами определения требований к качеству в настоящем стандарте и процессами, связанными с требованиями, определенными в [1].

Требования к инженерным процессам определены в [7], строго соответствующим двум техническим процессам (см. [1] и рисунок Д.1).

Требования, предъявляемые к инженерным процессам, формируют:

- СТЗС: спецификация требований заинтересованных сторон;

- ССТ: спецификация системных требований;

- СТПО: спецификация требований к программному обеспечению.

Они соответствуют следующим требованиям к качеству:

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

- требования к качеству продукции (для системы);

- требования к качеству продукции (для программного обеспечения).

В таблице Д.1 показано соответствие требований к качеству типам требований (см. [7]).

В этом приложении приведен пример того, как характеристики качества, приведенные в ГОСТ Р ИСО/МЭК 25010, могут быть сопоставлены с описанием документа (см. [7]) (СТЗС, ССТ, СТПО).

Рекомендуемая схема документа СТЗС в основном касается качества при использовании ГОСТ Р ИСО/МЭК 25010, и показана в таблице Д.2.

Рекомендуемая схема документа СТЗС и ССТ в основном касается качества продукции по ГОСТ Р ИСО/МЭК 25010, как показано в таблице Д.3.

ТКПИ может подразумевать несколько ТКП следующим образом:

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

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

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

Существует множество моделей перехода от характеристик качества при использовании к качеству характеристикам продукции в зависимости от категории системы. В таблице Е.1 приведен пример схем такого перехода для "системы управления ядерным реактором".

Система управления ядерным реактором должна иметь строгое требование к свободе от рисков. Поскольку система классифицируется как система, работающая в режиме реального времени и требующая большого количества людей, важна не только надежность, но и эффективность работы и удобство использования. Учитывая категорию целевой системы, использование [3] может привести к лучшему выводу.

Примечание - Следует обратить внимание на то, что в некоторой степени взаимосвязи зависят от задачи, например, ремонтопригодность и переносимость будут влиять на эффективность, производительность и удовлетворенность обслуживанием.

В данном приложении приведен пример взаимосвязи между любыми двумя типами характеристик качества продукции.

В таблице Ж.1 приведен пример взаимосвязи, которая может существовать между характеристиками качества продукции.

Следующие пояснения даны для каждой строки таблицы:

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

- повышение надежности (завершенности) какого-либо компонента может помочь достичь безопасности и ремонтопригодности для всей системы;

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

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

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

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

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

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

Примечание - Отношения не всегда симметричны.

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

ТКП/ТКД реализуются в программных компонентах (включая компоненты данных), как показано на рисунке И.1. Существует четыре типа реализации:

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

б) архитектура для реализации требований к качеству, например, требования отказоустойчивости отказоустойчивая архитектура;

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

г) политики для процесса проектирования, например, требования безопасности политика безопасного кодирования.

На рисунке И.1 также описывается необходимость двунаправленной прослеживаемости ТКП/ТКД для установки и обслуживания целевого программного обеспечения.

В таблице К.1 приведены основные важные требования к качеству для определенных пользователей и на примере интернет-магазинов.

В таблице К.2 приведены некоторые важные требования к качеству для определенных заинтересованных сторон и некоторые из их задач.

Другие заинтересованные стороны:

- дизайнер продукции;

- тестер;

- производители;

- люди, ответственные за транспортирование грузов;

- общество.

В таблице Л.1 приведен пример таблицы решений, в которой показано, что различная продукция ИКТ требует разного уровня качества.

В данном приложении приведено описание выполнения требований к качеству ИТ-услуг.

Объем требований, связанных с качеством ИТ-услуг, показан на рисунке М.1.

На рисунке М.1 область требований к качеству ИТ-услуг - это ИТ-услуги, а область ТКПИ (определенная в контексте ИТ-услуг) - это контекст использования ИТ-услуг. Целевая ИТ-услуга предоставляется некоторыми системами предоставления услуг, качество которых может влиять на качество ИТ-услуги и качество при использовании в заданных условиях. Поэтому некоторые требования к качеству для систем предоставления услуг вытекают из требований к качеству ИТ-услуг для целевой услуги и ТКПИ для их условий использования.

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