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

Рис. 4-6 показывает передачу управления ответственности (responsibility hand-offs) через несколько технических уровней. Каждое из этих передач управления обычно соответствует промежуточному отчету обзора проекта и решению готовности в соответствии с программой, чтобы перейти к следующему шагу разработки. Оценки готовности в этих пунктах обзора решающие. Они определяют, является ли проект достаточно зрелым, чтобы перейти к следующей стадии. Они могут также выделять потребность в

·  ускорении или подчеркивании специфических областей проекта

·  ослаблении проектных бюджетов

·  перераспределении требований

·  рассмотрении состояния работы

·  подтверждении неудачи программы

·  пересмотре профилей финансирования

Небольшая группа приглашенных экспертов должна рассмотреть все документы заранее и разработать оценку готовности. Здравые вопросы и инакомыслие приветствуются. Церемониальные обзоры проекта, которые препятствуют "смущающим" взаимодействиям - просто социальные события, не заслуживающие инвестиций программы.

Рис. 4-6. Иерархия ответственностей для разрабатываемых спецификаций.

Пошаговые передачи управления к низшим уровням проекта обычно происходят в определенных промежуточных отчетах программы.

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

Спецификация на уровне требований относится к девяти классам документации (рис. 4-7). Рисунок показывает также описательные или поддерживающие документы, которые должны быть «в струе» с основными требованиями. Однако они не требуют согласования с разработчиками. Хотя мы можем думать, что спецификация системы первая из этих классов, слой требований фактически начинается с определения потребностей пользователя, документа требований (requirements document). Пользователь может определять эти потребности во множестве принятых документов, таких как «Ведомость требований DOD», но они часто превращаются в негибкие ведомости не обсужденных позиций. Лучший подход состоит в том, чтобы установить взаимоприемлемые, но неофициальные средства для формулировки как пользовательских требований, так и требований разработчика – тех, которые являются результатом отдельных исследований и переговоров.

Рис. 4-7. Иерархия спецификации требований.

Спецификации – это книги, которые служат как контролируемая ссылка для проектирования системы. Когда они окончательно готовы, они служат законным основанием для поставок многих элементов системы

Основанная на потребностях миссии, исследованиях и работах по проверке правильности, спецификация системы (system specification) должна охватить каждый уместный аспект того, что система должна делать (функции - functions) и как хорошо это должно быть выполнено (требования характеристик – performance requirements). Должен быть адресован каждый аспект характеристик системы. В идеале, требования системы независимы от сегментов, потому что определение сегментов должно происходить от них. Часто, тем не менее, сегменты находятся на месте прежде, чем начинается спецификация системы. Однако требования системы обычно выбираются в одном разделе документа и функционально размещаются в другом разделе.