웹 기획 산출물: 요구사항 정의서 작성하기

요구사항 정의서가 도대체 뭐길래, 왜 작성해야 할까요?

한 프로젝트를 수주하기 위해 비딩을 하는 과정에서 RFP(Request For Proposal) 즉 제안 요청서를 받게 됩니다. 프로젝트를 만들고자 하는 클라이언트 측에서 담당할 업체를 선정하기 전에 여러 후보 업체에게 제공하는 문서인데요. 쉽게 말해서 ‘우리 회사는 이런 주제로 서비스를 론칭하려고 하고, 이렇고 저런 기능들이 포함되어야 해!’를 정리한 문서라고 이해하면 됩니다. 전달받은 RFP를 토대로 회사의 영업팀 또는 기획자, PM 등이 프로젝트 수주를 위한 제안서를 작성하겠죠? 이렇게 탄생한 제안서를 기반으로 최적의 업체로 우리 회사가 선정되면, 하나의 프로젝트가 시작되는 것이죠. 

프로젝트의 시작과 동시에 기획자는 우리의 클라이언트가 원하는 요구사항에 대해 빠르게 파악해야 합니다. “요구사항 뭐 별거 있겠어~ 그냥 플젝하면서 그때그때 대응하면 되지 뭐.”라고 생각하시는 분들 지금 엄청 뜨끔 하실 겁니다. 정답은 없겠지만, 저는 요구사항 정의서를 작성하는 이 시간이 추후 프로젝트의 끝무렵에 스트레스를 덜 받고, 덜 고생할 수 있는 방법이라고 말씀드리고 싶습니다. 요구사항 정의서 없이 시작하게 되면 개발이 끝나는 무렵 느닷없이 새로운 기능을 요구하는 고객사와 트러블이 마구마구 생기게 될 테니까요.

100% 완벽한 요구사항 정의는 없습니다.

RFP를 참고하여 현업 담당자와 많은 대화와 이메일을 주고받으며 요구사항을 추려서 문서를 완성시켰다고 가정해보겠습니다. 프로젝트가 끝날 때까지 고객사가 추가로 요구하는 요구사항이 없을 수 있을까요? 그 누구도 장담할 수는 없겠지만 아마도 제 짧은 경험상, 그게 끝은 아닐 겁니다. 갑자기 고객사의 회원 정책이 바뀔 수도 있고, 이미 협의된 사항이라 하더라도 번복될 수 있기에 확정된 요구사항이라고 단정 짓지 말고 모든 개발이 완료될 때까지 지속적으로 관리하는 작업이 필요합니다. 이렇듯 처음부터 완벽한 요구사항 정의서는 없기에 프로젝트 끝까지 고객 요청 사항을 보다 효율적으로 관리하고, 추후 논쟁 시에 그때 당시 히스토리를 추적하기 위해서 작성하고 있습니다.

요구사항 정의서 작성하는 방법

요구사항 정의서의 개념과 중요성에 대해 어느 정도 파악했다면, 이제 어떻게 작성하는지 샘플과 함께 살펴보겠습니다. 아래 문서의 경우 제가 설명을 위해 샘플로 제작한 문서이며, 실제 제가 일하면서 사용하는 문서 양식과 거의 유사합니다.

• 요구사항 구분: 프로젝트 규모가 크면 클수록 확인해야 할 요구사항이 많습니다. 예를 들어 웹사이트/앱/관리자 페이지 모두를 구축해야 하는 프로젝트라면 제일 앞쪽에 [구분] 칼럼을 만들어 주는 것이 좋습니다.

EX) [웹], [앱], [사용자], [관리자], [공통]

• 요구사항 ID: 화면 설계서를 작성할 때 화면 별 화면 ID를 부여하는 것처럼 요구사항들을 관리하기 위한 [요구사항 ID]를 부여합니다. 고객사와 대화를 할 때나 개발팀과 커뮤니테이션 할 때마다 매번 주절주절 말로 설명하기보다는 요구사항 ID를 통해서 커뮤니케이션하는 것이 덜 혼란스럽고 명확하기 때문이죠! 요구사항 ID 부여에 있어서 정해진 룰은 없고 회바케 회사 나름입니다. 보통 규모가 작은, 비교적 간단한 프로젝트의 경우에는 Requirements Statement 약자인 REQ에 숫자 번호를 붙여서 부여하기도 합니다. 반대로 규모가 큰 프로젝트에서는 앞서 설명드렸던 요구사항 구분에 따라서 더 세분화하여 표현할 수도 있고요! 기능적으로 구분될 수 있도록 만 작성하면 큰 문제없습니다.

EX) [REQ-001], [WEB-001], [APP-001], [ADM-001]

• 요구사항 명: 말 그대로 해당 요구사항이 어떤 요구사항인지 요약하여 기재합니다. 상세한 내용이 아닌 키워드로만 작성해도 좋습니다. 저는 주로 명사형으로 끝날 수 있도록 작성하곤 합니다.

EX) [일반회원 회원가입], [메신저 기능], [자유게시판], [앱 푸시 기능]

• 요구사항 상세 설명: 요구사항에 대한 상세한 내용에 대해 기재합니다. 상세 설명은 자세하면 자세할수록 좋습니다. 그만큼 기획자가 고객 요구사항에 대해 더 자세히 파악하고 이해했다는 뜻이니까요.

EX) [일반회원의 경우 아이디와 비밀번호로 로그인할 수 있도록 함], [상대방과 1:1 채팅 메시지, 사진 전송, 음성통화, 영상통화 기능 제공]

• 요청자: 요구사항을 요청한 요청자 정보를 기재합니다. 여러 부서 담당자들이 요청할 경우에는 부서와 요청자를 함께 작성하는 것이 좋습니다. 추후 요구사항에 대하여 더 자세히 논의가 필요한 상황이 생길 수 있기 때문에, [요청자] 칼럼은 꼭 작성하시기를 권장합니다.

EX) [마케팅팀 김나나 대리], [신짱구 과장]

• 비고: 참고할 만한 레퍼런스를 전달받았거나, 수행사에서 역으로 확인 요청을 할 때에 비고란에 내용을 기재하기도 합니다.

EX) [굿리치 웹사이트 참고 (레퍼런스)], [메일 발송 대행업체 확인 필요]

이외에도 경우에 따라 다양한 칼럼으로 요구사항 정의서를 작성할 수 있습니다. 

• 메뉴 위치: 자세한 메뉴 위치를 뎁스 별로 쪼개서 요구사항을 기재하기도 합니다. 이 경우에는 메뉴 구조도 IA와 요구사항 정의서를 통합해서 하나의 문서로 작성할 수도 있습니다.

EX) [메인 → 고객센터 → 자유게시판] 

• 중요도: 개발 우선순위 파악을 위하여 각 요구사항의 중요도를 표기할 수도 있습니다. 중요도를 파악할 때는 꼭 고객사 담당자와 협의 후 작성이 필수입니다. 기획자 본인이 판단하는 중요도와 고객사 담당자가 판단하는 중요도가 다를 수 있습니다. 

 EX) [상/중/하], [Major/Minor] 

• 요청 일자: 1차적으로 요구사항을 정의하고 나서 추가적으로 요청이 들어온다면 요청 일자 기재는 필수입니다. 매번 누가 언제 요청한 사항인지 기억할 수 없고, 찾으려면 온갖 메일을 다 뒤져보아야 하기도 합니다.

EX) [08/05], [2021년 08월 5일]

• 수행사 수행/수용 여부: 정리된 요구사항 정의서를 보고 수행사의 디자인/개발팀에서 수행 여부를 판단합니다. 경우에 따라서는 기획자 또는 PM이 판단하는 경우도 있긴 합니다만, 규모가 큰 프로젝트를 진행할 때에는 일정 등을 고려하여 수행 여부를 명확히 전달해주는 작업이 필요합니다.

EX) [수행], [협의 필요], [협의 진행 중]

• 난이도: 수행 여부를 기반으로 고객사와 일정 조정 등의 이유로 협의가 필요할 때, 고객사에서 요구사항의 난이도를 물어보기도 합니다. 얼마나 오래 걸리는 작업인지 먼저 파악한 후에 난이도를 함께 작성하는 것도 좋은 방법입니다.

EX) [상/중/하], [매우 높음]

• 요구사항 근거: 프로젝트를 진행하다 보면 고객사의 여러 담당자들과 커뮤니케이션을 하고 요구사항을 작성하게 됩니다. 이때 전화 통화를 통해서 전달받은 요구사항인지, 이메일을 통해 전달받은 것인지 히스토리를 남겨두는 것이 도움이 될 수 있습니다.

EX) [유선], [이메일], [08/05 고객사 회의]