Табл. 1-5 в разделе 1.4 показывает необходимые требования для миссии FireSat. Эти требования ни диктуют, ни налагают бесполезные ограничения на проект, но они определяют то, что необходимо для выполнения миссии и управления системой. Таблица содержит достаточно информации, чтобы получить определенные характеристики проекта, с достаточным контролем требований пользователя. Таблица также не включает неподдающиеся проверке термины или цели типа "максимизировать", "достаточный", или "оптимизировать", потому что разработчики не могут интерпретировать их. Они быстро отказываются от таких неопределенных утверждений наряду с требованиями, заявленными как задачи выполнить необходимые потребности миссии в пределах отведенного бюджета. Слишком часто люди предлагают, чтобы цели являлись требованиями, которые должны быть реализованы только в том случае, если в результате не будет никакого "воздействия". В моем опыте каждое значащее требование рождает стоимость и будет иметь воздействие.
Альтернативный взгляд на "цели" против "требований" состоит в том, что это представляет проектный запас. Любое жесткое требование должно привести к некоторому уровню запаса в проекте, а "цель" может быть расценена как определение желательного запаса. При разработке проекта запас обеспечивает пространство «торга», доступное лицам, принимающим решение. Пользователь должен, в конечном счете, решить, стоят ли дополнительные эксплуатационные качества связанной с ними возрастающей стоимости.
Проектировщики часто сосредотачиваются на таких областях характеристик, как работа полезной нагрузки и распределение данных миссии, и недооценивают более «приземленные» требования, типа готовности к применению и внешних интерфейсов. Все же «приземленные» требования могут быть решающими по стоимости и риску. Например, готовность может потребовать увеличенную надежность компонентов и поэтому повысить стоимость разработки. Она может управлять концепцией обслуживания, включая пополнение и орбитальную поддержку. Она может также влиять на продолжительность изготовления, особенно для критических компонентов. Аналогично, игнорирование внешних интерфейсов может привести к созданию проекта без внешней поддержки, необходимой для того, чтобы развертывать и управлять миссией.
Поскольку большинство космических систем выполняют больше одной миссии, планировщики должны разрабатывать требования, которые учитывают каждую миссию. Например, полезная нагрузка для ИК наблюдения на спутнике FireSat может привлечь других пользователей своими способностями по ИК-съемке и радиометрическому измерению. Если увеличенная стоимость и риск приемлемы, их требования могли бы привести к большему количеству диапазонов полезной нагрузки, увеличенному охвату и дополнительным требованиям по распределению данных. Именно поэтому мы должны установить все поддерживаемые миссии на ранней стадии определения требований или быть подготовлены к тому, чтобы приспособить новые миссии в будущих модернизациях к способностям системы.
Хотя системные требования должны распределять все аспекты характеристик по всему циклу разработки, роль и характеристики требований в каждой стадии разработки меняются. Следовательно, нам нужно использовать определенные структуру и язык на ранней стадии процесса, но не запирать себя в преждевременных деталях. Табл. 4-1 показывает, как изменяются требования в процессе разработки системы. (Руководство по системному проектированию [1989] более формально характеризует стадии разработки для DOD.) Даже при разработке концепции мы должны рассматривать и документировать управляющие требования, среду и опасности везде, где это применимо. Эти основные требования управляют начальными действиями - разработкой концепции системы и методики оценки. Мы должны расширить их, когда мы утверждаем концепцию и анализируем требования, чтобы обратить внимание на наиболее рискованные особенности проекта системы.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.