SRS(Software Requirements Specification) 작성기

Description

이 프롬프트는 프로덕트 매니저가 명확하고 실행 가능하며 전략적인 SRS(Software Requirements Specification)를 작성하도록 돕습니다. 문제 정의, AI 활용, 비즈니스 목표, 기능 명세, 이해관계자 정렬 같은 핵심 영역을 다루는 13개 섹션 구조를 제공합니다. 각 섹션에는 명확성과 팀 간 협업을 지원하는 상세 예시와 형식이 포함되어 있습니다. 복잡한 제품이나 AI 기반 제품에 특히 적합하며, 높은 수준의 아이디어를 구조화되고 실행 준비가 된 계획으로 바꾸는 데 도움을 줍니다.

Head of Product 입장에서, 세계 최고 수준의 Software Requirements Specification(SRS)을 만든다는 마음가짐으로 이 작업에 접근해주세요. 제가 컨텍스트를 제공하면, 당신은 명확하고 실행 가능한 SRS 문서를 함께 구축할 수 있도록 안내하는 역할을 맡습니다.

## SRS 템플릿(SRS Template)

### 1. 소개(Introduction)
- **제품명:** {{product_name}}
- **버전:** {{version}}
- **목적(Purpose):** 이 시스템은 무엇을 하며, 왜 존재하나요?
- **범위(Scope):** 시스템의 경계 — 포함되는 것과 제외되는 것
- **독자(Audience):** 누가 이 SRS를 읽나요? (엔지니어, QA, 이해관계자)

### 2. 시스템 개요(System Overview)
- **도메인(Domain):** [Domain] (예: Healthcare, E-commerce, Education)
- **시스템 컨텍스트 다이어그램:** 시스템의 경계와 외부 인터페이스를 설명하세요.
- **핵심 액터(Key actors):** 제품과 상호작용하는 모든 사용자 유형과 외부 시스템을 나열하세요.

### 3. 기능 요구사항(Functional Requirements)

#### 3.1 Use Case 카탈로그
| ID | Use Case Name | Actor | Priority | Description |
|---|---|---|---|---|
| UC-001 | [FunctionName] | [Actor] | P0/P1/P2 | 간단 설명 |

#### 3.2 상세 Use Case
각 use case마다 다음을 제공하세요:
- **사전조건(Preconditions):** 이 use case가 시작되기 전에 참이어야 하는 것
- **메인 플로우(Main flow):** happy path의 번호 순서 단계
- **대체 플로우(Alternative flows):** 변형과 분기(branch)
- **사후조건(Postconditions):** 성공적으로 완료된 뒤 참이 되는 상태
- **비즈니스 규칙(Business rules):** 해당 도메인에 적용되는 규칙

#### 3.3 Use Case ID 규칙
형식: `[Domain].[Actor].[FunctionName]`
예시: [Chatbot.User.CreateTask], [Chatbot.User.GetTaskList]

### 4. 비기능 요구사항(Non-Functional Requirements)
- **성능(Performance):** 응답 시간, 처리량(throughput), 동시 사용자 수
- **확장성(Scalability):** 예상 성장과 그에 대한 시스템 대응 방식
- **보안(Security):** 인증(authentication), 권한 부여(authorization), 데이터 보호
- **가용성(Availability):** uptime 목표 (예: 99.9%), 재해 복구(disaster recovery)
- **사용성(Usability):** 접근성 표준, 지원 기기/브라우저

### 5. 데이터 요구사항(Data Requirements)
- **데이터 모델(Data model):** 핵심 엔터티(entity)와 그 관계
- **데이터 보존(Data retention):** 저장 기간과 아카이브 정책
- **데이터 마이그레이션(Data migration):** 기존 시스템을 대체하는 경우, 데이터를 어떻게 옮기는가

### 6. 인터페이스 요구사항(Interface Requirements)
- **사용자 인터페이스(User interfaces):** 핵심 화면과 상호작용 패턴
- **API 인터페이스:** endpoint, method, payload format
- **외부 시스템 인터페이스:** 서드파티 통합(third-party integration)

### 7. 추적성 매트릭스(Traceability Matrix)
| Requirement ID | Use Case | Test Case | Status |
|---|---|---|---|
| [UC-1] | ... | ... | Draft/Reviewed/Approved |
| [UC-2] | ... | ... | ... |

### 8. 가정과 제약(Assumptions & Constraints)
- 기술적 가정(infrastructure, framework)
- 비즈니스 제약(budget, timeline, regulatory)

### 9. 용어집(Glossary)
문서 전반에서 쓰는 도메인 특화 용어를 정의하세요.

## 가이드라인(Guidelines)
- 요구사항은 테스트 가능하고 모호하지 않게 작성하세요.
- 필수 요구사항에는 "shall", 권장 요구사항에는 "should"를 사용하세요.
- 각 요구사항에는 추적성(traceability)을 위한 고유 ID가 있어야 합니다.
- 구현 세부사항은 피하고, 어떻게(how)가 아니라 무엇(what)을 설명하세요.

Customize This Prompt