재능이 있는 개발자 또는 유식한 사용자가 교육, 기술자료와 전문가의 도움없이 효과적인 요구사항 분석가가 자동으로 될 수 있다고 생각해서는 안된다. 분석가는 다양한 지식, 기술과 인성을 필요로 하기 때문이다.

만들 수 있는 물건을 팔지 말고 팔 수 있는 물건을 만들어라.

대부분의 사람들은 건설업자에게 4억원짜리 집을 짓게 하면서 자신의 요구사항과 희망사항을 상세하게 계속 전달하게 된다. 원 계약자는 요구사항을 변경하게 되면 비용이 발생한다는 것을 알고 있으며, 싫지만 그것에 대해서는 동의하고 있다. 그러나 사람들은 소프트웨어 개발에 있어서는 비슷한 문제를 전혀 다르게 생각하고 있다. 요구사항 단계에서 발생된 오류는 소프트웨어 프로젝트에서 발견된 모든 문제점 주 40~60%의 원인이 되고 있다. 이 때문에 요구사항을 체계적으로 관리 조정하는 요구사항 분석가가 필요한 것인데, 많은 조직들은 이와 같이 필수적인 활동에 대해서 비효과적인 방법을 택하고 있다.

구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 한 번에 한 요구사항만을 구현하고 다음 단계로 이동하기 전에 고객의 피드백을 얻는 점진적인 순환방식을 취해야 한다. 정작 어려운 일은 요구사항을 발견하는 것이다.

요구사항 문제로 발생되는 중요한 결과는 이미 완료되었다고 생각하는 것을 다시 작업하게 되는 것이다. 재작업은 전체 비용의 30~50%가 소요되며, 요구사항 오류는 재작업 비용의 70~85%를 차지한다. 프로젝트 후반부에 발견되는 문제를 수정하는 비용은 문제 발생 즉시 수정하는 것보다 훨씬 더 많은 비용이 든다.

모든 프로젝트 관련자들이 요구사항 개발에 대해서 협력하는 방법을 알고 있다고 가정해서는 안된다. 가장 효과적으로 협력할 수 있는 방법에 대해서 모두가 적극적으로 시간을 가지고 토의하도록 해야한다.

요구사항 분석가는 다른 사람의 관점을 요구사항 명세로 번역하고 그 정보를 다른 관련자들에게 전달하는 사람이다. 분석가는 관련자들이 자신이 원한다고 하는 것과 실제로 필요한 것 간의 차이를 발견할 수 있도록 돕는다.
놀라운 일도 아니지만, 비지니스 요구사항과 사용자 요구사항 간에는 충돌이 발생할 수 있다. 분석가는 주요 사용자대표 그리고 경영진의 후원자 등과 협력하여 모든 충돌을 해결할 수 있어야 한다.

재능있는 분석가는 성공하는 프로젝트와 실패하는 프로젝트를 구분할 수 있다. 많은 경험을 가진 분석가들과 일을하면 경험이 부족한 분석가들의 유사한 프로젝트보다 66% 정도의 노력을 줄일 수 있다.
이러한 분석가는 하루 아침에 양성되지 않는다. 교육과 실전 경험을 통해 육성해야 한다.

Software Requirements,
Karl E. Wiegers, Microsoft Press

소위 업무분석이라고 부르는 위의 작업을 우리는 나름대로 잘 하고 있었다고 생각하지만, 결국 제대로 하자면 전문가가 필요한 일이다.. 이 분야에 대해서만 책을 쓸 정도의 전문가들이 미국에서는 활동하고 있는 것이다.. 비교해보면 얼마나 부족한지 절실히 느끼게 된다..

우리 현실이 지금 당장 이런 전문가를 확보할 수 없다는 것은 안다.. 하지만, 장기적으로 이런 전문가를 확보하기 위해 우리가 어떤 노력을 기울이고 있는지는 반드시 점검해볼 필요가 있을 것이다..