Как написать FRD: руководство по функциональным требованиям и примеры

FRD, или Functional Requirements Document, отвечает на вопрос, который следует за определением продукта: как должна вести себя система. Он переводит продуктовые требования в конкретные, тестируемые описания поведения системы — входы, выходы, бизнес-правила, обработку ошибок и потоки данных.

Там, где PRD говорит «пользователи должны иметь возможность сбросить пароль», FRD описывает точный сценарий: пользователь нажимает «Забыли пароль», вводит email, получает токен, действительный 30 минут, задаёт новый пароль, соответствующий правилам сложности, и видит экран подтверждения. FRD также описывает, что происходит, когда email не найден, когда токен истёк и когда новый пароль не проходит валидацию.

Key insight

FRD — это контракт между продуктом и инженерами. Продукт определяет, что строить (PRD), а FRD определяет, как система должна себя вести, чтобы инженеры могли её реализовать, а QA — проверить.

Кто пишет и для кого

Владелец FRD — обычно бизнес-аналитик, технический продакт-менеджер или системный аналитик — специалист, способный перевести бизнес-потребности в точные описания поведения системы.

Читатель	Что ищет в документе
Разработчики	Точное поведение, потоки данных, бизнес-правила, граничные случаи
QA / тест-инженеры	Критерии приёмки, ошибочные состояния, тестируемые условия
Архитекторы	Точки интеграции, модели данных, границы системы
UX-дизайнеры	Сценарии взаимодействия, правила валидации, сообщения об ошибках
Проектные менеджеры	Границы скоупа, маппинг зависимостей

Key insight

В отличие от BRD (его читают руководители) или PRD (его читает продуктовая команда), FRD — технический документ. Его основные читатели — те, кто будет строить и тестировать систему.

Когда FRD нужен — а когда нет

FRD нужен, когда:

В системе сложные бизнес-правила, которые необходимо зафиксировать до начала разработки
Несколько команд или внешних подрядчиков нуждаются в однозначном описании поведения системы
Регуляторные или комплаенс-требования предполагают прослеживаемые, аудируемые требования
Проект включает интеграцию с внешними системами, где контракты данных нужно определить заранее
QA требуется формальная основа для разработки тест-кейсов

FRD не нужен, когда:

Небольшая agile-команда владеет всем продуктом и работает по user stories с критериями приёмки
PRD достаточно детализирован, чтобы инженеры могли вывести функциональное поведение напрямую
Используется AI-Optimized PRD с фазами и тестируемыми результатами — PRD уже выполняет роль облегчённого FRD
Проект — прототип или proof of concept, где формальные спецификации замедлят обучение

На практике решение зависит от размера команды и организационной сложности. Стартап из пяти человек редко пишет FRD. Банк, строящий систему обработки платежей, пишет его всегда.

Что содержит FRD

Основные секции

Хорошо структурированный FRD обычно включает семь секций:

Введение — цель документа, скоуп системы, определения терминов и ссылки на связанные документы (PRD, BRD, архитектурные документы). Введение устанавливает границы: что этот FRD покрывает и что явно исключает.
Функциональные требования — ядро документа. Каждое требование описывает конкретное поведение системы с уникальным идентификатором, описанием, входами, выходами, бизнес-правилами и приоритетом.

Хорошее функциональное требование соответствует пяти критериям:
- Конкретное — нет пространства для интерпретации
- Измеримое — можно проверить, выполнено ли оно
- Атомарное — одно поведение на требование
- Прослеживаемое — связано с бизнес-требованием или user story через идентификатор
- Приоритизированное — must-have, should-have или nice-to-have
Конвенция: «shall» для обязательных требований, «should» для опциональных. «The system shall validate the email format before sending the reset link» — однозначно. «The system should support SSO» — оставляет пространство для обсуждения скоупа.
Нефункциональные требования — целевые показатели производительности, стандарты безопасности, SLA доступности, ожидания по масштабируемости и требования доступности. Эта секция описывает, насколько хорошо система должна работать, а не что она делает.
Требования к данным — модели данных, связи между сущностями, словарь данных (имена полей, типы, ограничения, правила валидации) и политики хранения данных. Эта секция предотвращает ситуацию, когда разработчики обнаруживают в середине спринта, что критическое поле не было определено.
Требования к интерфейсам — как система взаимодействует с пользователями (UI-спецификации), с другими внутренними системами (API, очереди сообщений) и с внешними сервисами (интеграции с третьими сторонами, потоки данных). Для проектов с большим количеством API эта секция может вырасти до отдельного API FRD.
Критерии приёмки — тестируемые условия, определяющие, когда каждое функциональное требование считается выполненным. Критерии приёмки связывают FRD с планом тестирования: если критерий пройден, требование выполнено.
Приложения — вайрфреймы, мокапы UI, блок-схемы, диаграммы состояний, глоссарий и журнал изменений. Визуальные материалы размещаются здесь, а не инлайн — они поддерживают требования, но не должны заменять точные текстовые описания.

Key insight

Разница между хорошим и посредственным FRD — в секции 2: самих функциональных требованиях. Расплывчатые требования («система должна корректно обрабатывать ошибки») приводят к расплывчатым реализациям. Конкретные требования («система должна отобразить код ошибки E-401 с сообщением “Сессия истекла” и перенаправить на страницу входа в течение 3 секунд») приводят к тестируемому коду.

Написание функциональных требований: конвенция идентификаторов

Каждое требование в FRD получает уникальный идентификатор. Это обеспечивает прослеживаемость — от бизнес-требования к функциональному требованию и далее к тест-кейсу.

Распространённый формат:

ID	Требование	Приоритет	Источник
FR-001	Система должна позволять пользователям регистрироваться с email и паролем	Must	PRD §3.1
FR-002	Система должна отправлять письмо для подтверждения в течение 60 секунд после регистрации	Must	PRD §3.1
FR-003	Система должна блокировать аккаунт после 5 последовательных неудачных попыток входа	Must	SEC-01
FR-004	Система может поддерживать вход через Google OAuth 2.0	Should	PRD §3.2

Колонка «Источник» связывает каждое требование с PRD, BRD или политикой безопасности. Эта прослеживаемость важна в регулируемых отраслях, где аудиторы должны убедиться, что каждая бизнес-потребность покрыта функциональным требованием, а каждое функциональное требование — тест-кейсом.

Варианты FRD

Вариант	Когда использовать	Ключевая характеристика
Стандартный FRD	Корпоративные системы, сложная бизнес-логика	Полная структура из семи секций
API FRD	API-продукты, микросервисы	Фокус на эндпоинтах, схемах, кодах ошибок
Облегчённый FRD	Agile-команды, меньший скоуп	Только таблица требований + критерии приёмки

API FRD — вариант для систем, где основной интерфейс — API, а не пользовательский интерфейс.

FRD и другие документы требований

FRD занимает техническую сторону в цепочке документов требований:

MRD → BRD → PRD → FRD → SRD

Документ	Вопрос	Уровень
MRD	«Что нужно рынку?»	Стратегический
BRD	«Зачем бизнесу инвестировать?»	Стратегический
PRD	«Что мы строим?»	Тактический
FRD	«Как должна вести себя система?»	Технический
SRD/SRS	«Каковы полные технические спецификации?»	Технический

FRD принимает входные данные от PRD (или напрямую от BRD в сценариях аутсорсинга) и формирует выходные данные, которые разработчики используют для написания кода, а QA — для написания тестов. В некоторых организациях FRD и SRS объединяются в один документ.

PRD → FRD: PRD говорит «пользователи могут сбросить пароль». FRD определяет каждый шаг, валидацию, ошибочное состояние и граничный случай этого сценария.
BRD → FRD (аутсорсинг): Когда внешний подрядчик строит систему, заказчик предоставляет BRD + FRD. FRD заменяет PRD, потому что подрядчику не нужна продуктовая стратегия — ему нужны точные спецификации поведения.

Типичные ошибки

1. Смешение требований с дизайном. «Кнопка сброса должна быть синей, высотой 44px, расположена в правом верхнем углу» — это дизайн-спецификация, а не функциональное требование. FRD описывает поведение, дизайн-система описывает внешний вид.

2. Нетестируемые требования. «Система должна быть удобной для пользователя» невозможно проверить. «Система должна позволять новому пользователю завершить регистрацию менее чем за 3 минуты» — проверяемое утверждение.

3. Пропущенные ошибочные состояния. Основной сценарий (happy path) легко описать. Ценность FRD — в покрытии того, что происходит, когда что-то идёт не так: невалидный ввод, истёкшие сессии, сетевые сбои, параллельные изменения и лимиты запросов.

4. Отсутствие идентификаторов требований. Без идентификаторов требования невозможно связать с тест-кейсами, запросы на изменения не могут ссылаться на конкретные пункты, а анализ влияния изменений становится гаданием.

5. FRD написан слишком рано. FRD, написанный до утверждения PRD, рискует специфицировать поведение для функций, которые будут вырезаны. FRD следует за PRD, а не наоборот.

Тренд 2026: FRD как входные данные для AI-агентов разработки

В 2026 году FRD служит двойной цели. Инженеры по-прежнему читают его, но AI-агенты разработки (Cursor, Claude Code, GitHub Copilot Workspace) также используют его как структурированные инструкции.

Это меняет способ написания FRD:

Требования хранятся в markdown-файлах в репозитории, а не в Confluence или Google Docs, чтобы AI-агенты могли читать их вместе с кодом.
Каждое требование включает критерии приёмки как тестируемые условия, которые AI-агенты могут напрямую преобразовать в тест-кейсы.
FRD и техническая спецификация всё больше сливаются в один документ на фичу, снижая переключение контекста как для людей, так и для AI-агентов.

Тренд не меняет содержание FRD — он меняет место хранения и формат.

Ресурсы

Шаблоны FRD — стандартный и API, готовы к использованию
Промпт-генератор FRD — создайте FRD с помощью ИИ
API FRD — вариант FRD для API-продуктов
PRD vs BRD vs FRD — тройное сравнение
PRD — полное руководство — документ, который питает FRD
Промпт-навигатор — подберите нужный тип документа