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
Ниже представлен пример плохого варианта использования и указаны допущенные ошибки
В данном use case допущены следующие ошибки:
- Отсутствуют акторы, которые участвуют в процессе оформления заказа на доставку еды, такие как ресторан.
- Отсутствуют альтернативные потоки событий, которые могут возникнуть при оформлении заказа. Например, если блюда из меню недоступны, если заказ не может быть выполнен и т.д.
- Описание Use Case слишком краткое и не содержит достаточной информации для полного понимания процесса.
- Отсутствуют расширенные атрибуты, такие как возможность отслеживания статуса заказа и возможность оставить отзыв о доставке.
- Не корректно составлена UML Use Case диаграмма.
Пример хорошего Use Case
Исправив ошибки мы получили хорошо составленный вариант использования, который можно использовать в работе.
Как понять что найдены все альтернативные сценарии?
Вы рассмотрели все возможные сценарии использования системы, которые могут возникнуть в разных условиях.
Вы учли все возможные ошибки и исключительные ситуации, которые могут произойти во время использования системы.
Вы обратили внимание на все возможные изменения, которые могут произойти в системе или внешних факторах и привести к изменению сценария использования.
Вы описали все возможные варианты поведения пользователей при использовании системы и предусмотрели соответствующие реакции системы на эти действия.
Вы провели анализ Use Case диаграммы и убедились, что она покрывает все основные сценарии использования системы и все возможные альтернативные потоки событий.
Если вы уверены, что учли все возможные альтернативные потоки событий и проверили диаграмму на полноту, то можно считать, что найдены все альтернативные потоки событий.
Однако, если у вас есть сомнения, то вы можете провести review. Попросите коллег или друзей посмотреть на ваш вариант использования и предложить свой взгляд на альтернативы. Также можно провести тестирование функционала на реальных пользователях и собрать обратную связь от них. Это может привести к выявлению новых возможных альтернативных сценариев.