← Назад к вопросам

Приведи пример User Story для мобильного банка

2.0 Middle🔥 221 комментариев
#User Story и Use Case

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI29 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

User Story для мобильного банка: подробный пример

Определение User Story

User Story — это описание функции с точки зрения конечного пользователя в формате:

As a [кто пользователь] I want [что он хочет сделать] So that [почему ему это нужно]

Это инструмент для:

  • Фокусирования на потребностях пользователя
  • Коммуникации между бизнесом и разработкой
  • Разбиения функций на управляемые части

Пример 1: Перевод денег другому клиенту (базовый)

User Story ID: BANK-001
Приоритет: Высокий
Оценка: 5 story points

Narrative:
-----------
As a          → клиент мобильного банка
I want        → отправить деньги другому клиенту банка
So that       → легко рассчитаться с друзьями без наличных

Acceptance Criteria:
--------------------
1. Given  я авторизован в приложении
   When   я нажимаю на кнопку "Отправить деньги"
   Then   открывается форма ввода данных получателя

2. Given  я начал новый перевод
   When   я вписываю номер счёта или номер телефона
   Then   система показывает "подсказки" по совпадающим контактам
   And    я могу выбрать контакт из списка

3. Given  я выбрал получателя
   When   я ввожу сумму (от 10 до 100 000 рублей)
   Then   система показывает комиссию (0,5%) и итоговую сумму

4. Given  я ввёл все данные
   When   я нажимаю "Подтвердить"
   Then   система просит подтверждение через биометрию (отпечаток пальца)

5. Given  я прошёл биометрическую аутентификацию
   When   система обрабатывает платёж
   Then   я вижу сообщение "Платёж успешно отправлен"
   And    платёж появляется в истории транзакций
   And    получатель получает уведомление о переводе

6. Given  произошла ошибка (например, недостаточно средств)
   When   система обрабатывает платёж
   Then   я вижу понятное сообщение об ошибке
   And    мне предлагается исправить ошибку или отменить

Notes (Дополнительно):
- Комиссия различается для разных типов счётов
- Нужна защита от fraud (максимум переводов в сутки)
- История сохраняется минимум на год

Пример 2: Просмотр выписки по счёту (детальный)

User Story ID: BANK-002
Приоритет: Высокий
Оценка: 3 story points

Title: Просмотр выписки по счёту

As a          → клиент банка
I want        → смотреть все транзакции по своему счёту
So that       → контролировать свои расходы и доходы

Acceptance Criteria:
--------------------
1. Отображение списка транзакций
   When   я открываю счёт
   Then   я вижу последние 10 транзакций по умолчанию
   And    каждая транзакция показывает:
        - Дату и время
        - Описание (например, "Оплата коммунальных услуг")
        - Контрагента (кому переведено или от кого получено)
        - Сумму (красная для расходов, зелёная для доходов)
        - Статус (завершено, в ожидании, отклонено)

2. Фильтрация по датам
   When   я нажимаю на фильтр "Период"
   Then   я могу выбрать диапазон дат
   And    список транзакций обновляется
   And    система показывает: всего входящих, всего исходящих, баланс

3. Поиск по описанию
   When   я ввожу текст в поле поиска
   Then   список фильтруется по совпадающим транзакциям
   Example: ввожу "Яндекс" → вижу все платежи Яндексу

4. Категоризация расходов
   When   я прокручиваю список
   Then   транзакции сгруппированы по категориям:
        - Питание
        - Транспорт
        - Развлечения
        - Зарплата
        - Коммунальные услуги
        - Прочее
   And    каждая категория показывает общую сумму

5. Детали транзакции
   When   я нажимаю на транзакцию
   Then   открывается экран с полной информацией:
        - Дата, время, ID платежа
        - ФИО отправителя и получателя
        - Статус
        - Назначение платежа
        - Комиссия
   And    я могу экспортировать в PDF
   And    я могу повторить платёж (если это возможно)

Edge Cases:
-----------
- Пустой счёт (нет транзакций) → показать сообщение "Нет транзакций"
- Загрузка большого файла (год данных) → показать прогресс
- Сбой при загрузке → предложить повторить

Пример 3: Пополнение счёта через QR-код (с зависимостями)

User Story ID: BANK-003
Приоритет: Средний
Оценка: 8 story points
Dependencies: BANK-001 (функция перевода должна быть готова)

Title: Пополнение счёта через QR-код платежной системы

As a          → клиент банка
I want        → отсканировать QR-код и пополнить счёт
So that       → быстро оплатить счета в кафе/магазине

Acceptance Criteria:
--------------------

1. Открытие камеры
   When   я нажимаю иконку камеры на главной странице
   Then   приложение запрашивает разрешение на доступ к камере
   And    я вижу поле для сканирования QR-кода

2. Сканирование QR
   When   я наведу камеру на QR-код
   Then   система распознаёт и декодирует QR
   And    если QR валидный, показывает детали платежа:
        - Сумма
        - Получатель
        - Назначение (опционально)

3. Валидация данных
   When   система получает QR
   Then   проверяет:
        - Формат (должен быть EMV QR или аналогичный стандарт)
        - Сумма в допустимых пределах (0-500 000 РУБ)
        - Получатель есть в белом списке
   If     QR невалидный → показать ошибку "Неверный QR-код"

4. Подтверждение платежа
   When   я вижу детали платежа
   Then   я могу:
        - Изменить сумму (если QR это позволяет)
        - Выбрать счёт (если их несколько)
        - Добавить комментарий
   And    я нажимаю "Оплатить"
   And    требуется подтверждение биометрией

5. Результат
   When   платёж обработан
   Then   вижу экран успеха с QR-кодом чека
   And    могу поделиться чеком (WhatsApp, Email)

Technical Notes:
- Использовать библиотеку ML Kit для распознавания QR
- Поддержка стандартов: EMV QR, SBQR (РФ)
- Timeout на сканирование: 30 сек

Структура хорошей User Story

┌─────────────────────────────────────┐
│ Title (краткое название)            │
├─────────────────────────────────────┤
│ Narrative (As a... I want... So...) │
├─────────────────────────────────────┤
│ Acceptance Criteria (Given/When/Then)│
├─────────────────────────────────────┤
│ Mockups (если есть)                 │
├─────────────────────────────────────┤
│ Risks / Dependencies                │
├─────────────────────────────────────┤
│ Story Points (оценка)               │
├─────────────────────────────────────┤
│ Additional Notes                    │
└─────────────────────────────────────┘

Best Practices для User Stories

Хорошая User Story

  • INVEST принцип:
    • Independent — не зависит от других
    • Negotiable — можно обсуждать детали
    • Valuable — даёт ценность пользователю
    • Estimable — команда может оценить
    • Small — завершается за 1-2 спринта
    • Testable — можно протестировать

Типичные ошибки

  • Слишком крупные (Epic вместо Story)
  • Технические детали вместо потребностей пользователя
  • Нечёткие критерии приёмки
  • Отсутствие контекста "почему"

Связь с требованиями

Разные уровни детализации:

Epic (очень крупно):
"Система переводов денег между пользователями"

User Stories (средний уровень):
- BANK-001: Перевод на счёт в том же банке
- BANK-004: Перевод на счёт в другом банке
- BANK-005: Отмена незавершённого перевода

Tasks (очень детально):
- Разработать API endpoint PUT /transfers/{id}/cancel
- Написать unit тесты
- Обновить документацию

Вывод

User Story — это мост между бизнесом и разработкой. Хорошая User Story:

  • Ориентирована на конечного пользователя
  • Имеет чёткие критерии приёмки (Given/When/Then)
  • Описывает ценность, а не только функцию
  • Управляемого размера (завершается за 1-2 недели)
  • Отделена от технических деталей

Для мобильного банка особенно важны: usability, security, reliability и performance. User Story должна учитывать все эти аспекты через acceptance criteria.