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]. Хотя общий формат описания вариантов использования примерно совпадает, существует множество стилей самого разного уровня строгости и формальности. Однако варианты использования,

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

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