Что такое FR?

FR (Functional Requirements): Определение и применение

FR — это функциональные требования, которые определяют ЧТО система должна делать. Это основа для разработки и тестирования. FR отвечают на вопрос "что система делает", в отличие от NFR (non-functional requirements), которые отвечают на вопрос "как хорошо это делает".

FR vs NFR: Ключевая разница

Functional Requirements (FR) — ЧТО делать:

• User может авторизоваться через email и пароль
• System отправляет confirmation email
• User может добавить товар в корзину
• Admin может заблокировать пользователя

Non-Functional Requirements (NFR) — КАК хорошо делать:

• Login должен завершиться за < 200ms
• System должна выдержать 10,000 одновременных пользователей
• Email отправляется в течение 5 минут
• Passwords шифруются с bcrypt

Типы Functional Requirements

1. User Interaction Requirements

Что может делать user в системе:

- Авторизация и регистрация
- Поиск и фильтрация
- Создание, редактирование, удаление
- Экспорт и импорт данных
- Скачивание отчетов

2. Data Management Requirements

Какие данные сохранять и как:

FR-001: System должна сохранять Order с полями:
- order_id (уникальный)
- customer_id (обязателен)
- items (список товаров)
- total_price
- status (draft, pending, confirmed, shipped, delivered)
- created_at, updated_at

FR-002: System должна удалять user data через 30 дней
после запроса (GDPR compliance)

FR-003: System должна сохранять историю всех платежей
для audit trail

3. System Integration Requirements

Интеграция с внешними системами:

FR-004: System интегрируется с Stripe для обработки платежей
FR-005: System получает email events из SendGrid webhook
FR-006: System синхронизирует inventory с 1C ERP
FR-007: System отправляет уведомления через Firebase Push

4. Business Logic Requirements

Правила вычисления и бизнес-логика:

FR-008: Total price = (item_price * quantity) - discount + tax
FR-009: Discount code может использоваться только 1 раз
FR-010: VIP users получают 10% скидку автоматически
FR-011: Order отменяется если payment не прошел в течение 1 часа

Структура документирования FR

Вот как я документирую FR в проектах:

FR-001: User Authentication

Description:
System должна позволить пользователю авторизоваться
с email и password для доступа к personal dashboard

Trigger:
Пользователь открывает /login страницу

Preconditions:
- User account существует в системе
- Email подтвержден
- Account не заблокирован

Main Flow:
1. User вводит email
2. User вводит пароль
3. User нажимает "Login" button
4. System валидирует credentials
5. System проверяет 2FA (если включена)
6. System создает session
7. System редиректит на /dashboard

Alternative Flows:
A1: Неправильный пароль
  3a. System показывает "Invalid password"
  3b. User может попробовать снова
  3c. После 5 попыток — account заблокирован на 15 минут

A2: Account не существует
  2a. System показывает "No account with this email"
  2b. User может нажать "Sign up"

A3: Account заблокирован
  1a. System показывает "Account locked for 15 minutes"
  1b. User может нажать "Forgot password"

Postconditions:
- User авторизован
- Session token в HTTP cookie (HttpOnly, Secure)
- Audit log записан (email, time, IP address)
- Last login updated

Business Rules:
- Max 5 failed попыток за 15 минут
- Session истекает через 24 часа
- Password должен быть >= 8 символов
- Password не может быть одной из 5 последних паролей
- Email case-insensitive, password case-sensitive

Non-Functional:
- Response time < 200ms
- Support для Chrome, Firefox, Safari, Edge
- Mobile responsive

Dependencies:
FR-002 (Password Reset)
FR-003 (Email Verification)
FR-004 (Two Factor Authentication)

Priority: CRITICAL
Status: Active
Owner: Backend Team

Реальный пример: E-commerce Shopping Cart

## Shopping Cart Functional Requirements

FR-100: Add to Cart
- User может добавить товар в корзину
- Можно выбрать размер, цвет, количество
- Количество >= 1
- System проверяет наличие товара
- При добавлении показывается toast notification

FR-101: Cart Persistence
- Товары в корзине сохраняются между сессиями
- Если user авторизован — сохраняется в БД
- Если анонимный — сохраняется в localStorage
- При авторизации — локальная корзина мержится с БД

FR-102: Update Quantity
- User может изменить количество
- Quantity не может быть < 1
- Если quantity > available stock — error message
- Цена обновляется сразу

FR-103: Remove from Cart
- User может удалить товар
- Item удаляется сразу
- "Undo" доступна 5 секунд

FR-104: Apply Discount
- User может ввести discount code
- System валидирует код
- Discount применяется перед tax

FR-105: Checkout
- User может перейти на checkout
- Требуется авторизация
- Shipping address обязателен
- Доступные способы доставки с ценой

FR-106: Order Confirmation
- После платежа создается Order
- Корзина очищается
- Confirmation email отправляется
- Order tracking доступен

Мой процесс сбора FR

1. Интервью со stakeholders

Вопросы:
- Какие actions может делать user?
- Какие данные нужно сохранять?
- Какие правила применяются?
- Какие системы интегрировать?
- Какие отчеты нужны?

2. Анализ конкурентов

Вопросы:
- Что делает конкурент?
- Чем мы отличаемся?
- Какие фичи обязательны?

3. Документирование FR

Формат: description, trigger, main flow, error cases
Business rules и dependencies
Priority и owner

4. Review с разработчиком

Вопросы:
- Это реализуемо в timeline?
- Нужны ли clarifications?
- Какие технические constraints?

Best Practices для FR

Хорошие FR:

• Конкретные и проверяемые
• Не содержат реализацию (не говорят "как", только "что")
• Покрывают happy path и error cases
• Имеют clear acceptance criteria
• Документируют dependencies

Плохие FR:

❌ "System должна быть user-friendly"
✅ "User может добавить товар за <= 3 клика"

❌ "Система должна быть быстра"
✅ "Search возвращает результаты за <= 500ms"

❌ "Использовать React для frontend"
✅ "Frontend должна работать на всех современных браузерах"

Инструменты для FR

• Jira — прямо в task description
• Confluence — для больших документов
• Google Docs — для collaboration
• Miro — для визуализации flows
• Figma — для дизайна с annotated requirements

Хорошие FR — это инвестиция в качество разработки и скорость delivery.