요구 정의 · 양식
기능 기획서 (Feature Spec) 양식
단일 기능의 동작, 화면 흐름, 예외 처리를 상세히 규정한다.
이럴 때 써요
- PRD 보다 좁은 단일 기능의 동작을 상세히 적을 때
- 화면 흐름과 예외 처리를 개발에 그대로 넘길 때
양식 구성
7개 절로 이루어져 있습니다.
- 문서 정보
- 버전 · 관련 제품/서비스 · 상태 · 작성자 · 검토자 · 승인자 · 작성일
- 1 기능 개요
- 이 기능이 왜 필요한지, 어떤 사용자 문제를 푸는지 적습니다.
- 2 상세 동작 규칙
- 정상 흐름과 예외 상황을 나눠 적어야 개발·QA가 같은 기준을 봅니다.
- 3 UI/UX
- 화면이 어떤 순서로 이어지는지 적는다. 디자인 시안이 따로 있으면 링크로 잇고 여기서는 흐름과 규칙만 적는다.
- 4 API 인터페이스
- 이 기능이 쓰는 API 만 적는다. 자세한 규격은 API 명세서에 두고 여기서는 무엇을 주고받는지 수준으로 적는다.
- 5 수용 기준
- 이 조건을 모두 만족하면 기능이 완료된 것으로 봅니다.
- 6 변경 이력
- 문서를 고칠 때마다 한 줄 남긴다. 승인 뒤에 바뀐 것은 특히 빠짐없이 적는다.
바로 써 보기
로그인 없이 바로 쓸 수 있습니다. 다 쓰면 PDF·Word·한글(HWPX)·Markdown 으로 내보냅니다.
요구 정의 단계의 다른 양식
- 용어사전 — 핵심 개념의 뜻을 요구사항보다 먼저 정의해 팀이 같은 말을 쓰게 한다. 전사 공유용.
- 제품 요구사항 정의서 (PRD) — 무엇을 왜 만드는지, 성공을 무엇으로 판단할지 정의한다.
- 유저 스토리 백로그 — 요구사항을 사용자 문장과 수용 기준으로 쪼개 스프린트에 붙인다.
- 릴리즈 계획 — MVP 범위와 버전별 단계, 출시 판단 기준을 미리 정한다.
- 요구사항 명세서 (SRS) — 계약 기준이 되는 기능·비기능 요구사항을 항목별로 명세한다.