Идентификация руководящих требований. Анализ миссии, страница 34

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

Ни одна система не разрабатывается и не развертывается в один момент. Мы разрабатываем индивидуальные сегменты и их определенные способности ступенчато, чтобы уменьшить сложность и риск, и живем в пределах бюджета. План переходов (transition plan) устанавливает, что требуется на каждом шаге и обеспечивает эффективные даты, которые служат как промежуточные отчеты системных переходов. Каждое требование в каждом документе согласия требует согласования с одной из этих имеющих силу дат. В то время как это важно для внутренней иерархии требований системы, это обязательно и для внешних интерфейсов. Например, предположите, что миссия FireSat ожидает использования внешней релейной системы связи. В этом случае даты, указанные для начальной работоспособности наземного сегмента и для построения орбитальной группировки, должны соответствовать запланированным способностям системы связи для соответствующих дат. Часто разработчики пропускают или симулируют внешние интерфейсы в ранних стадиях разработки системы, но они могут требовать много внимания для фактической интеграции в программы.

Объединенный план испытаний системы (integrated system test plan) указывает требования, которые должны быть подтверждены или проверены испытанием системы (в противоположность анализу, демонстрации или осмотру). Этот документ устанавливает требования к оборудованию и оснастке, конфигурации интерфейсов, условиям, определенные планам испытаний и приемным критериям для выполнения испытаний.

Спецификации сегмента получаются из требований, предназначенных сегменту в спецификации системы. Каждый сегмент имеет собственную спецификацию, которая служит как единственная ссылка для требований. Поэтому он требует отстаивать полностью свои интересы, за исключением того, что мы можем обращаться к стандартам или спецификациям оборудования, нуждаясь в обычной увязке сегментов. Объединенная со спецификациями интерфейса, спецификация сегмента - основная передача управления между требованиями и проектом. Если оборудование поставляется независимо от контрактов на сегменты, системный инженер должен определить их разработку и конструкцию через спецификацию оборудования (facility specification), так как оно обслуживает все сегменты.

Документация интерфейсов между сегментами, обычно называемая документами по контролю интерфейсов или ICD, является ключом к объединению этих сегментов. Документы по критическим интерфейсам, таким как спутник – Земля для миссии FireSat, могут стать большими томами из-за их сложности. Два руководящих принципа важны в разработке и уточнению документов интерфейса. Каждый документ охватывает только две стороны - два вовлеченных сегмента. Однако системный инженер должен объединять эти два сегмента на любых переговорах относительно интерфейсов. Часто эмоциональные аргументы относительно того, кто "контролирует" документы интерфейса, потребляют больше энергии, чем проблема того стоит. Документ всегда отражает соглашение с тремя сторонами (включая системного инженера) независимо от стадии разработки. На ранней стадии разработки требований системный инженер устанавливает необходимые требования для интерфейсов: исходные данные или сообщения, размер сообщения, источник и предназначение, частота передачи, точность данных и некоторые характеристики связи, основанные, например, на данных по окружающей среде уровня системы. Таким образом, системный инженер может присвоить себе лидерство на ранней стадии разработки. По мере того как системный проект выходит на завершающую стадию, переговоры продвигаются на уровень выполнения, и сегменты имеют тенденцию принимать на себя все большую роль в определении проекта. Во всех случаях мы должны честно воспроизвести эти соглашения в документе интерфейса, независимо от того, на чьем текстовом процессоре он набран. Мы должны управлять им, однако, на программном уровне.