외주 개발

요구사항 정의서 양식과 작성법: 비개발자도 쓰는 외주 개발 템플릿

firebench 팀

요구사항 정의서란?

요구사항 정의서는 만들려는 서비스가 무엇을 할 수 있어야 하는지를 개발사와 같은 말로 적어 둔 문서입니다. 외주 개발에서는 견적의 기준이 되고 완성됐는지 따지는 검수의 기준이 됩니다. 회사에 따라 기능 정의서나 기능 명세서라고도 부릅니다.

비슷한 문서와는 역할이 다릅니다.

처음부터 세 문서가 모두 필요하지는 않습니다. 외주를 맡기기 전이라면 요구사항 정의서 한 장이 가장 도움이 됩니다.

일곱 칸이면 충분합니다. 엑셀이나 구글 시트에 그대로 옮겨 쓸 수 있고 양식 파일(CSV)을 내려받아 열어도 됩니다. 아래 예시는 주문 관리 서비스를 가정했습니다.

ID	분류	요구사항	사용자	우선순위	완료 기준	비고
R01	주문	관리자는 오늘 들어온 주문을 목록으로 볼 수 있어야 한다	관리자	필수	오늘 주문이 최신순으로 나오고 주문 번호, 고객명, 금액이 보인다
R02	주문	관리자는 주문 상태를 접수, 배송중, 완료로 바꿀 수 있어야 한다	관리자	필수	상태를 바꾸면 목록에 바로 반영되고 되돌릴 수 있다
R03	알림	고객은 주문 상태가 바뀌면 문자를 받아야 한다	고객	나중	상태가 바뀐 뒤 1분 안에 문자가 간다	문자 발송 업체 미정

1단계: 해결하려는 문제를 한 문장으로 씁니다
2단계: 서비스를 쓰는 사람을 나눕니다. 관리자, 고객, 운영자처럼요
3단계: 사용자별로 해야 하는 일을 한 줄씩 늘어놓습니다
4단계: 필수와 나중으로 나눕니다. 필수가 너무 많으면 첫 버전의 범위가 크다는 신호입니다. 범위를 줄이는 기준은 MVP 개발 기간은 무엇이 정하나요?에서 다룹니다
5단계: 기능마다 완료 기준을 붙입니다

구현 방식까지 정해 버립니다. 데이터를 어디에 저장할지 같은 기술 선택은 개발사에 맡기고 원하는 결과만 적습니다. 이미 쓰는 시스템이 있다면 그것만 알려 주세요.
모호한 형용사를 씁니다. 「빠르게」, 「편하게」, 「깔끔하게」는 검수할 수 없습니다. 「목록이 3초 안에 열린다」처럼 확인할 수 있게 씁니다.
한 줄에 기능을 여러 개 넣습니다. 「로그인하고 주문하고 결제한다」는 세 줄로 나눕니다.
우선순위가 없습니다. 전부 필수면 일정과 견적을 줄일 방법이 없습니다.
완료 기준이 없습니다. 나중에 「이게 아닌데」로 이어지기 쉽습니다.

요구사항 정의서는 완성해서 건네는 시험지가 아닙니다. 개발사가 빈칸과 모호한 곳에 질문을 던지게 하는 출발점입니다. 칸을 채우다 막히면 그 칸이 상담에서 같이 정할 안건입니다.

firebench는 기획서나 요구사항 정의서가 없어도 시작할 수 있습니다. 무료 상담에서 문제 상황을 듣고 3일 안에 시제품과 로드맵을 만들어 드립니다. 양식을 채워 오시면 상담이 조금 빨라질 뿐입니다. 막히는 칸이 있다면 무료 상담에서 같이 정리합니다.

정해진 분량은 없습니다. 첫 버전에 필요한 기능이 모두 들어 있고 완료 기준이 적혀 있으면 충분합니다. 한 장짜리 표여도 됩니다.

기획서는 왜 만드는지와 누구를 위한 것인지를 다룹니다. 요구사항 정의서는 그 서비스가 무엇을 할 수 있어야 하는지를 다룹니다. 기획서가 없어도 요구사항 정의서부터 시작할 수 있습니다.

엑셀, 구글 시트, 노션 어디든 됩니다. 칸이 일정하게 유지되고 개발사와 함께 고칠 수 있으면 됩니다.

바뀌는 일은 자연스럽습니다. 바뀐 내용을 문서에 남기고 일정과 견적에 미치는 영향을 같이 확인하는 것이 중요합니다. firebench는 로드맵에 담은 범위는 일정이 늘어나도 추가 비용 없이 마무리하고 범위를 넓히는 요청은 진행 전에 견적을 먼저 드립니다.