Requirement​ ​Analysis​ ​คือ​อะไร​ ​และ​เหตุ​ใด​ ​Requirement​ ​ที่​ไม่​ชัด​จึง​ส่ง​ผล​ต่อ​ทั้ง​โครงการ

Requirement Analysis คือการทำความเข้าใจ ตรวจ และจัดความต้องการของผู้เกี่ยวข้องให้กลายเป็นข้อกำหนดที่ทีมออกแบบและทดสอบได้ คำว่า “ต้องมี Dashboard” อาจเป็นเพียงแนวทางแก้ แต่ปัญหาจริงคือหัวหน้าทีมไม่รู้ว่างานใดค้างและต้องจัดคนเพิ่ม การวิเคราะห์จึงเริ่มจากปัญหาและการตัดสินใจ ไม่ใช่รับรายการฟีเจอร์ทันที

เก็บข้อมูลจากใครและอย่างไร

ระบุผู้ใช้หลัก ผู้อนุมัติ เจ้าของข้อมูล ผู้ดูแลระบบ และระบบภายนอกที่เกี่ยวข้อง ใช้การสัมภาษณ์ การสังเกตงานจริง ตัวอย่างเอกสาร และข้อมูลข้อผิดพลาดประกอบกัน เพราะแต่ละคนอาจเห็นเพียงส่วนของกระบวนการ ตัวอย่างเช่น ฝ่ายขายรู้วิธีรับคำขอ แต่ฝ่ายบัญชีรู้ข้อยกเว้นเรื่องยกเลิกรายการ

ภาพที่ 1: Requirement ที่ใช้พัฒนาได้ต้องเชื่อมผู้ใช้ เงื่อนไขข้อมูล และผลที่คาด ไม่หยุดที่ชื่อหน้าจอ

ข้อกำหนดที่ชัดควรตอบอะไร

ข้อกำหนดด้านการทำงานควรบอกผู้กระทำ เหตุการณ์ เงื่อนไข และผลลัพธ์ เช่น “เมื่อเจ้าหน้าที่รับคำขอที่มีข้อมูลครบ ระบบกำหนดเลขอ้างอิงและสถานะใหม่” ต้องถามต่อว่าข้อมูลครบคืออะไร เลขอ้างอิงซ้ำได้หรือไม่ และถ้าส่งซ้ำจะเกิดอะไรขึ้น ข้อกำหนดด้านคุณภาพยังครอบคลุมการเข้าถึง ความปลอดภัย ความเร็วที่จำเป็น และการดูแลหลังเปิด โดยควรเขียนเป็นสิ่งที่ตรวจได้ ไม่ใช้คำว่า “เร็ว” หรือ “ใช้ง่าย” โดยไม่มีบริบท

ตัวอย่างสมมติ: คำว่า “อนุมัติได้” ยังไม่พอ

ทีมอาจตีความต่างกันว่าใครอนุมัติ รายการใดอนุมัติได้ และหลังอนุมัติแก้ไขได้หรือไม่ เมื่อถามต่อพบว่าเฉพาะหัวหน้าทีมของผู้ยื่นจึงอนุมัติได้ และรายการที่อนุมัติแล้วต้องเก็บประวัติการเปลี่ยนแปลง ข้อสรุปนี้ส่งผลถึงหน้าจอ โครงสร้างข้อมูล สิทธิ์ และกรณีทดสอบ หากปล่อยคำเดิมไว้จนช่วงทดสอบ การแก้จะข้ามหลายส่วนของระบบ

ควรแยก ข้อเท็จจริงที่ยืนยันแล้ว, สมมติฐานที่ต้องทดลอง, และ ข้อขัดแย้งระหว่างผู้เกี่ยวข้อง ไว้ในบันทึกเดียวกัน เมื่อคำขอเปลี่ยน ให้บันทึกเหตุผลและผลต่อเวลา/ขอบเขต การเปลี่ยน Requirement ไม่ใช่ความล้มเหลว แต่ต้องเห็นผลกระทบก่อนตัดสินใจ

ใช้เป็นกรอบในรายงาน

รายงานควรแสดงวิธีเก็บข้อมูล ผู้ให้ข้อมูลโดยไม่เปิดเผยข้อมูลส่วนบุคคลเกินจำเป็น รายการข้อกำหนดที่จัดลำดับแล้ว และตัวอย่างการแปลงคำคลุมเครือเป็นเกณฑ์รับงาน ระบุข้อจำกัดด้วย เช่น สัมภาษณ์เพียงทีมเดียวจึงยังไม่ครอบคลุมงานทุกสาขา แนวทาง ISO/IEC/IEEE 29148 ให้ความสำคัญกับข้อกำหนดที่มีรูปแบบและคุณลักษณะเหมาะกับการตรวจสอบตลอดวงจร

อ่านต่อ Acceptance Criteria และ Software Design หรือดู บริการพัฒนา Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

ลองกำหนดกรณีศึกษาเป็น คำขอจากผู้จัดการว่าอยากได้ Dashboard ที่เห็นงานค้าง และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้

หลักฐานที่ควรแสดงคือ บันทึกสัมภาษณ์ ผู้ใช้เป้าหมาย นิยามงานค้าง และ Acceptance Criteria ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ ผู้ใช้สองฝ่ายตีความข้อมูลและผลที่คาดตรงกัน ส่วนข้อจำกัดที่ต้องระบุคือ การถามเพียงหน้าตาที่อยากได้ยังไม่ยืนยันปัญหาธุรกิจ หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• ISO/IEC/IEEE 29148: Requirements engineering — กระบวนการและลักษณะของข้อกำหนด
• IBM: What is the software development life cycle? — ตำแหน่งของการวิเคราะห์ความต้องการในวงจรพัฒนา