[서비스기획] 수행사의 요구사항 정의서(기능, 사유)

요구사항 정의서는 고객사의 요구사항을 정의한 문서이다.

해당 문서는 결국 이번 프로젝트에서 뭘 할 것이냐를 공식적으로 약속한 내용을 담고 있다. 따라서 프로젝트 진행에 있어서 범위를 정의하는데 근간이 되는 문서이기도 하다.

요구사항 정의서는 사용자 인터뷰 등을 통해 도출된 요구사항을 분석하여 정리된 문서이다. 여기서 "분석"이라는 점이 중요한데, 수행사 관점에서는 결국 해당 문서에서 이행하기로 약속한 기능을 "구현"해야하는 의무를 갖고 있다. 따라서 모든 요구사항을 기능 단위로 분리하고, 구현 관점에서 제한된 인력과 기간 내에 수용 가능한 요구사항인지를 분석해야 한다. 

*기획자 입장에선 현업의 요구사항을 상당 부분 수용해주고 싶다. 그러나 프로젝트 입장에선 기한 내 불가능한 요구사항을 수용할 경우, 수행사 프로젝트팀의 고생을 떠나서 기한 내 아예 오픈을 못해버리는 불상사가 발생할 수도 있다. 그리고 기한 초과는 곧 예산 초과로 이어진다. 이러면 최악의 경우 법적 다툼으로까지 이어질 수 있다..

기능 단위의 분석이라 하면 요구사항 하나에 2가지 이상의 기능을 담는 걸 지양해야 한다는 것을 의미한다. 이는 요구사항에 따라 수용할 수 있을 수도, 없을 수도 있기 때문이다. 즉, 요구사항A에 기능A와 기능B 개발을 포함할 때, 기능A는 수용 가능한데 기능B는 그렇지 못할 수 있다. 물론 이 경우, 요구사항 정의 단계에선 부분 수용이라하고 고객사와 협의를 통해 요구사항을 수용 가능한 요구사항으로 수정할 수 있는 여지가 있다. 그러나 요구사항 다 확정하고 구현 단계에서 수행사가 막상 개발하려니 기능A는 되는데 기능B는 안된다고 해버릴 순 없는 노릇이다. 따라서 기능 단위의 요구사항 분리가 개인적으로 중요하다고 생각한다.

*이는 개발 관점에서 기능단위이다. 요구사항을 가령 체크박스 옵션 단위나 지나친 세분화하는 것 또한 지양해야한다. 요구사항이 너무 많아질 경우 관리가 어려워지기 때문이다.

요구사항 정의서는 또한 분석된 내용을 토대로 작성되는데, 여기서 중요한 점은 단순히 프로젝트 범위만 정의하면 안된다는 점이다. 요구사항은 수행사가 검토 후 고객과 협의를 결정되는데, 여기서 수용하기로 했다면 구체적으로 어떤 기능을 수용했는지, 그리고 미수용으로 결정되었다면 무엇 때문에 어떤 걸 미수용하기로 했는지 구체적으로 정의되어 있어야 한다.

이러한 사유들을 정의서에 포함해야 하는 이유는 아무리 워터폴 방법론을 채택하더라도 설계 또는 구현 단계에서도 여전히 요구사항은 추가되기 때문이다. 물론 모든 요구사항을 반영할 수 있다면 좋겠지만, 프로젝트는 제한된 자원 안에서 진행되기에 끊임없이 추가되는 요구사항은 프로젝트의 실패를 야기할 가능성이 높다.

따라서 추가되는 요구사항에 대해 가능한 범위를 한정지어야 하는데, 이때 요구사항 정의서에 정의된 사유를 통해 미수용했던 요구사항, 즉 이번 프로젝트에서 진행불가한 요구사항을 받아들이는 사고의 발생 가능성을 줄일 수 있다.

---

+ 요구사항 정의서를 정리하는 순서는 아래와 같다

1. 사용자 인터뷰 등을 통한 요구사항 조사
2. 기능 단위 요구사항 정의
3. 수행사 검토를 통한 요구사항정의서 정리
4. 고객사-수행사 협의를 통한 요구사항 확정
5. 수행사 검토를 통한 수용여부 확정 - 수행사의 프로젝트팀 전체가 함께 검토함
6. 수행사-고객사 협의를 통한 최종 요구사항 확정

---

이 글은 제 개인적인 경험을 바탕으로 작성되었습니다. 댓글을 통해 부족한 부분은 채우고, 다른 부분은 맞춰갈 수 있길 희망합니다.