Это исследование было проведено по запросу Управления инженерными требованиями (Requirements Engineering Management, REM), размещённому Техническим центром Федерального управления гражданской авиации имени Уильяма Дж. Хьюза.

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

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

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

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

Для наглядной демонстрации рекомендуемых практик в руководстве будут использоваться два примера:

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

• Второй — очень простые система управления полётом (FCS, flight control system), подсистема руководства полётом (FGS, flight guidance system) и автопилот (AP, autopilot), иллюстрирующие, как требования к системе могут быть назначены на подсистемы для организации разработки несколькими субподрядчиками.

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

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

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

Все рекомендации основаны на результатах отраслевого исследования и изучении литературы: и то и другое вы можете найти в указазнном источнике [1].

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

Методы, описанные в этом руководстве, в значительной степени основаны на методологии сокращения затрат на программное обеспечение (Software Cost Reduction, SCR) и модели с четырьмя переменными, первоначально предложенной Парнасом и Мэди [2] для определения требований к самолёту A-7E Corsair II ВМС США [3].

Позже эти идеи были расширены Software Productivity Consortium и превратились в методологию разработки требований консорциума (Consortium Requirements Engineering, CoRE) [4 и 5], которая использовалась для определения требований к самолёту C-130J [6]. Многие из методов организации требований основаны на идеях, первоначально разработанных с использованием этой CoRE методологии. Методология сокращения затрат на программное обеспечение (SCR) также продолжала развиваться последние два десятилетия. Военно-морская исследовательская лаборатория разработала ряд инструментов для спецификации и анализа моделей SCR [7].

Другим важным источником передового опыта стала обширная работа, проделанная Левесон и её коллегами по разработке машинного языка состояния требований (Requirements State Machine Language, RSML) [8], который использовался для описания второй версии системы предотвращения столкновений (Traffic Alert and Collision Avoidance System) [9].

Позже этот подход был расширен до RSML без событий (RSML-e) [10] и использован в качестве основы для формального анализа спецификаций требований [11 и 12]. И совсем недавно эта нотация была расширена до Комплекта инструментов спецификации и Методологии требований (Specification Toolkit and Requirements Methodology, SpecTRM), разработанной Safeware Engineering Corporationn [13, 14, и 15]. Модели SpecTRM встроены в более широкую спецификацию, которая «обеспечивает непрерывный поток обоснований и рассуждений от целей системы самого высокого уровня, через модель SpecTRM вплоть до материалов по внедрению и обучению пользователей» [13, 14 и 16].

За последние два десятилетия было проведено большое количество исследований по описанию требований в виде вариантов использования (юскейсов), которые, по-видимому, являются отличным способом обеспечить переход от первоначального неформального обзора системы к подробному формальному описанию требований. Обсуждение концепций эксплуатации в этом руководстве основано на использовании текстов юскейсов, аналогичных тем, которые описаны в ссылках [с 17 по 21].

Хорошее общее руководство по разработке и управлению требованиями содержится в источнике [22], который имеет много общего с подходом, изложенным в этом руководстве. В документе по ссылке содержится множество отличных рекомендаций по процессу работы с требованиями, примеры и определение хороших требований и примеры чек-листов. Другая хорошо известная ссылка — [23]. В тексте Левесон по безопасности систем и программного обеспечения также подробно обсуждается управление требованиями [24].

И, наконец, читателю стоит знать о ряде стандартов, связанных с REM или имеющих отношение к практике REM в индустрии авиационных бортовых систем.

К таким стандартам относятся:

• Руководство IEEE по разработке спецификаций системных требований (IEEE Std 1233) [25]
• Рекомендуемая практика IEEE для спецификаций требований к программному обеспечению (IEEE Std 830−1998) [26]
• Соображения по программному обеспечению при сертификации бортовых систем и оборудования (DO-178B) [27]
• Заключительный отчёт для разъяснения DO-178B, «Соображения по программному обеспечению при сертификации бортовых систем и оборудования» (DO-248B) [28]
• Руководство по обеспечению целостности программного обеспечения систем связи, навигации, наблюдения и управления воздушным движением (CNS/ATM) (DO-278) [29]
• Соображения по рекомендуемой практике сертификации сильноинтегрированных или сложных авиационных систем 4754 [30]
• Правила и методы проведения оценки безопасности гражданских бортовых систем и оборудования, ARP 4761 [31]

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

Перейти ко 2-й главе