✨ ПЕРЕХОДИМ К ОПИСАНИЮ USE CASE ✨

Варианты использования могут быть представлены:
- в графической форме (например, с помощью Use Case Diagram UML),
- в виде таблицы.

Оформление с помощью нотации UML мы рассмотрим позднее, когда детально углубимся в нотации моделирования 😉

А пока разберём более простой и универсальный способ оформления use case – с помощью таблицы.
В документации к ПО именно этот вариант оформления считается основным, а графический - вспомогательным.

#hardGetAnalyst

Существует два варианта табличного оформления use case: полная табличная форма и свободная табличная форма (упрощённая).

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

🟢 Если проект небольшой и варианты использования — не единственное описание будущих требований к системе (а есть ещё, например, user story, модели процессов, протипы и другие артефакты), можно не использовать полный шаблон записи вариантов использования и обойтись свободным форматом.

Именно его мы и рассмотрим.

⬇️⬇️⬇️

Табличная форма представления фокусируется на детальном рассмотрении последовательности действий, которая описывает взаимодействие актора и системы в рамках одного варианта использования. В ней мы описываем основные и альтернативные сценарии. Но обо всём по порядку

Предлагаем сохранить этот и предыдущий пост в избранное, чтобы шаблон use case был у вас всегда под рукой!


1️⃣ Вариант использования

В этом поле указывается название одного варианта использования, которое вы хотите описать, в формате «глагол + существительное».
Например: «зарегистрироваться на сайте», «создать заявку», «оплатить покупку» и так далее.

Для определения возможных вариантов использования можно руководствоваться следующими способами:
📌Определить действующие лица и бизнес-процессы, в которых они участвуют
В каждом процессе выделить доступную для выполнения функцию — это и будет вариант использования.
📌 Применить CRUD-модель для определения возможных сценариев взаимодействия с данными системы: создания (англ. create), чтения (англ. read), изменения (англ. update) или удаления (англ. delete).


2️⃣ Область действия

Границы системы, в рамках которых выполняется сценарий.
Например, приложение или сайт.


3️⃣ Участники процесса

Участники процесса включают основное действующее лицо и иных участников.
- Основное действующее лицо запускает вариант использования, то есть это и есть актор. Можно записать имя пользователя, должность или роль. Например, пользователь ЛК или администратор.
- В иных участниках указывается перечень дополнительных действующих лиц и их целей в рамках варианта использования. Записывается в формате: [Актор] — [его цель].

Например, сайт, цель которого — сформировать ЛК клиенту. Система-партнёр, которая возвращает информацию об оплате услуги в основную систему.


4️⃣ Предусловие

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


5️⃣ Описание

В этом блоке таблицы описывают основной сценарий в виде пошагового описания действий актора и системы.

Например:
1. Система открывает пользователю форму регистрации
2. Пользователь указывает свои персональные данные в форме
3. Система запускает проверку указанных данных на формат
4. Система создаёт пользователю личный кабинет (ЛК)
5. Система авторизует пользователя в ЛК под его персональными данными.

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


6️⃣ Расширения

В расширениях представлено описание альтернативных сценариев, которые выполняются при ответвлении от основного.

Причин такого ветвления может быть несколько:
- Альтернативные пути к успеху;
- Актор действует некорректно;
- Бездействие актора;
- Некорректные данные;
- Внутренние ошибки системы;
- Критические недостатки в производительности системы.

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


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