Школа
системного анализа
и проектирования
системного анализа
и проектирования
Systems Education
Школа системного анализа
и проектирования
Школа системного анализа
и проектирования
Федеральное управление
гражданской авиации
Министерства транспорта США
Руководство по разработке
и управлению требованиями
При создании авиационных бортовых
встраиваемых систем реального времени
Исходный текст, 2009 / Русский перевод, 2022
2.3 Разработайте
«Концепцию эксплуатации»
«Концепцию эксплуатации»
2.3 Для каждого контекста, в котором будет использоваться система, опишите как она будет взаимодействовать с окружающей средой. Систему представляйте в виде виде чёрного ящика.
В описание должно входить:
Один из самых популярных способов сделать это — юскейсы (UC, Use cases, варианты использования).
В описание должно входить:
- Описание реализуемых функций системы
- Пользователи или другие системы
- Порядок, в котором вышеупомянутые функции могут быть вызваны
- Значения, которые могут быть предоставлены в качестве входных данных
- И информация, необходимая от системы в качестве обратной связи
Один из самых популярных способов сделать это — юскейсы (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.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.7 Свяжите каждый шаг варианта использования с той функцией системы, которую он вызывает.
2.3.8 Объедините действия, которые повторяются в нескольких вариантах использования, в UC, который может быть вызван из нескольких мест.
2.3.9 Опишите в виде исключений особые ситуации или шаги, в которых вариант использования может не достигнуть своей цели или не выполнить постусловия.
2.3.10 Опишите альтернативные сценарии — сценарии, с помощью которых вариант использования может достичь своей цели и выполнить постусловия.
2.3.11 Используйте названия внешних объектов в вариантах использования для агентов, имён измеряемых и изменяемых переменных в предусловии, постусловии и шагах сценария.
2.3.12 Избегайте указания деталей интерфейса пользователя в концепции эксплуатации. Вместо этого назовите те возможности системы, которые будут вызваны пользователем.
2.3.13 Обновите описание границ системы теми переменными, которые были выявлены в ходе разработки вариантов использования.
2.3.14 Соберите из юскейсов предварительный набор функций, которые система должна будет выполнять.
2.3.12 Избегайте указания деталей интерфейса пользователя в концепции эксплуатации. Вместо этого назовите те возможности системы, которые будут вызваны пользователем.
2.3.13 Обновите описание границ системы теми переменными, которые были выявлены в ходе разработки вариантов использования.
2.3.14 Соберите из юскейсов предварительный набор функций, которые система должна будет выполнять.
Концепция эксплуатации — это алгоритмы или сценарии, описывающие, как будет использоваться разрабатываемая система [22]. Подготовка такой концепции — это полезный этап на пути от общего описания системы к подробным требованиям.
В документе «Концепция эксплуатации» систему рассматривают как чёрный ящик, описывая её взаимодействие со своими пользователями и другими системами в своей среде. Он помогает определить:
Они также помогают определить последовательность, в которой пользователи могут вызывать функции системы во время нормальной работы, и реакцию пользователей на неожиданное поведение системы.
В документе «Концепция эксплуатации» систему рассматривают как чёрный ящик, описывая её взаимодействие со своими пользователями и другими системами в своей среде. Он помогает определить:
- Какие функции будет выполнять система
- Какие значения могут поступить от пользователей в качестве входных данных
- Какую информацию пользователи получат в качестве ответа от системы
Они также помогают определить последовательность, в которой пользователи могут вызывать функции системы во время нормальной работы, и реакцию пользователей на неожиданное поведение системы.
В идеале «Концепция эксплуатации» должна быть написана в простом, интуитивно понятном всем заинтересованным сторонам стиле. Это помогает добиться взаимопонимания между различными заинтересованными сторонами и выявить функции, которые ранее могли быть упущены из виду.
Поскольку документ «Концепция эксплуатации» сосредоточен на том, как пользователи и другие системы взаимодействуют с системой, при его написании часто выявляют проблемы пользовательского интерфейса, особенно с точки зрения того, какая информация требуется от пользователя, когда пользователь может вызывать функции и какая информация нужна ему от системы.
Поскольку документ «Концепция эксплуатации» сосредоточен на том, как пользователи и другие системы взаимодействуют с системой, при его написании часто выявляют проблемы пользовательского интерфейса, особенно с точки зрения того, какая информация требуется от пользователя, когда пользователь может вызывать функции и какая информация нужна ему от системы.
В то же время в «Концепция эксплуатации» следует избегать определения конкретных деталей человеко-машинного интерфейса (HMI), поскольку это ограничит применимость требований к этому интерфейсу. Во многих авиационных системах интерфейс стал настолько сложным, что из-за плохого дизайна интерфейсов даже возникло несколько аварий [24 и 32−37]. По этой причине проектирование человеко-машинного интерфейса часто рассматривается как комплексная деятельность, которая выполняется параллельно с разработкой самой системы [16 и 24].
Например, в термостате инкубатора желаемый температурный диапазон должен быть предоставлен пользователем, но как следует его вводить: с клавиатуры или с помощью указателей на циферблате? Каким должен быть сигнал тревоги: звуковым сигналом или мигающей лампочкой? Хотя эти решения важны, необязательно, чтобы они принимались на этапе разработки «Концепция эксплуатации». К сожалению, подробное обсуждение дизайна человеко-машинного интерфейса является сложной темой, которая выходит за рамки данного руководства. Практики, представленные здесь, ограничены определением и документированием только высокоуровневой «Концепция эксплуатации». Посмотрите источники [24, 33, 38 и 39] для получения дополнительных рекомендаций по теме проектирования HMI.
Например, в термостате инкубатора желаемый температурный диапазон должен быть предоставлен пользователем, но как следует его вводить: с клавиатуры или с помощью указателей на циферблате? Каким должен быть сигнал тревоги: звуковым сигналом или мигающей лампочкой? Хотя эти решения важны, необязательно, чтобы они принимались на этапе разработки «Концепция эксплуатации». К сожалению, подробное обсуждение дизайна человеко-машинного интерфейса является сложной темой, которая выходит за рамки данного руководства. Практики, представленные здесь, ограничены определением и документированием только высокоуровневой «Концепция эксплуатации». Посмотрите источники [24, 33, 38 и 39] для получения дополнительных рекомендаций по теме проектирования HMI.
Варианты использования — это популярный способ выявления и документирования взаимодействий между системой, её пользователями и другими системами. Им посвящено много литературы, их используют как для описания высокоуровневых требований, так и для детального проектирования. Некоторые из наиболее известных источников вы можете найти тут: [17, 18 и 19]. Хотя общий формат описания вариантов использования примерно совпадает, существует множество стилей самого разного уровня строгости и формальности.
Судя по всему, юскейсы приносят больше всего пользы на ранних стадиях процесса, помогая понять и описать, как пользователи и другие системы будут взаимодействовать с системой. Варианты использования привлекают ещё и тем, что их можно использовать, чтобы лучше понять какие функции необходимы пользователям от системы. По сути, они помогают выполнить проверку поведения системы на ранних этапах разработки.
Судя по всему, юскейсы приносят больше всего пользы на ранних стадиях процесса, помогая понять и описать, как пользователи и другие системы будут взаимодействовать с системой. Варианты использования привлекают ещё и тем, что их можно использовать, чтобы лучше понять какие функции необходимы пользователям от системы. По сути, они помогают выполнить проверку поведения системы на ранних этапах разработки.
Что дальше