검증(Validation)

요구사항이 확정되는 네 단계

요구사항은 식별(Elicitation) → 분석(Analysis) → 명세(Specification) → 검증(Validation)의 흐름을 거쳐 확정된다. 식별에서 원천 데이터를 모으고, 분석에서 누락·중복·상충과 실현 가능성을 정리한 뒤, 명세 단계에서 수행사가 요구사항 정의서 초안을 작성한다.

이 초안이 0.9 버전이며, 고객의 확인(컨펌)을 거쳐야 비로소 1.0으로 확정된다.

Validation과 Verification의 구분

가장 자주 혼동되는 지점이다. Validation은 ‘제대로 된 것을 만들고 있는가’를 고객이 직접 확인하는 활동이고, Verification은 ‘제대로 만들고 있는가’를 엔지니어가 설계 명세 차원에서 검토하는 활동이다.

명세 0.9를 고객이 확인하면 Validation 1.0이 된다. 이 구분을 명확히 하지 않으면 검수 단계에서 ‘합의된 범위인가 아닌가’를 두고 분쟁이 발생한다.

수행사 기준선을 그대로 취하지 않는다

이 프로젝트의 미션, 곧 요구사항의 기준선(baseline)은 검증된 1.0이다. 수행사가 작성한 기준선을 그대로 채택해서는 안 되며, 반드시 고객의 확인 절차를 거쳐야 한다.

수행사가 동일한 수준으로 작성한 명세라 하더라도 그것은 0.9에 불과하고, 고객이 확인하지 않은 기준선은 이후 책임 소재가 모호해진다.

비기능에서 드러나는 추가 요구

잠재 요구(Needs)에서 확정 요구(Requirements)로 좁혀가는 과정에서 추가로 드러나는 요구는 대개 비기능 영역에서 나온다. 검증 단계에서 기능 요구만 보지 말고 성능·보안·사용성 같은 비기능이 명세에 충분히 반영되었는지를 함께 확인해야 1.0의 완성도가 보장된다.

아키텍처 구성과 기능 정의의 명확성, 테이블 구조의 정합성이 결국 산출물의 완성도를 뒷받침한다.

추적성으로 검수를 잇는다

검증이 의미를 가지려면 추적성(traceability)이 받쳐줘야 한다. 요구사항 명세서에는 요구 ID와 유형, 출처, 우선순위, 수용 여부, 변경 이력이 담겨야 하며, 이 정보가 있어야 합의 범위를 두고 논쟁이 생길 때 추적이 가능하다.

검수 단계에서는 확정된 1.0이 기준이 된다. 기능은 결함률(인수 테스트)로, 비기능은 성능·보안(시스템 테스트)으로 확인한다.

우선순위는 단순 등급이 아니라 협상의 여지를 남기는 장치로, 범위가 위협받을 때 낮은 우선순위를 운영 단계로 이관하는 근거가 된다.

우선순위가 협상의 여지를 만든다

검증으로 확정된 1.0은 검수의 기준이 되는 동시에, 우선순위 체계를 통해 협상의 여지를 남긴다. 생성·조회·수정·삭제가 모두 필요한 핵심 기능은 높은 우선순위로, 편의 기능은 낮은 우선순위로 분류한다.

범위가 감당 한계를 위협할 때, 낮은 우선순위 항목을 검수 범위 밖으로 빼서 운영 단계 개발로 이관하는 협상이 가능해진다. 이때 우선순위는 단순한 등급이 아니라 실질적인 대안(플랜 B)이 된다.

따라서 검증은 ‘무엇을 1.0으로 확정할 것인가’와 ‘무엇을 협상의 여지로 남길 것인가’를 함께 설계하는 작업이며, 이 설계가 인도 단계의 협상력을 좌우한다.