요구사항 정의서 작성법, 발주자가 직접 쓰는 양식과 작성 예시

2026.10.208분

요구사항 정의서가 없으면 업체와 어디서 말이 어긋나는가

요구사항 정의서는 "무엇을 만들고 싶은지"를 글로 적은 목록입니다. 길 필요도 없습니다. 이 문서가 하는 일은 발주자 머릿속에 있는 서비스와 업체가 이해한 서비스를 같은 모양으로 맞추는 것입니다.

이 문서 없이 "필라테스 예약 앱 하나 만들려고요" 정도로 상담을 시작하면 어긋나는 지점이 정해져 있습니다.

견적 단계: 업체마다 머릿속에 그린 앱이 달라 금액이 벌어지는데, 비교할 근거가 없습니다.
개발 중: "회원권 차감은 당연히 들어가는 줄 알았다"와 "그 기능은 처음 듣는다"가 부딪힙니다.
검수 단계: 화면은 나왔는데 운영 방식이 달라 "우리가 말한 건 이게 아니다"가 나옵니다.

누가 잘못했느냐보다, 돌아가서 확인할 문서가 없었다는 점이 문제입니다. 이 시리즈는 발주자가 업체에 건네는 문서를 순서대로 다룹니다. 1편이 요구사항 정의서, 2편이 화면설계서, 3편이 견적 요청서(RFP)입니다.

기능명세서, 기능정의서, PRD와 다른 점

기능정의서는 기능을 이름과 설명으로 나열한 목록이고, 기능명세서는 거기에 입력값과 예외 상황까지 적어 개발자가 바로 구현할 수 있게 만든 문서입니다. PRD는 IT 기업 안에서 기획자가 제품 목표와 측정 지표까지 담아 쓰는 문서입니다. 셋 다 쓰는 사람도 읽는 사람도 개발팀입니다.

발주자가 쓰는 요구사항 정의서는 서비스를 왜 만드는지, 누가 쓰는지, 어떤 기능이 꼭 필요한지를 발주자의 말로 적습니다. 예외 처리나 데이터 구조처럼 개발 쪽에서 채울 부분은 비워 둡니다. 그 빈칸을 업체가 질문하고 채워 간 결과물이 계약서에 붙는 기능명세서가 됩니다. 실무자가 추가로 챙길 항목은 RFP 요구사항 상세화와 제안서 평가 기준 정하기에 따로 정리해 두었습니다.

발주자용 양식 구성: 세 부분만 채우면 됩니다

퍼스트핍이 만든 양식은 프로젝트 개요, 기능 목록, 미정·질문 세 부분입니다. 요구사항 ID 체계나 비기능 요구사항처럼 발주자가 채우기 어려운 칸은 뺐습니다.

1. 프로젝트 개요

서비스 이름, 한 줄 설명, 주 사용자, 만드는 이유, 플랫폼(웹, iOS 앱, Android 앱, 관리자 페이지), 참고 서비스 1~3개, 희망 오픈일, 예산 범위, 우선순위(일정·비용·완성도 중 지킬 순서), 최종 결정권자와 연락 담당자를 적습니다.

특히 공들일 칸은 "만드는 이유"와 "우선순위"입니다. 이유가 있어야 업체가 다른 방법을 제안할 수 있고, 지킬 순서가 있어야 예산이 모자랄 때 협의가 빨라집니다. 결정권자와 담당자를 나눠 적는 이유는, 담당자가 답한 내용을 대표가 뒤집으면 그때까지 한 작업이 되돌아가기 때문입니다.

2. 기능 목록

문서의 몸통입니다. 한 줄이 기능 하나이고 칸은 여덟 개입니다.

번호: 업체와 통화할 때 "7번 기능이요"라고 부르기 위한 번호입니다.
사용자 구분: 회원, 강사, 관리자처럼 이 기능을 쓰는 사람입니다.
메뉴/화면: 어느 화면에 있을지 짐작 가는 대로 적습니다. 다음 편 화면설계서로 이어지는 칸입니다.
기능 이름: "수업 예약", "회원권 차감"처럼 짧게 씁니다.
상세 설명: 누가 무엇을 하면 어떻게 되는지를 한두 문장으로 씁니다. 가장 중요한 칸이라 아래에서 따로 다룹니다.
우선순위: 필수, 있으면 좋음, 나중에 중 하나입니다. 전부 필수로 적으면 없는 칸과 같습니다.
참고: 비슷한 기능이 있는 앱의 링크나 화면 캡처입니다.
업체 확인 메모: 발주자는 비워 둡니다. 업체가 "가능", "추가 비용", "다른 방식 제안"처럼 회신을 적어 돌려주면 그대로 협의 기록이 됩니다.

3. 미정·질문

정하지 못한 것, 그 이유, 업체에 묻고 싶은 것 세 칸입니다. 결제 방식을 정하지 못했으면 왜 못 정했는지(수수료를 모른다, 앱 결제 규정을 모른다)까지 적어 두면 업체가 그 부분부터 설명해 줍니다. 미정 사항을 숨긴 채 받은 견적은 나중에 그만큼 바뀝니다.

상세 설명 쓰는 법: 가나다 필라테스 예시

엑셀 양식의 '작성 예시' 시트에는 가상의 업체 '가나다 필라테스'가 수업 예약 앱을 발주한다고 가정하고 채운 예시가 들어 있습니다. 회원은 수업을 예약하고 취소하고, 강사는 자기 수업 일정을 보고, 관리자는 회원과 수업을 관리하는 앱입니다. 기능 16개와 미정 사항 3개를 적어 두었으니 형식을 그대로 따라 쓰시면 됩니다. 상세 설명 칸의 고치기 전과 고친 뒤를 나란히 두면 이렇습니다.

수업 예약: 고치기 전 "회원이 수업을 예약할 수 있다." 고친 뒤 "회원이 주간 시간표에서 수업을 고르고 예약 버튼을 누르면 예약이 확정되고 회원권 횟수가 1회 줄어든다. 정원이 찬 수업은 예약 버튼 대신 대기 신청 버튼이 보인다."
예약 취소: 고치기 전 "예약 취소 기능." 고친 뒤 "회원이 수업 시작 24시간 전까지 취소하면 회원권 횟수가 1회 복구된다. 24시간 이내 취소는 횟수가 복구되지 않고, 취소 버튼을 누르면 그 안내가 먼저 뜬다."
강사 일정: 고치기 전 "강사 스케줄 관리." 고친 뒤 "강사가 로그인하면 자기 수업만 보이고, 수업마다 예약한 회원 이름과 인원을 볼 수 있다. 수업을 만들거나 지우는 일은 관리자만 한다."
회원 관리: 고치기 전 "관리자가 회원을 관리한다." 고친 뒤 "관리자가 회원을 등록하고 회원권(10회, 20회, 기간제)을 부여한다. 회원별로 남은 횟수와 예약 이력을 볼 수 있다."

고친 문장에는 누가 하는지, 어떤 조건에서 결과가 달라지는지, 화면에 무엇이 보이는지가 들어 있습니다. 업체가 견적을 낼 때 세는 것이 바로 이 조건과 화면입니다. 취소 기준 24시간이나 회원권 종류처럼 아직 못 정한 값은 임시 값을 적고 미정·질문 칸에 "검토 필요"라고 남기면 됩니다. 업체는 빈칸보다 임시 값에 더 정확하게 답합니다.

쓰다가 막히는 지점

기능이 몇 개여야 하는지 모를 때: 참고 서비스의 메뉴를 하나씩 눌러 보면서 필요한 것만 적으세요.
관리자 기능을 빼먹을 때: 회원이 예약을 하면 누군가는 그 예약을 보고, 바꾸고, 취소해 줘야 합니다. 그 사람이 쓰는 기능을 관리자 줄에 적으세요.
기술 용어를 써야 할 것 같을 때: "예약 전날 저녁에 회원 휴대폰으로 알림이 간다"처럼 일어나는 일을 적으면 용어는 업체가 붙입니다.
개발 도중 내용이 바뀔 것 같을 때: 바뀝니다. 그래도 처음 문서가 있어야 무엇이 바뀌었는지 셀 수 있습니다. 변경 처리 절차는 개발 외주 요구사항 변경과 추가 비용 관리에서 다뤘습니다.

양식 다운로드와 다음 편

양식은 엑셀 파일 하나입니다. 첫 시트에 1단계 프로젝트 개요, 2단계 기능 목록, 3단계 미정·질문이 차례로 있고, 칸마다 회색 ex) 예시가 들어 있어 지우고 쓰면 됩니다. 둘째 시트는 가나다 필라테스 작성 예시입니다.

요구사항 정의서 양식 (엑셀, 41KB)

다음 편에서는 기능 목록의 '메뉴/화면' 칸을 바탕으로 화면설계서를 만드는 방법을, 그다음 편에서 견적 요청서를 다룹니다.

이 글은 「처음 맡기는 개발 외주, 발주 문서 준비」 시리즈 3편 중 1편입니다.

1편: 요구사항 정의서 작성법 (지금 보는 글)
2편: 화면설계서 작성법, 메뉴구조도와 와이어프레임
3편: 견적 요청서 양식과 작성법