Уроки, извлечённые из управления требованиями: программа подводной лодки S-80

Программа подводных лодок S-80 показывает, почему в проектах по разработке аппаратных продуктов требования, ограничения, изменения в конструкции и проверки верификации должны оставаться связанными между собой.

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

Программа подводных лодок S-80 в Испании наглядно демонстрирует эту закономерность. В ходе разработки программа столкнулась с серьезной проблемой массы и плавучести. Переработка конструкции помогла решить эту задачу, но обновленные размеры судна привели к новой практической проблеме: подводная лодка стала слишком длинной для гавани, которую предполагалось использовать.

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

Ключевые выводы

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

Что произошло в программе S-80

Испания запустила программу S-80 для разработки нового класса подводных лодок. В ходе разработки программа столкнулась с серьезной проблемой массы и плавучести. Судно стало тяжелее, чем планировалось, что вызвало опасения относительно того, хватит ли ему запаса плавучести, чтобы надежно всплывать после погружения.

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

Проблема с инфраструктурой добавила еще один уровень работ в программу, которая уже потребовала серьезной переработки конструкции. В итоге программа стала сложнее, заняла больше времени и обошлась дороже, чем ожидалось изначально.

Этот пример напоминает: у каждой переработки конструкции всегда остается еще один вопрос — что еще теперь нужно проверить?

Чему команды по разработке аппаратуры могут научиться на примере S-80

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

Недостаточно просто знать об этих ограничениях. Именно здесь важно управление требованиями: оно помогает командам сохранять их видимость, связанность и возможность пересмотра по мере развития конструкции. Для команд по разработке аппаратуры это сводится к трем практическим привычкам:

Делайте критически важные ограничения видимыми

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

Связывайте требования с проектными решениями

Требование становится полезнее, когда оно связано с областью системы, блоком, объектом проектирования или инженерной деятельностью, на которые оно влияет. Такая связь помогает инженерам понять, почему проектное решение важно, какие требования оно поддерживает и что еще может быть затронуто при изменении конструкции.

Используйте прослеживаемость для анализа влияния изменений

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

Как помогает связанный процесс управления требованиями

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

Altium Requirements Portal создан для поддержки такого рабочего процесса за счет управления требованиями, прослеживаемостью, ответственностью и верификацией в одной общей среде. Вместо того чтобы рассматривать требования как изолированный текст, команды могут видеть, что изменилось, на что это влияет, кто отвечает за следующий шаг и как требование будет проверяться.

Что является вашей «подводной лодкой» в проекте?

В каждом проекте по разработке аппаратуры есть ограничения, которые легко упустить, когда проектирование идет быстро. Они могут быть механическими, электрическими, нормативными, эксплуатационными или связанными с процессами. Риск заключается не в том, что командам не хватает знаний, а в том, что важные знания не всегда фиксируются, связываются и пересматриваются при изменении конструкции.

Именно поэтому пример S-80 полезен вне зависимости от его масштаба. Та же закономерность может проявляться в повседневной разработке продуктов, когда инженерный замысел, проектные решения и подтверждающие данные со временем не остаются связанными.

Упростите отслеживание влияния изменений с помощью инструмента управления требованиями, к которому есть доступ у всей вашей команды.

Начните работу с Requirements Portal →

Часто задаваемые вопросы

Что вызывает проблемы управления требованиями в аппаратных проектах?

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

Почему электронные таблицы становятся неудобными для управления требованиями?

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

Как прослеживаемость помогает сократить дорогостоящие доработки на поздних этапах?

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