요구사항 정의서 쉽게 이야기하기

출처: Unsplash photo by Wesley Tingey

 

기획업무를 하다 보면 꼭 듣게 되는 문서 이름 중 한 개가 요구사항 정의서입니다.

요구사항 정의서 이름만 놓고 보면 요구사항을 정의했다 그런 느낌인데 어떤 걸까요?

 

Q. 고객이 말하는 것을 정리해 놓은 것이 요구사항 정의서인가요?

 

 요구사항 정의서는 우선 말 그대로 들어온 요구사항을 작성하는 문서입니다.

그럼 누가 요구를 하느냐? 회사마다 다르겠지만 요구사항이 오는 곳은 고객일 수도 있지만, 경영진일 수도 있고 혹은 회사 내 PM, QA 등 다른 부서에서도 요구를 할 수도 있겠죠? 제품에 대한 개선 아이디어는 누구나 낼 수 있고 신규 제품을 사내에서 개발하는 경우에는 별도의 고객이 없는 상황이니까요.

 

Q. 요구사항이 있으면 그 자리에서 명확하게 정하면 되지 굳이 문서를 만들 필요가 있을까?

 

 제품을 개발하다 보면 프로젝트가 길어지게 되고 그러다 보면 다양한 경우의 수가 생깁니다. 너무 많은 사람들과 이야기를 하다 보니 협의한 내용을 까먹을 수도 있고 중요한 이유로 해당 내용은 반영하지 않기로 했지만 다른 회의에서 된다고 말해버릴 수도 있고 기획자가 나가버릴 수도 있습니다.

 이런 다양한 경우의 수를 대비하고자 히스토리를 알 수 있고 내용이 잘 정리된 문서를 작성하게 되는 데 이 문서를 요구사항 정의서라고 합니다.

 

Q. 그렇다면 회의록이 요구사항 정의서가 될 수 있지 않을까요?

 

회의할 때마다 생성된 파일이 많아 해당 문제에 대한 내용을 찾기가 힘듭니다.

Excel을 통해서 정리해두면 각각의 요구사항에 대해 알아보기 쉬우며 필터를 통해서 특정 상황에 대해서 정리할 수도 있습니다.

 요구사항 정의서는 특정 양식을 가지고 있습니다. 그렇다고 모든 회사가 동일하지는 않습니다.

요구사항을 요청했다고 해서 모든 내용을 다 들어줄 수는 없습니다. 시간과 인력의 한계가 존재하기 때문이죠.

말하는 이와 듣는 이의 이해관계가 서로 다를 수도 있습니다. 그 점을 명확히 할 필요도 있는 거죠.

다른 두 사람이 서로 연관된 내용을 요구할 수도 있습니다.

다양한 경우의 수가 있다 보니 회의록을 요구사항 정의서로 보기에는 한눈에 보기도 어렵고 이해하기도 힘들다는 문제가 생기게 됩니다.

 

Q. 요구사항 정의서는 그럼 어떤 내용이 들어가면 좋을까요?

 

요구사항 명세서 작성시 들어갈 수 있는 항목 1

요구사항 명세서 작성시 들어갈 수 있는 항목 2

 

회사마다 다르지만 정리된 구분이 필요합니다. 항목과 항목에 대한 설명이 잘 작성된 브런치 링크(참고 1번 링크)를 참고하시면 더 이해하기 편할 것이라 생각됩니다.

다만 회사마다 개발하는 SW가 다르기 때문에 내용은 다소 달라질 수 있습니다. 무조건 따라 해서 적기보다는 왜 작성하는지 이유를 명확하게 알고 항목을 선별하는 것이 좋을 것이라 생각됩니다.

그리고 요구사항 정의서는 중요한 내용만 요약해서 작성해두는 것이 좋습니다.

 

Q. 귀찮은 것 같은 데 바로 넘어가면 안 될까요?

 

출처: MBC 무한도전 방콕편

 말하는 사람도 자신이 무엇을 원하는지 모르는 경우가 많습니다. 상대방이 무엇을 원하는지 명확하게 알기 위해서 요구사항을 분석하고 또 이 요구사항 정의서를 바탕으로 이후 문서가 작성되기 때문에 요구사항 정의서는 중요합니다.

또한 개발자와 혹은 이해관계자와 이야기할 때 역시 이 요구사항 문서를 통해서 이야기하는 것이 가장 좋기 때문에 작성하는 것이 좋습니다. 

 가장 중요한 것은 요구사항에 대한 분석과 고민 협의 없이 개발될 경우 목적을 잃은 엉뚱한 제품이 나올 수도 있습니다.

누가 무엇을 원하는지 그것이 맞는지도 모르는 채 여러 사공에 이끌려 다니면서 제품이 개발될 테니까요.

 

 

참고: https://brunch.co.kr/@toqha7822/15

웹 기획 산출물#1 요구사항 정의서 작성하기