SRS(Software Requirements Specification) Generator

Overview

This prompt helps product managers write clear, actionable, and strategic Software Requirements Specifications (SRS). It provides a 13-section structure that covers key areas such as problem definition, AI usage, business objectives, functional specifications, and stakeholder alignment. Each section includes detailed examples and formats to support clarity and collaboration across teams. Ideal for complex or AI-powered products, this prompt helps turn high-level ideas into structured, execution-ready plans. This prompt is built for teams who need a fast, practical way to move from intention to execution.

In a delivery context, this prompt helps you align stakeholders, surface the right constraints, and structure the output so it is immediately actionable.

Prompt template

As Head of Product, approach this task with the mindset of crafting a world-class Software Requirements Specification (SRS). I will provide context; your role is to guide me in building a clear, actionable SRS document.

## SRS Template

### 1. Introduction
- **Product name:** {{product_name}}
- **Version:** {{version}}
- **Purpose:** What does this system do and why does it exist?
- **Scope:** Boundaries of the system — what is included and excluded
- **Audience:** Who will read this SRS? (engineers, QA, stakeholders)

### 2. System Overview
- **Domain:** [Domain] (e.g., Healthcare, E-commerce, Education)
- **System context diagram:** Describe the system's boundaries and external interfaces
- **Key actors:** List all user types and external systems that interact with the product

### 3. Functional Requirements

#### 3.1 Use Case Catalog
| ID | Use Case Name | Actor | Priority | Description |
|---|---|---|---|---|
| UC-001 | [FunctionName] | [Actor] | P0/P1/P2 | Brief description |

#### 3.2 Detailed Use Cases
For each use case, provide:
- **Preconditions:** What must be true before this use case starts
- **Main flow:** Numbered steps of the happy path
- **Alternative flows:** Variations and branches
- **Postconditions:** What is true after successful completion
- **Business rules:** Domain-specific rules that apply

#### 3.3 Use Case ID Convention
Format: `[Domain].[Actor].[FunctionName]`
Examples: [Chatbot.User.CreateTask], [Chatbot.User.GetTaskList]

### 4. Non-Functional Requirements
- **Performance:** Response time, throughput, concurrent users
- **Scalability:** Expected growth and how the system handles it
- **Security:** Authentication, authorization, data protection
- **Availability:** Uptime target (e.g., 99.9%), disaster recovery
- **Usability:** Accessibility standards, supported devices/browsers

### 5. Data Requirements
- **Data model:** Key entities and their relationships
- **Data retention:** Storage duration and archival policy
- **Data migration:** If replacing an existing system, how data is migrated

### 6. Interface Requirements
- **User interfaces:** Key screens and interaction patterns
- **API interfaces:** Endpoints, methods, payload formats
- **External system interfaces:** Third-party integrations

### 7. Traceability Matrix
| Requirement ID | Use Case | Test Case | Status |
|---|---|---|---|
| [UC-1] | ... | ... | Draft/Reviewed/Approved |
| [UC-2] | ... | ... | ... |

### 8. Assumptions & Constraints
- Technical assumptions (infrastructure, frameworks)
- Business constraints (budget, timeline, regulatory)

### 9. Glossary
Define domain-specific terms used throughout the document.

## Guidelines
- Write requirements that are testable and unambiguous
- Use "shall" for mandatory requirements, "should" for recommended
- Each requirement must have a unique ID for traceability
- Avoid implementation details — describe what, not how

How to use this prompt

• State the objective and the product context in one sentence.
• Add any constraints such as timeline, target users, or business metrics.
• Ask for a structured output (framework, checklist, or decision summary).

Prompt details