การวิเคราะห์และจัดทำข้อกำหนดความต้องการ

หลังจากเก็บรวบรวมความต้องการของผู้ใช้ (Requirement Elicitation) ในขั้นตอนการสำรวจแล้ว ข้อมูลที่ได้มักมีลักษณะกระจัดกระจาย ซ้ำซ้อน ขาดบริบท หรือแม้กระทั่งขัดแย้งกันเอง เนื่องจากมาจากผู้มีส่วนได้ส่วนเสียหลายกลุ่ม เช่น ผู้ใช้ปลายทาง ผู้บริหาร และฝ่ายเทคนิค

นักวิเคราะห์ระบบ (System Analyst) จึงมีบทบาทสำคัญในการนำข้อมูลเหล่านี้มาวิเคราะห์เชิงระบบ (Systematic Analysis) โดยดำเนินการจัดระเบียบ จัดกลุ่ม ตรวจสอบความถูกต้อง และจัดลำดับความสำคัญ ก่อนจะสังเคราะห์ออกมาเป็นเอกสารข้อกำหนดความต้องการของระบบ (SRS: Software Requirements Specification) ที่มีความชัดเจน ตรวจสอบได้ และสามารถใช้เป็น “สัญญาทางเทคนิค” ระหว่างผู้ใช้กับทีมพัฒนา รวมถึงเป็นฐานสำคัญสำหรับขั้นตอนการออกแบบและพัฒนาระบบในลำดับถัดไป

1. การจัดกลุ่มและตรวจสอบความครบถ้วนของความต้องการ

ขั้นตอนแรกของการวิเคราะห์คือการจัดกลุ่ม (Categorization) โดยนำความต้องการทั้งหมดมาจัดหมวดหมู่ตามฟังก์ชันการทำงานหรือโดเมนของระบบ เพื่อให้เห็นภาพรวมและความสัมพันธ์ของความต้องการได้ชัดเจนยิ่งขึ้น

ตัวอย่างการจัดกลุ่มในระบบห้องสมุด:

• กลุ่มการจัดการสมาชิก (Member Management)

• กลุ่มการยืม–คืน (Circulation)

• กลุ่มการค้นหา (Search & Catalog)

• กลุ่มรายงาน (Reporting)

• กลุ่มผู้ดูแลระบบ (Administration)

หลังจากจัดกลุ่มแล้ว ต้องทำการ “ตรวจสอบความครบถ้วน” (Completeness Check) โดยพิจารณาว่า:

• ครอบคลุมทุกกระบวนการทางธุรกิจ (Business Process) หรือไม่

• มี use case สำคัญตกหล่นหรือไม่

• รองรับทุกประเภทผู้ใช้งาน (User Roles) หรือไม่

เทคนิคที่นิยมใช้:

• Use Case Diagram

• User Story Mapping

• Process Flow Diagram (BPMN)

2. การวิเคราะห์ความสอดคล้องและความขัดแย้งของความต้องการ

เมื่อได้รายการความต้องการที่จัดกลุ่มแล้ว ขั้นตอนถัดไปคือการวิเคราะห์คุณภาพของความต้องการ (Requirement Quality Analysis) โดยพิจารณาประเด็นสำคัญดังนี้

• ความซ้ำซ้อน (Redundancy)
  ความต้องการที่กล่าวซ้ำในหลายรูปแบบ เช่น “ค้นหาหนังสือ” กับ “ค้นหารายการหนังสือ” ควรรวมเป็นข้อเดียวเพื่อลดความซับซ้อน

• ความขัดแย้ง (Conflict)
  เช่น

  • ผู้ดูแลต้องการจำกัดสิทธิ์การยืมเฉพาะนักศึกษา

  • ผู้บริหารต้องการเปิดให้บุคคลภายนอกยืมได้
    แนวทางแก้: จัดประชุม stakeholder หรือกำหนด business rule ที่ชัดเจน เช่น แยกประเภทสมาชิก

• ความกำกวม (Ambiguity)
  เช่น “ระบบต้องทำงานเร็ว” → ต้องกำหนดใหม่เป็น
  “ระบบต้องตอบสนองภายใน 2 วินาที เมื่อมีผู้ใช้งานพร้อมกัน 100 คน”

• ความเป็นไปได้ (Feasibility)
  พิจารณาใน 4 มิติ:

  • Technical feasibility

  • Economic feasibility

  • Operational feasibility

  • Schedule feasibility

ตัวอย่าง: “ระบบ AI แนะนำหนังสือแบบ Real-time” อาจไม่เหมาะกับงบประมาณหรือโครงสร้างพื้นฐานในระยะเริ่มต้น

3. การจัดลำดับความสำคัญของความต้องการด้วยเทคนิค MoSCoW

เนื่องจากข้อจำกัดด้านเวลา งบประมาณ และทรัพยากร การพัฒนาระบบจำเป็นต้องเลือกทำสิ่งที่ “มีคุณค่าสูงสุดก่อน” เทคนิค MoSCoW เป็นเครื่องมือที่ช่วยจัดลำดับความสำคัญได้อย่างมีประสิทธิภาพ

• Must have (ต้องมี)
  เป็นความต้องการหลักของระบบ หากขาดจะไม่สามารถใช้งานได้
  ตัวอย่าง:

  • บันทึกการยืม–คืน

  • ตรวจสอบสถานะหนังสือ

  • คำนวณค่าปรับ

• Should have (ควรมี)
  สำคัญแต่สามารถเลื่อนได้ชั่วคราว
  ตัวอย่าง:

  • ระบบแจ้งเตือนวันครบกำหนด

  • รายงานสถิติการใช้งาน

• Could have (มีได้)
  เพิ่มประสบการณ์ใช้งาน (UX) แต่ไม่จำเป็น
  ตัวอย่าง:

  • ระบบจองหนังสือล่วงหน้า

  • ตรวจสอบรายการยืมผ่านเว็บไซต์

• Won’t have (ยังไม่ทำ)
  เก็บไว้ใน roadmap อนาคต
  ตัวอย่าง:

  • ระบบ AI แนะนำหนังสือ

  • Mobile Application แบบ Native

ข้อดีของ MoSCoW:

• ช่วยวางแผน Sprint หรือ Phase ได้ชัดเจน

• ลด scope creep

• ใช้สื่อสารกับ stakeholder ได้ง่าย

4. การจัดทำเอกสารข้อกำหนดความต้องการของระบบ (SRS)

SRS เป็นเอกสารหลักที่ใช้ในการพัฒนาซอฟต์แวร์ โดยต้องมีความชัดเจน เป็นระบบ และตรวจสอบได้ โครงสร้างมาตรฐานอาจอ้างอิง IEEE 830 หรือ ISO/IEC/IEEE 29148

องค์ประกอบหลัก:

1. บทนำ (Introduction)

   • วัตถุประสงค์ของระบบ

   • ขอบเขต (Scope)

   • คำจำกัดความ (Definitions)

2. ความต้องการเชิงหน้าที่ (Functional Requirements)
   ระบุเป็นข้อ ๆ เช่น

   • FR-01: ระบบต้องสามารถบันทึกการยืมหนังสือได้

   • FR-02: ระบบต้องคำนวณค่าปรับอัตโนมัติ

3. ความต้องการไม่เชิงหน้าที่ (Non-functional Requirements)
   เช่น:

   • Performance: รองรับผู้ใช้ 500 คนพร้อมกัน

   • Security: ใช้ OAuth2 / RBAC

   • Usability: ผู้ใช้ใหม่ต้องเรียนรู้ภายใน 10 นาที

4. ข้อจำกัดและเงื่อนไข (Constraints)

   • ใช้ PostgreSQL

   • Deploy บน Cloud ขององค์กร

   • ต้องสอดคล้อง PDPA

5. เกณฑ์การยอมรับ (Acceptance Criteria)
   ตัวอย่าง:

   • เมื่อยืมหนังสือ ระบบต้องบันทึกข้อมูลภายใน 1 วินาที

   • ระบบต้องแจ้งเตือนก่อนครบกำหนด 1 วัน

คุณลักษณะของความต้องการที่ดี:

• Clear

• Complete

• Consistent

• Unambiguous

• Verifiable

• Feasible

• Traceable (เชื่อมโยงไปยังแหล่งที่มา เช่น stakeholder หรือ business goal ได้)

5. การตรวจสอบและยืนยันความต้องการ (Verification & Validation)

ก่อนเข้าสู่ขั้นตอนออกแบบ (System Design) จำเป็นต้องมีการตรวจสอบคุณภาพของ SRS ดังนี้:

• Verification (ตรวจสอบความถูกต้องของเอกสาร)
  ตรวจว่า:

  • เขียนครบหรือไม่

  • รูปแบบถูกต้องหรือไม่

  • ไม่มีข้อขัดแย้งภายใน

• Validation (ยืนยันกับผู้ใช้)
  ตรวจว่า:

  • ตรงกับความต้องการจริงหรือไม่

  • ใช้งานได้จริงในบริบทองค์กรหรือไม่

วิธีที่นิยมใช้:

• Requirement Review Meeting

• Walkthrough / Inspection

• Prototype หรือ Wireframe

• ให้ผู้ใช้ลงนาม (Sign-off)

ประโยชน์:

• ลดการแก้ไขซ้ำ (Rework)

• ลดต้นทุนในระยะยาว

• เพิ่มความเข้าใจร่วมกันระหว่างทีม