요구 정의 · 양식
유저 스토리 백로그 양식
요구사항을 사용자 문장과 수용 기준으로 쪼개 스프린트에 붙인다.
이럴 때 써요
- 스프린트 단위로 일을 쪼개 넘길 때
- 수용 기준을 미리 합의해 완료 판정 다툼을 없앨 때
양식 구성
8개 절로 이루어져 있습니다.
- 문서 정보
- 버전 · 제품 · 기능 · 백로그 관리자 · 스프린트 주기 · 검토자 · 승인자 · 최종 수정일
- 1 작성 규칙
- 팀이 같은 형식으로 쓰도록 규칙을 문서 안에 남깁니다.
- 2 에픽 구조
- 스토리를 묶는 큰 덩어리를 먼저 세운다. 에픽 없이 스토리만 쌓이면 무엇이 남았는지 보이지 않는다.
- 3 백로그
- "누가 / 무엇을 / 왜" 꼴로 적고 수용 기준을 붙인다. 수용 기준이 없으면 완료 판정이 사람마다 달라진다.
- 4 스프린트별 정리
- 스프린트마다 목표 한 줄을 먼저 적는다. 목표 없이 스토리만 담으면 무엇을 포기해도 되는지 판단할 수 없다.
- 5 정제 필요
- 아직 착수할 수 없는 스토리와 막힌 이유를 적는다. 담당과 기한이 없으면 계속 미뤄진다.
- 6 폐기 · 보류 로그
- 접은 스토리와 이유를 남긴다. 남기지 않으면 몇 달 뒤 같은 제안이 다시 올라온다.
- 7 변경 이력
- 문서를 고칠 때마다 한 줄 남긴다. 승인 뒤에 바뀐 것은 특히 빠짐없이 적는다.
바로 써 보기
로그인 없이 바로 쓸 수 있습니다. 다 쓰면 PDF·Word·한글(HWPX)·Markdown 으로 내보냅니다.
요구 정의 단계의 다른 양식
- 용어사전 — 핵심 개념의 뜻을 요구사항보다 먼저 정의해 팀이 같은 말을 쓰게 한다. 전사 공유용.
- 제품 요구사항 정의서 (PRD) — 무엇을 왜 만드는지, 성공을 무엇으로 판단할지 정의한다.
- 기능 기획서 (Feature Spec) — 단일 기능의 동작, 화면 흐름, 예외 처리를 상세히 규정한다.
- 릴리즈 계획 — MVP 범위와 버전별 단계, 출시 판단 기준을 미리 정한다.
- 요구사항 명세서 (SRS) — 계약 기준이 되는 기능·비기능 요구사항을 항목별로 명세한다.