brunch

라이킷 26 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 기획자 첼라 Feb 07. 2023

요구사항정의서, 어떻게 작성해야 할까요?

웹기획 사전

앞서서 우리는 요구사항을 수집하는 방법에 대해서 알아보았습니다.

필요한 요구사항들, 잘 수집하셨나요?

자, 그렇다면 이제 수집된 요구사항을 문서로 정리할 시간입니다.

우선은 요구사항정의서가 왜 필요한지에 대해서 알아봅시다.

rohitfarmer, 출처 Unsplash

프로젝트가 본격적으로 시작되고 나면 서비스를 구성하는 각 화면에서 필요한 기능을 분석하게 됩니다.

가령

회원가입을 SNS계정으로 가입 가능하도록 지원

이런 한 줄의 요구사항이 있다고 가정해봅시다.

단순한 한 줄의 문장같지만 이 기능을 구현하기 위해서 결정되어야 하는 사항이 여러가지가 있습니다.

첫번째. 서비스 성격상 SNS 계정 가입을 지원하는 것에 문제가 없는지에 대한 검토가 필요합니다.

단순한 커뮤니티 사이트, 브랜드 소개 사이틀라면 서비스를 제공하는데 있어서 기본적인 회원정보만으로도 충분히 가능하기 때문에 큰 문제가 없을 수 있습니다. 하지만 금융 서비스와 같이 개인 정보와 직접적인 연결이 필요한 서비스라면 어떨까요?

SNS계정 연동 가입, 즉 *Oauth로 해당 가입 기능을 제공하게 되면 서비스에서 필요한 개인의 정보를 충분히 확보할 수 없습니다. 본인인증도 불가능하죠. 이런 경우라면 회원가입 절차는 별도로 두는 것으로 방향 전환이 필요합니다.

두번째. 제공할 SNS계정과 우리 서비스를 연결하는데 있어서 문제는 없는지 검토합니다.

Oauth를 제공하는 많은 서비스들이 개발자 센터 사이트를 통해서 필요한 개발 스펙과 코드, 이슈 사항을 게시하고 있습니다. 이런 부분에 대해서는 개발자의 전문 검토가 필요하지만 기본적으로 데이터에 대한 개념만 알고 있다면 기획자도 기본 사항은 충분히 숙지할 수 있습니다. 따라서 무조건 개발팀에 맡기기 보다는 기획팀에서도 이렇게 미리 파악할 수 있는 기술적 사항들을 읽어보고 함께 검토를 하시는 것을 추천합니다.

세번째. 해당 기능을 구현하는데 있어서의 기술 난이도, 개발 기간에 대해서 확인합니다.

이 내용에 대해서는 개발팀의 검토가 필요한 부분입니다. 흔하게 여러 사이트에서 사용되고 있는 기술이라고 할지라도 실제로 그것을 우리 서비스에 구현하는데 있어서 필요한 기술 난이도와 개발 기간은 쉽게 예측할 수 없습니다. 서비스마다 가지고 있는 개발 스펙도 다르고 환경도 다르고 심지어 업무를 진행할 개발자의 경험도 영향을 끼칠 수가 있기 때문입니다.

요구사항정의서 예시

요구사항정의서 작성 시 필수 사항

아이디(ID)

분류/항목

상세내용

요청자/요청일자

중요도(우선순위) 난이도

수용여부

담당자

담당자 의견

비고

요구사항정의서에 들어가는 공통적인 내용들을 추려보면 위와 같습니다. 각각의 항목들이 어떤 것들을 의미하는지 알아볼까요?

요구사항 아이디(ID)

요구사항정의서 뿐 아니라 대부분의 기획 문서에는 아이디(ID)가 부여되는 문서가 많습니다.

간단한 작은 규모의 프로젝트라면 아이디를 굳이 부여하지 않고 진행하는 경우가 있긴 하지만 명확한 업무 내역에 대한 관리, 히스토리 추적을 위해서는 아이디를 부여해서 사용하는 것이 좋습니다.

분류/항목/상세내용

예를들어 회원가입 하나에 대해서도 요구사항은 여러가지 존재할 수 있습니다. 따라서 이 경우 요구사항을 그룹핑하여 해당 업무에 필요한 요구사항을 관리하게 됩니다.

요청자/요청일자

클라이언트가 있는 프로젝트라면 반드시 들어가는 것이 요청자 항목입니다. 다만 꼭 누군가의 ‘요청’을 통해서만 수집되는 것이 아니기 때문에 발췌가 된 문서나 미팅에 대한 정보를 입력해두기도 합니다.

Ex. RFP(제안요청서) p.12 xxxx 항목에서 발췌

중요도(우선순위) / 난이도

프로젝트를 진행하는데 있어서 목적과 방향성을 파악하는데 있어서 필요한 부분은 바로 이 부분과도 맞물려 있습니다.

중요도 혹은 우선순위로 표기하는 이 항목의 경우 크게 두가지로 분류됩니다. 서비스를 제작하고자 하는 발주사에서 중요하게 생각하는 항목. 혹은 개발 필요에 따라 우선이 되어야 하는 사항도 높은 순위로 차지할 수 있습니다. 작성할 때는 상/중/하를 사용하기도 하고 요구 사항이 많다면 숫자 형태로 작성하기도 합니다.

난이도의 경우에는 기술 난이도를 뜻합니다. 이 항목은 프로젝트를 구현하는데 있어서 다양한 기술을 요하는 서비스라면 기술 난이도 작성란을 통해서 최상/상/중/하로 구분하는 것이 일반적입니다.

수용여부

자, 이제 요구사항정의서의 역할 중 가장 중요한 부분에 등장합니다. 바로 해당 업무에 대해 진행을 할 것인지 아닌지에 대한 여부입니다. 일반적으로는 수용, 불가, 보류 등의 상태값을 많이 사용합니다. 수용여부를 결정하는데 있어서 중요한 것은 프로젝트 팀원들과의 협의입니다.

프로젝트 기간 내 소화가 가능한 건인지, 목적에 부합하는 요구 사항인지, 현행 서비스 혹은 수용된 다른 요건과 충돌되는 부분은 없는지 여러 담당자의 검토를 거쳐 최종적인 수용 여부를 결정하게 됩니다.

이런 검토를 거쳐 결정된 사항에 따라 수용여부를 확정했다면 해당 검토를 실행한 담당자, 담당자 의견을 작성하게 됩니다.

비고

말 그대로 비고란은 참고를 할만한 사항을 작성하기도 하고 각 요건에 대한 변경사항이 있다면 해당 히스토리를 기록해서 프로젝트가 완료될때까지 추적이 가능하도록 사용합니다.

Oauth Open Authentication

사용자가 이미 계정을 가지고 있는 타 서비스(카카오톡, 네이버, 구글, 애플 등)의 계정을 이용해서 사용자를 인증하는 프레임워크를 말합니다. Oauth를 제공하는 서비스를 이용해보면 타 계정 정보를 활용해서 간단하게 회원가입이 끝나는 것처럼 보이지만 실제로는 해당 사용자를 인증하는 수단이라고 생각하시면 됩니다. 이렇게 인증만으로 가입처리를 해도 문제가 되지 않는 서비스 같은 경우에는 해당 인증 키 값만으로 가입처리를 완료하기도 합니다. 하지만 실제로는 해당 계정에서 받아온 인증키 값, 사용자 기본정보 정도만 DB에 저장이 실행됩니다. 이용하는 계정에 따라서 받을 수 있는 사용자 정보는 상이함으로 이런 사항에 대해서는 각 계정에서 운영하는 개발자센터를 통해서 확인하세요.

네이버 개발자센터 링크

카카오 개발자센터 링크

애플 디벨로퍼 링크

구글 개발자콘솔 링크

필요한 개발문서를 검색하는 꿀 팁!!

프로젝트를 진행하다보면 Oauth 뿐 아니라 다양한 개발 지식이나 자료를 필요하는 경우가 많습니다.

이런 경우에는 구글에서 영문 문장 형태로 검색하시면 다양한 문서를 확인할 수 있습니다.