# Use case
{% hint style="info" %}
**Use case** представляет собой детальное описание взаимодействия между актерами (пользователями) и системой. Он описывает конкретную ситуацию, в которой актер взаимодействует с системой для достижения определенной цели.
{% endhint %}
Use case включает шаги, актеров, предусловия, основные действия и ожидаемые результаты. Use case помогает понять, как система будет использоваться и как она должна взаимодействовать с пользователями.
## Алгоритм описания Use case (UC)
Типовую последовательность разработки функциональных требований в форме UC можно представить следующим образом:
1. Определить **Акторов** — тех, кто взаимодействует с системой
2. Выявить и составить **список** UC — задач, которые стейкхолдеры смогут решить с помощью системы
3. Для каждого юскейса определить **приоритет** — важность UC по отношению к другим вариантам использования
4. Для каждого важного юскейса определить **контекст** применения, конечную **цель и результат**
5. Описать **основной поток** каждого UC с высоким приоритетом в виде последовательности шагов, которая приведёт к достижению его цели — пользовательского сценария (use case scenario)
6. Дополнить основной поток **расширениями**, **исключениями и циклами**
7. Собрать **воедино** результаты шагов 4−6, детально описав каждый юскейс с высоким приоритетом как алгоритм взаимодействия пользователя с системой
Теперь давайте рассмотрим каждый шаг поподробнее.
### Шаг 1. Определить **Акторов**
Актором может быть несколько разных пользовательских ролей и/или внешние сервисы, которые будут интегрироваться с проектируемой системой, то есть получать из неё данные или вносить их в неё.
Например, если рассматривать мобильный телефон как систему, то актором будет человек — пользователь мобильного телефона. Результат этого шага можно оформить в виде таблицы или диаграммы ролей.
### Шаг 2. Составить список UC
Мы советуем делать это в виде **реестра юскейсов** — единой таблицы, показывающей распределение юскейсов по акторам.\
\
Рекомендуем называть UC в формате «Инфинитив + Объект», где «Инфинитив» — это инфинитив глагол в совершенного вида с большой буквы, а «Объект» — это существительное, обозначающее объект управления с большой буквы.\
\
Из названия варианта использования должно быть сразу понятно, какую именно задачу пользователя он решает. Например, «Подписать Документ», «Оформить Заказ», «Оплатить Товар», «Сделать Звонок» и так далее. Для повышения наглядности можно сделать это в табличном виде или UML-диаграммы вариантов использования (она же Use case diagram, диаграмма прецедентов).
### Шаг 3. Определить приоритет
Реализация юскейсов в коде — трудоёмкая работа, поэтому надо понимать, с каких лучше начать в первую очередь, а до каких очередь может не дойти никогда.\
\
Реестр юскейсов может использоваться для приоритизации пользовательских функциональных требований с целью их ранжирования по степени важности, которая определяет порядок реализации.\
\
Самым простым методом приоритизации, который часто применяется на практике, считается метод MoSCoW.
MoSCoW
* ***Must*** — то, что необходимо сделать в любом случае. Считается, что без реализации этих требований решение не будет работать или при отсутствии этих фич продукт не будет нужен потребителям. Чаще всего этот приоритет называется 1-я очередь и обозначается цифрой 1
* ***Should*** — требования 2-ой очереди, которые должны быть реализованы после тех, что отнесены к группе Must. Это приоритет номер 2
* ***Could*** — желательные требования, которые можно сделать, если останется время и будут ресурсы. Это приоритет номер 3
* ***Would*** — требования, которые хотелось бы реализовать, но пока их можно проигнорировать или перенести на следующие итерации без вреда для продукта. Это приоритет номер 4
### Шаг 4. Определить контекст/цель/результат для Must have
Контекст = описание проблематики
Цель = итог Use Case
Результат = постусловия
### Шаг 5. Описать основной поток для Must have
**Пользовательский сценарий** — это последовательность шагов, которая приведёт к достижению конечной цели юскейса, получению нужного актору результата.
Основную часть пользовательского сценария составляет так называемый **happy path (основной поток)**, который представляет собой пошаговый алгоритм выполнения сценария без логических операторов XOR (исключающее или), используемых для ветвления потока управления в результате проверки каких-либо условий.
### Шаг 6. Дополнить основной поток **расширениями**, **исключениями и циклами**
На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.
### Шаг 7. **Собрать воедино результаты выполнения трёх предыдущих шагов, детально описав каждый UC как алгоритм взаимодействия пользователя с системой**
На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:
* Имя
* Приоритет
* Область действия
* Контекст
* Актор
* Цель
* Предусловия
* Результат (постусловие)
* Основной поток
* Расширения или альтернативные потоки
* Бизнес-правила
## Преимущества UC
* Нисходящая и восходящая трассировка (от системного уровня к бизнесу) улучшает понятность требований для Заказчика и команды реализации: UC несёт конечную бизнес-ценность, детально описывает структуры данных и бизнес-логику их обработки, позволяет убедиться в реализации
* Вариант использования можно использовать как единицу поставки при планировании, реализации, тестировании и приёмке работ
* Набор связанных друг с другом вариантов использования позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей
* Детальный шаблон представления UC позволяет полностью описать взаимодействие актора с системой, включая контекст, предшествующие, сопутствующие и результирующие события, а также ссылки к бизнес-правилам и нефункциональным требованиям (ограничения и некоторые атрибуты качества)
* UC — отличная база для формирования тестовых сценариев (test cases) для проверки того, работает ли реализованная система как ожидалось
## Недостатки UC
* Плохо подходят для документирования требований, основанных не на взаимодействии с системой, а на выполнении расчётов и преобразованиях уже имеющихся в системе данных. Например, построение графиков и отчётов, вычисления, описание математических алгоритмов
* Субъективность: качество изложения как самого UC, так и их реестра (ширина, глубина детализации уровней абстракции) зависит от навыков аналитика
* На детальную проработку каждого UC уходит много времени
* Проектирование системы только по UC исключает другие потенциально ценные методики документирования и анализа требований, такие как каноническая форма представления функциональных требований с привязкой с CRUD-операциям или популярная в Agile-проектах форма User Story по INVEST с критериям приёмки (Acceptance Criteria)
Источник: