요구 사항에 대한 불편한 진실

요구 사항은 프로젝트의 근간이 되는 대단히 중요한 요소입니다. 그리고 모델링과 밀접하게 연관돼 있죠(요구 사항은 함수 종속과 밀접하게 연관돼 있습니다).

 

프로젝트는 보통 아래와 같이 진행됩니다.

 

① 단계에서 개념 모델 또는 초기 논리 모델이 나오고요. ② 단계에서 물리 모델이 나옵니다. 딱 떨어지진 않지만요…

 

요구 사항은 ①, ② 단계에서 대부분 도출돼야 하는데요. 실제로 ④ 단계에서 폭주합니다. 심리인 거 같아요.  ㅎㅎ

홈쇼핑 마감 전에 주문이 폭주하는 거 같이…

 

④ 단계에서 요구 사항이 폭주하는 원인이 있습니다.

 

요구 사항은 일정 부분 도출하는 것인데요. 요구 사항을 도출할 수 있는 분석·설계자가 드문 게 현실입니다. 또한 분석·설계자가 도출하는 게 한계가 있습니다.

 

요구 사항은 근본적으로 사용자(User)에게서 나옵니다. 사용자가 업무를 어떻게 하겠다는 것을 요구하는 것이니까요.

 

①, ② 단계에서도 많은 요구 사항이 제시하지만 많은 부분 현행 업무와 유사하고요. 본격적으로는 ④ 단계에서 개발 화면을 보고 제시합니다. 사용자 입장에서도 부실한 문서만 보고 판단하기가 만만치 않습니다.

 

그래서 화면이 개발되고 버튼을 클릭하면서 데이터를 봐야 정확히 알게 됩니다. 잘못됐거나 빠진 것을요.

 

하지만 분명 개발된 것을 보고 요구 사항을 제시하는 것은 프로젝트 방법론상으로 잘못된 것입니다.

 

최소한 문서화된 화면을 보고 판단해야 할 거 같습니다. 사용자가 일찍 움직일 필요가 있습니다. 그리고 분석·설계 팀은 ② 단계까지 최소한 화면만은 철저하게 정제해야 합니다.

 

④ 단계에서 요구 사항이 폭주하면… 오픈이 연기됩니다.

 

데이터 모델부터 검토해야 하니 일정에 상당한 영향을 끼칩니다. ② 단계에서 변경하면 2의 수고(비용)가 더 들고요. ③ 단계에서 변경하면 6이, ④ 단계에서는 조금 과장해서 40정도가 듭니다. ㅎㅎ

 

그리고 일반적으로 ④ 단계엔 전문 모델러가 없어 모델이 이상해지기 일쑤입니다. 간혹 구조가 틀어지기까지 하고요. 결과적으로 모델이 바꿔서 모델러로서 괜히 편치 않습니다.

 

역시 모델러가 프로젝트 끝까지 남아야 된다는 생각을 또 하게 되네요. 이게 프로젝트 비용을 줄이는 방법인데 개인적으로는 답답합니다.

 

아래와 같이 되지 않으려면 분석·설계자가 개발 전에 화면을 정제할 것을 권합니다. 사용자와 함께 심도있게요.

 

사용자는 개발된 것을 한번 보자는 생각보다는, 문서를 보고 요구 사항이 반영됐는지를 심도 있게 검토했으면 좋겠습니다.

 

다같이 노력하지 않는 한 현재와 같은 상황(분석·설계·개발을 허둥지둥 한꺼번에)은 계속 반복될 것입니다.

 

모델링 시 어려움 중 하나가 요구 사항이 나중에 나오는 것입니다. 이에 대한 근본적인 답은 없지만, 데이터를 통합하고 정규화하면 모델 변경을 그나마 최소화할 수 있습니다.