ГОСТ Р 57102—2016
Процесс определения требований заинтересованных сторон (требований правообладателей) мо
жет использоваться для идентификации, сбора и соответствующего определения требований заинте
ресованных сторон. Приобретающая сторона и другие заинтересованные стороны вместе формируют
множество заинтересованных сторон, связанных с системной инженерией. Приобретающая сторона
обеспечивает начальный набор требований для каждой системы из структуры системы. Другие заин
тересованные стороны обычно обеспечивают дополнительные требования, которые могут влиять на
проектные решения. Примеры даны в перечне ниже, это:
a) взаимодействие с соответствующими обеспечивающими системами или взаимодействие с дру
гими системами в намеченной эксплуатационной среде;
b
) необходимость учета критичных факторов, таких как безопасность, защищенность, производи
тельность. надежность, пригодность, применимость и сопровождаемость;
c) потребности, навыки (мастерство), компетентности и рабочая окружающая среда оператора и
пользователя.
Получающееся множество требований заинтересованных сторон представляет собой набор тре
бований системной инженерии. Эти требования заинтересованной стороны включают функции, под
лежащие выполнению, требования к тому, насколько хорошо они должны быть выполнены, требования к
окружающей среде, в которой они должны быть выполнены, любые необходимые характеристики
системы и любые услуги, связанные с обеспечивающими системами. Должны быть исследованы все
процессы по ИСО/МЭК 15288 для гарантирования учета возможных источников требований заинтере
сованных сторон. Так, в качестве характерных примеров соответствующие действия каждого из про
цессов — реализации, комплексирования, верификации, передачи, валидации, функционирования, об
служивания (сопровождения) и процесса изъятия и списания — могут стать генераторами требований,
которые иначе могут быть упущены, что. в свою очередь, отрицательно повлияет на качество создава
емой системы. Аналогичным образом следует исследовать действия нетехнических процессов, чтобы
зафиксировать их соответствие требованиям заинтересованных сторон.
После того как множество требований заинтересованных сторон определено, следует осуще
ствить их прослеживаемость снизу вверх и сверху вниз (или проверки на полноту и непротиворечи
вость) для гарантии того, что никакие требования не были упущены или добавлены без обоснований.
Это множество требований заинтересованных сторон следует использовать при выполнении про
цесса валидации после того, как система будет реализована или скомплексирована и верифицирована.
Важно принять во внимание требования для функционирования системы и ведения бизнеса при обра
щении к процессу определения требований заинтересованных сторон (требований правообладателей).
5.4.3.2.3 Процесс анализа требований
Требования заинтересованной стороны не всегда декларируются в технических терминах и мо
гут оказаться не подготовленными к использованию для проектирования архитектуры. Для того чтобы
выполнить анализ требований заинтересованных сторон и преобразовать их в ряд технических тре
бований. пригодных к употреблению, может быть использован процесс анализа требований. Он пред
усматривает идентификацию и анализ требований внешнего взаимодействия, функциональных тре
бований, требований эксплуатации системы и ограничений, а также количественных и качественных
показателей, связанных с этими требованиями.
Получающееся множество технических требований следует проворить на прослеживаемость
снизу вверх и сверху вниз, чтобы гарантировать, что никакое требование заинтересованной стороны не
было упущено, у всех требований заинтересованных сторон есть генерированные технические тре
бования. и у всех технических требований есть изначальное требование заинтересованной стороны.
Получающееся множество технических требований следует проверить на наличие составных требова
ний, содержащих множественные части, которые, в свою очередь, следует декомпозировать в частные
требования.
5.4.3.2.4 Процесс проектирования архитектуры
5.4.3.2.4.1 Общее
Процесс проектирования архитектуры может быть использован для преобразования определен
ного набора технических требований в приемлемое решение архитектурного проекта, которое реали
зует технические требования для создаваемой системы. Это решение следует задокументировать в
пакете технических данных или в базе данных, которая включает множество спецификаций решения
архитектурного проекта и другие описания конфигурации.
5.4.3.2.4.2 Логическое определение архитектуры
Вначале следует преобразовать множество технических требований в более детализированное
множество таких технических требований, которые получаются с помощью ряда логических моделей
28