Привет! Снова я, Юлия Чугунова. В первых трех частях мы прошли большой путь:
- Слушали заказчика сквозь «у меня что-то не так»,
- Собирали разрозненные мнения фасилитацией,
- Фиксировали требования в BRD, SRS и Backlog.
Теперь наш герой обзавелся «ушами» и «лапами» – пора отрастить когти. В этой части разберем:
- User Story – как упаковать желание в одно предложение, где видно кто, что и зачем,
- Use Case – почему «оформить заказ» это не кнопка, а целая вселенная сценариев,
- Диаграммы – как рисовать Sequence и Activity так, чтобы разработчики сказали «О, теперь ясно!».
Готовы увидеть, как хаос превращается в алгоритмы? Тогда погружаемся в станцию «Сценарии, роли и разговоры между частями системы».
Станция “Сценарии, роли и разговоры между частями системы”
“Use Case помогает договориться о том, что система должна делать – еще до того, как кто-то начнёт её строить,” – по мотивам книги Alistair Cockburn, Writing Effective Use Cases
Мы уже умеем слышать заказчика, формулировать цели и превращать смутное «хочу» в понятные артефакты. Теперь настало время перейти к структуре: сначала – User Story, потом – Use Case, чтобы зафиксировать последовательность взаимодействий.
User Story: коротко, ясно, по делу
User Story – это сжатое желание. Которое отвечает на вопросы: «Кто? Что хочет? Зачем?» Это история от первого лица, в которой сразу видно:
🔹 Кто хочет что-то сделать (роль),
🔹 Что он хочет сделать (действие),
🔹 Зачем ему это (ценность).
Примеры из нашего проекта с джемами:
- Как покупатель, я хочу ввести адрес доставки один раз, чтобы не повторять его при оплате.
- Как покупатель, я хочу видеть сообщение об ошибке при неудачном платеже, чтобы понимать, что делать.
- Как покупатель, я хочу получить email с подтверждением заказа, чтобы быть уверенным, что заказ оформлен.
Чтобы User Story стала рабочей, к ней добавляют:
Пример:
| Элемент | Содержание |
|---|---|
| User Story | Как покупатель, я хочу получить email с подтверждением заказа, чтобы быть уверенным, что он оформлен |
| Acceptance Criteria | • Письмо отправляется после оплаты • Содержит список товаров и адрес доставки • В случае ошибки отображается сообщение |
| Priority | Высокий |
User Story помогает не потеряться в деталях. Она — якорь. А ещё она заставляет задать вопрос: Зачем..? Зачем делаем эту кнопку? Зачем меняем процесс?
Use Case: один путь – много решений
После того как мы нарисовали процесс в виде BPMN-схемы и увидели общую картину, настало время приблизиться: выбрать один маршрут, рассмотреть его как под микроскопом. Для этого есть мощный инструмент – Use Case.
Use Case – это структурированное описание одного конкретного сценария использования системы. Кто действует? Что делает? Что система отвечает? Что может пойти не так?
В нашем проекте с джемами один из ключевых путей – оформление заказа.
Разберемся, из чего это описание состоит:
Use Case: оформление заказа
| Компонент | Содержание |
|---|---|
| Акторы | Покупатель, Приложение, Платёжный сервис, Склад |
| Предусловие | В корзине есть хотя бы один товар. Открыта страница оформления заказа. |
| Основной сценарий | 1. Покупатель нажимает «Оформить заказ»2. Вводит имя, адрес и телефон3. Подтверждает оформление4. Приложение перенаправляет к оплате5. Платёж проходит успешно6. Система получает подтверждение и отправляет заказ на склад7. Склад начинает сборку8. Покупателю отображается сообщение «Заказ оформлен» |
| Постусловие | Заказ успешно создан, передан на склад и отображается в истории заказов. |
| Альтернативные сценарии | • Платёж не прошёл → показать сообщение и предложить повторить• Не заполнены поля → подсветить, не дать оформить• Склад временно недоступен → заказу присваивается статус «В ожидании» |
| Исключения | Нет связи с платёжной системой → заказ сохраняется как черновик, пользователь может завершить оформление позже |
У героя появился позвоночник невидимый, но несущий. Он начал удерживать маршрут: от старта до результата. Это внутренняя собранность, которая не даёт распасться в деталях.
Совет героя
Начни с цели – с того, что хочет пользователь и зачем (User Story). А уже потом опиши путь – кто участвует, что делает и как система отвечает (Use Case).
Так ты удержишь и смысл, и структуру.
Команда поймет, зачем строим и как это должно работать.
Диаграммы: когда взгляд становится системным
User Story – это цель.
Use Case – это маршрут.
А что дальше?
Дальше – система в лицах и связях. Чтобы построить её надёжно, нужны диаграммы. Не ради красоты, а ради точности: кто с кем общается, из чего всё состоит, как проходит процесс.
В этой части мы познакомим героя с тремя ключевыми видами UML-диаграмм, которые помогут ему стать не просто аналитиком, а архитектором смысла.
| Диаграмма | Зачем нужна | Что показывает |
|---|---|---|
| Sequence Diagram | Чтобы понять, как части системы разговаривают между собой | Порядок и логику сообщений между актерами, сервисами, модулями |
| Class Diagram | Чтобы увидеть, из чего всё построено | Структуру данных, их связи, наследование и зависимости |
| Activity Diagram | Чтобы описать внутреннюю логику действия | Ветвление сценариев, циклы, условия, альтернативные пути |
Тренды и фишки из мира IT,
экспертные статьи и всё о тестировании.
Sequence Diagram – разговор по ролям
Иногда важно не просто знать, что делает система, но и в каком порядке это происходит. Кто с кем говорит? Что отвечает? Что будет, если шаг пропущен? Вот тут и вступает Sequence Diagram — диаграмма последовательностей. Она показывает время, взаимодействие и участников.
Ее стоит использовать, когда нужно показать сценарий пошагово – особенно при оплатах, заказах, регистрации, уведомлениях. Всё, где важно: кто первый, кто второй, кто должен ответить, а кто – ждать. Sequence Diagram даёт:
- Чёткую картину взаимодействия
- Видимость, где может случиться сбой
- Возможность сразу обсуждать с командой, как построить, что логичнее
Вот как это будет выглядеть:
Как читать и писать Sequence Diagram:
@startuml
actor Покупатель
participant Приложение
participant Платёжка
participant Склад
Покупатель -> Приложение : Нажимает "Оформить заказ"
Приложение -> Платёжка : Отправка данных об оплате
Платёжка -> Приложение : Подтверждение оплаты
Приложение -> Склад : Уведомление о заказе
Склад -> Приложение : Подтверждение сборки
Приложение -> Покупатель : Показывает "Заказ оформлен"
@enduml
Разбор синтаксиса:
Попробуйте сами: скопируйте код и вставьте его на сайт plantuml.com. Вы увидите свою первую Sequence Diagram в картинке.
Activity Diagram – маршрут с развилками
Иногда важно показать весь процесс, который проходит пользователь или система: со всеми шагами, развилками, проверками и альтернативами. Тут поможет диаграмма активностей – Activity Diagram. Это как карта сценария, где видны все повороты.
Используйте ее, когда нужно описать:
- Пошаговый процесс с проверками и условиями
- Что происходит при альтернативных сценариях
- Поведение системы в виде алгоритма
- Внутреннюю логику одного участника
Она покажет, где могут быть ошибки и что делать, а также позволит обсудить поведение до реализации. Кроме всего этого, Activity Diagram отлично читается: менеджером, тестировщиком, дизайнером.
Как читать и писать Activity Diagram:
@startuml
start
:Открыть приложение;
:Выбрать джем из каталога;
:Добавить товар в корзину;
if (Корзина не пуста?) then (да)
:Перейти к оформлению заказа;
else (нет)
:Показать сообщение "Корзина пуста";
stop
endif
:Ввести данные для доставки;
:Выбрать способ оплаты;
if (Выбран онлайн-платёж?) then (да)
:Ввести данные карты;
:Подтвердить оплату;
if (Оплата прошла?) then (да)
:Показать экран подтверждения заказа;
else (нет)
:Показать сообщение об ошибке;
stop
endif
else (нет)
:Выбрать оплату при получении;
:Подтвердить заказ;
:Показать экран подтверждения заказа;
endif
stop
@enduml
Разбор синтаксиса:
Попробуйте сами: скопируйте код и вставьте его на plantuml.com. Вы увидите свою первую диаграмму активностей!
У нашего героя появились когти – точные, не острые, но решительные. Он научился вскрывать сценарии, находить ошибки, вмешиваться, когда нужно.
Совет героя
Смотри вглубь – не просто на шаги, а на то, как они соединяются.
Диаграммы – твои когти: с их помощью ты не только видишь, но и можешь вмешаться вовремя.
Теперь наш герой умеет не просто слушать – он видит связи. С помощью:
- User Story, которая превращает «хочу удобно» в четкий запрос,
- Use Case, раскладывающего путь пользователя на атомы,
- Диаграмм, показывающих, как «разговаривают» между собой приложение, оплата и склад.
Его новые когти – это способность вскрывать процессы, находить скрытые развилки и ошибки до того, как их увидит пользователь.
А в пятой статье (если Юлина муза не съест все запасы клубнично-кокосового джема 😉), быть может, увидим и разберем: прототипы в Figma и валидацию требований. А пока попробуйте сами побыть аналитиком: возьмите любой процесс (хоть «как сварить кофе») и опишите его как Use Case с альтернативами. Увидите – мир станет чуть более управляемым! И делитесь своими достижениями в наших соцсетях и комментариях 😉.
