Школа
системного анализа
и проектирования
системного анализа
и проектирования
Systems Education
Школа системного анализа
и проектирования
Школа системного анализа
и проектирования
Use Cases
Что это такое и зачем они нужны?
Автор:
Анна Абрамова, руководитель Сообщества аналитиков
Санкт-Петербурга
Анна Абрамова, руководитель Сообщества аналитиков
Санкт-Петербурга
Use Case (вариант использования, ВИ, Прецедент, юскейс) — это сценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.
В общем случае, с помощью Use Case может описываться взаимодействие двух или большего количества участников, имеющее конкретную цель:
В общем случае, с помощью Use Case может описываться взаимодействие двух или большего количества участников, имеющее конкретную цель:
- покупка товара в магазине (Покупатель-Продавец),
- отправка письма по электронной почте (Адресант-Почтовый клиент),
- запрос страницы браузером (Браузер-Web-сервер).
В разработке ПО эту технику часто применяют для проектирования и описания взаимодействия пользователя и системы, поэтому название Use Case часто воспринимает как синоним требования человека-пользователя к решению определенной задачи в системе. В статье мы будем рассматривать использование Use Case для описания взаимодействия пользователя с системой.
Воркшоп Миры Карлаш
«Use Case: основы»
Воркшоп будет полезен начинающим системным аналитикам, которые хотят:
- научиться писать Use Cases,
- строить диаграмму сценариев использования,
- формировать пакеты и реестр Use Cases,
- не допускать типичных ошибок
Исторически требования к функционированию системы описывались в виде отдельных функций. Ивар Якобсон в середине 1990-х годов предложил Use Case как альтернативу и дополнение описания функциональности системы. Описание требований к системе не в виде отдельных функций, а в виде описания контекста и последовательности действий пользователя помогает сформировать набор функциональных требований, который будет обеспечивать полноту и неизбыточность требований.
Мы можем сформулировать набор функциональных требований:
FRQ1 Система должна предоставить пользователю возможность ввести код бронирования
FRQ2 Система должна сохранить сведения о регистрации пассажира на рейс
FRQ3 Система должна предоставить пользователю возможность распечатать посадочный талон
FRQ1 Система должна предоставить пользователю возможность ввести код бронирования
FRQ2 Система должна сохранить сведения о регистрации пассажира на рейс
FRQ3 Система должна предоставить пользователю возможность распечатать посадочный талон
Пока это разрозненные требования, мы не можем проверить их набор на полноту и соответствие целям пользователей, так как мы не видим:
1) контекста выполнения этих функций,
2) роли пользователя, которому должна быть доступна функция,
3) целей этого пользователя при использовании системы.
Use Case задаёт формат, в котором все эти важные факторы описываются и учитываются. И перечисленные выше функциональные требования можно объединить в один Use Case, описывающий цель пользователя.
1) контекста выполнения этих функций,
2) роли пользователя, которому должна быть доступна функция,
3) целей этого пользователя при использовании системы.
Use Case задаёт формат, в котором все эти важные факторы описываются и учитываются. И перечисленные выше функциональные требования можно объединить в один Use Case, описывающий цель пользователя.
UC1 Регистрация пассажира на рейс
Пример базовой части 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 для людей, выполняющих разные роли в проекте.
Use Case для руководителя проекта
Сам по себе Use Case — это естественный способ описывать диалог, он понятен человеку без подготовки, Use Case обычно не содержит деталей реализации и пишется на языке целей пользователей. Поэтому Use Case удобно согласовывать с Заказчиком как «единицу поставки»: элемент планирования работы над системой и сдачи проекта.
В отличие от планирования работы и сдачи результатов в виде отдельных функций (сохранять, предоставлять доступ) или элементов архитектуры (платформа, подсистема хранения данных, подсистема обработки данных, подсистема пользовательского интерфейса), согласование работ на основе Use Case гораздо прозрачнее для заказчика. Во-первых, каждый Use Case несет конечную бизнес-ценность, понятную заказчику, во-вторых, даже технически неподкованный заказчик может убедиться в наличии реализации того или иного Use Case в системе, в отличие от наличия отдельных подсистем или функций, никак не отображающихся на пользовательском интерфейсе.
В отличие от планирования работы и сдачи результатов в виде отдельных функций (сохранять, предоставлять доступ) или элементов архитектуры (платформа, подсистема хранения данных, подсистема обработки данных, подсистема пользовательского интерфейса), согласование работ на основе Use Case гораздо прозрачнее для заказчика. Во-первых, каждый Use Case несет конечную бизнес-ценность, понятную заказчику, во-вторых, даже технически неподкованный заказчик может убедиться в наличии реализации того или иного Use Case в системе, в отличие от наличия отдельных подсистем или функций, никак не отображающихся на пользовательском интерфейсе.
То, что набор Use Case состоит из меньшего количества элементов — обычно от 5 до 20, — чем набор отдельных функциональных требований, экономит время на согласование проекта с заказчиком, а то, что заказчику понятна бизнес-ценность каждого Use Case, сильно упростит выставление приоритетов между ними.
Use Case для тестировщика
Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев — test 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 и являются бизнес-правилами. В процессе расстановки приоритетов и выявления критичности тех или других 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 от основоположника техники, Ивара Якобсона: Use Case 2.0 Essentials Practice
Курс Дениса Бескова «Системный анализ.
Разработка требований в ИТ-проектах»
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Разработка требований в ИТ-проектах»
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
