- เกี่ยวข้องกับการแสดงให้เห็นว่า requirement ได้กำหนดระบบที่ลูกค้าต้องการจริงๆ
- ค่าใช้จ่ายเนื่องจากความผิดพลาดของ requirement มีค่าสูง ดังนั้นการตรวจสอบความถูกต้องจึงมีความสำคัญมาก
- การแก้ไขข้อผิดพลาดจาก requirement หลังจากการจัดส่ง อาจเสียค่าใช้จ่ายถึง 100 เท่าของค่าใช้จ่ายในการแก้ไขข้อผิดพลาดขณะ implementation ระบบ
- ความถูกต้อง (Validity)
- ระบบมีฟังก์ชันที่รองรับความต้องการของลูกค้าได้ดีที่สุดหรือไม่?
- ความมั่นคง (Consistency)
- มีข้อขัดแย้งเรื่องข้อกำหนดหรือไม่?
- ความสมบูรณ์ (Completeness)
- ฟังก์ชั่นทั้งหมดที่ลูกค้าต้องการ?
- สัจนิยม (Realism)
- ความต้องการสามารถดำเนินการได้ตามงบประมาณและเทคโนโลยีที่มีอยู่
- ตรวจสอบได้ (Verifiability)
- สามารถตรวจสอบความต้องการได้หรือไม่?
- บทวิจารณ์ความต้องการ (Requirements reviews)
- การวิเคราะห์ด้วยตนเองของระบบตาม Requirements
- การสร้างต้นแบบ (Prototyping)
- ใช้แบบจำลองปฏิบัติการของระบบเพื่อตรวจสอบความต้องการ
- การสร้างกรณีทดสอบ (Test-case generation)
- พัฒนา test-driven สำหรับ Requirements ในการตรวจสอบ
- ควรมีการทบทวนเป็นประจำในขณะที่มีการกำหนด requirement
- ทั้งลูกค้าและนักพัฒนาควรมีส่วนร่วมในการ review
- Review อาจเป็นทางการ (พร้อมเอกสารฉบับสมบูรณ์) หรือไม่เป็นทางการ
- การสื่อสารที่ดีระหว่างนักพัฒนาลูกค้าและผู้ใช้สามารถแก้ปัญหาได้ในระยะเริ่มต้น
- ตรวจสอบได้ (Verifiability)
- ความต้องการที่สมจริงสามารถทดสอบได้หรือไม่?
- ความสามารถเข้าใจ (Comprehensibility)
- เข้าใจข้อกำหนดถูกต้องหรือไม่?
- ตรวจสอบย้อนกลับ (Traceability)
- ที่มาของ requirement ได้ถูกระบุไว้อย่างชัดเจนหรือไม่?
- การปรับตัว (Adaptability)
- ความต้องการสามารถเปลี่ยนแปลงได้โดยไม่มีผลกระทบอย่างมากต่อ requirement อื่น ๆ หรือไม่?