Requirements
สัปดาห์ที่แล้วผมมีโอกาสได้แสดงความคิดเห็นต่อคำถามของคุณ siam2advance เกี่ยวกับกระบวนการหลังจากได้รับ requirement จากลูกค้ามาแล้ว ซึ่งผมอยากจะขยายความต่อในบทความนี้ครับ
ผมเชื่อว่าพวกเราทุกคนในวงการ software development คงจะเคยเจอปัญหาที่เกี่ยวข้องกับ requirement อยู่บ่อยๆโดยเฉพาะอย่างยิ่งปัญหาที่เกิดจาก requirement ที่ได้มาไม่มีความสมบูรณ์หรือละเอียดเพียงพอที่จะทำงานต่อ ทั้งในส่วนของ software development ซึ่งต้องทำการออกแบบระบบสำหรับแต่ละ requirement และในส่วนของ project management ซึ่งต้องทำ estimation and planning
ความไม่สมบูรณ์ของ requirement ที่ผมพบบ่อยๆก็เช่น
Completeness: requirement ไม่สมบูรณ์ในตัวเอง อธิบายเรื่องราวหรือความต้องการได้ไม่ครบถ้วนครับ เช่น “เพื่อเพิ่มความสามารถของระบบในการสนับสนุนการตัดสินใจของผู้บริหาร รายงานประจำปีรูปแบบใหม่จึงควรถูกสร้างขึ้น” สำหรับผม ถ้าได้ requirement มาแค่นี้จริงๆคงเศร้าหละครับเพราะว่าจะทำอะไรต่อก็ลำบากไปหมด ที่มึนมากๆก็คือ “รูปแบบใหม่” นี้มันแบบไหนหละ?
Ambiguity: ข้อมูลที่ระบุใน requirement มีความกำกวมไม่ชัดเจน เช่น “การสร้้้้างรายงานประจำปีต้องดึงข้อมูลจากตารางที่เกี่ยวข้องในฐานข้อมูล” คำว่า “ที่เกี่ยวข้อง” นั้นไม่ชัดเจนเพียงพอที่จะลงมือ design ระบบได้ทันทีหรอกครับ ยิ่งสำหรับคนที่ไม่มีประสบการณ์ในงานด้วยแล้ว ยิ่งยากใหญ่ Read the rest of this entry »


