요구사항을 뽑아내는 일은 결코 쉽지 않다. 시스템의 중점 아이템을 꺼집어 내어 지금까지 나왔던 자사 및 모든 경쟁 제품보다 훨씬 뛰어난 제품을 만들어야 하는 요구사항을 뽑아내야 하기 때문이다.
지난번 요구사항을 파악하기 첫번째에 이어서 요구사항 파악하기 두번째를 써보게 되었다.

사용자 시나리오나 기능성을 기반으로 하는 모듈을 분리하여 요구사항을 얻어 내는 것만으로는 완벽히(!) 부족하다.
모듈단위의 기능을 파악하는 것 외에 무엇을 생각해야 하는가?

1. 완성된 컴포넌트 모듈은 자주 바뀌는 가? 아니면, 한 번 만들어지면 계속 바뀌지 않는가? 에 대한 깊은 고민이 필요하다. 모듈의 타입에 따라 유지 보수할 때 유지 보수성을 생각하며 깊게 생각해야 되는 부분이 존재한다.

소프트웨어의 생명 주기중 가장 긴 부분이 "유지보수"라는 것을 잘 생각해야 한다. 소프트웨어의 생명은  "디자인", "개발", "유지보수"라고 하는 큰 3단계의 단계가 있는데, 이의 비용(시간 포함) 비율은 3:2:5 라고 생각한다. 그만큼 유지보수적인 부분이 굉장히 소요되기 까닭에 디자인단계에서 잘 생각하여 유지보수의 비용을 최대한 낮추는 설계방법을 가져야 한다.
디자인이 한 번 잘 못되면, 시스템의 변경이 필요해지고, 변경에 따른 비용, 변경을 하지 않아서 생기는 비용을 잘 염두해야 한다. 컴포넌트 모듈중 static, dynamic한 부분을 잘 나누어 본다. 컴포넌트 모듈의 input, output을 잘 생각한다. 각 컴포넌트의 모듈의 연관(아직 기능적인 모듈간의 인터페이스만 생각!)을 머리 속에 그리며, input과 output의 고민을 잘 해야 한다.

시스템에서 가장 많이 사용될, 아니 상용화될 때 가장 많이 바뀌는 부분은 신경을 써서 요구사항을 잘 파악하는 것이 중요하다. 20:80의 이론처럼 전체 시스템의 20%는 전체 프로젝트의 80%를 차지하고 있다는 것을 염두해야 한다.

보통 데이터를 동적으로 받아서 처리하는 부분을 프로퍼티, XML형태로 받아들 일 수 있도록 해야 하며, 네트웍인 경우는 Push인지 Pull방식이 좋을지 고민을 잘 해야 한다.

2. 네트웍 환경에 맞는 모듈 설계를 고려해야 한다.
Closed  네트웍을 사용해야만 하는 경우도 존재하므로, 네트웍 환경까지 생각할 필요성이 있다.
public ip를 받지 못하는 환경을 쓸 수 있는 네트웍 환경이 주어지는 경우가 존재 할 수 있다. 그 가능성에 대해서 염두할 필요성이 있다.

특히 방송환경은 네트웍 환경에 맞는 요구사항을 파악하는 것이 중요하다. 방송 서버는 Closed 망을 쓰기 까닭에 바깥으로 패킷은 허용될 수 있으나, 들어오는 패킷은 막는 형태로 되어 있다. 그런 부분까지도 잘 감안해서 요구사항을 뽑아내야 한다.

요구사항을 뽑아내는 것은 무척 어려운 일이다. 즉 대략 설계를 들어가지 않는 다고 하지만, 설계를 염두하지 않은 요구사항은 프로젝트에 큰 영향을 끼치기 까닭에, 요구사항을 단순한 부분이 아닌, 설계를 염두한 세부 요구사항까지 파악할 필요가 있다.

'철학' 카테고리의 다른 글

Project Management Office (PMO)  (0) 2006.07.20
디자인-요구사항 파악하기-1  (0) 2006.07.20
커뮤니케이션을 기반으로 하는 학습.  (0) 2006.07.20
버그의 원인  (0) 2006.07.20
자기 비하 하지 않기..  (0) 2006.07.20
Posted by '김용환'
,