Привет, Хабр!
Сегодня мы рассмотрим методы формализации требований: Use Case и User Story. В статье рассмотрим оба метода, сравним их преимущества и недостатки. А также рассмотрим, когда и при каких ситуациях использовать каждый из методов.
Что такое Use Case и User Story
Use Case
Use Case, или сценарий использования, представляет собой текстовое описание конкретного взаимодействия между пользователем и системой. Это описание помогает определить функциональные требования системы и документирует шаги, нужные для достижения конкретной цели.
Use Case обычно включает несколько элементов:
Акторы:
Акторы представляют роли или внешние сущности, которые взаимодействуют с системой. Это могут быть как пользователи, так и другие системы или устройства. Актор играет определённую роль в сценарии использования. Например, в системе онлайн-заказов актором может быть "Покупатель" или "Администратор".Предусловия:
Предусловия описывают состояния и условия, которые должны быть выполнены до начала сценария использования. Они определяют, в каком состоянии должна находиться система перед началом выполнения сценария. Например, предусловие для сценария оформления заказа может быть таким: "Пользователь должен быть авторизован в системе".Основной поток:
Основной поток описывает последовательность шагов, которые необходимо выполнить для достижения цели сценария. Это основной путь, который следует пользователь в типичной ситуации. Например, для сценария покупки товара основной поток может включать следующие шаги: выбор товара, добавление товара в корзину, ввод данных для оплаты и подтверждение заказа.Альтернативные потоки:
Альтернативные потоки описывают возможные отклонения от основного потока, которые могут возникнуть в процессе выполнения сценария. Это могут быть варианты действий пользователя или системы, которые приводят к успешному завершению сценария. Например, если выбранный товар отсутствует на складе, система может предложить пользователю выбрать другой товар.Постусловия:
Постусловия описывают состояние системы после завершения сценария использования. Они указывают, какие изменения должны произойти в системе по завершении всех шагов сценария. Например, постусловие для сценария оформления заказа может быть таким: "Информация о заказе сохранена в базе данных".Исключения:
Исключения описывают ошибки или неожиданные ситуации, которые могут произойти во время выполнения сценария. Эти сценарии определяют, как система должна реагировать на такие события. Например, если произошла ошибка при обработке платежа, система должна уведомить пользователя и предложить повторить попытку.
Пример Use Case:
Название: Оформление заказа на покупку
Акторы: Покупатель
Предусловия: Пользователь авторизован на сайте
Основной поток:
Покупатель выбирает товар.
Добавляет товар в корзину.
Переходит к оформлению заказа.
Вводит данные для доставки и оплаты.
Подтверждает заказ.
Альтернативные потоки:
Если товар отсутствует на складе, предложить выбрать другой товар.
Если адрес доставки не поддерживается, попросить ввести другой адрес.
Постусловия: Заказ создан и подтвержден, информация о заказе сохранена в системе.
Исключения: Если произошла ошибка при обработке платежа, уведомить пользователя и предложить повторить попытку.
User Story
User Story — это короткое, неформальное описание функциональности системы с точки зрения конечного пользователя или заинтересованного лица. User Stories часто используются в Agile-разработке, т.к они помогают сфокусироваться на потребностях пользователя и предоставляют гибкость при изменении требований.
Шаблон User Story:
User Story обычно записывается в формате:
"Как <роль>, я хочу <действие>, чтобы <цель>."
Этот шаблон позволяет понять, кто является пользователем, что он хочет сделать и зачем ему это нужно.
Основные элементы User Story:
Роль :
Указывает на пользователя или заинтересованное лицо, которое будет взаимодействовать с системой. Например, это может быть "зарегистрированный пользователь" или "администратор".Действие:
Описывает, что именно пользователь хочет сделать. Это действие должно быть чётким и конкретным. Например, "добавить товар в корзину" или "создать отчёт".Цель:
Указывает на причину или выгоду, которую получит пользователь, выполняя это действие. Это помогает понять мотивацию пользователя и конечную цель. Например, "чтобы затем оформить заказ" или "чтобы проанализировать данные".
Пример User Story:
Роль: Зарегистрированный пользователь
Действие: Добавить товар в корзину
Цель: Чтобы затем оформить заказ
Таким образом, пользовательская история может выглядеть так:
"Как зарегистрированный пользователь, я хочу добавить товар в корзину, чтобы затем оформить заказ."
Для полной ясности и точности User Stories могут также включать:
Критерии приемки:
Условия, которые должны быть выполнены для того, чтобы пользовательская история считалась завершенной. Например, "Товар добавляется в корзину только если он есть в наличии."Заметки:
Доп. информация или комментарии, которые могут быть полезны для понимания контекста или деталей пользовательской истории.
Еще один пример:
Роль: Администратор сайта
Действие: Создать отчёт о продажах
Цель: Чтобы анализировать месячные продажи и принимать решения по ассортименту
User Story: "Как администратор сайта, я хочу создать отчёт о продажах, чтобы анализировать месячные продажи и принимать решения по ассортименту."
Критерии приемки:
Отчёт включает данные за указанный период.
Отчёт можно экспортировать в формате CSV.
Отчёт отображает данные по категориям товаров.
Заметки: Отчёт должен генерироваться не более чем за 30 секунд.
Сравнение
Аспект |
Use Case |
User Story |
|---|---|---|
Детализация и формат |
Детализированное и структурированное описание взаимодействий между пользователем и системой. |
Краткое и неформальное описание функциональности с точки зрения пользователя. |
Фокус и перспектива |
Ориентирован на системное поведение. Описывает, как система должна реагировать на действия пользователей и внешних сущностей. |
Сосредоточена на потребностях и целях пользователя. Описывает, что нужно пользователю и зачем. |
Гибкость и адаптивность |
Требует больше усилий для внесения изменений. |
Более гибкая и легко адаптируется к изменениям. |
Документация и коммуникация |
Более полная и подробная документация, полезная для технических команд. |
Способствует лучшей коммуникации и взаимодействию между заинтересованными сторонами и разработчиками благодаря своей простоте. |
Use Case лучше подходит для сложных проектов с множеством взаимодействий и строгими регуляторными требованиями. Например:
Системы с высокой степенью интеграции с другими системами или устройствами.
Проекты, требующие детальной тех. документации для соответствия регуляторным или стандартам безопасности.
Сложные бизнес-процессы, требующие полного описания всех возможных сценариев и взаимодействий.
User Story хороша в проектах с частыми изменениями требований и необходимостью тесного взаимодействия с заказчиками. Примеры:
Проекты, использующие Agile или Scrum методологии, где гибкость и адаптивность является базой.
Быстрая разработка MVP для тестирования идей и получения фидбека от пользователей.
Команды, работающие в тесном сотрудничестве с заказчиками и заинтересованными сторонами, требующие быстрого и гибкого подхода к изменениям.
Иногда команды используют гибридный подход, комбинируя фичи обоих методов. Например, User Story для начальной оценки и определения высокоуровневых требований, а затем переход к Use Case для детальной проработки сложных сценариев.
В завершение хотелось бы пригласить всех желающих на открытые уроки, которые скоро пройдут в рамках онлайн-курса «Бизнес-аналитик в IT» в Otus:
9 июля: Формирование концептуальных схем предметной области. Поговорим про описание предметной области в части состава объектов и их взаимосвязи. Запись по ссылке
22 июля: Бизнес-процессы как инструмент погружения в предметную область. Сконцентрируемся на моделировании бизнес-процессов. Рассмотрим примеры схем БП, обсудим часто возникающие ошибки и их влияние на ход проекта/разработку продукта. Запись по ссылке