SRS(Software Requirements Specification) Generator

Description

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.

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

Customize This Prompt