This prompt walks you through a series of questions and produces a filled-out FRD with requirement IDs, business rules, and acceptance criteria. It works for the standard format (7 sections). For API-focused projects, adapt the output using the API FRD template.
How to use
- Copy the prompt below
- Paste it into ChatGPT, Claude, or another AI chat
- Answer the questions — the AI will ask them one at a time
- Get a filled-out FRD in markdown format
- Review the acceptance criteria and error states — the AI generates reasonable defaults, but your domain knowledge is needed for edge cases
Prompt
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)Example dialogue
AI: What system or feature is this FRD for?
You: A refund processing module for our e-commerce platform. When a customer requests a refund, the system should validate the request, process the payment reversal, and update the order status.
AI: What business rules apply to refund processing?
You: Refunds are only allowed within 30 days of delivery. Digital products are non-refundable. Refunds above $200 need manager approval. The refund goes back to the original payment method.
AI: What happens if the original payment method is no longer valid — for example, an expired credit card?
You: Good question. In that case, the system should offer store credit instead.
AI: (after all questions) Here are your functional requirements for the refund module. FR-001: The system shall allow customers to request a refund within 30 calendar days of the delivery date recorded in the order. FR-002: The system shall reject refund requests for products tagged as “digital”…
Tips for better results
- Think about error states. The AI will prompt you, but the best FRDs come from someone who has seen real production failures. What happens when the payment gateway times out? When the order is partially shipped?
- Be precise about business rules. “Refunds need approval” is vague. “Refunds above $200 require approval from a user with the manager role” is a functional requirement.
- Review the requirement IDs. They should map cleanly to your test cases. If a requirement is too broad to test in one step, split it.
- Keep requirements at the behavior level. “The system shall use PostgreSQL” is a design decision. “The system shall persist order data with ACID guarantees” is a non-functional requirement.
Resources
- FRD — the complete guide — overview of all sections
- FRD templates — Standard and API, ready to use
- API FRD — endpoint-level specification
- Navigator prompt — find the right document type