Приведи пример функционального требования для мобильного банка

Функциональное требование для мобильного банка: подробный пример

Определение функционального требования

Функциональное требование (Functional Requirement, FR) — это чёткое описание того, что должна делать система, описанное с точки зрения функциональности и поведения, независимо от того, как это технически будет реализовано.

Структура типичного FR:

• ID и название
• Описание функции
• Входные и выходные данные
• Правила обработки
• Граничные случаи
• References и зависимости

Пример 1: Настройка автоматических платежей (детальный)

═══════════════════════════════════════════════════════════════
FREQ-BANK-0015
Название: Создание и управление автоматическими платежами
Приоритет: Высокий
Аффектирует: Billing Service, Scheduler Service
═══════════════════════════════════════════════════════════════

1. OVERVIEW
─────────
Система должна позволять пользователям настроить автоматические
перечисления денег (например, для оплаты счетов) по заданному
расписанию без ручного подтверждения каждый раз.

2. ВХОДНЫЕ ДАННЫЕ (INPUTS)
──────────────────────────
Пользователь предоставляет:

• Получатель платежа
  - Выбрать из:
    * Сохранённые бенефициары
    * Новый бенефициар (счёт/телефон)
  - Обязательное поле

• Сумма платежа
  - Тип: Decimal (2 знака)
  - Диапазон: 10.00 - 500,000.00 RUB
  - Можно: пустая (= переменная сумма, видит в день платежа)
  - Обязательное

• Расписание платежа
  - Опции:
    * Ежемесячно: день месяца (1-28, или "последний день")
    * Еженедельно: день недели (пн-вс)
    * Один раз: конкретная дата
  - Обязательное

• Дата первого платежа
  - Не может быть в прошлом
  - Не раньше завтрашнего дня
  - Обязательное

• Дата последнего платежа (опционально)
  - Если не указана = платежи идут бесконечно
  - Если указана = система прекращает платежи после этой даты
  - Не может быть раньше даты первого платежа

• Комментарий (опционально)
  - Максимум 100 символов
  - Пример: "Оплата интернета"

• Категория расходов (опционально, но желательно)
  - Выпадающий список: Коммунальные, Интернет, Подписка, Прочее
  - Используется для аналитики

3. ПРОЦЕСС ОБРАБОТКИ
────────────────────

### 3.1 Валидация

Система должна проверить:

✓ Сумма платежа
  • Не ноль
  • Не больше доступных средств на счёте (плюс лимит овердрафта если есть)
  • Соответствует лимитам: макс платёж 500k, макс в месяц 5M
  ERROR: "Сумма выходит за пределы лимита"

✓ Получатель
  • Проверить, не заблокирован ли он (blacklist)
  • Проверить IBAN/account валидность
  • Проверить, совпадает ли имя счёта с именем бенефициара
  ERROR: "Получатель заблокирован по соображениям безопасности"

✓ Расписание
  • Минимум 3 дня между платежами
  • День месяца: если выбран 31-й, а месяц только 28 дней → ошибка
  ERROR: "Некорректное расписание"

✓ Лимиты пользователя
  • Максимум 20 активных автоплатежей
  • Максимум 10 новых в месяц (от fraud)
  ERROR: "Превышен лимит на количество платежей"

### 3.2 Требование подтверждения

Для первого автоплатежа:

Если сумма:
  • < 5000 RUB → только PIN / пароль
  • 5000-50000 → PIN + SMS code
  • > 50000 → PIN + SMS + биометрия + позвонить в call center

### 3.3 Сохранение

Система должна:

1. Создать запись в таблице Auto_Payments:

id: UUID user_id: UUID beneficiary_id: UUID amount: Decimal currency: VARCHAR (RUB по умолчанию) schedule_type: ENUM (MONTHLY, WEEKLY, ONCE) schedule_day: INT start_date: TIMESTAMP end_date: TIMESTAMP (nullable) status: ENUM (ACTIVE, PAUSED, CANCELLED) comment: VARCHAR(100) category: VARCHAR created_at: TIMESTAMP updated_at: TIMESTAMP created_by_ip: VARCHAR

2. Зарегистрировать в аудит-логе:

event: "AUTO_PAYMENT_CREATED" user_id: UUID old_data: null new_data: {auto_payment_id, beneficiary, amount, schedule} timestamp: now() ip_address: user_ip user_agent: browser_info

3. Запланировать первый платёж в Scheduler:

scheduled_for: <start_date> type: AUTO_PAYMENT reference_id: <auto_payment_id> retry_count: 0

### 3.4 Результат (OUTPUT)

После успешного создания система должна:

1. Вернуть в UI:

{

     "success": true,
     "auto_payment_id": "550e8400-e29b-41d4-a716-446655440000",
     "status": "ACTIVE",
     "next_payment_date": "2026-04-15",
     "message": "Автоплатёж создан. Первый платёж: 15 апреля"

}

2. Отправить push-notification:
- Title: "Автоплатёж активен"
- Body: "[Получатель], [Сумма] каждый месяц"
- Action: "Открыть детали"

3. Отправить email:
- Subject: "Подтверждение настройки автоплатежа"
- Content: полные детали платежа, дата отписки, контакт support

4. Показать в списке на экране "Мои платежи"

4. БИЗНЕС-ПРАВИЛА
──────────────────

### 4.1 Лимиты и ограничения

**По сумме:**
- Минимум: 10 RUB
- Максимум за платёж: 500,000 RUB
- Максимум в месяц: 5,000,000 RUB (сумма всех автоплатежей)

**По количеству:**
- Максимум 20 активных автоплатежей
- Максимум 10 новых в месяц (freeze на 30 дней после 10-го)

**По сроку:**
- Минимум 3 дня между платежами
- Максимум 1 год в будущее для end_date

### 4.2 Поведение при недостаточных средств

Если в день платежа средств недостаточно:

1. **Первое срабатывание:**
- Отправить SMS: "Недостаточно средств для платежа [X]"
- Статус платежа: PENDING
- Retry: через 1 день (в 12:00)

2. **Второе срабатывание (день 2):**
- Повторить попытку
- Если не прошёл: статус FAILED
- Уведомление пользователю
- Retry: через 2 дня

3. **Третьего срабатывания (день 4):**
- Финальная попытка
- Если не прошла: установить статус PAUSED
- Отправить SMS и email: "Платёж заморожен. Пополните счёт."
- Пользователь может вручную возобновить (RESUME)

### 4.3 Отмена и пауза

Пользователь может:

**Пауза (PAUSE)**
- На время (до даты X) или навсегда
- Возобновить в любой момент (RESUME)
- Нет комиссий за паузу

**Отмена (CANCEL)**
- Необратима
- Требует подтверждения
- История остаётся в Audit Log

5. ГРАНИЧНЫЕ СЛУЧАИ (EDGE CASES)
─────────────────────────────────

**День месяца (например, 31-е число):**
- Февраль не имеет 31-го
- Опции: ошибка или автоматически перейти на последний день месяца
- Выбираем: автоматически перейти на последний день

**Блокировка платежа со стороны fraud system:**
- Если fraud detection выявил подозрение
- Платёж переходит в статус BLOCKED
- SMS: "Платёж заблокирован. Позвоните для подтверждения"

**Пользователь заблокирован:**
- Если аккаунт заблокирован по compliance
- Все активные платежи переходят в SUSPENDED
- Возобновляются автоматически, если аккаунт разблокирован

**Бенефициар удалён:**
- Если пользователь удалил бенефициара
- Автоплатёж переходит в статус BLOCKED
- SMS: "Не можем провести платёж: получатель не найден"

6. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ (LINK)
──────────────────────────────────────
См. NFREQ-PERFORMANCE-001: Все операции < 2 сек
См. NFREQ-SECURITY-015: Все платежи заводятся в БД с шифрованием
См. NFREQ-AVAILABILITY-008: Scheduler должен быть 99.99% доступен

7. ACCEPTANCE CRITERIA
──────────────────────
✓ Пользователь может создать автоплатёж за 2 минуты
✓ Не может установить сумму больше лимита
✓ Первый платёж совпадает с заданной датой
✓ Все данные шифруются при сохранении
✓ История всех операций логируется
✓ Пользователь получает подтверждение по email и SMS
✓ Система обрабатывает ошибки без обрывов
✓ При недостаточных средствах — retry механизм работает

8. ЗАВИСИМОСТИ
───────────────
- Billing Service (для расчёта комиссий)
- Notification Service (SMS, email, push)
- Fraud Detection (проверка платежа)
- Scheduler Service (планирование платежей)
- Audit Log Service

Пример 2: Покороче (Более простое требование)

═══════════════════════════════════════════════════════════════
FREQ-BANK-0032
Название: Категоризация расходов
═══════════════════════════════════════════════════════════════

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

Категории:
• Питание (рестораны, кафе, продукты)
• Транспорт (такси, общественный транспорт, заправки)
• Развлечения (кино, музеи, билеты)
• Подписки (Netflix, Spotify, облако)
• Коммунальные (ЖКХ, интернет, электричество)
• Медицина
• Образование
• Шопинг
• Другое

Правила категоризации:
1. По name получателя (если совпадает с regex)
2. По category кода платежа (ISO)
3. Если не совпадает ничего → "Другое"

Пользователь может:
• Переопределить категорию вручную
• Система запомнит и будет использовать это правило

Проверка:
• Статистика по категориям показывается верно
• Исправления сохраняются

Ключевые элементы функционального требования

Отличие FR от Requirements

Requirements (широко):

• Бизнес-требования: "Увеличить конверсию на 10%"
• Функциональные требования: "Пользователь может создать автоплатёж"
• Нефункциональные требования: "Платёж обрабатывается за 2 сек"

Функциональное требование (узко):

• Только описывает ВЧТ система делает
• Не описывает КАК она это делает (это дело архитектуры/разработки)
• Детально описывает входы, выходы, правила, ошибки

Вывод

Хорошее функциональное требование для мобильного банка должно:

1. Быть чётким — разработчик понимает, что нужно делать
2. Быть полным — включает граничные случаи и ошибки
3. Быть тестируемым — можно написать тесты
4. Быть реальным — соответствует бизнес-логике
5. Быть независимым — не зависит от других требований (если возможно)

В реальных проектах требований бывает 100+, и каждое должно быть на таком уровне детализации.