2.3 Разработайте
«Концепцию эксплуатации»

2.3 Для каждого контекста, в котором будет использоваться система, опишите как она будет взаимодействовать с окружающей средой. Систему представляйте в виде виде чёрного ящика.

В описание должно входить:

• Описание реализуемых функций системы
• Пользователи или другие системы
• Порядок, в котором вышеупомянутые функции могут быть вызваны
• Значения, которые могут быть предоставлены в качестве входных данных
• И информация, необходимая от системы в качестве обратной связи

Один из самых популярных способов сделать это — юскейсы (UC, Use cases, варианты использования).

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

2.3.2 Добавьте UC, описывающие, как интересующая нас система используется в более широком контексте её операционной среды.

2.3.3 Используйте цель каждого варианта использования в качестве его названия.

2.3.4 Соотнесите каждый Use case с теми целями системы, которые он помогает достичь.

2.3.5 Определите главного агента (участника, который инициирует UC), предусловия (предварительные условия, которые должны выполняться до начала варианта использования), и постусловия (условия, которые должны выполняться после завершения UC).

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

2.3.7 Свяжите каждый шаг варианта использования с той функцией системы, которую он вызывает.

2.3.8 Объедините действия, которые повторяются в нескольких вариантах использования, в UC, который может быть вызван из нескольких мест.

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

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

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

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

2.3.13 Обновите описание границ системы теми переменными, которые были выявлены в ходе разработки вариантов использования.

2.3.14 Соберите из юскейсов предварительный набор функций, которые система должна будет выполнять.

Концепция эксплуатации — это алгоритмы или сценарии, описывающие, как будет использоваться разрабатываемая система [22]. Подготовка такой концепции — это полезный этап на пути от общего описания системы к подробным требованиям.

В документе «Концепция эксплуатации» систему рассматривают как чёрный ящик, описывая её взаимодействие со своими пользователями и другими системами в своей среде. Он помогает определить:

• Какие функции будет выполнять система
• Какие значения могут поступить от пользователей в качестве входных данных
• Какую информацию пользователи получат в качестве ответа от системы

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

В идеале «Концепция эксплуатации» должна быть написана в простом, интуитивно понятном всем заинтересованным сторонам стиле. Это помогает добиться взаимопонимания между различными заинтересованными сторонами и выявить функции, которые ранее могли быть упущены из виду.

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

В то же время в «Концепция эксплуатации» следует избегать определения конкретных деталей человеко-машинного интерфейса (HMI), поскольку это ограничит применимость требований к этому интерфейсу. Во многих авиационных системах интерфейс стал настолько сложным, что из-за плохого дизайна интерфейсов даже возникло несколько аварий [24 и 32−37]. По этой причине проектирование человеко-машинного интерфейса часто рассматривается как комплексная деятельность, которая выполняется параллельно с разработкой самой системы [16 и 24].

Например, в термостате инкубатора желаемый температурный диапазон должен быть предоставлен пользователем, но как следует его вводить: с клавиатуры или с помощью указателей на циферблате? Каким должен быть сигнал тревоги: звуковым сигналом или мигающей лампочкой? Хотя эти решения важны, необязательно, чтобы они принимались на этапе разработки «Концепция эксплуатации». К сожалению, подробное обсуждение дизайна человеко-машинного интерфейса является сложной темой, которая выходит за рамки данного руководства. Практики, представленные здесь, ограничены определением и документированием только высокоуровневой «Концепция эксплуатации». Посмотрите источники [24, 33, 38 и 39] для получения дополнительных рекомендаций по теме проектирования HMI.

Варианты использования — это популярный способ выявления и документирования взаимодействий между системой, её пользователями и другими системами. Им посвящено много литературы, их используют как для описания высокоуровневых требований, так и для детального проектирования. Некоторые из наиболее известных источников вы можете найти тут: [17, 18 и 19]. Хотя общий формат описания вариантов использования примерно совпадает, существует множество стилей самого разного уровня строгости и формальности.

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

В следующем разделе мы подробнее поговорим о написании юскейсов.