Generating the Product Specification Document
Functional Specification Document Generation
By Chi Kit Yeung in App Development AI Software Engineering
July 7, 2026
There are two distinct sections to the specification generation flow: Generation and Review.
The following is the exact system prompt I’ve given to Gemma 4 via Open WebUI to discuss and refine my app idea with. I’ve actually found this prompt in Open WebUI’s Prompt catalog but for some reason I couldn’t find the exact link to the original anymore. The prompt has a placeholder for you to type in your idea. It is always best to be as specific as possible otherwise the LLM would fill in the blanks for you, which usually isn’t what you want.
You can follow instructions here to add this prompt to your own instance of Open WebUI: https://docs.openwebui.com/features/workspace/prompts/#creating-a-prompt
Generation
System Prompt
Act as an expert Technical Product Manager and Software Architect. I need you to generate a detailed, actionable Functional Specification Document (FSD) based on the feature or system concept I provide.
Your FSD must be clear, concise, and structured specifically for engineering teams. Please use the following exact markdown headings:
## 1. Executive Summary
- Provide a brief 1-2 sentence overview of the feature.
- Core user goal: What problem are we solving for the user?
## 2. User Personas & Use Cases
- Define the primary users interacting with this feature.
- List 3-4 core use cases (e.g., "As a [User], I want to [Action] so that [Result]").
## 3. Detailed Functional Requirements
- List the system's exact capabilities in a bulleted or numbered list.
- Specify what the system "must do," "should do," and "must not do".
## 4. Business Rules & Logic
- Detail the core logic (e.g., state transitions, validation logic, calculations).
- Outline the Happy Path.
- Outline the Unhappy Path (what happens if validation fails or inputs are invalid).
## 5. User Interface & Interactions (If applicable)
- Describe the UI components required.
- Detail user interactions (e.g., "Clicking the 'Submit' button triggers API call and displays loading spinner").
## 6. Data & API Specifications
- Outline the necessary data models, schemas, or payload formats (use tables or JSON).
- Specify expected API endpoints, request types, and potential response codes.
## 7. Edge Cases & Error Handling
- Identify critical edge cases (e.g., network failure, boundary limits, concurrency, invalid data types).
- Define the specific error messages or fallback behaviors for each case.
## 8. Non-Functional Requirements
- Mention constraints related to security, performance (e.g., latency limits), compliance, or accessibility.
## 9. Acceptance Criteria
- Write testable, behavior-driven acceptance criteria for this feature.
- Use the standard "Given / When / Then" format for each scenario.
--------------------------------------------------
My feature idea is:
{{feature_idea | textarea:placeholder="Write your idea here"}}
Chat with user to clarify additional details, highlight gaps, discuss the idea until all necessary details are clear.
Then offer to draft the comprehensive functional specification based on this
I’ve made some minor edits to the original prompt and added the following crucial instruction:
Chat with user to clarify additional details, highlight gaps, discuss the idea until all necessary details are clear.
Then offer to draft the comprehensive functional specification based on this
Our initial ideas are often not defined clearly enough or might be misinterpreted in unexpected ways. With this instruction, the LLM becomes a brainstorming partner that helps you flesh out the idea and point out potential issues early on instead of blindly generating a specification documentation immediately. I’ve personally found this discussion process to be very helpful in fully forming the idea for the app. After several rounds of back-and-forth, you can tell the LLM to draft the full spec document. Be sure to manually check this document or any discrepancies would end up as technical debt.
Generation Flow
┌─────────────────────────────────────────────────────────────┐
│ OpenWebUI + Gemma 4 │
│ (System Prompt loaded) │
└──────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ You: Describe your app idea │
│ (be as specific as possible) │
└──────────────────────┬──────────────────────────────────────┘
│
▼
┌────────────────┐
│ LLM asks │
│ clarifying │
│ questions │
└───────┬────────┘
│
▼
┌────────────────┐
│ You: answer │◀──────────────┐
│ / refine │ │
└───────┬────────┘ │
│ │
▼ │
┌────────────────┐ No │
│ All details ├───────────────┤
│ clear? │ │
└───────┬────────┘ │
│ Yes │
▼ │
┌────────────────┐ │
│ LLM drafts │ │
│ full FSD │ │
└───────┬────────┘ │
│ │
▼ │
┌────────────────┐ │
│ YOU: Manual │ │
│ review of FSD │ │
└───────┬────────┘ │
│ │
▼ │
┌────────────────┐ │
│ Accurately │ No │
│ reflects idea?├───────────────┘
└───────┬────────┘
│ Yes
▼
┌────────────────┐
│ FSD ready for │
│ Review step │
└────────────────┘
Review
You now have the spec document, you’ve read it and it accurately reflects the idea you have. Next it’s time to pass it to another LLM to review.
The following is the system prompt I used with Gemma 4 31b (dense model, better reasoning capabilities).
System Prompt
Act as a **Principal Software Architect** and **QA Lead**. Please perform a rigorous and critical review of the provided Functional Specification. Your primary goal is to poke holes in the requirements, ensure implementation readiness, and catch edge cases.
Provide your critique in the following structure:
---
### 1. Assumptions & Hidden Dependencies
* Identify any underlying assumptions that may not hold.
* List any hidden dependencies (e.g., third-party APIs, specific database structures) that aren't explicitly declared.
### 2. Ambiguities & Contradictions
* Highlight any areas of the specification that are vague, conflicting, or open to developer interpretation.
### 3. Missing Edge Cases & Error States
* What happens during negative scenarios, invalid inputs, network failures, or edge cases that the current spec completely ignores?
* Provide a list of "What if..." questions that the product team needs to answer.
### 4. Testability & Implementation Readiness
* **Readiness Rating:** Rate the implementation readiness of this spec (e.g., Low/Medium/High).
* Point out any requirements that are not measurable, testable, or lack precise input/output definitions.
### 5. Suggested Improvements
* For every hole you find, suggest specific, actionable additions or modifications to fix the specification.
### Here is the Functional Specification to review:
{{specification | "INSERT YOUR SPECIFICATION HERE"}}
Pass your functional specification document (FSD) to the LLM for it to review. The idea is to use a stronger model to review and further refine your document. At this stage the LLM should return you with a list of specific issues to be fixed. In my case, it found contraints with Android system, stability issues, contradictions and more. Sounds like a headache but all you need to do is pass this feedback right back to the generation LLM from the previous step and tell it to resolve those issues in the document. Once again, I’ll need to stress the need for you to carefully review what the LLMs spit out (human-in-the-loop). Once that is done, pass the FSD back to the review LLM again. Loop this process until all issues are addressed. Ofcourse there may be cases that the issue raised is not a real concern so use your own judgement.
Review Flow
┌─────────────────────┐
│ FSD from previous │
│ step │
└──────────┬──────────┘
│
▼
┌─────────────────────────────────────────────┐
│ LLM Review │◀──┐
│ (Gemma 4 31b Dense) │ │
│ "Principal Software Architect & QA Lead" │ │
│ → returns structured critique │ │
└──────────┬──────────────────────────────────┘ │
│ │
▼ │
┌─────────────────────────────────────────────┐ │
│ YOU: Review the feedback │ │
└──────────┬──────────────────────────────────┘ │
│ │
▼ │
┌─────────────────────────────────────────────┐ │
│ LLM Regenerate │ │
│ Gemma 4 26b-a4b (MoE) │ │
│ Pass feedback in → LLM updates FSD │ │
└──────────┬──────────────────────────────────┘ │
│ │
▼ │
┌─────────────────────────────────────────────┐ │
│ YOU: Manual review of updated FSD │ │
└──────────┬──────────────────────────────────┘ │
│ │
▼ │
Satisfied? ──── No ────────────────────────┘
│
Yes
│
▼
┌──────────┐
│ FSD │
│ Final │
└──────────┘