쓰고 싶었던 시리즈의 내용이다. 잡소리 그만하고 이건 바로 시작할 것이다.
요즘 내가 기술 문서를 정리하면서 기능 요구조건에 대한 use case(유스 케이스)를 정리하고 분석하여 설계한 설계서를 찾아내었다. 이걸 보면서 내가 배웠던 내용이면서 다른 사람들이 했던 실수가 기억나서 블로그에 적어봤다. 보통 많은 사람들이 유스 케이스를 적으면서 비즈니스 케이스에 대해서 하나하나 다 추가하거나 if then 같은 로직수준까지 넣는 경우도 있는다. 이런 정보는 사실 요구조건에 대해서는 불필요한 정보가 상세화되는 케이스가 될 수 있다.
요구조건 분석 문서를 가지고 여러 의견이 나뉘는 건 어쩔 수 없다. 왜냐면 이건 상세화의 레벨을 어디까지 해야 되느냐에 따라서도 개발 프로세스를 담당하는 사람에 따라서 다르게 받아들이기 때문이다. 어느 아키텍트는 분석 마비(analysis paralysis), 즉 상세화 하지 않으면 불안하다면서 모든 유스 케이스에 구축을 위한 목적을 표편하는 것보다 기능 자체에만 집중을 하는 경우가 생긴다.
그러나 실제로 유스 케이스를 상세하게 작성하면 분석하고 설계할 때 오히려 방해가 된다. 실행 조건과 종료 상태 정도만 정확하게 작성하면 사실 그걸로도 끝난다. 그런데 왜 그러질 못할까..?
잘못된 유스 케이스는 메인 시나리오에서는 문제가 없지만 대체 시나리오, 변경 정보, 비즈니스 룰까지 포함되어 있다. 이는 개발 프로세스 문서에서의 정보의 혼재와 버전 관리를 힘들게 하며, 서로간의 결합도가 너무 높아지는 구조를 그대로 가지고 개발 단계에서 개발을 하게 되므로 프로그램 또한 나중의 유지 보수가 상당히 힘들어지게 된다.
그래서 올바른 유스 케이스를 작성하는 것은 메인 시나리오, 대체 시나리오, 변경 정보에 대해서는 전부 어느 정도 구분해서 작성하고 있으며, 시나리오 분석할 때에도 불필요한 비즈니스 부분(비즈니스 룰)에 대해서는 별도의 카탈로그화 해서 작성하게 된다. 특히 비즈니스 룰의 경우에는 동일한 비즈니스 분야라 할지라도 해당하는 회사에 따라 룰이 다르게 적용될 수 있는 부분이므로 이 부분은 확실하게 나눠서 처리하지 않으면 안된다. 별첨 꼭 해야 하는 이유이기도 하다.