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

Фактически, спецификации (specifications) – это просто контролируемые документы, которые фиксируют устойчивые основные характеристики от начала до конца нескольких стадий разработки. Когда они достигают стадии, где они определяют систему, которая будет приобретена, они станут документами согласия (compliance documents), которых разработчик должен придерживаться. Мы не можем разрабатывать спецификации в соответствии с предписанием. Программы должны «кроить» и управлять содержанием, структурой и разработкой. Стандарты NASA или DOD, например, являются путеводителями, готовыми для того, чтобы им следовать. Конечно, я не подразумеваю, что мы должны капризно пренебречь или выхолостить необходимую документацию программы, особенно если она критическая для поддержки полного эксплуатационного цикла системы. Но я предлагаю, чтобы мы документировали каждое требование с преднамеренной злобой и не просто потому, что военный стандарт предписывает это.

Эффективные спецификации должны быть последовательными и завершенными по отношению к глубине проработанности системы в цикле ее разработки. Последовательность (consistency) означает, что требования характеристик должны быть написаны только однажды, найдены в логическом месте, и соответственно помещены в иерархии установленных требований. Завершенность (completeness) зависит от стадии разработки системы, но она означает, что мы должны определить каждое требование так, чтобы оно удовлетворяло следующим более высоким уровням. Это не означает, например, что мы должны адресовать требования по устойчивости к плесени немедленно после разработки концепции. Для требования по местоположению для миссии FireSat, завершенность означает адресацию всех источников ошибок как в спецификации сегментов, так и в документах интерфейса. Эффективное требование - также прослеживаемое требование, что означает, что мы можем понимать и оправдывать его существование и следить за ним через изменения. Понимание взаимоотношений и драйверов требований будет удерживать нас от капризного ослабления требования, когда зрелый проект показывает, что оно будет трудно для выполнения.

Мы должны строго прослеживать требования, когда мы разрабатываем спецификации. Доступные компьютерные инструменты поддержки обычно устанавливают и показывают зависимости и источники требований. Чтобы прослеживать их, мы можем вести записную книжку как приложение к определенному документу требований, возможно используя особенности базы данных компьютерных инструментов. Эта записная книжка могла бы иметь краткую статью для каждого требования. Статья индексировала бы документы и определенные параграфы, от которых требование было прослежено. Требование, полученное в результате анализа, имело бы ссылку на определенную техническую записку или отчет, показывающий результаты анализа для будущего использования.

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

На ранних стадиях разработки требования всегда определяются или решаются. План решения, который сопровождает спецификацию, может проследить заданные даты и назвать, кто должен выполнить их. Каждое примечание в спецификации типа TBD (Будет определено) или TBR (Будет решено) ведет ко входу в сопровождающий план решения. «Будет определено» означает, что мы не выбрали ни определенную функцию, ни её характеристический номер. Когда мы оцениваем требование по измерению или стоимость "грубо", мы назначаем TBR,чтобы показать, что требуется дальнейшая работа. Мы можем следить за скоростью закрытия (или открытия на очень ранних стадиях) требований с итоговыми сообщениями TBD и TBR.