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

요구사항정의서는 회사 혹은 프로젝트 규모에 따라 조금씩 변형하여 작성하기 때문에
내 기준 서비스 규모에 따라 요구사항 정의서를 그에 맞게 적용한다.

이번 글은 규모가 크거나 요구사항 목록이 많을 경우 사용하는 예시이다.

 

작성 예시 2

요구사항정의서의 또 다른 예시

 

위의 양식의 경우는 진행할 개발의 최종 비즈니스 목표와 같이 직무와 상관없이 공통으로 참고해야할 요구사항도 표 윗부분에 추가되어있다.

예시와 같이 한 시트에 작성하거나 표지처럼 나누어 작성하기도 한다.

 

ID: 요구사항정의가 완료되고난 후 해당하는 ID를 부여하여 적는다.

구분: 사용자와 관리자로만 나뉜 서비스가 아니라, 여러 시스템을 연계해서 프로젝트를 진행하는 경우가 있다. 이때 공통, 사용자, 관리자 시스템 1, 관리자 시스템 2와 같이 구분하여 작성한다.

서비스(메뉴): 해당 사용자 혹은 관리자 시스템들을 개발할때 해당되는 메뉴명들을 적는다. 로그인을 예로 들면 사용자의 경우는 회원가입과 같고, 관리자의 경우는 회원 관리(메뉴명)을 적어볼 수 있다.

기능: 개발될 기능을 적는다. 이때 말 그대로 사용자/관리자들이 사용할 기능들을 적는 것 외 개발적 측면에서 반영해줘야할 기능들도 적게 된다. 예를 들면 '회원 탈퇴 시 별도의 DB에서 관리해야한다.' 라는 요구사항이 있을때 이에 해당하는 부분은 시스템 개발적인 측면에서만 적용되는 기능이다.

이러한 기능처럼 서비스를 사용할 이용자들 뿐 아니라 필요한 디자인, 개발, 환경적인 측면의 모든 요구사항을 적어야 한다.

상세기능: 기능에 대한 상세 설명을 적는다. 기능에서 '탈퇴 회원 별도 DB 관리' 라는 기능 요구가 있을때 상세 설명으로는 어느 시스템과 연계된 어느 위치의 DB에 관리하는지 등 가능한 상세히 적어두는 것이 좋다.

개발상태: 이미 개발한 상태를 체크해도 되지만 새로운 기능이라면 개발할 기능의 개발 방식을 말한다. 위의 예시는 좀 더 사용자 측면의 개발 상태를 적었지만, 경우에 따라 개발적인 요소가 포함된 상태로 적어두어도 된다. 이는 작성자와 이해관계자들의 협의사항에 따라 변경하여 적을 수 있다.

출처: 이전 글에 설명한 것처럼 작성한 요구사항의 근거를 적는다. 

제약조건: 제약조건의 경우 기존 연계 시스템에 대한 조건들을 적거나, 사용자 측면에서 필요한 조건들을 명시한다. 이 부분은 상세 기능에 설명하여 생략하기도 한다. 좀 더 명확하고 구체적으로 기록하고자 한다면 적는 것도 좋다.

특이사항: 해당 요구사항에서 참고해야할 사항을 적으면 된다.

 

 

 

위의 작성 양식에 대한 부분들은 정답이 아니다.
본인의 서비스 규모와 환경 등 여러 요소를 종합하여 이해관계자들과 함께 만들어나가는 문서이기 때문에 그에 맞게 잘 활용해야한다.