글쓴이: 양승익
오늘은 지난 블로그에 언급했던 요구사항을 어떻게 기술하는 것이 좋을지에 대한 글을 쓰려고 합니다.
사실, 요구사항을 어떻게 써야하는지 많은 고민들이 있어왔습니다. 하지만, 대부분이 목차를 어떻게 작성할지에 대한 고민이 대부분이었고 정작 요구사항의 내부 컨텐츠를 어떻게 작성하는지를 가이드하는 것은 그렇게 많아 보이지 않습니다.
IEEE에서 제공하는 가이드처럼 목차는 얼마든지 이상적으로 만들 수 있지만 중요한 것은 목차 내부의 컨텐츠를 어떻게 잘 쓰는 것이 요구사항을 작성하는 핵심 Key입니다. 오늘은 상세하게 요구사항을 작성하는 기법적인 측면보다 전반적으로 요구사항을 작성하는 방향성에 대해 주로 말하려고 합니다.
요구사항을 잘 쓰기 위해서는 제가 생각하는 접근법은 “First Breadth and Evolutionary Depth Approach”입니다. 참고로 이 접근은 Lean SW Development로 부터 영감을 얻었습니다.
먼저, Breadth의 의미는 요구사항의 커버리지를 의미합니다. 즉, 무엇을 개발할 지에 대해 고객의 요구사항을 빠짐 없이 기록하고 정의하는 것을 의미합니다. 여기서 중요한 것은 잘 모르거나 아직 미결정사항에 대해 너무 깊은 수준까지 내려가지 않는다는 점입니다. 어짜피 지금 수준에서는 알 수 없고 시간이 필요로 하는 내용에 대해 미리 고생할 필요가 없다는 뜻입니다. 차라리, 그 시간에 상위수준의 고객 요구사항을 명확하게 업무정의 하는것이 바람직합니다. 여기서 많이 쓰는 기법은 Use Case를 쓰기도하고, Agile에서는 User Story를 사용하기도합니다.
다음으로 Evolutionary Depth 의미는 요구사항 자체의 불완정성으로 부터 비롯되었습니다. 즉, 요구사항은 태생적으로 개발 초기에는 완전할 수 없어서 개발이 계속 진행되면서 상세화되고 정확성이 높아진다는 의미입니다. 저는 이것을 진화적인 입장에서 보고 싶었습니다. 처음에 Breadth하게 정해진 요구사항이 개발을 진행하면서 구체화되고 고객 또한 이러한 과정을 통해 자신의 요구사항을 더욱 구체적으로 말할 수 있다고 생각합니다.
결국, First Breadth and Evolutionary Depth Approach 는 잘 모르는 요구사항을 넓이와 깊이 측면에서 이분화함으로써 비교적 추상화 수준이 높더라도 개발 전체를 커버할 수 있을 정도의 요구사항을 먼저 만들어서 합의를 진행한 후 상세한 부분은 프로젝트를 진행하면서 좀더 많은 정보를 획득한 후 정확한 의사결정을 하도록 유도함으로써 프로젝트의 전체 진행을 현명하게 가져 가자는 것입니다. 물론, 프로젝트 상황에 따라 이 방법이 항상 적용될 수는 없겠지만 어느 정도는 고려할 필요가 있다고 생각합니다.
ps. 이미 고정된 표준, 규격 등은 굳이 위와 같은 방법을 사용할 필수는 없겠고 여기서 말하는 것은 고객의 머리로 부터 나왔지만 아직 구체화되지 않은 요구사항을 의미합니다
