기획서가 길어도 개발자가 다시 질문한다면, 사용자·예외 상황·완료 기준부터 확인해 보세요. 이 가이드는 PM과 서비스기획자가 기능 아이디어를 구현 가능한 요구사항으로 바꾸는 출발점입니다.
기능 목록보다 먼저 정할 세 가지
- 누구의 문제인가: 실제 사용할 사람과 발생 상황을 한 문장으로 적습니다.
- 어떤 불편을 줄이나: 사용자 문의나 관찰처럼 근거가 있는 문제와 팀의 추측을 구분합니다.
- 무엇으로 확인하나: 성공 여부를 확인할 행동과 지표를 정합니다. 기준값이 없으면 먼저 측정해야 한다고 적습니다.
복사해서 쓰는 한 장 요구사항
대상 사용자 / 사용 상황:
해결할 문제와 근거:
기대하는 사용자 행동:
이번에 구현할 범위:
이번 범위에서 제외할 항목:
입력·출력과 화면 상태:
실패·취소·중복 요청 처리:
완료를 판단할 조건:
측정할 지표와 수집 방법:
미정 사항 / 결정 담당자:
가상 예제: 회의록의 할 일을 놓치는 팀
‘AI 회의록 기능’이라는 이름만으로는 완료 기준을 정하기 어렵습니다. 다음은 실제 프로젝트 성과가 아닌 설명용 예제입니다.
- 문제: 회의가 끝난 뒤 결정 사항과 담당 업무를 다시 정리해야 합니다.
- 입력: 사용자가 제공한 회의 메모.
- 출력: 결정 사항, 할 일, 담당자, 기한. 메모에 없는 담당자와 기한은 ‘미정’으로 표시합니다.
- 인수 조건: 메모에 적힌 할 일을 누락하지 않고, 출처 문장과 결과를 대조할 수 있어야 합니다.
- 예외: 메모가 비어 있으면 입력 안내를 보여줍니다. 내용이 충돌하면 임의 확정하지 않고 확인 대상으로 표시합니다.
개발 전달 전에 질문할 것
정상 흐름만 적혀 있지 않은지, 같은 요청을 두 번 보내면 어떻게 되는지, 권한이 없는 사용자는 무엇을 보는지 확인하세요. 미정 사항은 숨기지 말고 담당자와 결정 시점을 함께 남깁니다.
근거와 활용 범위
Atlassian의 PRD 안내를 참고했습니다. 위 양식과 회의록 예제는 cmsworld의 편집 예시이며 조직의 필수 표준이나 실적을 의미하지 않습니다. 공식 자료 확인일: 2026-09-16.