본문 바로가기

더 괜찮은 개발자가 되기위한/요구사항 분석하기

요구사항 검증

□ 요구사항 검증


요구사항 명세서가 완료됐으면 고객과 작성이 잘 됐는지 한 번 확인해 봐야 한다. 요구사항 명세서는 프로젝트 개발 범위를 결정하는 아주 중요한 문서이기 때문에 고객과 최종 합의 후 요구사항 베이스라인을 결정해야 한다. 요구사항 베이스라인이 결정되면 이후에 추가되거나 변경되는 요구사항에 대해서는 고객사와 개발사 간의 공식적인 협상을 통해 변경관리를 수행해야 한다.


앞 장에서 언급한 폭포수 모델에 따르면 요구분석이 끝나면 요구사항 도출이 완료되고 이후 이 것을 바탕으로 설계가 이루어진다. 따라서 설계 단계에서 요구사항 추가 및 수정을 고려하지 않으며 변경이 발생하더라도 절차가 굉장히 까다롭다. 하지만 현실적으로 볼 때 사람이 하는 일이 완벽할 수 없기 때문에 요구사항은 프로젝트 전 생명주기에 걸쳐 계속 변화하고 추가된다.


요구사항 변경관리


요구사항 베이스라인을 결정하고 변경되는 요구사항에 대해 공식적인 변경관리 프로세스를 거쳐야 한다는 이론과 요구사항은 프로젝트 전 과정에서 지속적으로 변경될 수 밖에 없다는 현실을 조화롭게 관리하면서 프로젝트를 수행해야 하는 문제에 직면하게 된다.


이 문제에 대한 완벽한 솔루션은 없다. 다만 고객사와 개발사가 각자 반드시 해야 할 일이 있는데, 첫째 고객사는 프로젝트 발주 전에 명확한 범위를 설정 해야 한다. 반복적인 업무 분석을 통해 우리 회사가 구축하고자 하는 시스템의 기능과 특성을 구체적으로 도출해야 한다. 과거 정부에서 기능점수 기반으로 규모 산정을 해야 한다고 강조하던 때가 있었다. 기능점수를 산출할 수 있다는 것은 시스템에 대한 개념 설계가 완료됐다는 의미 이므로 이 과정에서 고객사는 충분히 업무 분석을 할 수 있다는 생각에서였다. 하지만, 업무 분석을 중요한 업무로 생각하지 않는 한국 사회의 특성 때문에 이런 시도는 실패하고 말았다. 많은 프로젝트에서 투입 인력 기반으로 산출한 비용을 역산해서 기능점수를 산출했기 때문이다.


둘째 개발사는 요구분석 과정에서 고객의 참여를 유도하고 철저한 분석을 통해 요구사항을 도출해야 한다. 이 과정에서 프로토타입과 같은 도구를 사용하는 것도 고객의 이해를 돕기 위한 중요한 수단이 될 수 있다. 또한 유사한 프로젝트 경험이 있는 숙련된 설계자를 투입해야 한다. 그래야 고객이 요구하는 기능을 명확하게 도출하고 고객이 프로젝트 초반에 생각하지 못하는 잠재된 요구사항을 도출할 수 있다.


이제 요구사항 분석을 통해 설계와 개발에 필요한 요구사항 명세서를 도출했다. 하지만 명심해야 할 것은 요구사항 명세서가 완성된 것이 아니라는 것이다. 물론 가장 좋은 것은 지금 최종적인 요구사항을 가지고 있는 것이지만 너무나도 유연한 소프트웨어 프로젝트 특성상 어느 정도 요구사항이 변경되고 추가된다는 것은 가정해야 한다.


프로젝트 전체 구조를 흔들거나 터무니 없는 요구사항을 수주사 입장에서 받아들이기 힘들겠지만, 조그만 추가 요구사항이나 제안요청서에 대한 해석의 차이에서 발생하는 수준의 요구사항 변경은 적극적으로 대응해야 한다.

하지만, 요구사항을 분석하는 시점에는 고객의 모든 요구사항을 도출해야 하고 말겠다는 생각을 가지고 정해진 기간 동안 최선을 다해야 한다. 그래야지만 프로젝트 후반부에 고생하지 않고 좋은 고품질을 소프트웨어를 개발할 수 있다.


'더 괜찮은 개발자가 되기위한 > 요구사항 분석하기' 카테고리의 다른 글

요구사항 검증  (0) 2018.11.19
요구사항 명세  (0) 2018.11.19
요구사항 분석  (0) 2018.11.19
요구사항 도출  (0) 2018.11.19
요구사항 분석 개념  (0) 2018.11.19