기능 명세서, 요구사항 정의서는 무엇일까?
당연하게 생각한 용어들을 낯설게 바라보기
내가 너무 당연하게 넘어갔던 것들에 대해 다시 생각해볼 계기가 많아지고 있다. 의외로 it 업무를 오랫동안 담당했던 사람들과 커뮤니케이션하는 일은 어렵지 않다. 하지만 전혀 다른 분야, 예를 들어 병원 일을 하다가 서비스 기획 업무로 넘어가려는 사람들, 부동산 업무를 하다가 기획 업무를 하려는 사람들과 대화를 할 때 더 깊게 공부를 하게 된다. 나조차 너무 당연하게 넘어갔던 용어들이 낯설게 느껴질 수 있구나, 어려울 수 있구나 , 이런 생각을 다시금 해보게 된다. 그중 대표적인 예시가 바로 '기능 명세서'와 '요구사항 정의서'이다.
"누나, 그런데 기능 명세서는 뭐고 요구사항 정의서는 뭐예요?"
"이거 용어를 누가 만든 거예요? 용어가 비슷한 게 뭐가 다른 거예요?"
나는 이 두 가지 질문을 부끄럽게도 한 번도 심도 깊게 고민해보지 않았다. 그래도 웹 개발, 서비스 기획 프로젝트 경험이 10년 차 이상인데 이런 용어가 정확히 어떻게 다른지 관심조차 두지 않았다. 너무 당연하게 여겼다. 양산 프로젝트를 진행할 때 너무나 당연하게 '요구사항 정의서'를 작성하였고 때가 되면 '기능 명세서'를 산출물로 매회 리뷰를 시작하였다. 때론 내가 이러한 요구사항 정의서나 기능 명세서를 작성해야 하는 시기가 있는 경우도 왕왕 있었다.
동생이 물어봤던 요구사항 정의서는 무엇이고, 대체 기능 명세서는 무엇을 의미하는 것일까?
요구사항 정의서
요구사항 명세서, 요구사항 기술서라고도 부르는 '요구사항 정의서'는 문구 그대로 고객의 요구사항을 정리한 내용이다. 웹/앱 프로젝트나 서비스 프로젝트를 진행하는 이유는 무언가 목적이 있기 때문이다. 어떤 기능이 필요할 수도, 문제 되는 상황을 해결하고자 프로젝트를 진행하게 된다.
요구사항 정의서에 필수적으로 필요한 요소는 요구사항 구분, 요구사항 ID, 요청사항(기능), 요청사항에 대한 설명, 요청자, 수용 여부가 필요하다. 회사나 수행하는 프로젝트마다 요구사항 기술서는 천차만별이기 때문에 무조건 이것을 따라야 한다는 기준은 없다. 편의에 따라 필요한 요소는 자유롭게 변경하여 사용할 수 있다.
요구사항 정의서 예시이 프로젝트의 경우 요구사항 정의서를 꽤 상세하게 기술한 편인데 그중에서도 요구사항 구분(업무 구분), 요구사항 ID, 요구사항명, 설명은 필수적인 요소라고 볼 수 있다.
요구사항 구분 (업무 구분)
요구사항이 앱인지, 웹인지, 웹에서도 계정 정보인지, 대시보드인지 등을 명확하게 구분한 칼럼이다. 프로젝트가 크면 클수록 어떤 업무인지 분간하기가 어렵다. 웹이나 앱이라도 대시보드를 만드는 것인지, 환불 시스템을 기획하는 것인지에 따라 개발 내용이 달라진다. 그래서 먼저 크게 해당 프로젝트가 어떤 영역을 담당하는 것인지 보여주면서 개발 항목들을 직관적으로 보여준다.
요구사항 id
때론 요구사항명 자체가 꽤 길 수 있다. '쇼핑몰 회사 공용 계정'을 만든다고 가정하였을 때 요구사항 명칭을 일일이 사용한다면 더 헷갈리고 복잡하다. 이때 간단하게 편하고 부르면서 관리하기 좋은 id로 치환해 사용한다면 효율적으로 논의를 이어나갈 수 있다.
요구사항명/ 요구사항 설명
요구사항 제목과 설명에 대한 부분이다. 주로 개선을 하거나 해결해야 하는 기능 명칭이 요구사항명에 해당된다. 처음 보는 사람도 쉽게 이해할 수 있도록 요구사항명에 덧붙여 간략히 보충 설명을 써준다.
그런데 왜 이렇게 요구사항 정의서를 만드는 것일까?
왜 이렇게 문서화하여 명세서를 만들까? 일을 위한 일이 아닐까?라는 생각을 할 수 있다. 하지만 요구사항 명세서로 인해 프로젝트 종료 이후 불필요한 잡음을 방지할 수 있다. 요구사항 정의서는 클라이언트와 프로젝트 수행자 간 합의서이기 때문이다.
문서 기반으로 필요 기능을 정리하면 보다 명확하게 필요 사항들을 합의해 나갈 수 있다. 모호하거나 막연했던 필요사항, 해결 사항들이 일목요연하게 정리를 해나가면서 빠르게 의사를 타진해 나갈 수 있기 때문이다.
수많은 요구사항 중 가장 긴급하고 중요도가 높은 사항이 무엇인지 우선순위 기반으로 알 수 있다. 100가지 요구사항 모두가 가 급하고 중요한 것은 아닐 테다. 가장 클라이언트가 필요한 것이 무엇이고 무엇을 가장 중요하게 다뤄야 할지 초반에 정리할 수 있어 효율적으로 업무 처리가 가능해진다.
그렇다면 기능 명세서는 무엇?
요구 명세서와 비슷하면서도 헷갈리는 개념이 바로 기능 명세서이다. 요구사항 정의서, 기능 명세서라는 이름이 헷갈려 두 용어를 혼용하여 사용하기도 한다. 하지만 기능 명세서를 이야기할 땐 최종 아웃풋에 대한 기능들을 중심으로 설명된 자료라고 볼 수 있다. 최근에 진행했던 프로젝트로 '모 쇼핑몰의 환불 서비스 개선 기획' 업무를 한 적이 있었다. 인포메이션 아키텍처, 와이어프레임, GUI 작업을 한 뒤 최종적으로 이 서비스에 어떤 기능들이 정리된 내용들이 필요했다. 그래야 리뉴얼된 서비스에 무엇이 기존과 달라졌고 어떤 것들을 할 수 있는지 이해시킬 수 있었기 때문이다.
클라이언트도 마찬가지로 프로젝트를 의뢰하고 다 만들어지면 검수를 하게 된다. 검수를 할 땐 해당 서비스에 담겨있는 기능 위주로 테스트를 하게 되므로 '기능 명세서'가 기준이 된다. 서비스 착수는 클라이언트의 요구사항 정의서부터 시작하기에 클라이언트가 원하는 요구사항들과 일부 겹칠 수 있다. 하지만 요구사항 정의서가 기능 명세서와 모두 일치하지는 않는다. 모든 요구사항들을 그대로 반영하기엔 일정, 자원 등의 리소스가 한정적이기 때문이다. 그래서 우선순위에 따라 반영된 기능들이 최종적으로 담긴 문서가 기능 명세서라고 볼 수 있다.
내가 관심 있는 분야에 대해 공부할수록 감탄이 적어진다. 새로운 무언가를 알아간다는 희열보다 식상하게 되고, 무심하게 바라보게 된다. 요구사항 정의서, 기능 명세서와 같은 용어, 내가 작성해야 하는 문서들 역시 너무나 당연하게 생각되어 때론 무심하게, 때론 귀찮게 느껴졌다. 하지만 해당 분야를 처음 접하는 사람에게 근본적이고 당연하게 생각하는 용어에 대한 질문을 받으면 당연함이 없어지고 낯설게, 다시 한번 바라보게 된다.
"작가님은 모빌리티 분야 중에서 어떤 게 가장 인상적이셨어요?"
오늘도 누군가 내게 이런 질문을 하였다. 순간 '가장'이라는 단어에 멈칫하며 대답을 얼버무렸다. 수많은 서비스를 접하면서 비슷하게 여겼고 언제부터인가 별다른 감흥이 없었기 때문이다. 이 질문을 받으며 그저 머릿속으로 분석하고 제3자로서 서비스를 바라본 나 자신이 부끄럽게 느껴졌다.
서비스 기획에 대한 공부를 거듭하고, 직접 실무 프로젝트를 진행하면서 다양한 사람들과 계속 교류를 해야겠다는 생각을 하였다. 질문을 서로 주고받으면서 '당연히 사용한 용어'들을 낯설게 바라보는 연습을 해 나가야겠다. 누구나 이해하고 통용할 수 있는 개념 정리로 서로 이해하고 교류할 때 새로운 아이디어가 나오고 좀 더 괜찮은 방법론이 나타나지 않을까. 타인의 지식과 나의 지식이 만나 서로 융합해 나가기를 희망해본다.
