요구 정의 · 양식

제품 요구사항 정의서 (PRD) 양식

무엇을 왜 만드는지, 성공을 무엇으로 판단할지 정의한다.

이럴 때 써요

양식 구성

15개 절로 이루어져 있습니다.

문서 정보
버전 · 문서 상태 · 작성자 (기획) · 리뷰어 · 승인자 · 최초 작성일 · 최종 수정일 · 목표 출시일
1 개요
이 문서를 처음 보는 사람이 맥락을 알 수 있게 쓴다. 목표는 숫자로, 하지 않을 것은 이유와 함께 적는다.
2 성공 지표
지표마다 계산식과 데이터 출처를 적는다. 정의가 없으면 출시 뒤에 서로 다른 숫자를 들고 온다.
3 대상 사용자 · 유즈케이스
누구를 위한 기능인지와 그 사람이 하려는 일을 적는다. "모든 사용자" 는 대상을 안 정한 것과 같다.
4 범위 (Scope)
포함과 제외를 같이 적는다. 제외에 이유와 후속 계획을 적어 두면 나중에 같은 논쟁을 반복하지 않는다.
5 요구사항
ID 를 붙이고 "무엇이 되면 done 인가"(수용 기준)를 적는다. 개발·QA 가 이 표만 보고 일할 수 있어야 한다.
6 화면 · 플로우
화면설계서·유저 플로우 문서와 화면 ID 로 이어 둔다. 그림을 여기 붙이지 말고 어디를 보라고만 적는다.
7 정책
이번에 새로 만들거나 바꾸는 정책만 적는다. 자세한 내용은 정책 정의서에 두고 여기서는 ID 로 가리킨다.
8 권한
역할마다 할 수 있는 것과 할 수 없는 것을 함께 적는다. 못 하는 것을 안 적으면 구현이 제각각이 된다.
9 의존성 · 연동
남의 일정에 걸린 것을 적는다. 리드타임과 요청 상태를 적어야 언제 막힐지 미리 보인다.
10 데이터 · 이벤트 로깅
출시 뒤 지표를 보려면 어떤 이벤트가 필요한지 미리 적는다. 나중에 붙이면 그 기간 데이터가 비어 버린다.
11 예외 · 에러 처리
잘 되는 경우 말고 안 되는 경우를 적는다. 사용자에게 보일 문구까지 적어야 개발이 임의로 쓰지 않는다.
12 리스크
일어나면 목표가 흔들리는 것만 적는다. 대응 계획이 없는 줄은 지운다. 일정과 출시 판단 기준은 릴리즈 계획에서 다룬다.
13 참고 자료
이 문서를 읽다가 찾게 될 자료만 모은다. 링크가 끊길 수 있으니 무엇인지도 함께 적는다.
14 변경 이력
확정 뒤의 변경은 빠짐없이 남긴다. 무엇이 바뀌었는지 모르면 개발이 옛 판으로 만든다.

바로 써 보기

로그인 없이 바로 쓸 수 있습니다. 다 쓰면 PDF·Word·한글(HWPX)·Markdown 으로 내보냅니다.

이 양식으로 바로 쓰기 · 양식 미리 보기

요구 정의 단계의 다른 양식