Unit 3 — Requirements in Software Project
1. Need vs Requirement
Requirement (ความต้องการ) = สิ่งที่ต้องทำให้สำเร็จ เพื่อบรรลุ Need หรือ Goal
ตัวอย่างคลาสสิกจากสไลด์
- "ความอยากดื่มน้ำ" → นี่คือ Need (ความต้องการพื้นฐาน/เป้าหมาย)
- "ความอยากหาซื้อน้ำมาดื่มเพื่อดับกระหาย" → นี่คือ Requirement (สิ่งที่ต้องทำให้สำเร็จเพื่อบรรลุ Need)
Need → Requirement → Specification
2. ประเภทของ System Requirement (3 ก้อนหลัก)
| ประเภท | ความหมาย | ตัวอย่าง |
|---|---|---|
| 1. Functional Requirement | หน้าที่หลัก สิ่งที่ระบบ Should Do ฟังก์ชันที่ผู้ใช้เรียกใช้ได้โดยตรง | ผู้ใช้ Login ด้วย Username และ Password ได้ / ระบบออกรายงานเป็น .pdf .docx .xlsx ได้ |
| 2. Non-Functional Requirement (Quality of Software: QoS) |
ไม่เกี่ยวข้องโดยตรงกับหน้าที่หลัก แต่สนใจว่าระบบต้องมี คุณภาพ ด้านใด | ระบบตอบสนองภายใน 2 วินาที / รองรับ 10,000 transactions ต่อชั่วโมง / รองรับ 3 ภาษา |
| 3. Domain Requirement | เกี่ยวข้องกับงานหลักของ ระบบธุรกิจ ที่ต้องการซอฟต์แวร์มาสนับสนุนโดยเฉพาะ อาจเป็นเงื่อนไขของฟังก์ชัน หรือเงื่อนไขที่ใช้คำนวณผลลัพธ์ | กติกาการคิดค่าโดยสารของแอปเรียกรถ / เงื่อนไขคิดค่าธรรมเนียมของธนาคาร |
คุณสมบัติที่อยู่ใต้ Non-Functional Requirement
- Speed — ความเร็ว
- Security — ความปลอดภัย
- Portability — ย้ายไปใช้ที่อื่นได้
- Compatibility — ทำงานร่วมกับสิ่งอื่นได้
- Capacity เช่น storage
- Reliability เช่น จำนวน/เปอร์เซ็นต์ของ failures, time between failures
- Environment เช่น running schedules, weather conditions
- Localization เช่น languages, currencies, time zones
3. Business / Functional / Non-Functional
| ระดับ | คำอธิบาย |
|---|---|
| 01 Business Requirement | ความต้องการเชิงธุรกิจ กำหนดโดย stakeholder เป็นความต้องการ ระดับแรก เมื่อเริ่มโครงการ มักมีจำนวนไม่มาก อยู่ในระดับ "problem space" |
| 02 Functional Requirement | ฟังก์ชันที่ผู้ใช้เรียกใช้ได้ สนับสนุนการทำงานของผู้ใช้โดยตรง |
| 03 Non-Functional Requirement | Quality Attributes — ระบบต้องมีคุณภาพด้านใด |
ตัวอย่าง Business Requirement
- Time to Market — พัฒนาเสร็จเร็วทันขาย
- Low Cost — ต้นทุนต่ำ อยู่ในงบ
- Support a Variety of Customer Behavior
- Highly Customizable
- Increase Net Profit — เพิ่มกำไรสุทธิ 10%
- Reduce Paper Work / High Competitiveness / Build Awareness
4. Requirement Type Encoding
| Requirement Type | Encoding | คำอธิบาย |
|---|---|---|
| Functional Requirement | F | หน้าที่การทำงาน/ฟังก์ชันที่มีปฏิสัมพันธ์กับผู้ใช้ |
| Data Requirement | D | ด้านข้อมูล |
| Behavior Requirement | B | ด้านพฤติกรรมหรือการตอบสนองของระบบ |
| Interface Requirement | I | การติดต่อ/เชื่อมต่อกับระบบอื่น รวมถึงส่วนติดต่อผู้ใช้ |
| Output Requirement | P | ด้านผลลัพธ์ที่ได้จากระบบ |
ระวังข้อสอบ: Output Requirement ใช้รหัส P ไม่ใช่ O
5. Requirement Engineering
วิศวกรรมความต้องการ คือกระบวนการที่ทำให้เข้าใจและเข้าถึงความต้องการของลูกค้าได้อย่างแท้จริง ด้วยการ สกัด ตรวจสอบ และนิยาม ความต้องการ เพื่อสร้างเป็นข้อกำหนดความต้องการด้านระบบหรือซอฟต์แวร์ สำหรับการพัฒนาระบบในขั้นตอนถัดไป [Jawadekar, 2004]
Requirement Engineering Process — 7 กระบวนการ
RE Process 7 ขั้น
| # | ขั้น | รายละเอียด |
|---|---|---|
| 1 | Inception การเริ่มต้นวิเคราะห์ | วิศวกรซอฟต์แวร์ ตั้งคำถามเปิด เพื่อเข้าใจพื้นฐานของปัญหาและแนวทางแก้ สร้างการสื่อสารและความร่วมมือระหว่างลูกค้ากับผู้พัฒนา |
| 2 | Elicitation การสกัดความต้องการ | สอบถามลูกค้า/ผู้ใช้ว่าต้องการอะไร เป้าหมายของระบบคืออะไร ปัญหาที่พบ: การหาขอบเขตของปัญหา, การทำความเข้าใจปัญหา, ความไม่แน่นอน |
| 3 | Elaboration การขยายรายละเอียด | นำสารสนเทศจากลูกค้ามาขยายและแจกแจง พัฒนาแบบจำลองทางเทคนิค แบ่งกลุ่มความต้องการ และสร้างแบบจำลองแนวคิด |
| 4 | Negotiation การเจรจาต่อรอง | กรณีลูกค้าต่อรองเกินกว่าที่ระบบจะทำได้ ต้องประสานความขัดแย้งและปรับเปลี่ยนความต้องการให้ทุกฝ่ายยอมรับได้ |
| 5 | Specification การจัดทำข้อกำหนด | จัดทำเอกสารรวบรวมข้อกำหนด ระบุคุณลักษณะหรือความสามารถของซอฟต์แวร์ |
| 6 | Validation การตรวจรับ | ทบทวนข้อกำหนดเพื่อให้มั่นใจว่าทุกความต้องการถูกระบุ ครบถ้วนและไม่คลุมเครือ โดยวิศวกรซอฟต์แวร์ ลูกค้า และ stakeholders |
| 7 | Requirement Management | ความต้องการของระบบมักเปลี่ยนไปตลอดช่วงชีวิตของระบบ จึงต้องจัดการความต้องการอย่างต่อเนื่อง |
6. Requirement Elicitation
การสกัดความต้องการถือเป็น ทักษะหลักของวิศวกรรมความต้องการ เป็นกระบวนการที่ได้มาซึ่งข้อมูลที่จำเป็นของโครงการจากผู้มีส่วนได้ส่วนเสีย ทำให้ทราบภาพรวมและขอบเขตของซอฟต์แวร์ก่อนเริ่มพัฒนา
4 Process of Requirement Elicitation
- Gathering — ติดต่อ/ทำกิจกรรมร่วมกับผู้มีส่วนได้ส่วนเสียเพื่อให้ได้ความต้องการ ด้วยเทคนิคสกัดต่างๆ
- Organizing — จัดโครงสร้างโดยรวมของซอฟต์แวร์ โดยจัดกลุ่มความต้องการที่เกี่ยวข้องกัน แบ่งเป็นระบบย่อยและระบุความสัมพันธ์
- Prioritizing — จัดลำดับความสำคัญและความจำเป็น บางความต้องการอาจถูกตัดออก ต้องเจรจาต่อรองเมื่อเกิดความขัดแย้ง
- Documenting — จัดทำเอกสาร ได้แก่ URS (User Requirement Specification) และ SRS (System Requirement Specification)
เทคนิคการสกัดความต้องการ (Elicitation Techniques)
Interview
สัมภาษณ์ผู้ใช้/ผู้มีส่วนได้ส่วนเสียรายบุคคล ได้ข้อมูลเชิงลึก
Focus Group
ประชุมกลุ่มตัวแทนผู้ใช้ ได้มุมมองหลากหลายในเวลาเดียว
Brainstorm
ระดมสมองหาไอเดียใหม่ ไม่ตัดสินระหว่างระดม
Survey and Questionnaire
เก็บจากผู้ใช้จำนวนมาก เหมาะเมื่อผู้ใช้กระจายตัว
Documentation Analysis
วิเคราะห์เอกสาร/กระบวนการเดิมขององค์กร
Interface Analysis
วิเคราะห์การเชื่อมต่อกับระบบอื่นที่มีอยู่
User Interface Analysis
วิเคราะห์หน้าจอ/การใช้งานของระบบเดิม
Prototyping
สร้างต้นแบบให้ลูกค้าเห็นภาพแล้วเก็บ feedback
Requirements Workshop
จัด workshop รวมผู้เกี่ยวข้องมาสรุปความต้องการร่วมกัน
7. User Requirement vs System Requirement
| ประเด็น | User Requirement | System Requirement |
|---|---|---|
| คำถามหลัก | ผู้ใช้ทำอะไรได้บ้าง? (Actor/User performs the task) | ระบบ/ซอฟต์แวร์ทำอะไรได้บ้าง? (System performs the task) |
| ระดับ | ความคาดหวังจากระบบ ระดับสูงสุด | การทำงาน ฟังก์ชัน บริการ ระดับรายละเอียด → Functional Specification |
| เขียนเพื่อใคร | Written for Customers | Written for Developers |
| ภาษา | ภาษาธรรมชาติ ไม่มีรายละเอียดทางเทคนิค | ระบุ functional & non-functional อย่างชัดเจนและเข้มงวดกว่า |
ตัวอย่างตู้กดน้ำเต่าบิน
User Requirement: ผู้ใช้สามารถเรียกดูรายการเมนูเครื่องดื่มได้System Requirement 1: ระบบสามารถแสดงกลุ่มหรือประเภทเครื่องดื่มทั้งหมดให้ผู้ใช้ผ่านทางหน้าจอได้
System Requirement 2: ระบบสามารถแสดงรายการเครื่องดื่มในแต่ละกลุ่มหรือประเภทให้ผู้ใช้ดูผ่านทางหน้าจอได้
8. Work Product จากการเก็บความต้องการ
กลุ่มของ Work Product ที่ได้จากขั้นตอนการเก็บความต้องการ แล้วนำไปวิเคราะห์ต่อ:
- User Requirement
- Business Work Flow
- Problem Statement
- Business Information & Rules
คำถามที่ต้องได้คำตอบระหว่างสัมภาษณ์: ใครอยู่เบื้องหลังความต้องการ, ใครที่ใช้, ประโยชน์ทางเศรษฐกิจ/แก่ธุรกิจ, ข้อมูลอื่นๆ ที่จำเป็น
บทบาทของนักวิเคราะห์ระบบ: เป็น คนกลาง ที่ปรึกษา ผู้ช่วยแก้ปัญหา และผู้ต่อรอง
ระหว่างลูกค้ากับทีมพัฒนา