요구사항 정의

 

왜 요구사항정의가 필요 할까요?

기획은 과거와 현재를 기반으로 미래를 설계하고 만들어가는 작업이라고 생각합니다. 비즈니스를 운영중에 데이터화로 필요한 모든 노하우, 아이디어, 업무문서 등이 누적됩니다.

기획자는 눈에 보이지 않는 이러한 누적 데이터들의 상호관계를 이해하며 이 데이터들이 만들어낼 미래까지 나름대로 가늠하고 파악할 수 있어야 합니다. 따라서 기획자는 정보를 파악하고 이해하는 능력이 가장 기본이 되어야 합니다.

하지만 프로젝트를 진행하다 보면 정보파악 및 이해순의 능력이 아니라 회의 중 나온 기본적인 말과 의도조차 파악하지 못하는 기획자가 많습니다. 아니라는 말을 맞다고 받아 들이거나, 하지 말라는 말을 하라는 말로 이해하고, 심지어 화를 내고 회의 분위기가 험악했는데도 회의가 잘 끝났다고 업무파악이 됬다고 회의록 후기를 작성 하기도 합니다.

이러다 보니 개발 기획 시 전달받은 요구사항 명세서 그대로, 상세화 작업 없이 스토리보드 작업을 하는 경우도 종종 있습니다. 무엇을 어떻게 상세화 해야 하는지 알지 못할 뿐 아니라, 서비스의 방향, 목표, 시스템화 의도가 무엇인지 파악해서 목록화 한다는 것조차 모르는 경우도 있습니다. (의외로 이런 기획자가 많이 있다는 점에 놀라게 될 것입니다.)

 

 

요건상세화의 중요성

기획자의 업무 중 요건분석이라는 것은 무엇을 개발해야 하는지를 분명하게 하는 필수업무 입니다. 같은 이커머스 플랫폼을 개발한다고 해도 옥션을 개발하는 것과 스마트스토어를 개발하는 것은 다른 일입니다.

하지만 많은 서비스개발 기획자들은 이걸 같게 생각하는 경우가 많습니다. 이럴경우 경쟁우위의 서비스 경험, 차별사항등은 모두 제외되고 공통분모인 상품목록, 장바구니, 결제 만 구현되게 됩니다. 디자인 또한 공통분모인 이커머스 형태로 되어 개성도 날아가겠지요.

요건정의서는 요건상세화 하는 일중에서 우선이며 이후 플로우, 기능정의, 스토리보드까지 영향을 주는 업무이며, 이는 개발의 방향성의 오차를 줄여줍니다. 또한 기업이 가지고 있는 개발 환경의 특수성을 파악할 수 있게 해 줍니다. 각 기업마다 데이터 방식, 결제 솔루션, 통합 장바구니 참조 객체 등 기존 개발 상황에 따라 차이가 있을 수 있기 때문입니다.

요구사항 상세화를 하지 않는다면 또는 제대로 진행하지 못한다면 해당 온라인 서비스 개발 환경의 특수성을 제대로 파악할 수 없게 됩니다. 당연히 개발 리스크는 커지고 실패 가능성은 올라가게 됩니다.

즉, 리스크 감소를 위해 요건상세화는 필수이고, 요건정의서라는 형태로 문서화 되고 서비스를 기안한 고객과 공유가 되어야 합니다.

 

 

요건정의서 특징

1. 요건정의중 가장 기본적인 요구사항정의는 프로젝트, 시스템에 필요한 항목들을 리스트업 및 정리 한 내용입니다. 이 내용을 기준으로 프로젝트속에서 시스템속 프로그램들이 해야할 제반사항에 대한 내용을 기재 하게 됩니다. 또한, 프로덕트의 기능들을 정리해 보여주고, 추후 소통 과정에서 발생하는 갈등을 예상하거나 예방할 수 있게 도와줍니다.
2. 에이전시의 경우, 클라이언트가 원하는 요구사항에 대해 빠른 대응 및 피드백을 줘야 합니다. 요구사항정의서가 명시 및 관리가 되지 않는 경우, 갑자기 추가되는 다양한 기능과 요건에 대응할 방법이 없기 때문입니다.
3. 요구사항 은 프로젝트 진행중에 끝없이 요건이 변경되고 추가가 됩니다. 요구사항 정의서는 이에 따른 히스토리를 확인하고 시행착오를 줄이는 역할을 하게 됩니다.

 

작성된 요구사항들은 다 개발이 되어야 할까요?

아닙니다. 이러한 요건들은 프로젝트의 기간과 비용에 가장 큰 영향을 주는 항목으로 한정된 기간과 비용, 자원속에서 목표에 맞는 프로덕트가 되도록 “협의” 및 “조정”을 하여야 합니다. 협의, 조정된 요건들은, 이후 기능으로 목록화 되어 기능정의서를 위한 기본 백그라운드가 되어 주는 역할을 합니다.

“요구사항 정의서”를 작성 시, 이는 100% 작성후 넘어가는 완성 필수 문서가 아닙니다. 완성될 필요도 없고, 또 사실 작은 규모의 프로덕트는 제외해도 됩니다. 기능정의서, 플로우, 화면설계서에서 충분이 포함이 되기에 그때 확인 해도 무관 하기 때문입니다.

 

 

요구사항정의서는 어떻게 작성해야 하나요?

요구사항은 프로젝트에서 완료 될 프로덕트의 실 이용자(회원, 실무자) 로부터 업무담당자, 클라이언트, 고객피드백 통해 발생 됩니다.

기획자는 이때 요건을 취합하고 시스템화 필요한 요건만을 정리하여 체계화 해야 합니다.

또한 요건들을 모두 프로덕트안에 입혀줘야 하는것도 아닙니다. 요구사항정의서의 역할은 “목표 수립” 이라는 전략에 맞는 “전략”을 선정하는 기능 선정 및 확정 요소 이기 때문에, 전략과 전술에 상관없는 요건은 Keep하거나 ByPass 해도 되기 때문입니다. 클라이어트경우 협의하여 승인/부분승인/반려/보류 등의 상태로 요구사항의 개발여부를 마크 해 놓으면 됩니다.

요국사항 정의서의 양식은 엑셀이 사실 제일 편하고, 워드, 노션, 구글 Doc, 트렐로 등 자유롭습니다.

자주 사용되는 항목을 정리해 보겠습니다.

 

• 번호 (SEQ)
• 구분 : 프로젝트 규모가 크면 클수록 확인해야 할 요구사항이 많습니다. 예를 들어 웹/앱/관리자 페이지 모두를 구축해야 하는 프로젝트라면 제일 앞쪽에 “구분”을 두어 분류를 하는게 좋습니다.
• 요구사항 ID : 요구사항의 구분에 맞는 ID를 네이밍 하여 일렬번호를 지정 해 줍니다. 이 항목은 개발진행중 이슈발생 시, 참여자와 명학한 이슈위치를 지정해 주는 역할을 합니다. 요건번호가 너무 많은 경우는 개발팀도 분야별로 구분이 되기에 아래와 같이 세분화 하여 네이밍을 작성하시면 됩니다.
  예) REQ_01, WEB_01, APP_01, ADMIN_01
• 요구사항명 : 해당 요구사항의 개요를 간단하게 기재 합니다.
• 요구사항 : 요구사항을 서술형으로 기재 합니다. 그리고 서술은 자세하게 작성해 두는 것이 좋습니다. 미작성된 요건은 나중에 추가해야 하거나 클라이언트, 개발자의 문의, 오해를 살 수 있는 부분입니다. 요구사항이 추가로 생기는 경우 해당 요구사항에 내용을 추가하고, 개정이력을 통해 언제 파일이 업데이트 되었는지를 알 수 있도록 합니다. 사실 개정이력까지 봐 가면서 하기 힘들기에 댓글, 메모등에 알고 있어야 할 사람들에게 “멘션”을 해 두는것을 선호 합니다. 저는 이 부분때문에 구글스프레드시트를 선호 합니다.
• 요구처 : 해당 요건에 대해 추가 논의가 필요한 담당자를 기재 합니다. 부서일 경우 부서명과 담당자명을 기재하면 좋습니다.
• 진행여부 - 진행, 미진행, 보류
• 협의 내용
• 비고

샘플에 없으나 필요시 추가할 항목의 제한은 없습니다.

아래 항목은 컬럼 추가하여 더 디테일한 정보를 작성할 수 있습니다.

추가될수 있는 항목 : 중요도(등급) / 난이도(상,중,하) / 요청일 / 최종수정일 / 최종수정자 / 요구사항형태 (회의,이메일,전화 등)