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

Требования к интерфейсам, как часть системных требований, должны быть идентифицированы во время определения системных решений. Они фиксируются в моделях функциональной и физической архитектуры, уточняются на совещаниях заинтересованных лиц. Для систем высокой сложности спецификации и планирование разработки и управления интерфейсами должны следовать структурированному подходу путем определения всех ключевых подсистем внутри общей системы и размещения их в матрице строк и столбцов N^>2, где каждый элемент матрицы представляет собой технический или системный интерфейс для управления.

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

a) определить интерфейс и его характеристики (физические, электрические, механические, человеческие и т.д.);

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

c) разработать документ управления интерфейсом;

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

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

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

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

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

• Документ управления интерфейсом (ICD) излагает детали интерфейса между двумя элементами системы: числа и типы разъемов, электрических параметров, механических свойств, а также экологических ограничений, определяет дизайнерское решение на требование интерфейса.

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

Документ «Требования к интерфейсу» входит в общий набор требований к системе, подпадает под управление конфигурацией и входит в общую контрольную «Матрицу соответствия требований к системе или продукту», верифицируемую на этапах разработки. Другие два документа интерфейса могут существовать в общем потоке документов системы по принадлежности. Отечественный и зарубежный опыт разработки высокотехнологичных систем показывает, что на проекте интерфейсы сложной системы (внешние и внутренние) нуждаются в дополнительном контроле, так как являются источником большого количества нестыковок как в ходе разработки проекта системы, так и на этапах ее интеграции и валидации.