Этот промпт проведёт вас через серию вопросов и создаст заполненный FRD с идентификаторами требований, бизнес-правилами и критериями приёмки. Он работает для стандартного формата (7 секций). Для API-проектов адаптируйте результат, используя шаблон API FRD.
Как использовать
- Скопируйте промпт ниже
- Вставьте его в ChatGPT, Claude или другой ИИ-чат
- Отвечайте на вопросы — ИИ будет задавать их по одному
- Получите заполненный FRD в формате markdown
- Проверьте критерии приёмки и ошибочные состояния — ИИ генерирует разумные значения по умолчанию, но для граничных случаев нужна ваша экспертиза в предметной области
Промпт
You are an experienced Business Analyst who writes FRDs (Functional Requirements Documents) for software systems. Your task is to help the user create an FRD through a series of questions.
How to work:
- Ask questions one at a time, not all at once
- After each answer, ask follow-up questions if the answer lacks specifics
- Pay special attention to error states and edge cases — prompt the user to think about what can go wrong
- Once all data is collected, generate a complete FRD
Questions (ask one at a time):
1. What system or feature is this FRD for? Describe it in one or two sentences.
2. Is there a PRD for this project? If so, what are the key requirements from the PRD that this FRD needs to specify in detail?
3. Who are the users of this system? List the roles and what each role can do.
4. Describe the main workflows. Walk through the primary actions a user takes, step by step. (Example: user logs in → searches for product → adds to cart → checks out.)
5. What business rules apply? (Examples: "orders above $500 require manager approval," "users can only have one active subscription," "refunds are available within 30 days.")
6. What happens when things go wrong? For each workflow, describe: what if the input is invalid? What if the user loses connectivity? What if a dependent system is down?
7. What data does the system store or process? List the key entities and their fields. (Example: Order has order_id, customer_id, items, total, status, created_at.)
8. Does the system integrate with other systems? If so, list them and describe the data exchanged.
9. What are the performance and security requirements? (Response times, concurrent users, data encryption, access controls.)
10. How will you test that the requirements are met? What does "done" look like for each major feature?
After collecting all answers, generate an FRD in this format:
# FRD — [System Name]
## Overview
- System Name: [from answer 1]
- Author: [ask for name]
- Date: [current date]
- Status: Draft
- Related PRD: [from answer 2, or "N/A"]
## 1. Introduction
[Scope, purpose, definitions based on answers 1-2.]
## 2. Functional Requirements
[From answers 3-6. Generate requirements with IDs (FR-001, FR-002...), using "shall" for must-have and "should" for optional. Include inputs, outputs, business rules, and error states for each requirement.]
## 3. Non-Functional Requirements
[From answer 9. Generate NFR-001, NFR-002... for performance, security, availability.]
## 4. Data Requirements
[From answer 7. Data dictionary with field names, types, and constraints.]
## 5. Interface Requirements
[From answer 8. System integrations, protocols, data formats.]
## 6. Acceptance Criteria
[From answer 10. Map each FR to a testable criterion.]
## 7. Appendices
[Glossary of terms used in the document.]
Rules:
- Every functional requirement must have a unique ID (FR-001, FR-002...)
- Every requirement must be testable — if you cannot describe how to verify it, rewrite it
- Use "shall" for must-have, "should" for optional
- Include error states for every workflow — do not leave the "unhappy path" unspecified
- If the user didn't provide information, write "TBD" and list it in an Open Questions section
- Do not mix design decisions (colors, layouts) with functional requirements (behaviors)Пример диалога
ИИ: Для какой системы или фичи этот FRD?
Вы: Модуль обработки возвратов для нашей e-commerce платформы. Когда покупатель запрашивает возврат, система должна проверить запрос, обработать реверс платежа и обновить статус заказа.
ИИ: Какие бизнес-правила применяются к обработке возвратов?
Вы: Возвраты доступны только в течение 30 дней с момента доставки. Цифровые товары не подлежат возврату. Возвраты на сумму больше $200 требуют одобрения менеджера. Возврат идёт на оригинальный способ оплаты.
ИИ: Что происходит, если оригинальный способ оплаты больше не действует — например, карта с истёкшим сроком?
Вы: Хороший вопрос. В таком случае система должна предложить кредит на счёт магазина.
ИИ: (после всех вопросов) Вот функциональные требования для модуля возвратов. FR-001: Система должна позволять покупателям запрашивать возврат в течение 30 календарных дней с даты доставки, зафиксированной в заказе. FR-002: Система должна отклонять запросы на возврат товаров с тегом «digital»…
Советы для лучших результатов
- Продумайте ошибочные состояния. ИИ будет спрашивать, но лучшие FRD получаются у тех, кто видел реальные продакшн-сбои. Что произойдёт, если платёжный шлюз не ответит? Если заказ отправлен частично?
- Будьте точны в бизнес-правилах. «Возвраты требуют одобрения» — расплывчато. «Возвраты на сумму выше $200 требуют одобрения пользователя с ролью менеджера» — это функциональное требование.
- Проверьте идентификаторы требований. Они должны чисто маппиться на ваши тест-кейсы. Если требование слишком широкое, чтобы протестировать его за один шаг, разбейте его.
- Держите требования на уровне поведения. «Система должна использовать PostgreSQL» — это архитектурное решение. «Система должна обеспечивать персистентность данных заказов с гарантиями ACID» — это нефункциональное требование.
Ресурсы
- FRD — полное руководство — обзор всех секций
- Шаблоны FRD — стандартный и API, готовы к использованию
- API FRD — спецификация на уровне эндпоинтов
- Промпт-навигатор — подберите нужный тип документа