Requirements Validation

[ Requirements Validation(요구사항 검증) ]

▪ 요구사항이 실제로 고객이 원하는 바를 정의했는지를 보이는 것과 관련이 있다.

▪ 요구사항 검증은 요구사항 문서에 있는 오류가 시스템을 개발하거나, 시스템이 서비스 중일 경우에 발견되면 방대한 재 작업 비용이 들기 때문에 중요하다.

▪ 시스템을 변경하여 요구사항 문제를 수정하는 비용은 설계나 코딩 오류를 수정하는 것 보다 많이 든다. 그 이유는 요구사항의 변경은 시스템 설계와 구현 또한 변경되어야 하고 시스템을 다시 시험해야 하기 때문이다.

 

[ 요구사항 검증 점검 ]

Validity Checks (유효성 점검)	사용자의 요구를 가장 잘 반영한 기능을 제공하는가? 사용자는 시스템이 어떠한 기능을 수행하는 것이 필요하다고 생각한다. 그러나 나중에 요구한 것과 다르거나 추가의 기능을 발견할 수 있다. 시스템은 참여자마다 다양한 요구를 가지기 때문에, 요구 사항은 필연적으로 참여자 간에 타협점을 찾아야 한다.
Consistency Checks (일관성 점검)	요구사항의 충돌이 있는가? 문서에 있는 요구사항은 서로 상충되지 않아야 한다. 즉 모순이 되는 제약 조건이나 같은 시스템 기능에 대한 기술을 포함해서는 안 된다.
Completeness Checks (완전성 점검)	고객이 원한 기능이 모두 포함되어 있는가? 요구사항 문서는 모든 기능을 정의하고 시스템 사용자가 의도한 제약 조건을 모두 포함해야 한다.
Realism Checks (현실성 점검)	예산과 기술적으로 현실 가능성이 있는가? 기존 기술을 사용하여 요구사항이 실제로 구현될 수 있는 지를 보증해야 한다. 이것은 또한 시스템 개발의 예산과 일정 내에서 가능한 지도 고려해야 한다.
Verifiability (증명가능성)	고객과 계약자 사이의 분쟁에 대한 소지를 줄이기 위해서 시스템 요구사항과 일치하는 지를 보여줄 수 있는 시험을 작성 해야 한다.

 

[ Requirements Validation Techniques(요구사항 검증 기술) ]

Requirements reviews (요구사항 검토)	검토 팀에 의해서 요구사항이 체계적으로 분석된다.
Prototyping (프로토타입)	시스템의 실행 가능한 모델을 최종 사용자와 고객에게 보여주는 것이다. 그들은 이 모델을 이용하여 자신들의 실제 요구에 맞는 지를 실험할 수 있다.
Test-Case Generation (시험 사례 생성)	요구사항은 시험이 가능해야 한다. 만약 요구사항에 대한 시험을 검증 프로세스의 부분으로 생각한다면, 그것은 요구사항의 문제를 드러낸다. 만약 시험을 설계하는 것이 불가능하거나 어렵다면, 이것은 보통 요구사항을 구현하는 것이 어렵다는 의미이기 때문에 재고해보아야 할 사항이다.

 

댓글이나 공감 남겨주는 사람 착한사람