요구사항 정리 방법론?

차/과장급 교육인 요구사항 방법론 세미나를 듣고 있습니다.

요구사하에 대한 방법론과, 변경관리에 관한 부분이 주요이슈인데 (사실 PMP교육중 요구사항 방법론 심화학습이라고 봐도 무방할듯 싶습니다) 사실 강의를 들으면서 나름 중요하게 생각되어지는 단어가 있습니다.

그건은 "단어의 정의"

사실 TMS, TMW, TMA와 관련되어진 프로젝트를 진행하다보면 고객사의 관리자와 말이 맞지 않을경우가 있습니다. 물론 이 경우는 내부적으로 엔지니어와 개발자, 그리고 영업팀과도 "단어의 정의"때문에 고생한적이 많습니다.

물론 영업팀은 사실 그만큼 노력이 있기에 (RFP, RFD문서 분석 능력 스킬이라고해야하나) 단어의 정이가 상당히 세밀화되어져 있습니다. 하지만 이 단어가 모든곳에는 통용되어질수 없는 부분도 있고, 약어를 쓸 경우는 더욱더 난해해지기 마련입니다.

사실 고객의 요구사항정의를 하면서 고객은 단순히 "웹 페이지" 라고 부르지만, 이것을 받아드리니 영업과, 기술과 그리고 개발의 입장은 각각 다 틀리다는것을 명확히 해야합니다.

단순히 "웹 페이지"라고 명칭한다면 html로 되어진 문서들의 집합 혹은 문서내부의 미디어들의 집합일것입니다.
고객사는 당연히 쉽게 생각하고 "웹 페이지"라고 정의를 해버립니다.

하지만 이것을들은 영업팀은 "웹 페이지"의 정의가 틀릴수 있습니다. 엔지니어는 당연히 틀립니다. 개발팀은 더욱더 헷갈리기 마련입니다.

다들 생각하는것이 틀리다보니 "웹 페이지에 대한정의"가 있다면 추후 누군가가 문서를 보아도 헷갈리지 않고 고객사(결국은 "갑")이 원하는것이 무엇인지를 좀더 명확하게 할수가 있습니다.

또 다른 예를 들면 "빨리" 라는 고객사의 요구입니다.

고객사의 "빨리"의 의미는 하루를 넘기지 않는 24시간을 의미합니다.
영업팀은 이런 고객사의 "빨리"의미를 잘 알고 있을것입니다.
엔지니어인 저는 "개발 & 작업"의 일정이 더해져, 48시간이 되어집니다.
개발팀은 "개발 & 기획 & 코딩 & 디자인"의 개념이 더해져 96시간이 되어져 버립니다.

이렇듯 용어의 정의가 정확하지 않다면 요구사항정의에 대한 부분을 명확히 할수가 없는 부분으로, UML (소프트웨어공학)에서도 세심있게 들었습니다. (아니 사실은 앞 부분뿐이 기억이 안날수도...)

요구사항뿐만 아니라, 평소에도 좀 딱딱 부러지는 성격이여야 하는데, 좀 유들유들 넘어가다보니..ㅎㅎ;;;