Продолжаем погружаться в мир анализа требований с использованием техник Use Case. Мы подробно рассмотрели концепцию вариантов использования и поняли, какую важную роль они играют в создании качественного ПО. Теперь перейдем к практике — познакомимся с разными форматами их описания.   ✅ Форматы описания    Варианты использования можно представить двумя основными способами:

• Графический формат (Use Case Diagram, диаграмма вариантов использования в нотации UML).
• Табличный формат — детально структурированное представление последовательности действий.    Мы сосредоточимся на втором подходе, так как он лучше раскрывает всю глубину взаимодействия актора и системы.    🔍 Структура полной табличной формы    Давайте посмотрим, из каких элементов состоит полная таблица варианта использования:    ❗(см. картинку к посту)    👉 Рассмотрим каждый элемент отдельно:
• Вариант использования: Название функции, которую хочет выполнить пользователь. Например, «зарегистрироваться на сайте».
• Контекст использования: Зачем нужен этот вариант использования. Например, приобретение услуг отеля.
• Область действия: Где реализуется сценарий. Например, веб-сайт или мобильное приложение.
• Уровень. В этом блоке указывается одно из следующих значений уровня:  • Обобщённый — если вариант использования покрывает несколько целей актора или подходит разным акторам. Например, управление проектом, управление личными финансами и так далее;  • Цели пользователя — если вариант использования покрывает одну цель актора. Например, зарегистрироваться на сайте, оплатить заказ и прочие атомарные функции;  • Подфункции — если вариант использования покрывает цель, которая в дальнейшем необходима для достижения цели актора. Такой уровень редко используется, это скорее техническая задача, где нет непосредственного участия пользователя. Примером такого варианта использования может быть: «Найти изделие», «Сохранить в файле» и так далее.
• Основное действующее лицо: Лицо, инициирующее сценарий. Например, гость отеля.
• Участники: Дополнительные объекты, вовлечённые в процесс. Например, сам сайт.
• Предусловия: Необходимые условия для запуска сценария. Например, пользователь находится на странице регистрации.
• Минимальные гарантии успеха: Результат в случае неполучения желаемого исхода. Например, сохранение введенных данных.
• Гарантии успеха: Итог успешного выполнения сценария. Например, авторизация в личном кабинете.
• Триггер: Событие, запускающее сценарий. Например, нажатие кнопки «регистрация».
• Описание: Последовательность шагов основного сценария.
• Расширения: Возможные отклонения от основного сценария.
• Изменения технологий и данных: Новые технологии, применяемые в сценарии. Например, биометрия.    ❗️ Важно учитывать как основные, так и альтернативные сценарии, чтобы избежать неприятных сюрпризов при эксплуатации системы.    Таким образом, владение техникой Use Case значительно повышает качество разрабатываемого продукта и снижает риск возникновения ошибок в ходе проекта. Используйте этот инструмент грамотно, и ваши проекты станут ещё ближе к совершенству! ✨ P.s. Загляните в комментарии 👇