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

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

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

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

  • Первый, это термостат для изолятора, который используется в отделении ухода за новорожденными. Он представляет собой небольшой понятный пример, иллюстрирующий применение рекомендуемых методов в одной системе.
  • Второй — очень простая Система управления полётом (FCS), Система управления полётом (FGS) и автопилот (AP), иллюстрирует, как требования могут быть распределены от системы к её подсистемам для облегчения разработки несколькими субподрядчиками. Оба примера предназначены для иллюстрации рекомендуемой практики и не являются полным описанием реальных систем. Эти примеры используются на протяжении всего документа для иллюстрации рекомендуемых практик. Их описание вы найдёте в приложении.

В руководстве для пояснения методик используются конкретные примеры, но существует множество и других форматов, которые можно использовать для достижения тех же целей. Компаниям может потребоваться внести изменения (иногда значительные), чтобы интегрировать описанные в руководстве методики с уже имеющимися у них процессами и инструментами.
1.2 Предпосылки
Все методы основаны на результатах отраслевого исследования и изучении литературы: и то и другое вы можете найти по ссылке [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], который использовался для описания системы предупреждения о проблемах дорожного движения и система автономного экстренного торможения автомобиля [9].
Позже этот подход был расширен до RSML без событий (RSML-e) [10] и использован в качестве основы для формального анализа спецификаций требований [11 и 12]. И совсем недавно эта нотация была расширена до Инструментов спецификации и методологии требований (Specification Toolkit and Requirements Methodology, SpecTRM), разработанной Safeware Engineering Corporation [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]
  • Соображения по сертификации Высокоинтегрированных или сложных авиационных систем (Рекомендуемая практика (ARP) 4754) [30]
  • Правила и методы проведения оценки безопасности гражданских бортовых систем и оборудования, ARP 4761 [31]
Что дальше
В следующей главе мы разберем практики для написания хорошей спецификации требований.

Вперед ко 2-й главе!
Made on
Tilda