Варианты на все случаи жизни: как написать полезный use case

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

Как использовать юзкейс, зависит от стадии проекта, подхода к разработке и того, о чём договорилась команда:

● ПО разрабатывают с нуля по водопадной методологии Waterfall, этапы проекта идут последовательно. Член команды пишет все юзкейсы с нуля, собирает из них огромную спецификацию, а потом передаёт разработчикам.

● Продукт развивают по гибкой методологии Agile, каждая задача проходит цикл, работать над ними можно параллельно. Команда работает над продуктом уже какое-то время и небольшими итерациями вносит изменения: доработать форму, добавить кнопку. В этом случае юзкейсы пишут в сокращённом виде, а из больших шаблонов берут только самые важные моменты.

Когда проект большой, например, интернет-магазин, написать все юзкейсы — огромный труд, и для это нужен отдельный человек. Если в команде есть системный аналитик, то всю эту документацию пишет он. Если системного аналитика в команде нет, то юзкейсы общими штрихами может написать менеджер проекта или тимлид.

1. Составить общее представление о продукте.
Система может состоять из множества компонентов, а вся команда, включая аналитика, должна знать, как они работают. Например, в какой базе данных хранится нужная информация или в какую подсистему нужно отправить запрос для выполнения расчётов. Если команде нужно понять, как обычный человек взаимодействует с ПО, поможет диаграмма use case.

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

Часто команды, которые давно разрабатывают продукт, говорят: «Нам это приложение уже как родное, мы знаем, как и что должно в нём работать. Давайте как-нибудь без юзкейсов. Сразу будем делать задачки». Однако в большом потоке задач можно упустить разные сценарии использования и забыть, что пользователи не идеальны и могут ошибаться, а системы не всегда выдают тот результат, который устроит пользователя. Например, при поиске авиабилетов пользователю может не подойти ни один из вариантов перелёта. Нужно предусмотреть, чтобы была возможность скорректировать параметры поиска.

3. Иногда помочь тестировщику.
Юзкейс может использовать тестировщик, когда проверяет готовую задачу. В этом случае диаграммы use case — это классический тест-кейс. Тестировщик идёт по нему, и если что-то в продукте работает не так, как описано, пишет в баг-репорте: ожидаемое действие такое, фактическое — другое. В документе он ссылается на юзкейс.

Допустим, аналитик пришёл в команду, которая разрабатывает приложение для такси. Разработка use case пройдёт в несколько этапов:

1. Сбор информации

Перед тем как писать use case, аналитик должен собрать:

● требования того, что хочет получить бизнес;

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

Системный аналитик может получить нужные требования от бизнес-аналитика, который общается с заказчиком, или сам обратиться к нему за информацией.

Пользовательские требования бизнес-аналитик и системный аналитик формируют вместе. Если аналитиков на проекте нет, то эта задача может лечь на менеджера проекта или UX/UI-дизайнера, который глубоко погрузился в тему и проводил исследования с пользователями. Например, выяснил, что люди хотят доехать из точки А в точку В, но им не нравится заказывать такси по телефону.

2. Общая картина в виде диаграммы

Системный аналитик работает по принципу от общего к частному: сначала описывает задачу в целом, а затем постепенно детализирует её до мельчайших подробностей.
Составить общую картину помогает use case диаграмма. На ней отображаются все участники процесса, все варианты использования ПО, а иногда и системы, которые отвечают за сервис.

Например, в диаграмме use case для приложения такси аналитик укажет, что в процессе участвует сам пользователь, оператор такси, водитель, служба поддержки и платёжная система. Пользователь может залогиниться в приложении, привязать карту, сделать заказ.

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

Требований к диаграмме use case немного:

● участников процесса нужно обозначать специальными значками в виде человечков;

● варианты использования писать в овалах, например, залогиниться, авторизоваться, положить товар в корзину;

● для обозначения связей между элементами используются элементы нотации UML (от англ. Unified Modeling Language) — стрелки и пояснения текстом. Они показывают, как можно попасть в этот вариант использования и к какой функциональности он относится.

3. Текстовый use case по отдельным задачам

Use case в формате текста — это уже детализированная часть диаграммы. Аналитик берёт из неё каждый овал и подробно расписывает. Здесь помощь команды не нужна.

Качество юзкейса — в его пользе. Если юзкейс помогает команде понять, что делать дальше, и не приводит к ошибкам в продукте — значит, системный аналитик проделал отличную работу. Плохой юзкейс содержит ошибки, которые приведут к проблемам в процессе разработки или к тому, что пользователь не достигнет своей цели.

В каждой компании или команде по-разному адаптируют стандартные шаблоны юзкейсов. Главное для системного аналитика — понять, какой шаблон нужен именно для его проекта.

Вот подробный пример use case для интернет-магазина — новичку лучше начать с такого шаблона.

● Читать теорию. Новичкам стоит начать с книги Карла Вигерса «Разработка требований к программному обеспечению» — это библия системного аналитика. По шаблонам из этой книги учат в Практикуме и других школах. Принципы Вигерса используют в компаниях в России и по всему миру.

● Описывать обычную жизнь. Когда аналитик погружается в системный анализ, в какой-то момент понимает: всё, что он делает каждый день, можно описать в виде сценария. Чтобы набить руку, можно описывать юзкейсы самых банальных вещей: заваривания кофе или приготовления салата. Так получается замечать мелкие детали, из которых состоит юзкейс. На собеседованиях системных аналитиков могут попросить выйти из контекста и, например, описать сценарий использования зубной щётки.

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

● Развивать насмотренность. Художники и дизайнеры постоянно смотрят чужие работы, чтобы развиваться. То же самое полезно делать и начинающим системным аналитикам — вбивать в поисковую строку «Use case варианты и примеры» и смотреть как можно больше чужих юзкейсов.
● Писать юзкейсы по другим продуктам. Если аналитик видел аналогичный продукт или функциональность, полезно зайти в этот сервис, пройти путь пользователя и составить по нему юзкейс. Так можно получить важные подсказки по проекту.