🔫 요구사항 정의서 작성 전에 해야할 일이 있다? 서비스를 개발할 때 요구사항 정의서는 계약서와 비슷한 서로 간의 약속에 해당한다. 개발을 진행하려면 요구사항 정의서는 필수적으로 필요하다. 나는 매번 새로운 프로젝트를 시작할 때 요구사항 정의서를 작성하기에 앞서 서비스 전략 기획서 (= Proposal Doc)를 먼저 작성하는데 왜 해당 프로젝트를 해야 하는지 목표와 사용자 분석 정보, 서비스 전략을 간단하게 정리 후 멤버들에게 피드백을 받는다. 이 피드백을 받고 부족한 부분을 채움으로써 팀 멤버들의 개발 방향성이 같아질 수 있도록 최선을 다한다. 그리고 그 후에 요구사항 정의서를 작성한다. 해당 글처럼 기획이 완료되려면 기능 명세서 작성 등 고도화 작업을 거쳐야만 하기 때문에 개발 멤버들에게 어느 정도 업무 범위인지와 주요한 기능이 무엇인지를 요구사항 정의서를 통해서 사전에 명시함으로써 기능 구현 가능 여부 검토와 우선순위를 같이 조정할 수 있게 된다. 의외로 서비스 전략 기획서를 스킵하고 요구사항 정의서를 개발 멤버들에게 공유하는 사례가 더러 있는데 기획(비즈니스 모델)과 개발(서비스 설계, 기능 구현 가능 여부)은 관점 차이가 있기 때문에 왜 만들어야 하는지 등 같이 이해하고 목표를 설정하면 정말 중요한 것이 무엇인지 다 같이 고민하게 되고 최선의 결과물로 이어질 수 있다고 생각한다. 📝 이하 아티클 메모 1. 개발자/디자이너는 ‘서비스의 설계나 기획, 기능의 구현 가능 여부 측면’에서 접근하는데요. 여러분이 구상하고, 기획한 대로 프로젝트가 끝나기 위해서는 그 의도를 충실히 담은 ‘요구사항 정의서’가 필요합니다. 2. 아이디어가 제대로 정립되어 있지 않다면, 필수적인 기능에 대한 기준을 세울 수 없기 때문에 먼저 아래와 같은 내용을 정리할 필요가 있다. -왜, 이 서비스를 기획하는가? -주요 고객은 누구인가? -어떻게 서비스를 제공할 것인가? -어떤 채널을 통해 고객에게 다가갈 것인가? -프로젝트 멤버는 누구인가? -서비스 오픈 시점은 언제인가? -시장 현황과 자사의 경쟁력은 무엇인가? -어떻게 수익화할 것인가? 3. 요구사항정의서는 의뢰자와 작업자가 구현하기로 합의한 업무범위와 상세 기능들을 명확하고 완전하게 명시한 문서입니다. 통상적으로 킥오프 미팅에서 기능 구현 가능 여부 검토와 우선순위별 업무 조정과 같은 과정을 거친다. 4. 요구사항정의서 초안 버전을 작성해서 개발 멤버들에게 리뷰를 받는다. 이는 초기 서비스 기획 문서로, 만들고자 하는 서비스의 규모나 요구사항이 포함되어 있어야 합니다. 5. 요구사항정의서 초안버전을 만들었다고 해서, 기획이 완료되었다는 것을 뜻하지는 않습니다. ‘기획완료’란 개발자가 기획문서를 보고 바로 작업에 착수할 수 있는 상태를 의미합니다. ‘요구사항정의서’는 말그대로 ‘초안’버전이기에, 작업자의 시선에서 다시 분석하고 다듬는 작업이 필요합니다.