ГОСТ Р 57102—2016
a) описание конфигурации, включая системные спецификации системы, которая была определе
на с помощью процесса определения требований заинтересованных сторон (требований правооблада
телей), процесса анализа требований и процесса архитектурного проектирования. После реализации
или комплексирования системы это описание конфигурации следует использовать при выполнении
процесса верификации.
b
) требования, которые будут предъявляться к следующим, более низким, уровням систем или
системным элементам. Эти требования следует использовать как начальные спецификации (или тре
бования) приобретающей стороны для разработки систем низшего уровня или системных элементов,
если решение для проектирования архитектуры не предназначено для системного элемента, у которо го
не будет системы низшего уровня для разработки;
c) требования для обеспечивающих систем, необходимые для поддержки жизненного цикла спро
ектированной системы. Эти требования следует использовать приобретающей стороне, для которой
востребована обеспечивающая система.
Описания конфигурации могут быть представлены в форме спецификаций, базовых линий, эски
зов. чертежей, спецификации деталей и других соответствующих описаний проекта. Определенные
описания конфигурации будут зависеть от стадии жизненного цикла, в которой используется процесс
проектирования архитектуры. Информация должна удовлетворять выходным критериям стадии жиз
ненного цикла и критериям входа для следующей стадии.
5.4.3.2.4.3.3 Прослеживаемость физических результатов проектирования архитектуры
Требования, выраженные в результатах описания конфигурации, следует проверить соответству
ющими способами для гарантии того, что они прослеживаемы сверху вниз и снизу вверх. Прослежива
емость следует проверять на соответствие трем источникам требований:
a) произведенным техническим требованиям из логического архитектурного проекта;
b
) произведенным техническим требованиям, которые получены на основе результатов анализа
альтернативных физических решений для проекта:
c) требованиям из выходных результатов процесса анализа требований, которые не были рас
пределены по модели логического архитектурного проекта. Это могло произойти, когда техническое
требование после анализа требований не нашло распределения согласно модели логического архи
тектурного проектирования.
Процесс определения требований заинтересованных сторон (требований правообладателей),
процесс анализа требований и процесс проектирования архитектуры могут быть выполнены вновь по
мере необходимости для уточнения требований по решению физического проектирования архитекту ры
и соответствующих описаний выходных результатов (см. пояснения по понятиям итераций в 4.4.4.3).
Факторы, которые могут вызвать эту итерацию, включают определение потребности в новых требова
ниях заинтересованных сторон в ходе проектирования архитектуры или выявление ошибок по резуль
татам проверки прослеживаемости сверху вниз и снизу вверх.
5.4.3.2.4.4 Определение структуры системы
Возможными результатами физического проектирования архитектуры являются требования для
следующих, более низких, уровней системы или системных элементов. Эти требования выходных ре
зультатов являются требованиями приобретающей стороны для рекурсивного применения процесса
определения требований правообладателей, процесса анализа требований и процесса проектирова
ния архитектуры к системному элементу или системе низшего уровня в структуре системы. Системы
или системные элементы на следующем, более низком, уровне структуры системы будут позже ском-
плексированы в систему, от которой произошли требования.
Рекурсивноо применение процесса определения требований потребностей и требований заин
тересованных сторон (требований правообладателей), процесса анализа требований и процесса про
ектирования архитектуры показано на рисунке 15 в виде петли, определяемой как нисходящий поток
требований приобретающей стороны для каждого уровня структуры системы. Для каждой системы
или системного элемента из структуры разрабатываемой системы должны быть применены процесс
определения требований заинтересованных сторон (требований правообладателей), процесс анализа
требований и процесс проектирования архитектуры. Также, чтобы сформировать входное множество
требований заинтересованных сторон для каждого системного элемента или системы на следующем
уровне структуры системы, должны быть определены другие требования заинтересованной стороны
(см. пояснения относительно понятия рекурсии в 4.4.3.2).
Рекурсивная петля на рисунке 15 продолжается, пока все системные элементы структуры систе
мы не будут определены, и никакие дополнительные системы или системные элементы не должны
30