User Stories и Use Cases простыми словами

Привет!Меня зовут Виталий Жданов, я ИТ-специалист, специализируюсь на системном администрировании. Нашел свою профессию на всю жизнь почти сразу. Постоянное саморазвитие стало привычным, поэтому прошел курс лекций по строительству компьютерных сетей Cisco. Через 2 года мне захотелось большего, чем просто обслуживать оборудование, устранять и предотвращать неисправности. Однажды я подал заявку на грант на обучение в SkillsUp на курсе по управлению проектами. Когда я получил приглашение на курс, понял, что сорвал куш. У меня есть мечта, звучит крайне масштабно, даже несколько безумно, однако пока сохрани интригу.

 

User Stories и Use Cases являются разными инструментами документирования требований, используемых в процессе разработки программного обеспечения. Каждый из них имеет свою функцию. Например, User Stories используются для определения функциональных требований к системе с точки зрения пользователя и языка бизнеса, Use Cases – для более подробного описания взаимодействия пользователя с системой в определенных сценариях.

Что же такое User Stories? Представим себе, что к нам обратился представитель MIT Consulting LTD и попросил создать мобильное приложение для медитации. В этом случае обращение будет выглядеть ориентировочно так: «Я как человек, который следит за своим психическим здоровьем и медитирует, хочу иметь приложение для медитации, чтобы входить в состояние глубокого транса с помощью специального устройства, слушая соответствующую музыку для улучшения процесса». В этой User Story у нас есть все необходимые компоненты:

  1. Роль (представитель MIT Consulting LTD).
  2. Объект желания заказчика (мобильное приложение для медитации).
  3. Цель (чтобы входить в состояние глубокого транса, слушая соответствующую музыку для улучшения процесса).

В то же время происходит детализация User Story — представитель компании отмечает, что хочет, чтобы приложение было доступно широкому кругу пользователей и имел интерфейс, который поймут даже люди с низкой компьютерной грамотностью. Users Stories создаются только для отображения потребностей заказчика с наиболее важными деталями, они не должны быть слишком большими. Если не получается сделать короткую User Story, следует разбить ее на несколько мелких. Конечно, приложение приведено только для примера. Здесь будет много итераций, поэтому нужно много мелких User Stories. Приведу несколько примеров:

«Я как будущий правообладатель приложения хочу, чтобы специальное устройство, которое пользователи будут надевать на голову, взаимодействовало с приложением через Bluetooth».

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

 

Формула User Story: Я, как [Х], хочу [Y], чтоб [Z], где

X — человек, которая выражает запрос;

Y — цель запроса; то,с чем к вам пришел клиент;

Z — финальная цель, по которой человек обратился; бизнес-ценность.

Use case (юзкейс, сценарий использования) можно описать как сценарий взаимодействия пользователя с продуктом. Юзкейс имеет следующие данные:

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

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

  1. Определите основного участника (актера). Актером может быть человек, другое ПО или оборудование
  2. Опишите цель. Укажите основную цель или задачу варианта использования с точки зрения актера.
  3. Перечислите шаги. Подробно опишите шаги, связанные с достижением цели варианта использования, начиная с первого действия актера и продолжая до завершения варианта использования.
  4. Добавьте вариации. Учитывайте любые потенциальные вариации шагов, связанных со сценарием использования, например альтернативные пути или сценарии исключений.
  5. Результат. Опишите конечный результат или результат варианта использования, который должен соответствовать цели актера.

Я бы написал юзкейс для BFB Training да:

  1. Кто? Конечный пользователь.
  2. Что он хочет сделать? Провести медитацию.
  3. Какова цель действия? Снять напряжение после тяжелого рабочего дня.
  4. Какие шаги выполняет пользователь при выполнении этого действия?

4.1. Включает Bluetooth на своем телефоне.

4.2. Подключает смартфон к специальному устройству для считывания активности головного мозга и надевает его на голову.

4.3. Открывает приложение.

4.4. Нажимает на иконку с надписью «Начать медитацию».

4.5. Устройство на голове анализирует активность мозга, на основе которой приложение выбирает режим медитации, подбирает музыку.

4.6. Пользователь медитирует.

4.7. Медитация заканчивается, человек успокоен и снимает устройство с головы.

4.8. Пользователь нажимает на иконку «Сохранить данные медитации».

4.9. Человек закрывает приложение.

4.10. Пользователь снимает с головы устройство, отсоединяет его от телефона и выключает Bluetooth на смартфоні

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

Это юзкейс нормального взаимодействия пользователя с приложением из д. Если что-то пошло не так, например человек хотел сохранить данные о медитации, а смартфон не подключен к интернету, пользователь увидит надпись: «Соединение с интернетом отсутствует или нестабильно. Проверьте подключение». Это будет юзкейс с нестандартным сценарием.

Важно, чтобы опытный аналитик умел документировать требования как через User Stories, так и через Use Cases. И хотя они имеют разные функции и используются на разных этапах проекта, они дополняют друг друга и позволяют разработчикам и заказчикам четко понять, каким должен быть конечный продукт и какие функции он должен иметь. Понимание требований пользователей и бизнес ценности поможет разработать эффективную и полезную систему, которая удовлетворит потребности клиентов и принесет пользу их бизнесу.

 

Автор статьи

Виталий Жданов
Системный администратор с 2-летним опытом, студент SkillsUP по направлению «Управление ИТ-проектами», открыт к новым возможностям в карьере.
Сертификат об окончании курса по построению сетей на базе оборудования Cisco:
https://www.udemy.com/certificate/UC-d8e7c424-1043-4884-8503-12af5e93e645/

 

Марина Мельник :

Горжусь студетом Виталием. Радуюсь, наблюдая за тем, как мои студенты и ученики становятся востребованными специалистами

 

Похожие темы