도메인 지식만 알고 있으면 요구사항 작성에 문제가 없는가?


요구사항 없이 개발했던 프로젝트를 개선할 수 있는 기회가 있었다.

그 프로젝트의 프로세스는 코딩하고 수정하기 수명주기를 사용하고 있었고, 코드는 찰떡같이 하나로 붙어 있어서 컴포넌트로 분리하는 외과적 수술을 하는 것도 불가능했다.

사실 해보려고 했다. 하지만 전역변수들이 촘촘하게 여러 function들을 묶어주는 미세혈관 같은 역할을 해서, 그것들을 하나하나 장인정신으로 떼어내는 것은 정신나간짓이라고 판단되었다. 2달정도 해봤는데 성과는 없었다. 10달 더 작업해도 결과는 같을 것 같았다.

제품의 구현 기준 혹은 출시 기준을 수립하기 위한 작업으로 방향을 바꿨다. 요구사항이라는 것이 과거에는 1차원적이거나 2차원적이라고 생각했다. 즉 sentence들이 1차원 혹은 2차원적으로 차곡차곡 쌓아서 틀에 넣고 찍으면 요구사항이 될 것으로 생각했다.

물론 그것도 요구사항이 되기는 한다. 다만 그것을 읽고 ‘내가 방금 읽은 것이 뭐였더라?’라고 깨닫게 되는 요구사항이 될 가능성이 높다는 것이다.

그런데 내가 내린 결론은 다음과 같다. 요구사항을 어떻게 정의하고 구조화하느냐에 따라서, 어떻게 concept을 잡느냐에 따라서 설계의 방향과 개발 일정에도 영향을 미칠 수 있음을 깨닫게 되었다는 점이다.

이런 생각을 하게 된 두 가지 사례가 있었다.

체계 개발 프로젝트(시스템들로 이루어진 시스템 개발)에서, 거대 시스템을 sub-system으로 나누고 그것을 기반으로 WBS를 만든다. 체계 Concept이 planning에 영향을 준 것이다.

코딩을 보고 reverse로 개념을 추출하는 도중 concept이 구조화되지 않아서 이것을 3차원적으로 입체적으로 구성하였다. 그러다보니 설계가 변경되어야 할 필요가 생겼다. 추가하거나 삭제한 concept은 없지만, 구성을 변경하니, 설계가 달라져야 할 필요가 생겼다. Concept은 어느 정도 설계의 guideline을 제공해 준다.

이 글의 결론이다. 도메인 지식만 가지고는 문서가 나오지 않는다. 머릿속에서 1차원 혹은 2차원 수준으로 맴돌고 있는 개념을 추출해서 그것을 3차원으로 구조화 할 수 있는 능력이 있어야 한다.

꼭 개발 능력이 절대적으로 필요한 건 아닌데, 요구사항 작성하면서 약간의 설계 제약 혹은 설계의 가이드라인을 제시하게 되기 때문에 구현관점에서 터무니 없는 요구사항이 되지 않으려면 ‘약간’은 필요하다.

다른 식으로 표현하자면, 요구사항을 잘 정리하는 능력이 필요하다. 도메인 전문가가 못하면 요구사항 분석가가 갖춰야 할 능력이다.

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s