요구 사항 수집

소개

모든 유형의 프로젝트에서 요구 사항 수집은 중요한 역할을합니다. 요구 사항 수집은 프로젝트에 중요 할뿐만 아니라 프로젝트 관리 기능에도 중요합니다.

프로젝트의 경우 프로젝트가 최종적으로 제공 할 내용을 이해하는 것이 성공에 중요합니다. 요구 사항을 통해 프로젝트 관리는 프로젝트의 최종 납품과 최종 납품이 고객의 특정 요구 사항을 어떻게 처리해야 하는지를 결정할 수 있습니다.

요구 사항 수집은 매우 간단 해 보입니다. 놀랍게도 이것은 대부분의 프로젝트가 잘못된 발로 시작하는 프로젝트 단계 중 하나입니다. 일반적으로 실패한 프로젝트의 대부분은 요구 사항 수집이 잘못되었거나 불충분하여 실패했습니다. 이에 대해서는 다음 섹션에서 논의 할 것입니다.

다음은 프로젝트에서 요구 사항 컬렉션이 제공되는 위치를 나타내는 그림입니다.

요구 사항의 중요성

소프트웨어 개발 프로젝트를 예로 들어 보겠습니다. 프로젝트 시작이 끝나면 비즈니스 분석가 팀은 서둘러 요구 사항을 수집합니다. BA (비즈니스 분석가) 팀은 다양한 방법을 사용하여 프로젝트 요구 사항을 캡처 한 다음 요구 사항을 프로젝트 팀에 전달합니다. 비즈니스 요구 사항이 기술 요구 사항으로 변환되면 구현이 시작됩니다.

위의주기는 매우 정상적이고 문제가없는 것처럼 보이지만 현실은 다소 다릅니다. 대부분의 경우 BA 팀은 프로젝트와 관련된 모든 요구 사항을 파악할 수 없습니다. 그들은 항상 요구 사항의 일부를 간과합니다. 프로젝트를 구성하는 동안 일반적으로 고객은 프로젝트의 요구 사항 차이를 인식합니다.

프로젝트 팀은 추가 고객 지불이나 고객 승인 변경 요청없이 이러한 누락 된 요구 사항을 구현해야합니다. BA 팀의 잘못 인 경우 서비스 제공 업체가 누락 된 요구 사항을 구현하는 데 드는 비용을 부담해야 할 수 있습니다. 이러한 경우 누락 된 요구 사항에 대한 노력이 프로젝트 비용에 상당한 영향을 미치는 경우 프로젝트는 서비스 공급자에게 재정적 손실이 될 수 있습니다.

따라서 요구 사항 수집 프로세스는 모든 프로젝트에서 가장 중요한 단계입니다.

요구 사항 수집 프로세스

요구 사항 수집을 위해 비즈니스 분석가가 사용하는 몇 가지 방법이 있습니다. 이러한 방법은 일반적으로 프로젝트마다, 클라이언트 조직마다 다릅니다.

일반적으로 새로운 시스템에 대한 요구 사항은 시스템의 잠재적 인 최종 사용자로부터 수집됩니다. 이러한 잠재적 인 최종 사용자의 요구 사항을 수집하는 데 사용되는 방법은 최종 사용자의 특성에 따라 다릅니다. 예를 들어 최종 사용자가 많은 경우 워크숍 방법을 요구 사항 수집에 사용할 수 있습니다.

이 방법에서는 모든 잠재적 인 최종 사용자가 워크샵에 참여하도록 요청됩니다. 이 워크숍에서 비즈니스 분석가는 사용자와 소통하고 새 시스템에 대한 요구 사항을 수집합니다. 경우에 따라 워크숍 세션은 사용자 피드백을 검토하고 캡처하기 위해 비디오로 녹화됩니다.

사용자 기반이 매우 적 으면 비즈니스 분석가는 대면 인터뷰를 수행 할 수 있습니다. 이것은 비즈니스 분석가가 모든 질문을하고 교차 질문을받을 수 있기 때문에 필요한 모든 요구 사항을 찾는 가장 효과적인 방법입니다.

질문자는 요구 사항 수집 프로세스에 효과적으로 사용될 수 있지만 이것이 최종 사용자와 상호 작용하는 유일한 방법은 아닙니다. 질문자는 인터뷰 또는 워크샵을위한 지원 기능으로 사용해야합니다.

위의 방법 외에도 특정 조건에 사용할 수있는 다른 많은 특정 방법이 있습니다.

성공적인 요구 사항 수집을위한 팁

다음은 요구 사항 수집 프로세스를 성공적으로 수행하기위한 몇 가지 팁입니다.

고객의 요구 사항을 알고 있다고 가정하지 마십시오. 일반적으로 생각하는 것은 고객이 원하는 것과 상당히 다를 수 있습니다. 따라서 가정이나 의심이있는 경우 항상 고객에게 확인하십시오.
처음부터 최종 사용자를 참여 시키십시오. 당신이하는 일에 대한 그들의 지원을 받으세요.
초기 수준에서 범위를 정의하고 고객의 동의를 얻습니다. 이렇게하면 기능 범위에 성공적으로 집중할 수 있습니다.
요구 사항을 수집하는 과정에서 요구 사항이 현실적이고 구체적이며 측정 가능한지 확인하십시오.
요구 사항 문서를 명확하게 만드는 데 집중하십시오. 요구 사항 문서는 클라이언트와 서비스 제공 업체가 계약을 맺을 수있는 유일한 방법입니다. 따라서이 문서에는 회색 영역이 없어야합니다. 회색 영역이있는 경우 잠재적 인 비즈니스 문제로 이어질 수 있습니다.
모든 요구 사항이 수집 될 때까지 솔루션이나 기술에 대해 고객에게 이야기하지 마십시오. 요구 사항에 대해 명확해질 때까지 고객에게 약속하거나 표시 할 수있는 위치에 있지 않습니다.
다른 프로젝트 단계로 이동하기 전에 클라이언트가 서명 한 요구 사항 문서를 가져옵니다.
필요한 경우 요구 사항을 시각적으로 보여주는 프로토 타입을 만듭니다.

결론

요구 사항 수집은 프로젝트에서 가장 중요한 단계입니다. 프로젝트 팀이 솔루션에 필요한 모든 요구 사항을 파악하지 못하면 프로젝트가 위험과 함께 실행됩니다. 이로 인해 앞으로 많은 분쟁과 불일치가 발생할 수 있으며 그 결과 비즈니스 관계가 심각하게 손상 될 수 있습니다.

따라서 요구 사항 수집을 프로젝트 팀의 주요 책임으로 삼으십시오. 요구 사항이 승인 될 때까지 솔루션의 특성에 대해 약속하거나 언급하지 마십시오.