← Назад к вопросам
Приведи пример 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.