ГОСТ Р 56923—2016
стем помогает уменьшить время и стоимость, но может увеличить сложность. Использование новых
технологий может обеспечить конкурентное превосходство, но может также увеличить риск. С учетом
этого новые интерфейсы могут быть введены идолжны быть включены во множество технических тре
бований через повторение процесса анализа требований системы.
Для восходящей и нисходящей прослеживаемости относительно множества технических требо
ваний. произведенных процессом анализа требований системы должно быть проверено множество
декомпозируемых и произведенных технических требований.
5.4.3.2.4.3 Физическое проектирование архитектуры
5.4.3.2.4.3.1 Общее
Физический проект архитектуры использует выходные результаты логического определения ар
хитектуры, и эти два процесса итеративно взаимодействуют. В выполнении физического проекта архи
тектуры для формирования альтернативных физических решений проекта могут использоваться логи
ческие модели архитектурного проектирования, полученные технические требования и те технические
требования, которые не распределены по логическим моделям архитектурного проекта (см. ИСО/МЭК
12207 подпункт 6.4.3.3). После оценки каждого альтернативногофизического проекта с использованием
соответствующего анализа стоимостной и эксплуатационной эффективности и рисков для проектиро
вания архитектуры должно быть выбрано наиболее предпочтительное решение.
5.4.3.2.4.3.2 Результаты физического проектирования архитектуры
Выбранное решение для проектирования архитектуры должно быть полностью определено для
того, чтобы обеспечить выходные результаты, перечисленные ниже.
a) описание конфигурации, включая системные спецификации системы, которая была определе
на с помощью процесса определения требований правообладателей, процесса анализа требований
системы и процесса архитектурного проектирования системы. После реализации или комплексирова-
ния системы это описание конфигурации должно использоваться по выполнении процесса квалифика
ционного тестирования системы:
b
)требования, которые будут предъявляться к следующим, более низким, уровням систем или си
стемным элементам. Эти требования должны использоваться как начальные спецификации (или тре
бования) приобретающей стороны для реализации систем низшего уровня или системных элементов.
Если решение для проектирования архитектуры предназначено только для системного элемента, то
для разработки какие-либо иные системы низшего уровня могут отсутствовать:
c) требования для обеспечивающих систем, необходимые для поддержки жизненного цикла спро
ектированной системы. Эти требованиядолжны быть использованы приобретающей стороной, которой
востребована обеспечивающая система.
Описания конфигурации могут быть предоставлены в форме спецификаций, базовых линий, диа
грамм идругих соответствующих описаний проекта. Определенные описания конфигурации будут зави
сеть от стадии жизненного цикла, в которой используется процесс проектирования архитектуры систе
мы. Информация должна удовлетворять выходным критериям стадии жизненного цикла и критериям
входа для следующей стадии.
5.4.3.2.4.3.3 Прослеживаемость физических результатов проектирования архитектуры
Требования, выраженные в результатах описания конфигурации, должны быть проверены соот
ветствующими способами для гарантий того, что они прослеживаемы сверху и снизу. Прослеживае
мость должна быть проверена на соответствие трем источникам требований.
a) произведенным техническим требованиям из логического архитектурного проекта:
b
) произведенным техническим требованиям, которые получены из результатов анализа альтер
нативных физических решений для проекта;
c) требованиям из выходных результатов процесса анализа требований системы, которые не
были распределены по модели логического архитектурного проекта. Это могло произойти, когда техни
ческое требование после анализа требований не нашло распределения согласно модели логического
архитектурного проектирования.
Процесс определения требований правообладателей, процесс анализа требований системы и
процесс архитектурного проектирования системы могут быть выполнены вновь по мере необходимости
для уточнения требований по решению физического проектирования архитектуры и соответствующих
описаний выходных результатов (см. пояснения по понятиям итераций в n. 4.4.4.3 этого стандарта).
Факторы, которые могут вызвать эту итерацию, включают определение потребности в новых требова
ниях заинтересованных сторон в ходе проектирования архитектуры или выявление ошибок по резуль
татам проверки прослеживаемости сверху и снизу.
38