2.5 KiB
2.5 KiB
name, label, description, icon, allowed-tools, tabs
| name | label | description | icon | allowed-tools | tabs | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| prd-generator | 요구사항 정의서 (PRD) | 제품 요구사항 정의서, 유저 스토리, 수용 기준을 체계적으로 생성합니다. | \uE8A5 |
|
cowork |
제품/기능의 요구사항 정의서(PRD)를 체계적으로 작성하세요.
워크플로우
-
요구사항 수집: 사용자에게 다음을 확인
- 제품/기능 이름
- 목적과 배경
- 대상 사용자
- 핵심 기능 목록
- 제약 조건 (기술, 일정, 예산)
-
구조화: document_plan으로 PRD 개요 설계
-
상세 작성: 섹션별 상세 내용 작성
- 유저 스토리 (As a... I want... So that...)
- 수용 기준 (Given... When... Then...)
- 기능 우선순위 (MoSCoW)
-
문서 생성: document_assemble 또는 html_create로 최종 문서
PRD 구조
1. 개요
- 제품/기능 이름
- 버전 / 작성일 / 작성자
- 문서 목적
2. 배경 및 목적
- 비즈니스 배경
- 해결하려는 문제
- 기대 효과 (정량적 KPI)
3. 대상 사용자
- 사용자 페르소나
- 사용 시나리오
- 사용자 여정 맵
4. 기능 요구사항
유저 스토리 형식
US-001: [기능명]
As a [역할],
I want [기능],
So that [가치].
수용 기준:
- Given [사전 조건], When [행동], Then [기대 결과]
- Given ..., When ..., Then ...
우선순위: Must Have / Should Have / Could Have / Won't Have
5. 비기능 요구사항
- 성능 (응답 시간, 처리량)
- 보안 (인증, 권한, 암호화)
- 접근성 (WCAG 수준)
- 호환성 (브라우저, OS, 디바이스)
6. 기술 제약
- 기술 스택 제한
- 연동 시스템
- 데이터 마이그레이션
7. 일정 및 마일스톤
| 마일스톤 | 예정일 | 산출물 |
|---|---|---|
| 설계 완료 | ... | 상세 설계서 |
| 개발 완료 | ... | 릴리즈 빌드 |
| QA 완료 | ... | 테스트 보고서 |
8. 성공 지표
- 핵심 KPI 및 측정 방법
- 목표 수치
9. 리스크 및 대안
| 리스크 | 영향 | 대안 |
|---|---|---|
| ... | 높음 | ... |
규칙
- 사용자 관점에서 작성 (기술 용어 최소화)
- 유저 스토리는 INVEST 원칙 준수 (Independent, Negotiable, Valuable, Estimable, Small, Testable)
- 수용 기준은 테스트 가능하도록 구체적으로
- 한국어로 작성 (영어 용어 병기 가능)