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

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

Спектр имеющих силу подходов широк. Серьезные различия существуют среди NASA, DOD, других разработчиков и даже среди отделений того же самого агентства. Например, все организации NASA проводят исследования Стадии А и Стадии B, которые кончаются в конечном счете Запросом на Предложение, включая спецификации верхнего уровня. Но они изменяются в широких пределах в части подхода к проведению этих исследований и продуктов требований. Для организаций DOD требования стандарта MIL-STD-490A слишком часто сокрушают аргументы, основанные на уникальных потребностях программы, при этом требования становятся слишком детальными и слишком формализованными на весьма ранней стадии. При полномасштабной разработке большая часть действий концентрируется на объединении интерфейсов программы (межсегментных и внешних к системе) и определении путей выполнения специфических требований. Решение более важных проблем системы в этой стадии может быть дорого и рискованно. Обычно требования замораживаются, как только система входит в стадию производства. Программа редко может позволить себе принимать изменения в этой стадии, выбирая гораздо более часто между тем, чтобы пределы системы оставались такими же, как при разработке, и между тем, чтобы отсрочить изменения до следующей модернизации.

Каждый часто слышит, что требования управляют программами технологии, но фактически новые технологии часто делают системы выполнимыми. Например, усовершенствования в широкополосной связной аппаратуре позволили в больших масштабах использовать передачу данных по линии «вниз» в реальном времени. Но полагаться на новые технологии или способности производства может быть рискованно. Новые технологии, которые позволяют снизить требования проекта по мощности, весу и объему, могут улучшить характеристики системы и стоимость. Мы должны контролировать технологию и базу производства и иметь резервные планы на случай, если недопустимый риск программы потребует, чтобы мы изменили основные проектные требования и интерфейсы для перераспределения характеристик.

Таблица 4-1

Эволюция действий и результатов по части требований. Каждая стадия разработки имеет тенденцию сосредоточиваться на определенном требовании и проектных соображениях.