Федеральное управление

гражданской авиации

Министерства транспорта США

Руководство по разработке

и управлению требованиями

При создании авиационных бортовых

встраиваемых систем реального времени


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


Оглавление

2.1 Создайте
«Общее описание системы»
2.1.1 Разработайте
«Общее описание системы»
на ранних этапах разработки требований

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

Этот документ должен включать в себя как минимум:

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

Примеры таких описаний приведены в 
приложении A.1 для инкубатора,
приложении B.1 для системы управления полётом,
приложении C.1 для подсистемы руководства полётом и 
приложении D.1 для AP.
Рекомендация 2.1.1
Разработайте «Общее описание системы» на ранней стадии процесса разработки требований и используйте его в качестве введения к спецификации требований.

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

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

Назначение термостата инкубатора: поддерживать температуру воздуха в инкубаторе в заданном диапазоне. Он определяет текущую температуру инкубатора и включает и выключает источник тепла для нагрева воздуха по мере необходимости. Система позволяет медсестре устанавливать нужный температурный диапазон в пределах, безопасных для младенцев.
Как и весь документ «Общее описание системы» этот текстовый обзор (синопсис) будет развиваться в процессе уточнения требований. Примеры полных системных обзоров приведены в начале приложения A.1 для инкубатора, приложения B.1 для системы управления полётом, приложения C.1 для подсистемы руководства полётом и приложения D.1 для автопилота.

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

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

Каждый соответствующий контекст для системы должен быть выявлен и описан. Поскольку разные люди будут заинтересованы в разных контекстах, обычно лучше описывать каждый контекст отдельно, чем пытаться объединить их в единый контекст.
Рекомендация 2.1.3
Рассмотрите весь жизненный цикл системы и определите каждый контекст, в котором она будет использоваться.
2.1.4 Используйте контекстные диаграммы
Для каждого контекста должны быть определены внешние объекты, с которыми взаимодействует система, и характер этих взаимодействий. Для этого удобно использовать контекстную диаграмму, которая графически изображает каждый внешний объект и его взаимодействие с системой. Пример контекстной диаграммы для инкубатора показан на рисунке A-1. Аналогичная контекстная диаграмма для FCS показана на рисунке B-1, для FGS — на рисунке C-1, а для AP — на рисунке D-1. Обратите внимание, что сама система показана на контекстной диаграмме в виде черного ящика без внутренней структуры. Также может быть полезно определить системы более высокого уровня, в которые встроена система (например, контекст Термостата включает в себя более крупное системное содержимое инкубатора).

Для удобства приведём здесь эти диаграммы:
Рекомендация 2.1.4
Используйте контекстные диаграммы для высокоуровневого визуального описания системы, внешних объектов, с которыми она взаимодействует, и этих взаимодействий.

Старайтесь писать именно высокоуровнево, чтобы документ можно было использовать для быстрой ориентации новых читателей.
2.1.5 Опишите внешние объекты
(внешние сущности)
Также должно быть предоставлено краткое описание каждого внешнего объекта, взаимодействующего с системой. Поскольку мы формулируем часть общего описания системы, текст должен быть кратким и простым (более подробная информация об объектах и их взаимодействиях будет предоставлена в последующих разделах спецификации). Примеры описаний внешних объектов и их взаимодействия с системой приведены в приложении A.1.1 для инкубатора, приложении B.1.1 для системы управления полётом, приложении C.1.1 для подсистемы руководства полётом и приложении D.1.1 для автопилота.

Приведём тут пример для термостата инкубатора.

Термостат напрямую взаимодействует с тремя объектами, входящими в состав инкубатора:

  • Датчик измерения температуры сообщает термостату текущую температуру воздуха в инкубаторе
  • Источник тепла нагревает воздух в инкубаторе. Он включается и выключается с помощью регулятора нагрева
  • Интерфейс пользователя предоставляет пользователю настройки термостата и получает обратную связь от термостата
Термостат также косвенно взаимодействует с другими объектами за пределами инкубатора:

  • Медсестра, которая использует пользовательский интерфейс для входа в настройки и просмотра обратной связи
  • Воздух в инкубаторе
  • Младенец, помещённый в инкубатор и согретый воздухом
Рекомендация 2.1.5
Для каждой контекстной диаграммы предоставьте краткое описание всех внешних объектов и их взаимодействие с системой.
2.1.6 Зафиксируйте предварительный набор целей системы
Цели — это неформальные заявления о потребностях стейкхолдеров разрабатываемой системы. Это не требования, поскольку не поддаются проверке и не предоставляют достаточной информации для построения системы. Тем не менее, они дают важные рекомендации о том, почему создаётся система и что важно стейкхолдерам.

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

Предварительный набор системных целей должен быть зафиксирован на ранней стадии разработки требований, чтобы их можно было использовать для формирования спецификации требований. Очевидным местом для описания целей системы является «Общее описание системы». Однако в крупном проекте системных целей может быть достаточно много, что оправдывает их размещение в отдельном разделе или даже в отдельном документе.
Рекомендация 2.1.6
Зафиксируйте предварительный набор целей системы на ранней стадии процесса разработки требований, чтобы их можно было использовать для управления процессом разработки требований.
2.1.7 Поддерживайте информацию
о целях системы
Цели часто помогают объяснить, почему существует то или иное конкретное требование или почему оно именно таким образом сформулировано.

Цели могут быть приведены в обосновании требования (см. раздел 2.11). Концепция эксплуатации (см. раздел 2.3) также можно соотнести с конкретным целям системы. Управление целями системы будет варьироваться в зависимости от размера, сложности и зрелости разрабатываемой системы. В небольших проектах цели могут быть хорошо поняты и, возможно, удастся перечислить их на одной странице, а всё управление ими может свестись к периодическому пересмотру и обновлению.

Это относится и к примеру с инкубатором, который изначально преследует только две простые цели:


  • G1 — Младенец должен находиться в безопасной и комфортной для него температуре

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

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

В зависимости от размера и стабильности проекта информация, которую может быть желательно собрать о каждой цели, может включать:
  • Источник — Откуда взялась цель (клиент, физическое лицо, документ…)?
  • Дата возникновения — Когда была впервые определена цель?
  • Автор — Кто первым задокументировал цель?
  • Приоритет — Какова важность цели по сравнению с другими целями?
  • Стейкхолдеры (Заинтересованные стороны) — Какие клиенты или пользователи больше всего обеспокоены этой целью?
  • Cтабильность — Насколько вероятно, что эта цель изменится?
  • Запланированная дата — На какую дату планируется реализовать эту цель?

Для таких атрибутов, как приоритет и стабильность, каждая компания скорее всего захочет ввести свои собственные шкалы и способ определения. Если ожидается, что цели системы будут часто меняться, важно отслеживать историю их развития средствами конфигурационного управления.
Рекомендация 2.1.7
В зависимости от размера и стабильности проекта (или, напротив, вероятности изменений в нём) собирайте и поддерживайте информацию, которая поможет оценить важность каждой из целей системы по отношению к другим.
Что дальше
В следующей главе мы разберём, что включает в себя определение границ системы.

Далее к разделу 2.2