Написать пост

User Stories и Use Cases в аналитике: когда и что лучше использовать

Какой метод описания требований выбрать: User Stories или Use Cases? Рассказываем о том, чем отличаются эти подходы.

Корректно проведенный анализ требований — ключ к успешной реализации проекта. Но как не запутаться в куче подходов и выбрать подходящий? Ответ: последовательно изучать новые методы и сравнивать их друг с другом. 


В этой статье я на понятных примерах расскажу про User Stories, Use Cases и их совместное использование при описании требований. Давайте разбираться.

User Story

User Story (или пользовательская история) — это подход к описанию возможностей ПО, который представляет собой короткие, независимые описания функциональности, составленные от имени конкретного пользователя. 

Формат пользовательских историй можно описать формулой. 

User Stories и Use Cases в аналитике: когда и что лучше использовать 1

Сразу на примерах посмотрим, как из хотелок пользователей собирать требования в формате User Stories. 

Пример 1

Студент хочет видеть полный список своих задач на главном экране университетского приложения

User Stories и Use Cases в аналитике: когда и что лучше использовать 2
User Story к примеру

Пример 2

Пользователь интернет-магазина хочет иметь возможность добавлять товары в корзину

User Stories и Use Cases в аналитике: когда и что лучше использовать 3
User Story к примеру

И формула, и перевод к её виду нормальных примеров кажутся простыми. Но, к сожалению, не все желания пользователей и заказчиков чёткие и адекватные, поэтому для создания хороших User Stories знания одной формулы недостаточно.

Пользовательские истории должны соответствовать критериям INVEST

Пояснение ниже стоит сохранить и запомнить, потому что о нём часто спрашивают на собеседованиях 😉.

User Stories и Use Cases в аналитике: когда и что лучше использовать 4
Критерии качества пользовательских историй INVEST

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

Время плохих примеров. 

Внимание! Так делать не стоит!

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

Эта User Story слишком общая, по ней непонятно, что именно нужно пользователю и зачем.

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

Тут тоже требования слишком размыты и не описывают, что именно необходимо оптимизировать для улучшения производительности пользователя.

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

Эта User Story слишком субъективна и не является измеримой или конкретной.

Чтобы научиться быстро генерировать User Stories по формуле, нужно тренироваться. Представьте, что заказчик отправил вам довольно расплывчатый набор требований к системе. 

Как бы вы оформили их в User Stories? Отправляйте свои варианты в комментариях!

То, что не указано явно, можно додумать.

Пользователь должен иметь возможность просматривать список товаров из каталога по категориям и подкатегориям.

При добавлении товара в корзину пользователь должен видеть динамическое обновление общей стоимости заказа.

Система должна предоставлять пользователю возможность отменить или изменить состав заказа до его оформления.

При покупке товара с помощью банковской карты пользователь должен видеть подтверждение успешного платежа.

Система должна регулярно резервировать и сохранять данные о заказах в случае сбоя или отключения.

После того, как мы разобрались с практикой, можем перейти к теории. Чем же этот подход хорош?

User Stories и Use Cases в аналитике: когда и что лучше использовать 5

Заказчикам проще описывать свои пожелания в «пользовательских» формулировках, иначе начинается «ой, я эти ваши технические штуки не понимаю, давайте нормально». Поэтому User Stories отлично подходят для сбора требований в виде, который понятен и для команды клиента, и для команды разработки. 

Так как требования должны быть сформулированы от имени конкретного пользователя, при формировании User Stories аналитик сразу выделяет пользователей и прочих заинтересованных в работе системы лиц и их требования к ПО. Это существенно упрощает дальнейшее определение ролей в системе и помогает расставить вашим задачам приоритеты.

Так, например, для интернет-магазина в пользовательских историях могут быть отражены запросы на возможность оформления заказа и оформления подписки на отсутствующие товары. Скорее всего, и для бизнеса, и для пользователей важнее  будет возможность оформления заказа. И если поставить две эти истории рядом и сравнить, то выбрать приоритетную будет проще. 

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

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

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

Так когда же их стоит использовать?

  1. Когда требования к проекту меняются. User Stories помогают быстро адаптироваться к изменяющимся требованиям, поскольку они могут быть легко добавлены, изменены или удалены в процессе разработки.
  2. При работе по методологии Agile. User Stories — основной инструмент в Agile-разработке, так как они фокусируются на ценности для конечного пользователя, способствуют итеративному процессу разработки и обеспечивают гибкость в планировании и реализации функциональности.
  3. При необходимости вовлечения заинтересованных сторон. User Stories понятны и доступны не только для членов команды разработки, но и для заинтересованных сторон, таких как заказчики, менеджеры продукта и конечные пользователи.
  4. При разработке продукта, ориентированного на пользователя. User Stories помогают сосредоточиться на потребностях и задачах конечных пользователей.
  5. При работе в команде со смешанным составом. User Stories предоставляют общий язык для команды разработки, который понятен как разработчикам, так и не-техническим участникам процесса, таким как менеджеры продукта или тестировщики.
  6. При необходимости верхнеуровневого описания сложной функциональности. Пользовательские истории используются не только для конкретизации небольших функциональных требований, но и для краткого описания более сложных и крупных фрагментов функциональности. Иногда анализ стоит начинать с формулировки основных пользовательских сценариев и требований в виде User Stories, чтобы чётко определить цели и потребности пользователей, а затем доработать эти истории другими подходами.
Резюме:

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

Use Case

Use Case (или пример использования) — это способ описания того, как определённый пользователь или система взаимодействует с программным продуктом для достижения определенной цели.

Use Cases описывают конкретные сценарии использования, их участников (пользователей или системы) и последовательность шагов, необходимых для достижения определенного результата.

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

В отличии от User Stories, Use Cases представимы в разных форматах. Например:

  • Текстовый формат включает в себя акторов (не путать с актёрами), цели, предусловия, сценарии и постусловия. Этот формат легко читается и понимается, но может быть менее удобным для больших объемов информации.
  • Диаграммы Use Case, например, Use Case UML. В этом случае каждый сценарий представлен в виде отдельного прямоугольника с указанием его имени, а акторы и связи между ними могут быть показаны стрелками.
  • Таблицы или матрицы. При необходимости можно записать текстовое представление в табличном формате. Например, под каждый use cases могут быть созданы отдельные таблицы с двумя столбцами, где первым выступает заголовок (акторы, сценарии и т. д.), а вторым описание конкретного use case.

Разберем ключевые элементы Use Cases на основе одного из вариантов структуры текстового представления. 

User Stories и Use Cases в аналитике: когда и что лучше использовать 6

Алгоритм создания текстовых примеров использования заключается в последовательном заполнении структуры, которую мы описали. 

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

User Story:

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

Use Case:

User Stories и Use Cases в аналитике: когда и что лучше использовать 7
Пример Use Case, составленный по пользовательской истории

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

Чтобы попрактиковаться, предлагаю разработать Use Cases для тех же примеров, которые вы переводили в User Stories. 

То, что не указано явно, всё ещё можно додумывать. Делитесь своими вариантами в комментариях!

Напоминаю кейсы

Пользователь должен иметь возможность просматривать список товаров из каталога по категориям и подкатегориям.

При добавлении товара в корзину пользователь должен видеть динамическое обновление общей стоимости заказа.

Система должна предоставлять пользователю возможность отменить или изменить состав заказа до его оформления.

При покупке товара с помощью банковской карты пользователь должен видеть подтверждение успешного платежа.

Система должна регулярно резервировать и сохранять данные о заказах в случае сбоя или отключения.

Главное преимущество Use Cases в том, что они помогают аналитикам идентифицировать и собирать требования к системе на основе конкретных сценариев использования. Необходимо отметить, что помимо основной своей цели — сбора требований, использование use cases помогают с определением границ функциональности проекта. 

На этом хотелось бы остановиться подробнее, потому что отсутствие таких ограничений способствовало убыточности многих проектов. Как это происходит? Приведу немного утрированный пример. 

Клиент приходит с требованием: «Хочу, чтобы в моем интернет-магазине был личный кабинет, как у всех».

Он же, когда вставили какой-то штатный вариант ЛК: «А где сумма по всем покупкам и список активных сессий? Мы обсуждали, что вы сделаете личный кабинет и оценили доработку. Пока не сделаете нормально, задачу принимать и оплачивать полностью не буду».

Команда:

User Stories и Use Cases в аналитике: когда и что лучше использовать 8

Говоря о плюсах этого подхода, стоит удостоить внимания простоту создания тестовых сценариев: формат Use Cases уже подразумевает наличие описанного порядка действий пользователя. Также они способствуют формированию общего видения того, как должен работать и выглядеть конечный продукт и служат инструментом для проверки полноты требований к системе, позволяя идентифицировать пробелы и пропуски в функциональности, которые могут быть упущены при других методах анализа требований.

Разумеется, такой подход можно использовать не всегда. Его использование для простых проектов с понятными требованиями использование Use Cases может показаться излишним и избыточным. 

В то же время и при разработке крупных систем количество и сложность “примеров использования” может значительно вырасти, что делает их поддержку и управление проблемными и затратными. 

Резюме:

Use Cases — это структурированный метод анализа требований, который детализирует сценарии использования системы.

Такой подход обеспечивает команде разработчиков понимание функциональных требований и помогает идентифицировать различные сценарии действий пользователей. Он отлично подходит для описания сложных требований. 

Что выбрать: User Stories или Use Cases

User Stories

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

Use Cases

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

В некоторых проектах целесообразно использование обоих методов вместе. 

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

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

Выбор между Use Cases и User Stories зависит от конкретных условий проекта, потребностей заказчика, требований к системе и методологии разработки. 

Не бойтесь экспериментировать и адаптировать выбранный метод анализа под потребности вашего проекта.

Следите за новыми постами
Следите за новыми постами по любимым темам
648 открытий7К показов