Ovaj prompt vas vodi kroz niz pitanja i pravi popunjen FRD sa identifikatorima zahteva, poslovnim pravilima i kriterijumima prihvatanja. Radi za standardni format (7 sekcija). Za API projekte, prilagodite rezultat koristeći API FRD šablon.
Kako koristiti
- Kopirajte prompt ispod
- Nalepite ga u ChatGPT, Claude ili drugi AI čet
- Odgovarajte na pitanja — AI će ih postavljati jedno po jedno
- Dobijte popunjen FRD u markdown formatu
- Proverite kriterijume prihvatanja i stanja greške — AI generiše razumne podrazumevane vrednosti, ali za granične slučajeve je potrebna vaša ekspertiza u domenu
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)Primer dijaloga
AI: Za koji sistem ili funkcionalnost je ovaj FRD?
Vi: Modul za obradu povrata za našu e-commerce platformu. Kada kupac zatraži povrat, sistem treba da proveri zahtev, obradi povrat plaćanja i ažurira status narudžbine.
AI: Koja poslovna pravila važe za obradu povrata?
Vi: Povrati su dozvoljeni samo u roku od 30 dana od isporuke. Digitalni proizvodi ne podležu povratu. Povrati iznad $200 zahtevaju odobrenje menadžera. Povrat ide na originalni način plaćanja.
AI: Šta se dešava ako originalni način plaćanja više nije važeći — na primer, kartica sa isteklim rokom?
Vi: Dobro pitanje. U tom slučaju sistem treba da ponudi kredit na računu prodavnice.
AI: (nakon svih pitanja) Evo funkcionalnih zahteva za modul povrata. FR-001: Sistem mora dozvoliti kupcima da zatraže povrat u roku od 30 kalendarskih dana od datuma isporuke zabeleženog u narudžbini. FR-002: Sistem mora odbiti zahteve za povrat proizvoda označenih kao „digital”…
Saveti za bolje rezultate
- Razmislite o stanjima greške. AI će pitati, ali najbolji FRD-ovi nastaju od nekoga ko je video realne produkcijske kvarove. Šta se dešava kada payment gateway ne odgovori? Kada je narudžbina delimično isporučena?
- Budite precizni u poslovnim pravilima. „Povrati zahtevaju odobrenje” je nejasno. „Povrati iznad $200 zahtevaju odobrenje korisnika sa ulogom menadžera” — to je funkcionalni zahtev.
- Proverite identifikatore zahteva. Oni treba čisto da se mapiraju na vaše test slučajeve. Ako je zahtev previše širok da se testira u jednom koraku, podelite ga.
- Držite zahteve na nivou ponašanja. „Sistem mora koristiti PostgreSQL” je arhitekturna odluka. „Sistem mora obezbediti postojanost podataka narudžbina sa ACID garancijama” je nefunkcionalni zahtev.
Resursi
- FRD — kompletan vodič — pregled svih sekcija
- FRD šabloni — standardni i API, spremni za korišćenje
- API FRD — specifikacija na nivou endpoint-a
- Navigator prompt — pronađite pravi tip dokumenta