서비스 기획 요구사항 정의서 작성 방법

요구사항 정의서는 서비스 개선 혹은 구축 전 이해관계자들과 협의된 내용들을 적는 문서이다.
해당 문서에 명시된 내용들은 모두 협의된 내용이기에 프로젝트 초기 설계부터 테스트가 완료되는 시점까지 지속적으로 참고한다. 

서비스(혹은 프로젝트) 규모에 따라 작성 범위가 다르다.
사용자 중점 기능들 위주로 적고 비기능적 요소(보안, 품질, 시스템 효율 등)은 필수적인 것들만 적거나,

사용자 중점의 기능적 요소와 비기능적 요소 모두를 구체적으로 적는 경우도 있다.

해당 문서는 워터폴 방식 프로젝트의 경우 설계 이후 단계에서 수정하기 어렵기 때문에 명확하고 자세히 적는 것이 좋다.
(애자일 프로젝트의 경우는 지속적으로 요구사항을 변경될 수 있다.)

보통 회사에서 필요로 하는 요구사항정의서는 명확하게 작성되어야 추후 이해관계자들과 논쟁 사유가 되지 않으므로 모든 이해관계자들이 긴밀하게 검토해야하는 문서다.

 

요구사항 정의서 

출처 - 예스폼 서식사전

위의 양식은 네이버에 검색 시 나오는 양식 플랫폼에서 다운받을 수 있는 서식이다.
요구사항 정의서도 다른 모든 문서와 마찬가지로 본인의 서비스 혹은 환경에 맞게 변형하여 적절히 적용해야한다.

작성 예시 1

나의 경우는 서비스 규모에 따라 요구사항 문서를 다르게 쓴다.
아래는 규모가 크지 않을때 작성하는 요구사항 정의서이다.
실무에 적용할 때 대체적으로 어떻게 작성했는지를 공유하는 것으로 본인의 환경에 맞게 작성하길 바란다.

서비스 규모가 작을 때

위의 요구사항 정의서는 작성 시 필수로 있어야 하는 필드만 있는 경우이다.

업무 기능의 경우 사용자에게 필수로 제공되는 기능들의 요소와 비기능 요소(시스템, 효율, 보안 등)를 나누어 작성한다.
정답은 없기 때문에 경우에 따라 업무 기능 단계부터 로그인, 장바구니와 같이 사용자에게 작성할 화면 단위로 작성하거나 UI UX/디자인/개발/ 등과 같이 나누기도 한다.

요구사항명은 요구사항에 대한 제목이라고 생각하면 된다.
'로그인 시 해외 이용자들은 국내 이용자들과 구분된 화면을 제공한다.' 라는 요구사항이 있을때 요구사항명은 '해외 유저 로그인 화면'과 같이 이를 요약하여 나타낸다.

요구사항 설명 요구사항에 대해 설명하는 부분이다. 요구사항정의서를 보는 이해관계자들이 어떤 업무를 담당하더라도 이해할 수 있도록 구체적이고 명확하게 적는 것이 좋다.

상태는 초안으로 작성한 요구사항정의서를 기반으로 이해관계자들과 협의한 상태(결과)를 작성한다.

중요도도 마찬가지로 해당 요구사항이 이번 프로젝트에서 얼마나 중요한지 우선순위를 매기는 것이라고 생각하면 된다. 물론 이 우선순위 또한 이해관계자들과 협의하에 작성된다.

검토 또는 논의 내용은 검토 및 논의 내용은 해당 요구사항을 협의하면서 논의된 추가 협의 건 혹은 재논의가 필요한 것들 위주로 내용을 적어두면 된다.

문서 출처 문서 출처는 해당 요구사항에 대한 요구 근거를 어디서 찾았는지 작성해야한다. 에이전시와 같이 외주를 받거나 다른 회사와 협업을 통해 업무를 진행한다면 서비스 의사결정자 측에서 작성한 RFP(제안요청서)와 같은 문서를 토대로 작성하기 때문에 해당 요구사항이 어느 문서 혹은 어느 회의록을 참고하면 이에 대한 근거가 되는지를 알 수 있기 때문에 적는다.

 

프로젝트 규모가 큰 경우 작성하는 요구사항정의서는 위의 요구사항보다 더 자세한 필드로 구성되어있다.
다음 글에 이어서 작성할 예정이다.