Software Engineering Network

  전규현님의 블로그에서 읽은 포스팅을 배경으로 트랙백 날립니다. 먼저 전적으로 공감하는 전규현님의 글을 읽고 실제 프로젝트 상황에서 요구사항 관리상의 관련 활동에서 가장 기초적이고 끝까지 잃지 말아야 하지만, 그게 쉽지만은 않은 전제조건이 무엇일까 하는 물음에 다음과 같이 4가지로 정리를 해봤습니다.

1. 프로젝트의 범위와 목적을 명확하게
  엄청엄청 중요한 조건이 아닌가 생각을 합니다. 프로젝트 착수 후, 프로젝트의 범위와 목적이 나오게 됩니다.(조직 환경에 따라 범위와 목직이 나온 후 프로젝트가 착수되기도 합니다.) 범위와 목적(Scope & Goal)은 개발 대상의 프로덕트의 특성 및 전체 프로젝트 스케쥴, 예산 규모에 막대한 영향을 끼치게 됩니다. 그렇기 때문에, stakeholder간의 충분한 협상과 대화를 통해 명확한 범위와 목적이 잡혀야 합니다. 추가적으로 프로젝트 베이스라인(baseline)을 만들어주면 좋겠지요.

2. 꾸준한 커뮤니케이션
  stakeholder는 크게 developer, manager, client, customer, user로 나눌 수 있습니다. 하지만 저마다의 View가 조금씩 차이를 보이게 되기도 하지요. 때문에 충분하고 지속적인 커뮤니케이션 활동은 아무리 강조해도 지나치치 않을 정도입니다. 커뮤니케이션의 목적은 서로 다른 View의 격차를 조금이라도 줄이고 개발 대상의 프로덕트에 대한 명확한 이해를 위해서 꼭 행하여야 하는 활동입니다.

3. 변경 이벤트 발생 시, 반드시 공유
  특히 소프트웨어 제품의 경우 조직환경 또는 예산에 따라, 고객의 요구에 따라 요구사항이 변화하기 때문에 제품의 특성 자체가 달라지는 경우도 있습니다. 빈번하게 발생하는 요구사항 변경 때문에 꾸준한 요구사항의 관리를 해주어야 하고, 변경 이벤트가 발생 시, 개발자 또는 관리자 간의 충분한 대화를 통해 서로 변경된 요구사항에 대해 정확하게 파악하고 있어야 합니다. 서로 다른 버전의 문서들을 보고 개발한다면 개발 후, 시스템은 분명 Error로 보답을 하게 되겠지요.

4. 용어사전의 통일
  앞서 언급한 꾸준한 커뮤니케이션의 활동을 강조하였는데, 커뮤니케이션 활동 및 문서작성 활동에 있어서 또 하나의 중요하게 지켜질 전제가 바로 용어사전(Glossary)의 통일입니다. 서로다른 어휘로 쓰여진 문서보단 통일된 문서로 관리를 하는게 당연히 더욱 편하고 이해관계자들 사이에서 오해를 불러일으킬만한 소지를 없앨수가 있겠지요.