User Stories и Use Cases в аналитике: когда и что лучше использовать
Отредактировано
Какой метод описания требований выбрать: User Stories или Use Cases? Рассказываем о том, чем отличаются эти подходы.
6К открытий19К показов
Корректно проведенный анализ требований — ключ к успешной реализации проекта. Но как не запутаться в куче подходов и выбрать подходящий? Ответ: последовательно изучать новые методы и сравнивать их друг с другом.
Кстати, если вы ищете новые карьерные возможности, обратите внимание на вакансию системного аналитика в Сбере.
В этой статье я на понятных примерах расскажу про User Stories, Use Cases и их совместное использование при описании требований. Давайте разбираться.
User Story
User Story (или пользовательская история) — это подход к описанию возможностей ПО, который представляет собой короткие, независимые описания функциональности, составленные от имени конкретного пользователя.
Формат пользовательских историй можно описать формулой.
Сразу на примерах посмотрим, как из хотелок пользователей собирать требования в формате User Stories.
Пример 1
Студент хочет видеть полный список своих задач на главном экране университетского приложения
Пример 2
Пользователь интернет-магазина хочет иметь возможность добавлять товары в корзину
И формула, и перевод к её виду нормальных примеров кажутся простыми. Но, к сожалению, не все желания пользователей и заказчиков чёткие и адекватные, поэтому для создания хороших User Stories знания одной формулы недостаточно.
Пользовательские истории должны соответствовать критериям INVEST.
Пояснение ниже стоит сохранить и запомнить, потому что о нём часто спрашивают на собеседованиях 😉.
При несоблюдении этих критериев, User Stories могут превратиться в нечто, доводящее команду разработки до ужаса и истерик. И чтобы точно усвоить эти правила, вам нужно прочувствовать эту боль.
Время плохих примеров.
Внимание! Так делать не стоит!
Как пользователь я хочу видеть кнопку на экране, чтобы кликнуть по ней и перейти на следующую страницу.
Эта User Story слишком общая, по ней непонятно, что именно нужно пользователю и зачем.
Как администратор я хочу, чтобы система была быстрая, чтобы я мог быстро выполнять свои обязанности.
Тут тоже требования слишком размыты и не описывают, что именно необходимо оптимизировать для улучшения производительности пользователя.
Как творческий человек я хочу, чтобы приложение выглядело красиво, чтобы я мог наслаждаться его использованием.
Эта User Story слишком субъективна и не является измеримой или конкретной.
Чтобы научиться быстро генерировать User Stories по формуле, нужно тренироваться. Представьте, что заказчик отправил вам довольно расплывчатый набор требований к системе.
Как бы вы оформили их в User Stories? Отправляйте свои варианты в комментариях!
То, что не указано явно, можно додумать.
Пользователь должен иметь возможность просматривать список товаров из каталога по категориям и подкатегориям.
При добавлении товара в корзину пользователь должен видеть динамическое обновление общей стоимости заказа.
Система должна предоставлять пользователю возможность отменить или изменить состав заказа до его оформления.
При покупке товара с помощью банковской карты пользователь должен видеть подтверждение успешного платежа.
Система должна регулярно резервировать и сохранять данные о заказах в случае сбоя или отключения.
После того, как мы разобрались с практикой, можем перейти к теории. Чем же этот подход хорош?
Заказчикам проще описывать свои пожелания в «пользовательских» формулировках, иначе начинается «ой, я эти ваши технические штуки не понимаю, давайте нормально». Поэтому User Stories отлично подходят для сбора требований в виде, который понятен и для команды клиента, и для команды разработки.
Так как требования должны быть сформулированы от имени конкретного пользователя, при формировании User Stories аналитик сразу выделяет пользователей и прочих заинтересованных в работе системы лиц и их требования к ПО. Это существенно упрощает дальнейшее определение ролей в системе и помогает расставить вашим задачам приоритеты.
Так, например, для интернет-магазина в пользовательских историях могут быть отражены запросы на возможность оформления заказа и оформления подписки на отсутствующие товары. Скорее всего, и для бизнеса, и для пользователей важнее будет возможность оформления заказа. И если поставить две эти истории рядом и сравнить, то выбрать приоритетную будет проще.
Использование User Stories – не панацея для вашего проекта. Как было показано ранее, формат фиксирован и имеет четкую структуру, которая не всегда подходит для описания сложных и уникальных требований.
Краткий формат записи выглядит очень общим и не включает в себя достаточно деталей, что может затруднить их понимание. Такие требования часто необходимо детально прорабатывать с помощью других подходов. К тому же из-за того, что User Stories в первую очередь описывают функциональные требования, использование только этого метода может затруднить работу с требованиями к производительности, безопасности и другими нефункциональными аспектами проекта.
Также необходимо понимать, что User Stories подходят не для всех типов проектов. В некоторых случаях, например, при работе над исследовательскими проектами или проектами с высокой степенью неопределенности, использование User Stories может быть неэффективным.
Так когда же их стоит использовать?
- Когда требования к проекту меняются. User Stories помогают быстро адаптироваться к изменяющимся требованиям, поскольку они могут быть легко добавлены, изменены или удалены в процессе разработки.
- При работе по методологии Agile. User Stories — основной инструмент в Agile-разработке, так как они фокусируются на ценности для конечного пользователя, способствуют итеративному процессу разработки и обеспечивают гибкость в планировании и реализации функциональности.
- При необходимости вовлечения заинтересованных сторон. User Stories понятны и доступны не только для членов команды разработки, но и для заинтересованных сторон, таких как заказчики, менеджеры продукта и конечные пользователи.
- При разработке продукта, ориентированного на пользователя. User Stories помогают сосредоточиться на потребностях и задачах конечных пользователей.
- При работе в команде со смешанным составом. User Stories предоставляют общий язык для команды разработки, который понятен как разработчикам, так и не-техническим участникам процесса, таким как менеджеры продукта или тестировщики.
- При необходимости верхнеуровневого описания сложной функциональности. Пользовательские истории используются не только для конкретизации небольших функциональных требований, но и для краткого описания более сложных и крупных фрагментов функциональности. Иногда анализ стоит начинать с формулировки основных пользовательских сценариев и требований в виде 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 на основе одного из вариантов структуры текстового представления.
Алгоритм создания текстовых примеров использования заключается в последовательном заполнении структуры, которую мы описали.
Требования можно сразу собирать в формате Use Cases, а можно использовать этот формат для уточнения User Stories. Попробуем в текстовом формате описать «пример использования» для пользовательской истории, которую мы разбирали ранее.
User Story:
«Как студент, я хочу видеть список всех своих задач на главном экране приложения, чтобы быстро оценить свою текущую загруженность»
Use Case:
Схема довольно простая: разбиваем задачу на небольшие блоки и не забываем задумываться, как система должна себя вести в случае ошибок и какие условия должны соблюдаться для работы вашего сценария.
Чтобы попрактиковаться, предлагаю разработать Use Cases для тех же примеров, которые вы переводили в User Stories.
То, что не указано явно, всё ещё можно додумывать. Делитесь своими вариантами в комментариях!
Напоминаю кейсы
Пользователь должен иметь возможность просматривать список товаров из каталога по категориям и подкатегориям.
При добавлении товара в корзину пользователь должен видеть динамическое обновление общей стоимости заказа.
Система должна предоставлять пользователю возможность отменить или изменить состав заказа до его оформления.
При покупке товара с помощью банковской карты пользователь должен видеть подтверждение успешного платежа.
Система должна регулярно резервировать и сохранять данные о заказах в случае сбоя или отключения.
Главное преимущество Use Cases в том, что они помогают аналитикам идентифицировать и собирать требования к системе на основе конкретных сценариев использования. Необходимо отметить, что помимо основной своей цели — сбора требований, использование use cases помогают с определением границ функциональности проекта.
На этом хотелось бы остановиться подробнее, потому что отсутствие таких ограничений способствовало убыточности многих проектов. Как это происходит? Приведу немного утрированный пример.
Клиент приходит с требованием: «Хочу, чтобы в моем интернет-магазине был личный кабинет, как у всех».
Он же, когда вставили какой-то штатный вариант ЛК: «А где сумма по всем покупкам и список активных сессий? Мы обсуждали, что вы сделаете личный кабинет и оценили доработку. Пока не сделаете нормально, задачу принимать и оплачивать полностью не буду».
Команда:
Говоря о плюсах этого подхода, стоит удостоить внимания простоту создания тестовых сценариев: формат Use Cases уже подразумевает наличие описанного порядка действий пользователя. Также они способствуют формированию общего видения того, как должен работать и выглядеть конечный продукт и служат инструментом для проверки полноты требований к системе, позволяя идентифицировать пробелы и пропуски в функциональности, которые могут быть упущены при других методах анализа требований.
Разумеется, такой подход можно использовать не всегда. Его использование для простых проектов с понятными требованиями использование Use Cases может показаться излишним и избыточным.
В то же время и при разработке крупных систем количество и сложность “примеров использования” может значительно вырасти, что делает их поддержку и управление проблемными и затратными.
Резюме:
Use Cases — это структурированный метод анализа требований, который детализирует сценарии использования системы.
Такой подход обеспечивает команде разработчиков понимание функциональных требований и помогает идентифицировать различные сценарии действий пользователей. Он отлично подходит для описания сложных требований.
Что выбрать: User Stories или Use Cases
User Stories
- подходит для описания верхнеуровневых требований с фокусом на потребности и цели пользователей;
- используется для планирования и приоритизации работ в рамках итераций или спринтов;
- применяется в проектах, где требования могут часто изменяться.
Use Cases
- используется для подробного анализа требований, особенно когда требуется детальное понимание сценариев использования;
- подходит для описания функциональности систем с учетом предусловий, альтернативных путей и постусловий;
- применяется в проектах с фиксированным объёмом работ, где требуется более строгий контроль над требованиями и изменениями.
В некоторых проектах целесообразно использование обоих методов вместе.
Например, можно начать анализ с User Stories для высокоуровневого описания ожиданий пользователей, а затем уточнять и детализировать требования с помощью Use Case. Выглядеть это будет примерно так же, как было описано в примерах этой статьи.
Комбинация методов позволяет собрать достаточно информации о требованиях, чтобы лучше понять потребности пользователей и создать функциональный и полезный продукт.
Выбор между Use Cases и User Stories зависит от конкретных условий проекта, потребностей заказчика, требований к системе и методологии разработки.
Не бойтесь экспериментировать и адаптировать выбранный метод анализа под потребности вашего проекта.
6К открытий19К показов
Из найма в IT к управлению собственной компанией Алексей Лихацкий шел более 10 лет. Из года в год индустрия менялась. Появлялись не только новые требования к специалистам, но и профессии. Рассказали о внешних и внутренних переменах рынка и их влиянии на нужные для специалиста навыки.
В Китае набирает популярность использование Tinder для поиска работы. Особенно часто это встречается среди местной молодежи
Тимлид frontend-разработки в Росбанке рассказывает о том, как быстро построить карьеру в IT и какие навыки для этого нужны.
Группа исследователей из США придумала метод, с помощью которого можно успешно передавать квантовые данные на тысячи километров