เรียนรู้การค้นหา วิเคราะห์ จัดลำดับ ตรวจสอบ และเขียนข้อกำหนดความต้องการของระบบ แล้วแปลงเป็น Use Case Model เพื่อใช้เป็นฐานในการออกแบบระบบเชิงวัตถุ
การวิเคราะห์ความต้องการ หรือ Requirement Analysis เป็นขั้นตอนสำคัญในกระบวนการวิเคราะห์และออกแบบระบบเชิงวัตถุ เพราะช่วยให้ทีมพัฒนาระบบเข้าใจว่า ผู้ใช้ต้องการอะไร ระบบควรทำอะไร และขอบเขตของระบบอยู่ตรงไหน ก่อนเข้าสู่การออกแบบและพัฒนาระบบจริง
หากวิเคราะห์ความต้องการไม่ครบถ้วนหรือไม่ชัดเจน ระบบที่พัฒนาขึ้นอาจไม่ตรงกับความต้องการของผู้ใช้ เกิดการแก้ไขซ้ำ ใช้งบประมาณสูง และอาจทำให้โครงการล้มเหลวได้ ดังนั้นบทนี้จึงเริ่มจากความหมายของ Requirement, User Requirement, System Requirement และ SRS ก่อนเชื่อมไปสู่ Use Case Model
บทเรียนยังครอบคลุมแหล่งที่มาของความต้องการ เทคนิคการเก็บข้อมูล การแยก Functional และ Non-functional Requirement การตรวจสอบความถูกต้อง และการเขียน Use Case Diagram กับ Use Case Description
Requirement คือข้อกำหนดที่บอกว่าระบบต้องทำอะไรได้บ้าง และต้องมีเงื่อนไขใดในการทำงาน
Requirement คือสิ่งที่ผู้ใช้ เจ้าของระบบ หรือผู้เกี่ยวข้องคาดหวังให้ระบบสารสนเทศสามารถทำได้ หรือเป็นเงื่อนไขที่ระบบต้องปฏิบัติตาม เพื่อให้ระบบแก้ปัญหาและสนับสนุนเป้าหมายขององค์กรได้
อ่านแล้วเข้าใจตรงกัน ไม่กำกวม
มีข้อมูลและเงื่อนไขที่จำเป็น
นำไปทดสอบได้จริง
ทำได้ภายใต้เวลา งบประมาณ และเทคโนโลยี
ภาษาธรรมชาติที่ผู้ใช้อ่านเข้าใจง่าย เช่น “ลูกค้าสามารถสมัครสมาชิกได้” หรือ “เจ้าของร้านดูรายงานยอดขายได้”
รายละเอียดเชิงระบบที่นำไปออกแบบ พัฒนา และทดสอบ เช่น ตรวจสอบอีเมลซ้ำ รหัสผ่านอย่างน้อย 8 ตัวอักษร
เอกสารรวบรวมข้อกำหนดทั้งหมดอย่างเป็นระบบ เพื่อเป็นข้อตกลงร่วมระหว่างผู้ใช้ นักวิเคราะห์ และทีมพัฒนา
ความต้องการไม่ได้มาจาก SA แต่ SA ต้องสังเคราะห์จากผู้ใช้และผู้เกี่ยวข้องหลายกลุ่ม
เจ้าของระบบ ผู้บริหาร ผู้จัดการ หรือผู้อนุมัติโครงการ สนใจความคุ้มค่า งบประมาณ และผลลัพธ์เชิงธุรกิจ
ผู้ใช้ที่ป้อนข้อมูลหรือใช้งานประจำวัน เช่น พนักงานขาย เจ้าหน้าที่ทะเบียน พยาบาล สนใจความรวดเร็วและความถูกต้อง
ผู้เชี่ยวชาญเฉพาะงาน เช่น หัวหน้าแผนก หัวหน้าช่าง แพทย์ ให้ข้อมูลเชิงลึกของงานเฉพาะทางได้ดี
ผู้ดูแลระบบ กำหนดสิทธิ์ ดูแลการทำงาน สำรองข้อมูล ตั้งค่า และแก้ปัญหาทางระบบ
ผู้บริหารที่ต้องการรายงาน สถิติ แนวโน้ม และสารสนเทศเพื่อการตัดสินใจ เช่น CEO, CIO, ผู้อำนวยการ
ผู้ใช้นอกองค์กร เช่น ลูกค้า ผู้ป่วย ผู้ชมภาพยนตร์ หรือญาติผู้ป่วยที่ใช้บริการของระบบ
เก็บข้อมูลข้อเท็จจริงจากผู้ใช้ เอกสาร กระบวนการ และปัญหาเดิม
ระบุความต้องการแต่ละข้อให้ชัดเจน แยกเป็นอิสระ และทดสอบได้
เลือกเฉพาะส่วนสำคัญที่อยู่ใน Problem Domain
จัดกลุ่มตามผู้ใช้ ฟังก์ชัน หรือมุมมองของระบบ
จัดลำดับความสำคัญ เช่น 0, 1, 2
ตรวจความถูกต้อง ความครบถ้วน และความเป็นไปได้
จัดทำรายงาน SRS
ลงพื้นที่สังเกตการทำงานจริง เพื่อเข้าใจ Workflow จริง เช่น การทำงานของพนักงานโรงพยาบาลหรือร้านคาร์แคร์
สัมภาษณ์รายบุคคลหรือรายกลุ่ม เหมาะกับข้อมูลเชิงลึกและบทบาทเฉพาะ
ใช้แบบสอบถามเมื่อต้องการข้อมูลจากผู้ใช้จำนวนมาก เพื่อสรุปแนวโน้มและระดับความต้องการ
ทบทวนเอกสารเดิม เช่น แบบฟอร์ม ใบเสร็จ รายงาน คู่มือ หรือนโยบาย
ประชุมผู้เกี่ยวข้อง เช่น User, Manager, Sponsor, SA เพื่อหาข้อสรุป Requirement ร่วมกัน
สร้าง Mockup หรือ Wireframe อย่างรวดเร็วให้ผู้ใช้ทดลองและเสนอแนะ เหมาะเมื่อผู้ใช้ยังอธิบายความต้องการไม่ชัด
บริการหลักหรือหน้าที่ที่ระบบต้องทำได้ เช่น บันทึกข้อมูลลูกค้า สั่งซื้อสินค้า จ่ายยา ออกใบเสร็จ หรือจองห้องพัก โดยทั่วไปสามารถแปลงเป็น Use Case ได้โดยตรง
เงื่อนไขหรือคุณภาพของระบบ เช่น ประสิทธิภาพ ความปลอดภัย ความเสถียร ความง่ายในการใช้งาน Browser อุปกรณ์ และกฎหมาย เช่น PDPA
| ReqID | REQ-001 |
|---|---|
| ชื่อ Requirement | บันทึกข้อมูลลูกค้า |
| ผู้ใช้ที่เกี่ยวข้อง | พนักงานขาย |
| รายละเอียด | ระบบต้องบันทึกข้อมูลลูกค้า ได้แก่ รหัสลูกค้า ชื่อ นามสกุล เบอร์โทรศัพท์ อีเมล และที่อยู่ |
| เงื่อนไข | เบอร์โทรศัพท์ต้องเป็นตัวเลข 10 หลัก และอีเมลต้องมีรูปแบบถูกต้อง |
| ระดับความสำคัญ | สูง / 2 |
| การทดสอบ | หากกรอกข้อมูลไม่ครบ ระบบต้องแสดงข้อความแจ้งเตือนและไม่บันทึกข้อมูล |
| ระดับ | ความหมาย |
|---|---|
| 0 | ไม่สำคัญ / ตัดออกได้ |
| 1 | ปานกลาง / ยังไม่เร่งด่วน |
| 2 | สำคัญมาก / เร่งด่วน |
Requirement หนึ่งอาจขึ้นอยู่กับอีก Requirement หนึ่ง เช่น ถ้าไม่มีข้อมูลห้องพัก จะไม่สามารถจองห้องพักได้ หรือถ้าไม่มีการเปิดคอร์ส จะไม่สามารถลงทะเบียนเรียนได้
ตรงกับความต้องการจริงหรือไม่
มีข้อกำหนดขัดแย้งกันเองหรือไม่
ครบถ้วนสำหรับผู้ใช้ทุกกลุ่มหรือไม่
สร้างได้จริงหรือไม่
ตรวจสอบหรือทดสอบได้หรือไม่
Use Case Diagram เป็นแผนภาพ UML สำหรับวิเคราะห์ระบบเชิงวัตถุ ใช้แสดงฟังก์ชันของระบบว่าระบบมีหน้าที่ใด และแต่ละหน้าที่มีปฏิสัมพันธ์กับ Actor ใด
| Association | Actor มีปฏิสัมพันธ์กับ Use Case |
|---|---|
| <<include>> | Use Case หลักต้องเรียก Use Case ย่อยทุกครั้ง เช่น ยืมหนังสือ include เข้าสู่ระบบ |
| <<extend>> | Use Case ย่อยเกิดเฉพาะบางเงื่อนไข เช่น คืนหนังสือ extend คิดค่าปรับล่าช้า |
| Generalization | แบ่งประเภท Actor หรือ Use Case เช่น ลูกค้า → สมาชิก / ลูกค้าทั่วไป |
| Requirement | Use Case |
|---|---|
| ลงทะเบียนลูกค้าใหม่และจัดการข้อมูลลูกค้า | ลงทะเบียนลูกค้า / แก้ไขข้อมูลลูกค้า |
| จัดการนัดหมายและตารางบริการ | นัดหมายบริการ / จัดตารางบริการ |
| บันทึกข้อมูลรถยนต์ | บันทึกข้อมูลรถยนต์ |
| ลูกค้าตรวจสอบสถานะบริการได้ | ตรวจสอบสถานะบริการ |
| คำนวณค่าบริการ | คำนวณค่าบริการ |
| Actor | Use Case |
|---|---|
| ลูกค้า | สมัครสมาชิก, เข้าสู่ระบบ, ค้นหาห้องว่าง, จองห้องพัก, ชำระเงิน, ตรวจสอบสถานะการจอง, ยกเลิกการจอง |
| เจ้าหน้าที่ | ตรวจสอบห้องพัก, ตรวจสอบสถานะการจอง, จัดการห้องพัก, ออกใบเสร็จ |
| ผู้ดูแลระบบ | จัดการข้อมูลผู้ใช้, จัดการข้อมูลห้องพัก, กำหนดสิทธิ์ |
| Use Case Name | จองห้องพัก |
|---|---|
| Actor | ลูกค้า |
| Preconditions | ลูกค้าต้องเข้าสู่ระบบ และมีห้องว่างในช่วงวันที่เลือก |
| Main Flow | เลือกวันที่ → ระบบแสดงห้องว่าง → เลือกห้อง → ระบบคำนวณราคา → ยืนยันการจอง |
| Alternative Flow | ถ้าห้องไม่ว่าง ระบบแสดงห้องอื่นหรือให้เปลี่ยนวันที่ |
| Postconditions | ระบบบันทึกข้อมูลการจองและแสดงเลขที่การจอง |
ช่วยให้ทุกฝ่ายเข้าใจปัญหา ความต้องการ และขอบเขตตรงกัน
ต้องเลือกถามข้อมูลให้ถูกคน
หลีกเลี่ยงคำคลุมเครือ เช่น ง่าย เร็ว ดี สวย
รวม ReqID, รายละเอียด, Priority, Dependency และ Test Criteria
แสดง Actor, Use Case, System Boundary และ Relationship
เมื่อ Requirement และ Use Case ชัดเจนแล้ว ขั้นต่อไปคือการวิเคราะห์ Class, Sequence, Activity และการออกแบบสถาปัตยกรรมระบบ