Use Case: что это такое и как писать

Use Case: что это такое и как писать

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

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

Значение Use Case в разработке продукта

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

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

Еще одним важным преимуществом использования Use Case является то, что это позволяет разработчикам лучше понимать, каким образом пользователи будут использовать продукт в реальной жизни. Это позволяет создать удобный и интуитивно понятный интерфейс, который будет соответствовать потребностям и ожиданиям пользователей.

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

В целом, использование Use Case является необходимым для разработки продукта, который будет соответствовать потребностям и ожиданиям пользователей, а также будет функциональным и удобным в использовании.

Что должен включать в себя хороший Use Case?

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

Хороший Use Case должен включать в себя следующие элементы:

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

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

Цель. Описание того зачем нужен этот use case

Краткое описание. Краткое описание того, что происходит в данном сценарии.

Предусловия. Описание условий, необходимых для начала работы системы в рамках данного Use Case. Это могут быть какие-то исходные данные, которые должны быть подготовлены до начала работы системы.

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

Альтернативные потоки событий. Опишите возможные варианты развития событий, которые могут произойти в рамках Use Case, если определенные условия не будут выполнены или произойдут какие-то непредвиденные события..

Постусловия (Результат). Опишите возможные варианты развития событий, которые могут произойти в рамках Use Case, если определенные условия не будут выполнены или произойдут какие-то непредвиденные события.

Расширенные атрибуты. Опишите дополнительные сведения о сценарии использования, такие как исключения, дополнительные условия, требования к безопасности и т. д.

UML Use Case диаграмма. Графическое представление сценария использования, которое показывает акторов, основной поток событий и альтернативные потоки.

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

Как построить идеальную Use Case диаграмму в целом, я уже писал, если вы всё делали по инструкциям, написанным в этом блоге, то у вас не должно возникнуть с этим трудностей.

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

Use Case пример

Пример плохого Use Case

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

Заголовок Оформление заказа на доставку еды.
Акторы Заказчик.
Описание Заказчик использует мобильное приложение для оформления заказа на доставку еды.
Предусловия Заказчик установил приложение и зарегистрировался в нем.
Основной поток событий Заказчик открывает мобильное приложение.
Заказчик выбирает блюда из меню и добавляет их в корзину.
Заказчик выбирает адрес доставки и указывает способ оплаты.
Приложение отправляет заказ на сервер.
Альтернативные потоки событий Нет альтернативных потоков событий.
Постусловия Заказ оформлен.
Расширенные атрибуты Отсутствуют.
UML Use Case диаграмма Не правильно составленная use case диаграмма

В данном use case допущены следующие ошибки:

  1. Отсутствуют акторы, которые участвуют в процессе оформления заказа на доставку еды, такие как ресторан.
  2. Отсутствуют альтернативные потоки событий, которые могут возникнуть при оформлении заказа. Например, если блюда из меню недоступны, если заказ не может быть выполнен и т.д.
  3. Описание Use Case слишком краткое и не содержит достаточной информации для полного понимания процесса.
  4. Отсутствуют расширенные атрибуты, такие как возможность отслеживания статуса заказа и возможность оставить отзыв о доставке.
  5. Не корректно составлена UML Use Case диаграмма.

Пример хорошего Use Case

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

Заголовок Оформление заказа на доставку еды через мобильное приложение.
Акторы Заказчик, Ресторан.
Цель. Оформить заказ
Описание В данном сценарии заказчик использует мобильное приложение для оформления заказа на доставку еды из ресторана.
Предусловия Заказчик установил приложение и зарегистрировался в нем. Ресторан подключен к приложению.
Основной поток событий Заказчик открывает мобильное приложение и выбирает ресторан.
Заказчик выбирает блюда из меню и добавляет их в корзину.
Заказчик выбирает адрес доставки.
Приложение отправляет заказ в ресторан.
Ресторан получает заказ и подтверждает его.
Приложение уведомляет заказчика о подтверждении заказа
Приложение списывает стоимость заказа со счета клиента.
Альтернативные потоки событий Если ресторан не подтверждает заказ в течение 10 минут, приложение уведомляет заказчика о задержке.
Ресторан может отменить заказ, если блюда не доступны или закончились.
Постусловия Клиент оформил заказ.

Ресторан получил оплату за заказ.

Расширенные атрибуты Заказчик может отслеживать статус заказа в приложении.
Заказчик может оставить комментарий к заказу и поставить рейтинг ресторану.
UML Use Case диаграмма Приме диаграммы прецедентов "Оформление заказа на доставку еды"
Рекомендации по реализации Разработать удобный интерфейс для выбора блюд и оформления заказа.
Организовать быстрое подтверждение заказов ресторанами.

Как понять что найдены все альтернативные сценарии?

При построении альтернативных потоков событий в диаграмме вариантов использования, вы можете считать, что вы нашли все возможные варианты взаимодействия системы и пользователей, когда:

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

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

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

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

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

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

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

Техноблог
Добавить комментарий