Приведи пример функциональных требований

Приведи пример функциональных требований

Функциональные требования описывают, ЧТО система должна делать. Дам несколько реальных примеров разной сложности.

Пример 1: Простая фича — Система оценок в приложении

User Story:

Как пользователь, я хочу оценить заказ (1-5 звёзд),
чтобы помочь другим пользователям принять решение

Функциональные требования:

1. FR-1: Отображение формы оценки
   • После выполнения заказа пользователю показывается форма оценки
   • Форма содержит:

     - Масштаб 1-5 звёзд (можно кликнуть на каждую звезду)
     - Текстовое поле для комментария (максимум 500 символов)
     - Кнопка "Отправить" и "Пропустить"

• Форма показывается в течение 7 дней после заказа

1. FR-2: Отправка оценки

   • Пользователь кликает на звёзды (1-5)
   • Может добавить комментарий (опционально)
   • Кликает "Отправить"
   • Система отправляет оценку на сервер
   • Показывает сообщение "Спасибо за оценку!"
   • Форма закрывается

2. FR-3: Валидация

   • Если оценка не выбрана → кнопка "Отправить" неактивна (disabled)
   • Если комментарий длиннее 500 символов → показывается ошибка
   • Если нет интернета → показывается ошибка, сохраняется локально, отправляется при восстановлении

3. FR-4: Редактирование оценки

   • Пользователь может изменить оценку в течение 14 дней
   • Кликает на заказ → видит свою оценку
   • Может изменить звёзды и комментарий
   • Кликает "Обновить"
   • Система обновляет оценку

4. FR-5: Удаление оценки

   • Пользователь может удалить оценку
   • Появляется подтверждение: "Вы уверены?"
   • После удаления оценка не видна в профиле пользователя

5. FR-6: Отображение оценок другим пользователям

   • На странице товара показывается средняя оценка (1-5)
   • Показывается количество оценок: "4.5 ★ (342 оценки)"
   • При клике показывается распределение: 5★ 200, 4★ 100, 3★ 30, 2★ 10, 1★ 2
   • Показывается список последних комментариев (сортировка по свежести)

---

Пример 2: Средней сложности — Система приглашений в систему

User Story:

Как администратор, я хочу пригласить пользователя в проект,
чтобы он мог начать работать без создания нового аккаунта

Функциональные требования:

1. FR-1: Интерфейс приглашения
   • На странице проекта есть кнопка "Пригласить участника"
   • При клике открывается модальное окно
   • Поля формы:

     - Email адрес (required, валидировать формат)
     - Роль: Admin / Editor / Viewer (dropdown, по умолчанию Editor)
     - Сообщение (optional, макс 200 символов)

• Кнопки: "Отправить приглашение" и "Отмена"

1. FR-2: Валидация и дублирование

   • Email должен быть валидным (regex проверка)
   • Если пользователь с таким email уже есть в проекте → ошибка
   • Если приглашение уже отправлено и не принято → показать, что уже приглашен
   • Максимум 100 приглашений в час (rate limiting)

2. FR-3: Отправка приглашения

   • При клике "Отправить" система:

     - Создает invite token (32 символа, уникальный)
     - Сохраняет в БД с полями: email, role, status=pending, created_at, expires_at (7 дней)
     - Отправляет email с ссылкой: http://app.com/invite/{token}
     - Показывает сообщение администратору: "Приглашение отправлено на {email}"

1. FR-4: Откры ие приглашение пользователем
   • Пользователь кликает на ссылку в email
   • Система проверяет: token существует, не истёк (менее 7 дней), статус=pending
   • Если всё OK:

     - Если пользователь не залогинен → редирект на логин/регистрацию
     - Если пользователь залогинен → добавляет его в проект с указанной ролью
     - Показывает сообщение: "Вы добавлены в проект {project_name}"
     - Меняет статус invite на accepted

• Если токен истёк → показывает ошибку "Приглашение истекло"
• Если уже принято → показывает сообщение "Приглашение уже принято"

1. FR-5: Отмена приглашения

   • Администратор видит список отправленных приглашений
   • Может отменить приглашение, если оно ещё pending
   • После отмены email перестаёт работать
   • Показывает сообщение "Приглашение отменено"

2. FR-6: Повторная отправка

   • Если приглашение не принято за 7 дней, администратор может отправить ещё раз
   • Система создает новый token
   • Отправляет новый email
   • Старый token становится невалидным

---

Пример 3: Сложная фича — Система интеграции с внешним API

User Story:

Как пользователь, я хочу синхронизировать свои данные с Google Sheets,
чтобы работать с ними в привычном инструменте

Функциональные требования:

1. FR-1: Подключение Google Account (OAuth)
   • На странице "Интеграции" есть кнопка "Подключить Google"
   • При клике:

     - Открывается Google OAuth окно
     - Пользователь авторизуется
     - Приложение запрашивает permission: "Доступ к Google Sheets"
     - После одобрения, система сохраняет access_token и refresh_token
     - Показывает: "Google подключен для {user@gmail.com}"

1. FR-2: Выбор таблицы для синхронизации

   • Пользователь видит список его Google Sheets
   • Может выбрать одну таблицу
   • Выбирает лист (sheet) в таблице
   • Показывается preview первых 5 строк

2. FR-3: Настройка маппинга колонок

   • Система анализирует колонки в Google Sheet
   • Показывает форму для маппинга:

     - Колонка A (Name) → маппировать на поле "user_name"
     - Колонка B (Email) → маппировать на поле "email"
     - И т.д.

• Пользователь настраивает маппинг

1. FR-4: Одностороння синхронизация (Sheet → App)
   • Каждый день в 23:00 UTC система:

     - Получает текущие данные из Google Sheet
     - Сравнивает с последней синхронизацией
     - Добавляет новые строки в приложение
     - Обновляет существующие

• Логирует синхронизацию: кол-во добавленных, обновлённых, ошибок
• Если ошибка → отправляет email пользователю

1. FR-5: Обработка ошибок

   • Если access_token истек → используем refresh_token
   • Если refresh_token истек → показываем уведомление "Требуется повторная авторизация"
   • Если Google Sheet удален → показываем ошибку
   • Если маппинг некорректен → пропускаем строку, логируем ошибку
   • Если интернет нет → пробуем снова через 1 час

2. FR-6: История синхронизации

   • Пользователь видит список всех синхронизаций:

     - Дата и время
     - Статус (Success / Error)
     - Кол-во добавленных / обновлённых записей
     - Сообщение об ошибке (если есть)

• Может посмотреть детали каждой синхронизации

1. FR-7: Отключение интеграции
   • Пользователь может отключить синхронизацию
   • Google account остаётся подключенным

     - Можно снова включить синхронизацию

• Кнопка "Отключить Google" удаляет все tokens

     - Нужна повторная авторизация

---

Пример 4: Таблица всех функциональных требований (template)

Для каждого требования опиши:

---

Ключевые момент при описании FR

1. Быть специфичным

   • ❌ "Система должна быть быстрой"
   • ✅ "Страница должна загружаться за 3 секунды или быстрее"

2. Включать edge cases

   • Что если данных нет?
   • Что если пользователь бот?
   • Что если интернет упал?

3. Валидация

   • Какие ограничения на поля?
   • Какие форматы?
   • Какие ошибки?

4. Поведение системы

   • Что система делает после действия пользователя?
   • Какие данные сохраняются?
   • Какие уведомления отправляются?

5. Очередность

   • Что должно произойти сначала?
   • Какие данные зависят от других?

Это основа хорошей спецификации. Без FR разработчики гадают, что делать.