요구 정의 · 양식
릴리즈 계획 양식
MVP 범위와 버전별 단계, 출시 판단 기준을 미리 정한다.
이럴 때 써요
- MVP 범위를 정하고 몇 차에 나눠 낼지 결정할 때
- 출시 판단 기준과 롤백 조건을 미리 못 박을 때
양식 구성
10개 절로 이루어져 있습니다.
- 문서 정보
- 버전 · 프로젝트 · 작성자 · 검토자 · 승인자 · 최종 수정일 · 목표 출시일
- 1 릴리즈 전략
- 한 번에 다 낼지 나눠 낼지를 먼저 정한다. MVP 는 "무엇을 검증하려는가" 에서 거꾸로 깎아 낸다.
- 2 버전별 범위
- 버전마다 포함과 제외, 그리고 다음 버전으로 넘어가는 조건을 적는다.
- 3 마일스톤
- 날짜가 있는 고정점만 적는다. 모든 작업을 여기 적으면 WBS 와 겹쳐 둘 다 안 보게 된다.
- 4 담당 · 책임 (RACI)
- 작업마다 정하는 사람과 하는 사람을 나눈다. 빈칸이 많은 줄은 대개 출시 직전에 사고가 난다.
- 5 출시 판단 기준 (Go / No-Go)
- 내보낼지 말지를 가르는 기준을 미리 적고, 출시 직전에 확인자와 확인일을 채운다.
- 6 롤백 계획
- 되돌릴 수 있는지, 얼마나 걸리는지 적는다. 데이터가 바뀌는 릴리즈는 되돌리기 어려우니 그것부터 확인한다.
- 7 출시 후 모니터링
- 출시 뒤 언제 무엇을 볼지 정한다. 이상일 때 무엇을 할지까지 적어야 새벽에 헤매지 않는다.
- 8 커뮤니케이션 계획
- 누구에게 언제 알릴지 적는다. CS·영업처럼 밖과 만나는 팀은 출시 전에 알아야 한다.
- 9 변경 이력
- 문서를 고칠 때마다 한 줄 남긴다. 승인 뒤에 바뀐 것은 특히 빠짐없이 적는다.
바로 써 보기
로그인 없이 바로 쓸 수 있습니다. 다 쓰면 PDF·Word·한글(HWPX)·Markdown 으로 내보냅니다.
요구 정의 단계의 다른 양식
- 용어사전 — 핵심 개념의 뜻을 요구사항보다 먼저 정의해 팀이 같은 말을 쓰게 한다. 전사 공유용.
- 제품 요구사항 정의서 (PRD) — 무엇을 왜 만드는지, 성공을 무엇으로 판단할지 정의한다.
- 기능 기획서 (Feature Spec) — 단일 기능의 동작, 화면 흐름, 예외 처리를 상세히 규정한다.
- 유저 스토리 백로그 — 요구사항을 사용자 문장과 수용 기준으로 쪼개 스프린트에 붙인다.
- 요구사항 명세서 (SRS) — 계약 기준이 되는 기능·비기능 요구사항을 항목별로 명세한다.