17장. 요구사항 정리는 어떻게 해야할까
요구사항 정리가 끝나지 않는 이유
PART 3. 이미 시작된 프로젝트를 붙잡는 시간
프로젝트가 시작되면 기획자는 요구사항정의서를 쓰기 시작한다. 제안요청서도 있었고, 제안서도 제출했고, 계약까지 끝났지만 요구사항을 다시 정리한다.
이 작업은 이전 내용을 반복하는 일이 아니라, 요구사항을 ‘최종 결정’의 형태로 정리하는 과정에 가깝다.
어떤 요구사항을 수락할지, 어디까지를 범위로 볼지, 받아들일 수 없다면 그 이유는 무엇인지까지 문서로 남겨두는 것이다.
이렇게 정리된 요구사항정의서는 단순한 산출물이 아니라, 이후 협의의 기준이 된다.
나중에 “그때 그렇게 이야기하지 않았나요?”라는 말이 나왔을 때, 말이 아니라 문서로 다시 판단할 수 있게 해주기 때문이다. 그래서 이 시점부터 요구사항은 더 이상 참고가 아니라, ‘조정과 합의’의 기록이자 기준으로 역할이 바뀐다.
요구사항정의서를 작성하는 시점에서 기획자가 받는 질문들은 비교적 분명하다.
“이건 어디까지 포함인가요?”
“이건 확정된 요구사항 맞죠?”
“이 기준으로 진행하면 되는 거죠?”
이 질문들은 새로운 요구가 아니다. 이미 여러 차례 오갔던 이야기들을 확인하고 정리하려는 질문에 가깝다. 그리고 그 답의 기준이 되는 것이 바로 요구사항정의서다.
즉, 요구사항정의서는 새로운 요구를 만들어내는 문서가 아니다. 흩어져 있던 말과 판단을, 나중에 다시 꺼내 확인할 수 있도록 한 줄씩 정리해두는 문서에 가깝다. 한 문장이 적히는 순간, 그 문장은 이후의 설계와 개발, 그리고 논의의 기준이 된다. 그래서 이 문서를 쓰는 일은 언제나 조심스럽다.
이 때문에 실무에서 요구사항정의서는 단순히 요구사항과 수락/거부 여부만 적는 문서로 끝나지 않는다.
요구사항이 언제 제기되었는지,
누가 제안했는지,
수락 여부는 무엇인지,
수락하지 않았다면 그 사유는 무엇인지까지 함께 남긴다.
경우에 따라서는 요구사항을 수락하기 위한 전제조건까지 기록한다.
이 문서는 단순한 정리가 아니라, 판단의 기록이기 때문이다.
주니어 때의 나는 모든 프로젝트에서 요구사항정의서를 작성하진 않았다. 프로젝트 규모가 작다는 이유로, 혹은 일정이 촉박하다는 이유로 요구사항정의서를 따로 만들지 않고 진행했던 프로젝트도 있었다. 회의에서 정리된 내용을 메일이나 메신저로 공유하는 선에서 충분하다고 판단했기 때문이다.
하지만 프로젝트가 진행될수록 문제가 드러났다. 마지막 단계에 와서야 요구사항이 누락되었다는 사실을 알게 되기도 했고, 처음과 다르게 변경된 요구사항을 놓친 채 개발이 진행된 경우도 있었다. 회의에서는 분명 A로 결정되었던 내용이 어느새 B로 바뀌어 있었고, 그 변경 과정에 대한 기록은 어디에도 명확하게 남아 있지 않았다.
결국 요구사항의 근거를 찾기 위해 수많은 메일과 메시지를 뒤져야 했다.
“그때 어떻게 정리됐더라”를 확인하는 데 시간이 쓰였고, 그 과정에서 한 번 더 헷갈리고, 한 번 더 설명해야 하는 일이 반복됐다.
그럴 때 고객사는 이렇게 말하곤 했다.
“지난번에 그렇게 하기로 했잖아요.”
“저희가 그렇게 말씀드린 적이 없는데요.”
이 말 앞에서 나는 어떤 대응을 해야 할지 난감해졌다. 언제, 누구와, 어떤 맥락에서 나온 이야기였는지를 설명할 근거를 찾기 쉽지 않았기 때문이다.
이 경험 이후로 나는 프로젝트의 규모와 상관없이 요구사항정의서를 작성하고 있다. 아주 간단한 형태라도, 지금 이 요구가 어떤 기준으로 어떻게 결정되었는지를 남기기 위해서다.
요구사항정의서는 상호 협의로 결정된 내용을 정리하는 문서다.
그런데 이 문서를 작성하다 보면, 지금 정리된 내용을 그대로 기준으로 고정해도 되는지, 아니면 다시 한 번 협의 테이블 위에 올려야 하는지를 고민하게 되는 순간이 있다.
그럴 때는 고객사와 프로젝트 참여자들과 함께 다시한번 해당 요구사항을 다시 확인하고, 최종 결정을 내린 뒤 문서에 남긴다. 이 경우, 왜 다시 협의가 필요했는지까지도 함께 정리한 뒤, 조정된 범위와 최종 결론을 남긴다. 그래야 나중에 같은 요구가 다시 등장했을 때, 그때그때의 기억이 아니라 일정한 기준으로 판단할 수 있기 때문이다.
기획자는 요구사항정의서를 작성하면서 이를 바탕으로 IA를 그리고, 사용자 흐름을 정리하고, 시나리오 작업을 진행한다. 즉 요구사항을 정리하는 작업은 무엇을 만들 것인가를 정의하는 동시에, 어디까지 ‘우리가 하기로 한 일’로 볼 것인지를 문서로 남기는 과정이다. 이 문서들은 디자인과 개발의 출발점이 되는 동시에, 이후 논의가 다시 이 문서를 기준으로 이루어지게 만든다.
나는 요구사항정의서를 쓸 때 복잡한 형식부터 만들지 않는다. 기능을 길게 설명하기보다, 이 요구가 어떤 상태로 결정되었는지를 먼저 남긴다.
누가 제안했고,
언제 나왔고,
지금 확정된 것인지,
조건이 있다면 무엇인지.
이 네 가지가 정리되어 있으면 이후 변경이 생겼을 때도 “무엇이 달라졌는지”를 기준으로 다시 논의할 수 있다.
결국 요구사항정의서는 기억에 기대지 않기 위해 남기는 문서이고, 판단을 다시 꺼낼 수 있게 해주는 기록이다.
다음 장에서는 협의를 통해 정리된 요구사항정의서가 있어도 왜 자꾸만 요구사항 정리가 반복되는지에 대해 이야기해보려 한다.