Как только мы устанавливаем функции верхнего уровня и последовательности, мы должны разложить и тщательно проанализировать каждую функцию на всём протяжении остающихся уровней потока. Например, определение местоположения спутника FireSat (функция 4.4 на рис. 4-2) требует последовательности действий от оценки ключевых параметров космического аппарата и полезного груза до получения местных земных координат. Мы должны пройти от начала до конца функций, пока мы не сможем разместить их единственным образом на желательном уровне проектной ответственности. Опять же, мы не можем размещать функции, если мы не разработаем сводки характеристик для многочисленных вовлеченных оценок и не определим, сколько каждый сегмент может допустить по какой стоимости и риску.
Мы можем использовать несколько других методов для описания функций, представляющих различные информационные и функциональные отношения. Информация может включать интерфейсные данные, текущие между функциями, управляющие отношения, показывающие, что должно случиться прежде, чем другая функция может начаться, или источники и предназначение данных. Можем ли мы использовать эту информацию, зависит от того, знаем ли мы достаточно о системе на текущей стадии проекта, чтобы описать этот уровень детализации. Кроме того, мы должны знать цель функционального описания. Например, используем ли мы его, чтобы распределить проектирование между инженерами и программистами, или просто описываем основную иерархию требований системы?
При применении этих методов мы должны быть осторожны. Конечно, функциональная структура помогает планировщикам проследить многие действия программы до уровня требований. Но программное обеспечение для разработки диаграмм и поддержки баз данных не управляет анализом. Фактически, мы выбираем специфическую блок-схему или потому, что мы предпочитаем работать с ней, или потому, что она хорошо применяется к подручной проблеме. Функциональная структура, которая развертывается, будет компромиссом между оценками характеристик, стоимостью, графиком и риском, связанных с каждым решением. McClure [1988] даёт одно из наиболее практичных и ясных обсуждений этих инструментов и методов поддержки.
Рис. 4-2. Функциональный поток требования по местоположению для миссии FireSat.
Функциональный поток определяет то, что должно быть выполнено в иерархической структуре. Дополнительные особенности могут быть добавлены к представлению (например, интерфейсы данных, последовательности управления) используя различные методы схематического изображения
Процесс анализа требований ведет, в конечном счете, к иерархически организованным бюджетам характеристик для взаимодействующих сегментов разработки. Этот повторяющийся процесс начинается с бюджетов, полученных с использованием анализа, моделирования, известного проекта или тестовых данных и большой доли опыта. На ранних стадиях программы мы должны ориентироваться на проблемы, управляющие миссией. После удовлетворения этих драйверов миссии мы можем вернуться к менее критическим требованиям.
Опыт особенно важен в разработке начальных бюджетов характеристик, чтобы выполнить требование по системной ошибке местоположения. Большое количество источников ошибки может сокрушить нашу способность распознать, какие из них являются доминирующими и плодородными для компромисса. В этом случае ошибки, связанные с конструкцией, юстировкой и калибровкой датчика и обработкой данных, относительно хорошо понимаемы, а их связанные допуски предсказуемы. Главные компромиссы и центр внимания при обосновании эксплуатационных качеств должны коснуться того, как точно система может оценить и управлять положением и ориентацией. Каждый из нескольких вариантов вносит риск в эксплуатационные качества или стоимость, и каждый тесно связан с требованиями по эксплуатационным качествам и охвату полезной нагрузки.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.