ФЕДЕРАЛЬНОЕ УПРАВЛЕНИЕ
ГРАЖДАНСКОЙ АВИАЦИИ
МИНИСТЕРСТВА ТРАНСПОРТА США
Руководство по разработке
и управлению требованиями
При создании авиационных бортовых
встраиваемых систем реального времени

Исходный текст, 2009 / Русский перевод, 2022

Оглавление
3. Подведём итоги
Управление требованиями является одним из наиболее важных видов деятельности при разработке информационных систем.

В ссылке [46] Фред Брукс кратко излагает проблему: «‎Самая сложная часть в разработке ПО — это принятие решения о том, что именно нужно создать. Никакая другая часть концептуальной работы не сложна так, как разработка детальных технических требований… Никакая другая часть работы не наносит такого ущерба итоговой системе, если она выполнена неправильно. Именно эту деталь труднее всего исправить в дальнейшем».

Хотя за прошедшие годы было разработано множество методологий для REM, результаты отраслевого опроса, описанные в ссылке [1], показывают, что лучшие из этих практик используются редко, если вообще используются, и у разработчиков цифровых систем возникает много вопросов о том, как эффективно собирать, документировать и систематизировать требования.
В этом руководстве предпринята попытка исправить сложившуюся ситуацию, объединив лучшие идеи из нескольких подходов, организовав их в единое целое и проиллюстрировав конкретными примерами, которые наглядно демонстрируют их преимущества.

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

Каждая рекомендация объясняется в руководстве путём выбора конкретного подхода к её реализации и иллюстрации этого подхода на рабочем примере. Хотя может показаться, что примеры и рекомендуемые практики предполагают определённый стиль и формат, их реальная цель состоит в том, чтобы проиллюстрировать и разъяснить метод и его преимущества.
Компаниям может потребоваться внести изменения (иногда значительные), чтобы интегрировать описанные в руководстве методики с уже имеющимися у них процессами и инструментами. Чтобы использовать это руководство, организация должна определить, какие практики не используются или используются неэффективно, а затем определить, как и в каком порядке стоит их внедрить. Если подход, описанный в руководстве, отвечает потребностям компании (например, варианты использования для определения концепции эксплуатации), сотрудники компании могут захотеть внедрить рекомендацию из руководства. Если требуется более подробная информация или адаптация, ссылки, приведённые в документе могут стать отличным источником дополнительной информации. Следует отметить, что некоторые из приведённых подходов уже адаптированы в этом руководстве в дополнение к другим рекомендуемым методам.
Как показано в этом руководстве, хорошая спецификация требований представляет из себя нечто большее, чем простой список утверждений «система должна» и подготовить её нелегко. Рекомендации, описанные в этом руководстве, посвящены созданию такой структуры документации, которая будет гарантировать, что в вашем документе приведены полные, последовательные, понятные и хорошо организованные требования.

Однако мы постарались продемонстрировать, что вложение времени и усилий в начале проекта для создания хороших требований в конечном итоге снижает затраты при одновременном повышении качества конечного продукта [22−24 и 47]. Использование рекомендаций из этого руководства поможет обеспечить структуру, необходимую для разработки полных, последовательных, точных требований, удобных с точки зрения поддержки и при этом хорошо организованных.