by Mr. Lim

이번 프로젝트에서 요구사항 정의서를 정리하며 느낀 점이 있습니다.

그건 바로 공식 요구사항정의서와 별도로 개인용 요구사항 정의서를 정의하는 것이 편할 수 있다는 점입니다.(어쩌면 더 효율적일 수 있습니다.)

일반적으로 프로젝트는 모듈별로 담당 기획자가 나뉩니다. 그리고 요구사항정의서 작성은 모듈별 담당 기획자가 완성한 후 취합하는 형식으로 완성됩니다.

이 부분에서 공식 버전과 별도로 개인용 요구사항 정의서 문서의 필요성을 경험했습니다.

공식버전의 경우 요구사항의 중복없이 완성됩니다. 그래서 취합하는 과정에서 유관하다 판단해 제 모듈에서 작성되었더라도 타 모듈과 내용이 중복될 경우 둘 중 하나의 모듈에선 빠지게 됩니다. 이 사실을 프로젝트 기간 동안 계속 염두하고 있으면 좋지만..시간은 언제나 부족하고..그럼 요구사항 정의서에서도 제 모듈에 정의된 요구사항 정의서만 보는 상황이 발생합니다. 물론 기획자라면 자신의 모듈것만 볼 게 아니라 타 모듈이라도 관련된 내용이라면 계속 확인하는 게 당연하지만 놓치는 상황이 분명 발생할 수 있습니다. 따라서 저는 이번 프로젝트를 통해 개인용과 공식 버전 요구사항 정의서의 필요성을 느꼈는데요.

다만 이렇게 문서를 분리하다보면 요구사항 정의서가 수정될 경우 문서를 2개 업데이트해야하는 상황이 발생하기에 이 경우에도 역시 업데이트가 되었음에도 놓치는 요구사항이 생길 수 있습니다. 그럼 어떻게 해야하나?

여기서 "개인용"이라는 부분을 놓치면 안되는데요. 즉, 공식 요구사항의 양식을 따를 필요가 없다는 점입니다. 모든 컬럼을 따를 필요없이 개인용 요구사항정의서에는 요구사항ID만 기록해두는 것입니다. 이러면 내용을 관리할 필요도 없기에 요구사항 내용 혹은 협의된 내용이 수정되어도 이를 따로 개인용 문서에 반영해야할 일이 생길리 없겠죠. IA를 관리하듯 요구사항 ID만 관리하면 되는 것입니다. 그럼 타 모듈에 정의된 요구사항이라도 놓칠 염려를 덜 수 있겠죠?

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

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

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

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

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

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

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

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

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

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

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

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

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