shamsbd71 · July 20, 2025 10:03
diff --git a/software-requirements-specification-prompt b/software-requirements-specification-prompt
 # “Generate a Detailed Software Requirements Specification” Meta-Prompt

 A reusable, structured prompt for LLMs (e.g. ChatGPT) that spins up a full Software Requirements Specification (SRS) document—modeled on the ConversWP/Userdoc example.

 ---

 ## 📖 Introduction

 Maintaining consistent, high-quality requirements docs accelerates development, reduces misunderstandings, and keeps teams aligned. This meta-prompt:

 - Guides any LLM to produce a fully-fleshed SRS  
 - Enforces a clear, industry-standard outline  
 - Includes Functional, Non-Functional, User Stories, UI/API interfaces, and more  
 - Mirrors the depth and formatting of the “ConversWP” screenshot examples  

 Simply drop this into ChatGPT (or your favorite LLM), swap in your project name, and you’ll have a draft SRS ready for review.

 ---

 ## 🚀 Quick Start

 1. **Copy** the prompt template below.  
 2. **Replace** every instance of `<PROJECT_NAME>` with your target application name.  
 3. **Paste** into your LLM prompt box.  
 4. **Review** and refine the generated SRS for accuracy and completeness.  

 ---

 ## 🔧 Prompt Template

 ```
 You are a software requirements engineer. Produce a comprehensive Software Requirements Specification (SRS) document for a new software project called **<PROJECT_NAME>**. Follow this structured outline—each section should be rich in detail, just like the Userdoc “ConversWP” example:

 1. **Introduction**  
   1.1 **Purpose**: Describe why <PROJECT_NAME> exists.  
   1.2 **Scope**: Summarize in bullet-points what the product will (and will not) do.  
   1.3 **Definitions**: Define key terms (e.g. “Event”, “Segment”, “Platform”).

 2. **Overall Description**  
   2.1 **Product Perspective**: How it fits into the existing ecosystem or workflows.  
   2.2 **User Classes & Characteristics**: List roles (Admin, End-User, Developer, etc.) and their needs.  
   2.3 **Operating Environment**: Supported OS, platforms, versions.  
   2.4 **Constraints & Assumptions**: Performance targets, compliance (GDPR/CCPA), coding standards.

 3. **System Features & Functional Requirements**  
   - Use a table with columns **ID**, **Requirement**, **Rationale**.  
   - Cover core functions (e.g. Script Injection, Event Tracking, Custom Hooks, E-commerce integration).

 4. **Non-Functional Requirements**  
   - Sections: Performance, Scalability, Security, Usability, Reliability, Compliance.  
   - Provide concrete metrics (e.g. “Page-load overhead <100 ms”, “Support 1 M events/month”).

 5. **User Stories & Acceptance Criteria**  
   - Format as a table with columns **As a**, **I want to**, **So that**, **Acceptance Criteria**.  
   - At least 4–5 representative stories.

 6. **External Interfaces**  
   - **Admin UI**: Sidebar, pages, forms, charts.  
   - **APIs**: REST endpoints, payload examples.

 7. **Documentation & Support**  
   - Inline help, export formats (Word/CSV/Excel), versioning, onboarding wizards.

 8. **Future & AI-Assisted Enhancements**  
   - AI scoping copilots, visual relationship graphs, one-click sync to PM tools, audit reports.

 9. **Next Steps**  
   - Bullet list: Review & refine, prioritize MVP, draft wireframes, write test plans.

 **Additional Instructions:**  
 - Mirror the tone and level of detail of the provided screenshots (streamlined scoping, detailed team needs, user-focus, pathway demos).  
 - Use clear headings, numbered sub-sections, and markdown tables for easy readability.  
 - Emphasize how each feature benefits users and business goals.  
 - Keep the document self-contained—any reader should understand context without external links.
 ```


 ---

 ## 🔍 Tips & Best Practices

 - **Be Explicit:** The more context you add around your project (domain, target users, existing integrations), the richer the LLM’s output.  
 - **Iterate in Chunks:** If your project is large, ask the LLM to generate one section at a time (e.g. “Generate only the Functional Requirements table”).  
 - **Validate Outputs:** Always review generated tables, user stories, and metrics for realism and accuracy.  
 - **Customize Tone:** Feel free to tweak the prompt’s “Additional Instructions”—e.g. swap “formal” for “conversational,” or specify your company’s naming conventions.  

 ---

 ## 📂 License

 This meta-prompt is MIT-licensed. Use it freely, adapt it to your workflows, and share improvements back with the community!

 ---

 > _Created with care by Abu Huraira—happy requirements writing!_
	# “Generate a Detailed Software Requirements Specification” Meta-Prompt

	A reusable, structured prompt for LLMs (e.g. ChatGPT) that spins up a full Software Requirements Specification (SRS) document—modeled on the ConversWP/Userdoc example.

	---

	## 📖 Introduction

	Maintaining consistent, high-quality requirements docs accelerates development, reduces misunderstandings, and keeps teams aligned. This meta-prompt:

	- Guides any LLM to produce a fully-fleshed SRS
	- Enforces a clear, industry-standard outline
	- Includes Functional, Non-Functional, User Stories, UI/API interfaces, and more
	- Mirrors the depth and formatting of the “ConversWP” screenshot examples

	Simply drop this into ChatGPT (or your favorite LLM), swap in your project name, and you’ll have a draft SRS ready for review.

	---

	## 🚀 Quick Start

	1. Copy the prompt template below.
	2. Replace every instance of `<PROJECT_NAME>` with your target application name.
	3. Paste into your LLM prompt box.
	4. Review and refine the generated SRS for accuracy and completeness.

	---

	## 🔧 Prompt Template

	```
	You are a software requirements engineer. Produce a comprehensive Software Requirements Specification (SRS) document for a new software project called <PROJECT_NAME>. Follow this structured outline—each section should be rich in detail, just like the Userdoc “ConversWP” example:

	1. Introduction
	1.1 Purpose: Describe why <PROJECT_NAME> exists.
	1.2 Scope: Summarize in bullet-points what the product will (and will not) do.
	1.3 Definitions: Define key terms (e.g. “Event”, “Segment”, “Platform”).

	2. Overall Description
	2.1 Product Perspective: How it fits into the existing ecosystem or workflows.
	2.2 User Classes & Characteristics: List roles (Admin, End-User, Developer, etc.) and their needs.
	2.3 Operating Environment: Supported OS, platforms, versions.
	2.4 Constraints & Assumptions: Performance targets, compliance (GDPR/CCPA), coding standards.

	3. System Features & Functional Requirements
	- Use a table with columns ID, Requirement, Rationale.
	- Cover core functions (e.g. Script Injection, Event Tracking, Custom Hooks, E-commerce integration).

	4. Non-Functional Requirements
	- Sections: Performance, Scalability, Security, Usability, Reliability, Compliance.
	- Provide concrete metrics (e.g. “Page-load overhead <100 ms”, “Support 1 M events/month”).

	5. User Stories & Acceptance Criteria
	- Format as a table with columns As a, I want to, So that, Acceptance Criteria.
	- At least 4–5 representative stories.

	6. External Interfaces
	- Admin UI: Sidebar, pages, forms, charts.
	- APIs: REST endpoints, payload examples.

	7. Documentation & Support
	- Inline help, export formats (Word/CSV/Excel), versioning, onboarding wizards.

	8. Future & AI-Assisted Enhancements
	- AI scoping copilots, visual relationship graphs, one-click sync to PM tools, audit reports.

	9. Next Steps
	- Bullet list: Review & refine, prioritize MVP, draft wireframes, write test plans.

	Additional Instructions:
	- Mirror the tone and level of detail of the provided screenshots (streamlined scoping, detailed team needs, user-focus, pathway demos).
	- Use clear headings, numbered sub-sections, and markdown tables for easy readability.
	- Emphasize how each feature benefits users and business goals.
	- Keep the document self-contained—any reader should understand context without external links.
	```


	---

	## 🔍 Tips & Best Practices

	- Be Explicit: The more context you add around your project (domain, target users, existing integrations), the richer the LLM’s output.
	- Iterate in Chunks: If your project is large, ask the LLM to generate one section at a time (e.g. “Generate only the Functional Requirements table”).
	- Validate Outputs: Always review generated tables, user stories, and metrics for realism and accuracy.
	- Customize Tone: Feel free to tweak the prompt’s “Additional Instructions”—e.g. swap “formal” for “conversational,” or specify your company’s naming conventions.

	---

	## 📂 License

	This meta-prompt is MIT-licensed. Use it freely, adapt it to your workflows, and share improvements back with the community!

	---

	> _Created with care by Abu Huraira—happy requirements writing!_
No results found