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

Пример функциональных требований для системы управления задачами (Task Management System)

Функциональные требования (Functional Requirements, FR) описывают что должна делать система, ее конкретные возможности и поведение с точки зрения пользователя. Они отвечают на вопрос: "Какие функции и сервисы предоставляет система?". Приведу структурированный пример для гипотетической веб-системы управления задачами — TaskFlow.

1. Управление пользователями и аутентификация

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

• FR-1.1: Регистрация нового пользователя. Неавторизованный пользователь должен иметь возможность создать новую учетную запись, заполнив форму.

    *   **Входные данные:** Имя, email (уникальный), пароль (соответствующий политике безопасности).
    *   **Действие системы:** Валидация email, хеширование пароля, создание записи в БД, отправка email для подтверждения.
    *   **Выходные данные:** Сообщение об успешной регистрации и инструкция по подтверждению email. Учетная запись остается неактивной до подтверждения.

• FR-1.2: Аутентификация пользователя. Пользователь должен иметь возможность войти в систему, используя email и пароль.

    *   **Входные данные:** Email и пароль.
    *   **Действие системы:** Проверка совпадения хеша пароля, проверка активности учетной записи.
    *   **Выходные данные:** Создание и выдача сессионного токена (JWT), перенаправление на личную панель управления (dashboard). В случае ошибки — соответствующее сообщение.

// Пример ответа API на успешный вход (FR-1.2)
{
  "status": "success",
  "data": {
    "user": {
      "id": 123,
      "name": "Иван Петров",
      "email": "ivan@example.com"
    },
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
}

2. Управление проектами

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

• FR-2.1: Создание проекта. Авторизованный пользователь может создать новый проект.

    *   **Входные данные:** Название проекта (обязательно), описание (опционально), цветовая метка.
    *   **Действие системы:** Сохранение проекта в БД, автоматическое назначение создателя владельцем проекта.
    *   **Выходные данные:** Новый проект отображается в интерфейсе пользователя. Возвращается объект проекта с уникальным ID.

• FR-2.2: Приглашение участников в проект. Владелец проекта может пригласить других пользователей системы в проект.

    *   **Входные данные:** Email приглашаемого пользователя и уровень доступа (`участник`, `редактор`, `администратор`).
    *   **Действие системы:** Проверка существования пользователя, отправка email-уведомления с уникальной ссылкой-приглашением, добавление связи "пользователь-проект" после принятия приглашения.

3. Управление задачами (Core Functionality)

Это ядро системы. Пользователь должен иметь возможность выполнять полный цикл работы с задачами.

• FR-3.1: Создание задачи. Авторизованный пользователь в рамках доступного ему проекта может создать задачу.

    *   **Входные данные:** Заголовок задачи (обязательно), подробное описание, срок исполнения (`due_date`), приоритет (`низкий`, `средний`, `высокий`), назначенный исполнитель (из списка участников проекта).
    *   **Действие системы:** Сохранение задачи в БД в статусе `Открыта`. Создание активности в ленте проекта.

• FR-3.2: Изменение статуса задачи. Пользователь с правами на редактирование задачи может изменить ее статус, перетаскивая на соответствующую колонку на доске (Kanban).

    *   **Допустимые статусы:** `Открыта` -> `В работе` -> `На ревью` -> `Завершена`.
    *   **Действие системы:** Обновление записи в БД. Автоматическое обновление UI доски. Если статус изменен на `Завершена`, система фиксирует дату закрытия.

• FR-3.3: Фильтрация и поиск задач. Пользователь должен иметь возможность фильтровать задачи в рамках проекта или глобально.

    *   **Критерии фильтрации:** По статусу, исполнителю, приоритету, наличию срока исполнения, тексту в заголовке и описании.
    *   **Действие системы:** Формирование и выполнение параметризованного SQL-запроса к БД.

```sql
-- Примерная логика запроса для FR-3.3 (фильтр: высокий приоритет, конкретный исполнитель)
SELECT t.id, t.title, t.status, u.name as assignee_name
FROM tasks t
JOIN users u ON t.assignee_id = u.id
WHERE t.project_id = :projectId
  AND t.priority = 'high'
  AND t.assignee_id = :assigneeId
  AND t.status != 'archived'
ORDER BY t.due_date ASC;
```

4. Уведомления и отчетность

Система должна информировать пользователей о важных событиях и предоставлять сводные данные.

• FR-4.1: Отправка уведомлений. Система должна отправлять пользователям уведомления в реальном времени и/или по email.

    *   **События-триггеры:** Назначение на задачу, комментарий к задаче, приближение или истечение срока исполнения задачи, приглашение в проект.
    *   **Действие системы:** Помещение события в очередь сообщений (например, RabbitMQ), обработка воркером и отправка через соответствующий канал (WebSocket, SMTP).

• FR-4.2: Формирование отчета по проекту. Владелец проекта должен иметь возможность сгенерировать PDF-отчет о состоянии проекта.

    *   **Содержание отчета:** Общее количество задач, распределение по статусам, список просроченных задач, диаграмма "Завершенные задачи за последние 30 дней".
    *   **Действие системы:** Агрегация данных из БД, формирование HTML-шаблона, конвертация в PDF с помощью headless Chrome (Puppeteer) или библиотеки (например, wkhtmltopdf).

Ключевые принципы формулирования требований:

• Ориентация на пользователя: Каждое требование описывает функцию с точки зрения роли пользователя (например, "Пользователь может...").
• Тестируемость: Требование должно быть сформулировано так, чтобы QA-инженер мог на его основе создать однозначный тестовый сценарий. Например, для FR-1.2 можно написать тест: "Ввод валидного email и пароля -> перенаправление на dashboard".
• Атомарность: Каждое требование описывает одну конкретную функцию.
• Однозначность: Использование четких терминов, исключение двусмысленностей ("быстро", "удобно" заменяются на измеримые параметры).
• Приоритизация: Каждому требованию обычно присваивается приоритет (Must Have, Should Have, Could Have, Won't Have) по методологии MoSCoW.

Данный пример демонстрирует, как функциональные требования (поведение системы) отделены от нефункциональных (как система это делает: производительность, безопасность, юзабилити). Такой структурированный подход является основой для создания технического задания, оценки трудозатрат и успешной реализации проекта.