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

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

  • Краткое описание системы
  • Одно или несколько описаний контекста
  • Краткое описание каждого внешнего объекта на контекстных диаграммах
  • Набор целей, задач и ограничений системы высокого уровня
Он также может включать и другую важную информацию, например, историческая справка, но при этом нельзя забывать о задаче быстро ввести в курс нового читателя. Примеры таких описаний приведены в приложении A.1 для инкубатора, приложении B.1 для FCS, приложении C.1 для FGS и приложении D.1 для AP

Рекомендация 2.1.1: Разработайте «Общее описание системы» на ранней стадии процесса разработки требований и используйте его в качестве введения к спецификации требований. Старайтесь писать именно высокоуровнево, чтобы документ можно было использовать для быстрой ориентации новых читателей.
2.1.2 Предоставьте краткое текстовое описание системы
(синопсис)
Само это описание должно начинаться с краткого обзора системы.

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

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

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

Рекомендация 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 для FCS, приложении C.1.1 для FGS и приложении D.1.1 для AP.

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

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

  1. Медсестра, которая использует интерфейс пользователя для ввода пользовательских настроек и просмотра обратной связи от термостата
  2. Воздух в инкубаторе
  3. Младенец, помещённый в инкубатор и согреваемый воздухом

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

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

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

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

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

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

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

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

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

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

Вперед к разделу 2.2!
Made on
Tilda