요구사항 문서는 이해를 거들뿐입니다.

요구사항을 정의한 문서는 ‘요구사항 정의서’, ‘요구사항 명세서’, ‘사용자 스토리’등 다양한 이름으로 부릅니다. 요구사항 문서는 요구사항을 소통하고 요구사항 변경여부를 판단하기 위해 활용합니다. 스타트업과 같은 조직을 제외하면 프로젝트에서 요구사항을 정의하는 조직과 요구사항을 구현하는 조직은 다릅니다. 두 조직은 처한 상황과 추구하는 목표가 다르기 때문에 요구사항 문서의 내용을 서로에게 유리한 방향으로 해석합니다. 그 결과 요구사항을 다르게 이해하고, 추가 요구사항이 발생할 때 기존 요구사항과 다른 요구사항인지 기존 요구사항을 구체화한 것인지 판단하기 힘듭니다.  특히 SI 프로젝트와 같이 고객과 프로젝트 팀이 처음 만난 상황에서 충분한 소통 없이 작성한 요구사항 문서를 쌍방이 같은 수준으로 이해하기 힘듭니다. 이런 상황에서는 요구사항을 상세하게 정의하는 것만으로는 충분하지 않습니다. 반면 오랫동안 호흡을 잘 맞추며 협업해 온 ‘상품기획팀과 상품개발팀’또는 ‘현업부서와 전산실 조직’은 요구사항 문서를 다르게 생각할 가능성은 상대적으로 낮습니다.    상품관리자가 프로젝트를 빨리 진행하고 싶은 마음으로 요구사항 정의서를 상품개발팀에 메일의 첨부로 전송하면서 ‘요구사항 정의서를 보냈으니 질문 있으면 메일로 의견을 주시기 바랍니다.’라고 작성하면 어떤 일이 발생할까요? 상품개발팀은 상품관리자가 제공한 요구사항 문서를 보고 아주 헷갈리는 것 한 두 가지를 메일이나 메신저로 물어보고 나머지는 개발팀이 이해한 대로 개발할 가능성이 높습니다. 이런 과정을 통해 개발한 결과물은 변경가능성이 높습니다.  물론 이렇게 극단적인 경우는 현실에서 드물지만 시간에 쫓겨 충분한 토론 없이 요구사항 정의서를 문서로만 소통하는 경우는 흔히 있습니다. 같은 문서라도 상황에 따라 사람에 따라 요구사항을 다르게 이해할 수 있습니다. 요구사항을 동일하게 이해하려면 요구사항 문서를 명확하고 구체적으로 작성하는 것도 중요하지만, 문서를 작성하기 전에 충분히 소통하는 것이 더 중요합니다. 요구사항을 협의하는 과정에 참여하지 않는 사람과 참여한 사람이 같은 문서를 같은 수준으로 이해하는 것은 불가능합니다.    함께 요구사항을 협의한 사람이라면 화이트보드를 촬영한 사진만 봐도 무엇을 협의했는지 알 수 있지만, 요구사항 협의에 참여하지 않은 사람은 그 사진만 봐서는 어떤 내용을 협의했는지 알 수 없습니다. 요구사항 문서는 화이트보드의 내용보다는 상세하고 체계적으로 기술하지만 회의 분위기, 주고받은 찬성 및 반대의견, 상대방의 미묘한 표정 등을 모두 옮길 수 없습니다. 예를 들어 요구사항 토론을 통해 내용의 80%를 이해한다고 가정하면 요구사항 문서를 통해 이해할 수 있는 내용은 20%에 불과합니다. 책보다는 인터넷 강의, 인터넷 강의보다는 직접 강의를 듣는 것이 학습에 도움이 되는 원리와 비슷합니다. 요구사항 이해도 학습과 다를 것이 없습니다.     두 조직이 오랫동안 협업해왔고 충분히 토론했다면 요구사항 문서를 간략하게 작성해도 프로젝트를 진행하는데 무리가 없습니다. 요구사항에 대해 충분히 소통한 사람들에게 요구사항 문서는 이해하기는 쉬워도 오해하기는 힘듭니다. 반대로 요구사항 협의가 부족한 사람들은 요구사항 문서를 이해하기 힘들고 오해하기는 쉽습니다.   요구사항 문서는 이해를 거들뿐입니다.  ======================================================= 제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 을 25년 1월 출간한 소식을 공유합니다. https://product.kyobobook.co.kr/detail/S000215148133