Requirements Analysis & System Modeling
การวิเคราะห์ความต้องการ คือการนำข้อมูลที่สกัดมาแล้วไปใช้ในการออกแบบและพัฒนาซอฟต์แวร์ ผู้รับผิดชอบหลักคือ SA (System Analyst) นักวิเคราะห์ระบบ
1. บทบาทของ System Analyst
| ด้าน | รายละเอียด |
|---|---|
| หน้าที่ | สกัดความต้องการ → วิเคราะห์ → ออกแบบระบบ → ส่งต่อทีมพัฒนา → จัดทำเอกสารด้านซอฟต์แวร์ |
| ความสามารถ | ความรู้ด้านเทคนิค + ทักษะการวิเคราะห์ + การสื่อสาร + การจัดการ |
2. Who / What / How
ในการแจกแจงความต้องการตามกลุ่มผู้ใช้ ให้ถามสามคำถามนี้:
| คำถาม | ความหมาย |
|---|---|
| Who | บทบาทของผู้ใช้ เช่น ผู้ปฏิบัติงาน, หัวหน้า, ผู้ดูแลระบบ |
| What | สิ่งที่ผู้ใช้จะทำกับระบบ หรือผู้ใช้คาดหวังจะให้ระบบทำอะไร |
| How | ผู้ใช้อยากให้ระบบทำอย่างไร หรือทำไมอยากใช้ระบบ เพื่ออะไร |
3. URS และ SRS
URS (User Requirement Specification) — จัดกลุ่มความต้องการของผู้ใช้ หรือจัดทำเป็นโมดูล
SRS (System Requirement Specification) — ระบุฟังก์ชันงานของซอฟต์แวร์ให้บรรลุความต้องการของผู้ใช้
System Requirement ประกอบด้วย:
- System Functional — ฟังก์ชันการทำงานของระบบซอฟต์แวร์
- Operational Constraint — เงื่อนไขในการดำเนินการ
- Services — การให้บริการ
ตัวอย่างการเขียน URS–SRS
URS-01 ผู้ใช้สามารถเข้าใช้งานด้วยการลงชื่อเข้าใช้ (Login)
ตามระดับสิทธิ์การใช้งาน ได้แก่ ผู้ปฏิบัติงาน, หัวหน้า, ผู้ดูแลระบบ
SRS-01 ระบบสามารถรองรับการ login ได้ด้วย username และ password
SRS-02 ระบบสามารถตรวจสอบระดับสิทธิ์ผู้ใช้งานที่ login ได้
ดังนี้ ผู้ปฏิบัติงาน, หัวหน้า, ผู้ดูแลระบบ
URS-02 หัวหน้าสามารถดูข้อมูลในหน้าแดชบอร์ดได้
URS-03 หัวหน้าสามารถดูรายงานสรุปข้อมูลได้
4. Analysis Model และ UML
แบบจำลอง (Model) = แผนภาพที่แสดงข้อเท็จจริงหรือกิจกรรมที่เกิดขึ้นในระบบ
โดยใช้ สัญลักษณ์แทนการอธิบายด้วยตัวหนังสือ ซึ่งชัดเจน เข้าใจง่าย ไม่ซับซ้อน
แบบจำลองการวิเคราะห์ = แบบจำลองที่เขียนขึ้นจากข้อกำหนดความต้องการของระบบ
สะท้อนหน้าที่การทำงานของระบบ และจะถูกนำไปใช้ในการออกแบบต่อไป
ภาษามาตรฐานที่ใช้เขียนคือ UML (Unified Modeling Language)
Behavioral UML Diagram — 3 ตัวที่ต้องรู้
| Diagram | ใช้แสดงอะไร |
|---|---|
| Use Case Diagram | ปฏิสัมพันธ์ระหว่างระบบงานภายในและผู้ใช้งาน |
| Activity Diagram | ขั้นตอนและเงื่อนไขการทำงานของแต่ละงานของระบบ |
| Sequence Diagram | ปฏิสัมพันธ์ (Interaction) ระหว่าง Object โดยเฉพาะการส่ง Message ตามลำดับเวลา |
5. Use Case Diagram
| ความสัมพันธ์ | ความหมาย |
|---|---|
| Include / Uses | The use case is mandatory — use case ที่ถูก include ต้องเกิดขึ้นเสมอ |
| Extend | The use case is optional — scenario สมบูรณ์ได้โดยไม่ต้องมี extended use case |
6. Activity Diagram
แผนภาพการทำงานของระบบ แสดงขั้นตอนและเงื่อนไขการทำงานแต่ละงาน มี 5 รูปแบบ:
| # | รูปแบบ | ลักษณะการทำงาน |
|---|---|---|
| 1 | Sequence | ทำงานตามลำดับขั้นตอน |
| 2 | Selection | เลือกกระทำตามเงื่อนไข — จริงทำกระบวนการหนึ่ง เท็จทำอีกกระบวนการหนึ่ง |
| 3 | Iteration | ทำซ้ำ (Loop) ในขั้นตอนเดิมจนกว่าจะได้ตามเงื่อนไข |
| 4 | Do while | ตรวจสอบเงื่อนไขก่อน ถ้าจริงจึงทำ วนจนกว่าเงื่อนไขเป็นเท็จ |
| 5 | Do until | ทำก่อน 1 ครั้ง แล้วตรวจเงื่อนไข ถ้าเท็จกลับไปทำใหม่ จนกว่าเงื่อนไขจะเป็นจริง |