Оглавление
- Почему я пишу об этом
- Что такое Use Case
- Когда и зачем описывать Use Case
- Классическая структура Use Case
- Как адаптировать Use Case под проект
- Пример Use Case из жизни
Всем привет! На этом канале я делюсь опытом системного аналитика, пишу, чтобы лучше структурировать знания и не забывать важные вещи, которые часто всплывают на собеседованиях или в рабочих обсуждениях.
Сегодня разберём тему, с которой я сталкивался и на аттестации, и на интервью — Use Case. Казалось бы, ничего сложного, но как только начинаешь объяснять, что это, зачем и как писать, оказывается, что в голове каша. В этой статье соберу всё, что считаю важным.
Почему я пишу об этом
Собеседования системного аналитика часто превращаются в экзамен. Неважно, чем ты занимаешься на текущем проекте, — тебя могут спросить про нотации, виды требований, паттерны, диаграммы. А если повезёт, ещё и попросят написать Use Case по сценарию «из головы».
Эта статья — часть моей подготовки: я не просто читаю теорию, но стараюсь переработать её через собственный опыт и язык. Заодно надеюсь, что это поможет кому-то ещё — тем, кто сейчас ищет работу или хочет навести порядок в голове.
Что такое Use Case
Use Case (вариант использования, юзкейс) — это сценарий взаимодействия пользователя или системы с продуктом, приводящий к достижению конкретной цели.
Если говорить проще, это подробное текстовое описание того, кто, как и зачем использует систему, шаг за шагом.
📚 Автор методологии — Ивар Якобсон. Он представил идею ещё в 80-х и позже подробно описал её в книге Object-Oriented Software Engineering: A Use-Case Driven Approach.
Вот как можно переформулировать определение по-человечески:
Юзкейс — это история о том, как кто-то (пользователь или система) делает что-то с системой, чтобы получить для себя понятный результат.
Когда и зачем описывать Use Case
Use Case помогает:
- понять, что именно нужно реализовать;
- посмотреть на задачу глазами пользователя;
- договориться о функциональности с заказчиком;
- донести идею до разработчиков, тестировщиков и всех участников проекта;
- не забыть важные ветки сценария — что делать, если «что-то пошло не так».
📌 Когда использовать:
- на этапе сбора требований — помогает понять процесс;
- при проектировании — помогает разложить функциональность;
- при постановке задач — особенно если нужна «сквозная» логика;
- при тестировании — юзкейсы можно использовать как базу для тестов;
- при приемке — если заказчик проходит по сценариям, чтобы убедиться, что всё работает.
Классическая структура Use Case
Сценарий можно оформлять по-разному, но чаще всего используется такая структура:
- Название — отражает суть (например: «Создание заявки»).
- Акторы (участники) — кто участвует: человек или система.
- Предусловия — что должно быть до начала сценария.
- Триггер — что запускает сценарий.
- Основной сценарий — пошаговое описание «хеппи-паса».
- Результат — что должно получиться в конце.
- Альтернативные сценарии — ветки, если что-то пошло не так.
👉 На практике всё это можно адаптировать: кто-то убирает триггер, кто-то пишет шаги в виде таблицы, кто-то добавляет post-condition. Главное — чтобы было понятно.
Как адаптировать Use Case под проект
Use Case — это не про канцелярит. Это инструмент. И его формат можно (и нужно!) подгонять под задачу:
- Если сценарий длинный — разбивай на под-сценарии.
- Если система сложная — добавь в начало контекст или диаграмму.
- Если много акторов — отдельно выноси их список, так проще искать нужный кейс.
- Если пишешь под тестировщиков — добавляй ID шагов и связи с тест-кейсами.
🔧 Главное — чтобы Use Case работал, а не просто был для галочки.
Пример Use Case из жизни
Контекст:
В проекте появился запрос: реализовать виджет подписки на рассылку. Пользователь вводит e-mail и подписывается на рассылки от нескольких компаний. Список компаний регулярно меняется. Возникла проблема — пользователи жалуются, что их данные переданы «не туда».
Решение:
Добавить версионирование списков компаний и сохранять, на какую версию согласился пользователь.
UC-1: Подписка пользователя на рассылку
Акторы:
Пользователь, Виджет (frontend), Сервер (backend)
Предусловие:
Пользователь находится на странице с виджетом. На фронте отображена актуальная версия списка компаний.
Триггер:
Пользователь нажимает кнопку «Подписаться».
Основной сценарий:
- Фронт отправляет e-mail и номер версии файла на бэкенд.
- Бэкенд сохраняет e-mail (в зашифрованном виде) и версию.
- Бэкенд возвращает успешный ответ.
- Фронт отображает сообщение: «Вы успешно подписались».
Результат:
Подписка сохранена, зафиксирована версия списка компаний. Пользователь проинформирован.
Если упростить — Use Case — это способ рассказать историю взаимодействия с системой понятным языком, чтобы все в команде и за её пределами поняли, что мы собираемся делать и почему.
Если тебе интересно — подписывайся, комментируй, делись опытом!