제품 요구 사항의 검증(validation)은 구현된 솔루션을 원래의 비즈니스 요구 사항과 체계적으로 비교하는 과정을 포함합니다. 비즈니스 분석가는 중요한 역할을 하며, 요구 사항을 올바르게 형식화하고, 수용 기준(acceptance criteria)을 정의하며, 수용 테스트에 직접 참여합니다. 불일치가 발견되면 분석가는 결함을 기록하고 그 원인을 파악(잘못된 구현, 잘못 이해한 요구 사항, 변경된 비즈니스 프로세스 등)하며, 수정 조치 또는 변경 사항에 대한 추가 합의의 적절한 단계를 결정하는 데 도움을 줍니다.
주요 특징:
비즈니스 분석가는 요구 사항 검증 작업을 테스트 담당자나 QA 팀에 완전히 위임할 수 있습니까?
아니요, QA가 시스템을 테스트하더라도 분석가는 제품이 비즈니스 요구 사항에 부합하는지에 대한 책임이 있습니다. 그는 비즈니스 맥락에 대한 전문성을 가지고 있습니다.
모든 기능적 요구 사항이 구현되었지만 비기능적 요구 사항이 고려되지 않은 경우 제품 출시가 허용됩니까?
아니요, 비기능적 요구 사항(성능, 보안, 편의성)을 충족하지 않으면 운영 중단 또는 사용자 불만으로 이어질 것입니다.
요구 사항이 형식화되지 않고 구두 계약으로만 존재할 경우 요구 사항을 검증된 것으로 간주할 수 있습니까?
아니요, 요구 사항은 명확하게 기록되고 형식화되어야 하며, 구두 합의는 종종 오해와 오류를 초래합니다.
부정적인 사례: 수용 기준이 사전 형식화 및 합의 없이 개발자의 데모를 기준으로 결과를 수용합니다. 장점: 수용 단계가 빠르게 완료됨 단점: 나중에 많은 미비점이 드러나고 고객과 갈등 발생
긍정적인 사례: 요구 사항을 형식화하고 고객과 요구 사항 문서를 서명하며 체크리스트를 작성하고 고객과 수용 테스트를 수행합니다. 모든 지적 사항이 기록되고 수정되었습니다. 장점: 오해 최소화, 양측 모두 투명한 과정, 분쟁 위험 감소 단점: 합의 및 테스트 과정이 예상보다 길어짐