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

• Диаграмма сценариев использования:Показывает акторов, границы системы и взаимосвязи.

• Описание сценария использования:Объясняет детальное поведение, условия, правила и результаты.

Диаграмма предоставляет карту; описание предоставляет маршрут.

1. Что такое сценарий использования?

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

Примеры:

• Клиент оформляет заказ

• Сотрудник подаёт заявление на возмещение расходов

• Пациент записывается на приём

• Администратор создаёт учётную запись пользователя

• Клиент сбрасывает пароль

Хороший сценарий использования:

• Ориентирован на достижение цели

• Ценен для актора

• Описан с точки зрения пользователя

• Не зависит от конкретной компоновки экранов

• Сфокусирован на наблюдаемом поведении системы

Неудачные и улучшенные названия сценариев использования

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

2. Ключевые понятия

2.1 Актеры

Актер — это внешняя роль, взаимодействующая с системой.

Актером может быть:

• Человек

• Организация

• Другая программная система

• Аппаратное устройство

• Запланированный или временной триггер

Примеры:

• Клиент

• Специалист службы поддержки

• Складской работник

• Платёжный шлюз

• Служба электронной почты

• Администратор

Актор — это роль, а не обязательно конкретный человек. Например, «Клиент» обычно лучше, чем «Джейн Смит».

Основные и вспомогательные акторы

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

Вспомогательный актор вспомогательный акторпомогает системе во время выполнения.

Пример:

• Основной актор: Клиент

• Вспомогательный актор: Платёжный шлюз

• Сценарий использования: Разместить заказ

Клиент инициирует заказ, а платёжный шлюз авторизует оплату.

2.2 Границы системы

Границы системы определяют, что находится внутри моделируемой системы.

Для интернет-магазина границы могут включать:

• Просмотр товаров

• Добавить товар в корзину

• Разместить заказ

• Оплатить заказ

• Отслеживание заказа

Следующее находится за пределами границ:

• Клиент

• Платёжный шлюз

• Доставочная компания

• Поставщик электронной почты

Граница предотвращает путаницу в вопросах ответственности системы.

2.3 Сценарий использования

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

Например:

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

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

2.4 Предусловия

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

Примеры:

• У клиента есть активный аккаунт.

• Товар доступен для продажи.

• Сотрудник аутентифицирован.

• Слот для записи существует.

• Корзина покупок содержит хотя бы один товар.

Предусловие — это не действие, выполняемое сценарием использования.

Плохое предусловие:

Клиент входит в систему.

Лучшее предусловие:

Клиент аутентифицирован.

2.5 Постусловия

Постусловие указывает, что является истинным после завершения сценария использования.

Примеры:

• Заказ зафиксирован.

• Оплата авторизована.

• Отправляется подтверждающее электронное письмо.

• Заявка на возмещение расходов имеет статус «подана».

• Учётная запись пользователя помечена как активная.

Постусловия должны описывать результаты, а не детали реализации.

Плохое постусловие:

Таблица заказов обновляется.

Лучшее постусловие:

Заказ сохраняется и доступен для выполнения.

2.6 Основной сценарий успеха

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

Каждый шаг должен описывать:

1. Взаимодействие между актором и системой

2. Ответ системы

3. Значимое бизнес-действие

Пример:

1. Клиент выбирает товары.

2. Система отображает текущую корзину.

3. Клиент вводит информацию о доставке.

4. Система проверяет информацию о доставке.

5. Клиент отправляет заказ.

6. Система запрашивает авторизацию платежа.

7. Платёжный шлюз авторизует платёж.

8. Система фиксирует заказ.

9. Система отображает подтверждение заказа.

Избегайте деталей, специфичных для интерфейса, если они не являются существенными для требования.

Плохой шаг:

Клиент нажимает на синюю кнопку в правом нижнем углу.

Лучший шаг:

Клиент оформляет заказ.

2.7 Альтернативные сценарии

Альтернативный сценарий описывает допустимое отклонение от основного сценария.

Примеры:

• Клиент выбирает самовывоз из магазина вместо доставки.

• Клиент оплачивает с помощью сохранённого способа оплаты.

• Администратор утверждает претензию с условиями.

• Пользователь проходит аутентификацию с помощью одноразового кода.

Альтернативные сценарии могут снова присоединиться к основному сценарию.

Пример:

A1. Клиент использует сохранённый способ оплаты
На шаге 6 клиент выбирает сохранённый способ оплаты. Система запрашивает авторизацию с использованием этого способа, а затем продолжает работу на шаге 7.

2.8 Исключительные сценарии

Исключительный сценарий описывает неудачное или аномальное условие.

Примеры:

• Оплата отклонена.

• Товар отсутствует на складе.

• Аутентификация не удалась.

• Внешний сервис недоступен.

• Требуемые данные недействительны.

Исключительный сценарий должен объяснять:

• Где возникает проблема

• Что делает система

• Что видит участник

• Завершается ли сценарий использования или возобновляется

Пример:

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

2.9 Отношения «включать» и «расширять»

включать»

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

Пример:

• Оформление заказа включает «Расчёт общей суммы»

• Оформление заказа включает «Аутентификация клиента»

• Снятие наличных включает «Проверка PIN-кода»

Включаемое поведение является обязательным.

Оформление заказа <<включает>> Расчёт общей суммы

расширять»

Используйте «расширять», когда дополнительное или условное поведение дополняет базовый сценарий использования.

Пример:

• Оформление заказа может быть расширено с помощью «Применение кода скидки»

• Оформление заказа может быть расширено с помощью «Добавление подарочного сообщения»

Расширяющее поведение выполняется не всегда.

Применение кода скидки <<расширяет>> Оформление заказа

Полезное правило:

• Включать: «Это всегда происходит в рамках сценария использования.»

• Расширять: «Это может происходить при определённых условиях.»

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

2.10 Обобщение

Обобщение представляет наследование между акторами или сценариями использования.

Пример:

• Сотрудник — это общий актор.

• Менеджер — это специализированный актор, который наследует поведение сотрудника.

Менеджер --|> Сотрудник

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

3. Стандартный шаблон описания сценария использования

Следующий шаблон хорошо подходит для документов с требованиями, спецификаций проектов и моделей анализа.

Идентификатор сценария использования:
Название сценария использования:
Цель:
Границы:
Уровень:
Основной актор:
Вспомогательные акторы:
Заинтересованные стороны и интересы:

Триггер:

Предусловия:

Минимальные гарантии:

Гарантии успеха:

Основной сценарий успеха:
1.
2.
3.

Альтернативные потоки:
A1.
A2.

Исключительные потоки:
E1.
E2.

Специальные требования:
- Производительность
- Безопасность
- Удобство использования
- Доступность
- Соответствие

Бизнес-правила:

Требования к данным:

Частота и объём:

Предположения:

Открытые вопросы:

Связанные сценарии использования:

Пояснение к полям

4. Пример: Размещение заказа

UC-001 — Размещение заказа

Цель:
Позволить клиенту приобрести один или несколько товаров.

Область:
Интернет-магазин

Уровень:
Цель пользователя

Основной исполнитель:
Клиент

Вспомогательные исполнители:

• Платёжный шлюз

• Сервис учёта запасов

• Служба электронной почты

• Служба доставки

Заинтересованные стороны и их интересы:

• Клиент: Хочет успешно приобрести товары и получить подтверждение.

• Магазин: Хочет зафиксировать действительный заказ и получить оплату.

• Склад: Нуждается в точной информации о выполнении заказа.

• Платёжный шлюз: Нуждается в действительном запросе на оплату.

• Служба доставки: Нуждается в полном адресе доставки.

Триггер:
Клиент передаёт корзину покупок для оформления заказа.

Предусловия:

• Клиент имеет хотя бы один товар в корзине.

• Товары доступны для заказа.

• Клиент предоставляет действительный адрес доставки.

• Система способна взаимодействовать с платёжным сервисом.

Минимальные гарантии:

• Ни один неоплаченный заказ не считается подтверждённым.

• Клиент уведомляется, если заказ не может быть завершён.

• Зарезервированные запасы освобождаются, если оплата не прошла.

Гарантии успеха:

• Оплата авторизована.

• Заказ зарегистрирован.

• Товары зарезервированы на складе.

• Клиент получает подтверждение.

• Информация о выполнении заказа становится доступной для склада.

Основной успешный сценарий

1. Клиент просматривает корзину покупок.

2. Система отображает товары, количества, цены, налоги, стоимость доставки и итоговую сумму.

3. Клиент предоставляет информацию о доставке.

4. Система проверяет корректность информации о доставке.

5. Клиент выбирает способ оплаты.

6. Клиент оформляет заказ.

7. Система проверяет наличие товаров.

8. Система запрашивает авторизацию оплаты у платежного шлюза.

9. Платежный шлюз авторизует оплату.

10. Система создает заказ.

11. Система резервирует заказанные товары.

12. Система отправляет подтверждение заказа клиенту.

13. Система отображает номер заказа и предполагаемую дату доставки.

Альтернативные сценарии

A1. Клиент использует сохраненный адрес

На шаге 3 клиент выбирает ранее сохраненный адрес. Система отображает этот адрес и переходит к шагу 4.

A2. Клиент использует сохраненный способ оплаты

На шаге 5 клиент выбирает сохраненный способ оплаты. Система использует этот способ и переходит к шагу 6.

A3. Клиент выбирает самовывоз из магазина

На шаге 3 клиент выбирает самовывоз из магазина вместо доставки. Система отображает доступные магазины и даты самовывоза, затем переходит к шагу 5.

Сценарии исключений

E1. Товар отсутствует в наличии

На шаге 7 система определяет, что товар отсутствует в наличии. Система идентифицирует отсутствующий товар, обновляет корзину и просит клиента пересмотреть заказ.

E2. Оплата отклонена

На шаге 9 шлюз оплаты отклоняет платеж. Система не подтверждает заказ, освобождает резервы товарных запасов, отображает сообщение об ошибке и позволяет клиенту выбрать другой способ оплаты.

E3. Шлюз оплаты недоступен

На шаге 8 шлюз оплаты не отвечает в течение заданного времени ожидания. Система помечает попытку оплаты как ожидающую, информирует клиента и предотвращает повторную отправку заказа.

Бизнес-правила

• Заказ должен содержать хотя бы один товар.

• Количество товара должно быть больше нуля.

• Товар нельзя заказать, если имеющийся запас недостаточен.

• Оплата должна быть авторизована до подтверждения заказа.

• Цены и налоги рассчитываются на основе действующих правил ценообразования.

• Клиент может отменить заказ только до начала его выполнения.

Специальные требования

• Сводка заказа должна отображаться в течение двух секунд при нормальной нагрузке.

• Информация об оплате не должна храниться в открытом виде.

• Повторные отправки не должны приводить к созданию дубликатов заказов.

• Система должна вести журнал аудита изменений статуса оплаты и заказа.

5. Уровни сценариев использования

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

Сценарий использования на уровне обзора

Сценарий использования на уровне обзора описывает широкий бизнес-процесс.

Пример:

Выполнение заказа клиента

Это может включать:

• Получение заказа

• Подбор товаров

• Упаковка заказа

• Отправка заказа

Сценарий использования на уровне цели пользователя

Обычно это наиболее полезный уровень для анализа требований.

Пример:

Оформить заказ

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

Сценарий использования уровня подфункции

Это описывает более мелкое, повторно используемое поведение системы.

Примеры:

• Рассчитать общую сумму заказа

• Проверить платеж

• Сформировать счет

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

6. Написание качественных описаний сценариев использования

Используйте язык, ориентированный на участника

Пишите с точки зрения участника:

Клиент оформляет заказ.

Избегайте формулировок, ориентированных на реализацию:

OrderController вызывает сервис заказов.

Последнее относится к проектной документации, а не к бизнес-сценарию использования.

Делайте каждый шаг атомарным

Избегайте объединения слишком многих действий:

Клиент вводит данные, выбирает способ оплаты, подтверждает заказ и получает электронное письмо.

Улучшите это, разделив взаимодействие:

1. Клиент вводит информацию о доставке.

2. Система проверяет информацию.

3. Клиент выбирает способ оплаты.

4. Клиент подтверждает заказ.

5. Система отправляет подтверждение.

Описывайте наблюдаемое поведение

Читатель должен иметь возможность определить, было ли требование реализовано.

Слабое:

Система обрабатывает запрос.

Более сильное:

Система проверяет запрос, регистрирует претензию, присваивает ей номер претензии и отображает статус подачи.

Избегайте преждевременного проектирования пользовательского интерфейса

Используйте:

Клиент предоставляет информацию о доставке.

Вместо этого:

Клиент вводит адрес в текстовое поле и нажимает зелёную кнопку «Продолжить».

Вторая версия неоправданно ограничивает интерфейс.

Основной сценарий должен быть успешным

Не заполняйте основной сценарий всеми возможными ошибками. Размещайте ошибки в сценариях исключений.

Выделяйте бизнес-правила отдельно

Бизнес-правила часто применяются к нескольким сценариям использования. Их раздельное хранение предотвращает повторение и несогласованность текста.

Делайте поведение при сбое явным

Для каждого важного сбоя укажите:

• Сохраняются ли данные

• Откатывается ли транзакция

• Может ли исполнитель повторить действие

• Уведомляется ли администратор

• Завершается ли сценарий использования или возобновляется

7. От требований к сценариям использования

Практичный рабочий процесс выглядит так:

1. Определите систему, которую моделируют.

2. Перечислите внешних исполнителей.

3. Уточните, чего каждый исполнитель хочет достичь.

4. Преобразуйте каждую цель в название сценария использования.

5. Определите границы системы.

6. Опишите основной успешный сценарий.

7. Добавьте альтернативные и исключительные сценарии.

8. Добавьте бизнес-правила и специальные требования.

9. Постройте диаграмму сценариев использования.

10. Обсудите модель с заинтересованными сторонами.

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

Анализ «актор-цель»

Полезный вопрос:

Какой бизнес-результат этот актор должен получить от системы?

8. Нотация диаграммы сценариев использования

Наиболее распространённые элементы:

• Актор: Внешняя роль

• Сценарий использования:Способность системы или цель актора

• Границы системы:Область системы

• Связь:Актор участвует в сценарии использования

• Включает:Обязательное переиспользуемое поведение

• Расширяет:Опциональное или условное поведение

• Обобщение:Специализированный актор или сценарий использования

Диаграмма сценариев использования не должна пытаться отображать:

• Каждый шаг рабочего процесса

• Таблицы базы данных

• Атрибуты классов

• Детальные бизнес-правила

• Макеты экранов

• Внутренние алгоритмы

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

9. Пример диаграммы PlantUML

Следующий пример моделирует Оформление заказа сценарий использования и связанное поведение.

@startuml
left to right direction

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Customer
actor "Payment Gateway" as Payment
actor "Inventory Service" as Inventory
actor "Email Service" as Email
actor "Delivery Service" as Delivery

rectangle "Online Store" {
    usecase "Browse Products" as Browse
    usecase "Manage Cart" as Cart
    usecase "Place Order" as PlaceOrder
    usecase "Calculate Order Total" as CalculateTotal
    usecase "Check Product Availability" as CheckStock
    usecase "Authorize Payment" as AuthorizePayment
    usecase "Reserve Inventory" as ReserveInventory
    usecase "Send Order Confirmation" as SendConfirmation
    usecase "Track Order" as TrackOrder
    usecase "Apply Discount Code" as ApplyDiscount
}

Customer --> Browse
Customer --> Cart
Customer --> PlaceOrder
Customer --> TrackOrder

Payment --> AuthorizePayment
Inventory --> CheckStock
Inventory --> ReserveInventory
Email --> SendConfirmation
Delivery --> TrackOrder

PlaceOrder ..> CalculateTotal : <<include>>
PlaceOrder ..> CheckStock : <<include>>
PlaceOrder ..> AuthorizePayment : <<include>>
PlaceOrder ..> ReserveInventory : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> PlaceOrder : <<extend>>

@enduml

Интерпретация

• «Клиент инициирует Оформить заказ.

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

• Применить код скидки является необязательным, поэтому он расширяет Оформить заказ.

• Внешние сервисы участвуют в определённом поведении системы.

• Граница системы — это Интернет-магазин прямоугольник.

Точное расположение элементов контролируется движком рендеринга. Важнейшие решения при моделировании касаются акторов, сценариев использования, границ и связей.

10. Создание диаграммы в Visual Paradigm VPasCode

VPasCode — это основанная на браузере платформа для преобразования текста в диаграммы, поддерживающая PlantUML, Mermaid, Graphviz и другие форматы диаграмм. Она обеспечивает редактирование исходного кода и живое отображение, позволяя диаграмме обновляться по мере изменения кода.

Базовый рабочий процесс

1. Откройте редактор VPasCode.

2. Создайте новую диаграмму PlantUML.

3. Вставьте исходный код PlantUML.

4. Убедитесь, что редактор распознаёт синтаксис PlantUML.

5. Просмотрите предпросмотр в реальном времени.

6. Отредактируйте акторов, сценарии использования, связи и стили в панели исходного кода.

7. Экспортируйте или скопируйте отрендеренную диаграмму.

8. Добавьте диаграмму в документацию проекта.

VPasCode поддерживает диаграммы сценариев использования PlantUML и обеспечивает рендеринг в реальном времени в браузере. Также он предоставляет примеры и варианты стилизации для диаграмм PlantUML.

Пример запроса для генерации с помощью ИИ

Если используется функция генерации диаграмм с помощью ИИ, полезный запрос будет следующим:

Создайте диаграмму сценариев использования PlantUML для интернет-магазина.

Основной актор:
- Клиент

Вспомогательные акторы:
- Платёжный шлюз
- Сервис инвентаризации
- Сервис электронной почты
- Сервис доставки

Основные сценарии использования:
- Просмотр товаров
- Управление корзиной
- Оформление заказа
- Отслеживание заказа

Оформление заказа должно включать:
- Расчёт общей суммы заказа
- Проверка наличия товара
- Авторизация платежа
- Резервирование на складе
- Отправка подтверждения заказа

Применение кода скидки должно расширять оформление заказа.

Используйте границу системы под названием «Интернет-магазин».

Рассматривайте сгенерированный код как отправную точку. Проверьте, соответствует ли он:

• Акторы действительно являются внешними

• Сценарии использования отражают цели пользователей

• включать и расширятьиспользуются корректно

• Границы системы определены точно

• Связи отражают реальное бизнес-поведение

VPasCode также поддерживает переключение между редактированием диаграмм на основе текста и графическими инструментами моделирования Visual Paradigm, что может быть полезно, когда команды хотят использовать редактирование на основе исходного кода для версионирования и визуальное редактирование для уточнения макета.

11. Поддержка диаграмм сценариев использования PlantUML

Используйте осмысленные псевдонимы

Псевдонимы упрощают поддержку связей:

usecase "Оформить заказ" as PlaceOrder
Customer --> PlaceOrder

Добавьте комментарии

' Основная транзакция клиента
usecase "Оформить заказ" as PlaceOrder

Комментарии помогают другим членам команды понять исходный код и поддерживать диаграмму.

Держите диаграмму сфокусированной

Если диаграмма содержит слишком много сценариев использования:

• Создайте контекстную диаграмму

• Создавайте отдельные диаграммы по областям бизнеса

• Используйте группировку по пакетам

• Связывайте связанные диаграммы через документацию

• Избегайте отображения каждой подфункции на самом высоком уровне

Используйте согласованную систему именования

Выберите одно соглашение и применяйте его последовательно:

• Оформить заказ

• Отменить заказ

• Отследить заказ

Избегайте смешения стилей, таких как:

• Оформить заказ

• OrderCancellation

• tracking_function

Хранить исходный код вместе с проектом

Типичная структура репозитория может выглядеть так:

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

Хранение .puml исходного кода под контролем версий делает изменения доступными для проверки и воспроизводимыми.

12. Отслеживаемость

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

Прослеживаемость помогает ответить на вопросы:

• Какие требования охвачены?

• Какие сценарии использования не были протестированы?

• Какие компоненты дизайна поддерживают бизнес-цель?

• Что будет затронуто, если требование изменится?

13. Распространённые ошибки

Моделирование внутренних компонентов как акторов

База данных или внутренний сервис обычно не являются акторами, если они находятся внутри границ системы.

Актор должен находиться за пределами моделируемой системы.

Рассмотрение экранов как сценариев использования

Экран — это элемент пользовательского интерфейса, а не обязательно цель пользователя.

Используйте:

Предоставление отчёта о расходах

Вместо:

Экран отчёта о расходах

Использование «include» для каждого общего шага

Само по себе совпадение формулировок не оправдывает использование включённого сценария. Используйте «include» только когда поведение является обязательным и имеет самостоятельное значение.

Использование «extend» для обычных шагов

Если поведение всегда происходит, его не следует моделировать как расширение.

Описание деталей реализации

Избегайте ссылок на:

• Контроллеры

• Таблицы базы данных

• Конечные точки API

• Классы

• Внутренние методы

если только документ не является специально техническим проектом.

Пропуск поведения при сбоях

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

Слишком широкий охват сценариев использования

«Управление всем бизнесом» не является конкретным действием. Разбейте широкие цели на сценарии использования на уровне целей пользователя.

Слишком узкий охват сценариев использования

«Проверить поле» и «Отобразить сообщение» обычно являются шагами системы, а не независимыми целями актора.

14. Контрольный список для проверки

Перед утверждением описания сценария использования проверьте:

Область действия и акторы

• Четко ли определена граница системы?

• Все ли внешние акторы идентифицированы?

• Являются ли акторы ролями, а не именами конкретных лиц?

• Моделируются ли вспомогательные системы только в том случае, если они являются внешними?

Качество цели

• Предоставляет ли сценарий использования ценность для основного актора?

• Является ли название четкой фразой «глагол–существительное»?

• Находится ли сценарий использования на соответствующем уровне детализации?

Качество потока

• Описывает ли основной сценарий успешный исход?

• Является ли каждый шаг атомарным и наблюдаемым?

• Документированы ли альтернативные пути?

• Документированы ли пути обработки исключений?

• Четко ли определено поведение при восстановлении?

Условия и результаты

• Являются ли предварительные условия проверяемыми?

• Являются ли гарантии успеха явными?

• Определены ли минимальные гарантии?

• Отделены ли бизнес-правила от процедурных шагов?

Качество диаграммы

• Находятся ли все случаи использования внутри правильной границы?

• Являются ли ассоциации акторов осмысленными?

• Являются ли “включение" отношения обязательными?

• Являются ли “расширение" отношения необязательными или условными?

• Читаема ли диаграмма без избыточной детализации?

Качество требований

• Можно ли протестировать каждый важный шаг?

• Включены ли нефункциональные требования?

• Зафиксированы ли нерешенные вопросы?

• Связан ли случай использования с требованиями и тестовыми случаями?

15. Рекомендуемая структура поставляемых материалов

Для полного пакета проекта используйте следующую структуру:

1. Контекст системы
2. Каталог акторов
3. Диаграмма случаев использования
4. Каталог случаев использования
5. Подробные описания случаев использования
6. Бизнес-правила
7. Нефункциональные требования
8. Матрица трассируемости
9. Открытые вопросы и допущения
10. Исходные файлы PlantUML

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

Ссылка

Эта статья также доступна на Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, Polski and Portuguese