ข้อกำหนดและเกณฑ์ความสำเร็จ
UAT 493 โครงงานเทคโนโลยีระบบอากาศยานไร้คนขับและระบบอัตโนมัติ 1
บทเรียน
เมื่อเรียนจบโมดูลนี้ ผู้เรียนจะสามารถ
- แปลงความต้องการของผู้มีส่วนได้เสียเป็นข้อกำหนดของระบบที่ตรวจพิสูจน์ได้
- ตรวจคุณภาพข้อกำหนดตามลักษณะ C1–C9 ของ INCOSE Guide to Writing Requirements
- จัดลำดับความสำคัญด้วย MoSCoW และตรวจสัดส่วนแรงงานของกลุ่ม Must
- กำหนดวิธีพิสูจน์ของแต่ละข้อกำหนดเป็น inspection, analysis, demonstration หรือ test
ทำไมต้องรู้
“ระบบต้องตรวจจับรอยแตกได้ดี” ฟังดูชัด แต่เมื่อถึงวันส่งงาน ทีมกับผู้ใช้อาจเถียงกันว่า “ดี” แปลว่าอะไร ข้อกำหนดที่เขียนดีทำหน้าที่เป็นสัญญา บอกว่าต้องสร้างอะไร วัดอย่างไร และเมื่อไรถือว่าเสร็จ มาตรฐาน ISO/IEC/IEEE 29148 และคู่มือของ INCOSE ให้หลักการเขียนข้อกำหนดที่ใช้กันทั่วโลก
จากความต้องการสู่ข้อกำหนด
ข้อกำหนดนิยมเขียนรูปแบบ “[ระบบ] shall [ทำอะไร] [เงื่อนไข] [เกณฑ์ที่วัดได้]” เช่น “ระบบ shall ระบุรอยแตกของคันคลองที่กว้างตั้งแต่ 5 cm โดยมีค่า recall อย่างน้อย 0.90 บนชุดภาพทดสอบที่ผู้ใช้รับรอง”
INCOSE Guide to Writing Requirements ฉบับที่ 4 (2023) กำหนดลักษณะของข้อกำหนดแต่ละข้อไว้ 9 ข้อ คือ จำเป็น (necessary) เหมาะกับระดับ (appropriate) ไม่กำกวม (unambiguous) ครบถ้วน (complete) เรื่องเดียว (singular) เป็นไปได้ (feasible) ตรวจพิสูจน์ได้ (verifiable) ถูกต้อง (correct) และเป็นไปตามรูปแบบ (conforming) และลักษณะของชุดข้อกำหนดอีกกลุ่มหนึ่ง เช่น ครบถ้วนและไม่ขัดกัน
ตัวอย่างที่ 1 ตรวจข้อกำหนดเบื้องต้นด้วยโปรแกรม
โปรแกรมหาอาการที่พบบ่อย: คำกำกวม ไม่มีตัวเลข และหลายเรื่องในข้อเดียว (ตรวจได้เพียงบางลักษณะ ยังต้องให้คนตรวจ)
import re
VAGUE = ["user-friendly", "fast", "quickly", "adequate", "sufficient", "easy", "approximately",
"as appropriate", "etc", "and/or", "good", "robust"]
requirements = {
"R1": "The system shall detect canal bank cracks of 5 cm width or more with recall of at least 0.90.",
"R2": "The system shall be user-friendly.",
"R3": "The drone shall fly fast and take good photos.",
"R4": "The system shall complete one 2 km inspection round in at most 15 minutes of flight.",
"R5": "The system shall store images and send reports and alert the office.",
"R6": "The system shall mark each defect with coordinates accurate to within 3 m.",
}
for rid, text in requirements.items():
words = text.lower()
issues = [f"vague '{w}'" for w in VAGUE if re.search(r"\b" + re.escape(w) + r"\b", words)]
if not re.search(r"\d", text):
issues.append("no measurable value")
if words.count(" and ") >= 2 or words.count(" shall ") > 1:
issues.append("several requirements in one")
print(f"{rid}: {'ok' if not issues else '; '.join(issues)}")
R1: ok
R2: vague 'user-friendly'; no measurable value
R3: vague 'fast'; vague 'good'; no measurable value
R4: ok
R5: no measurable value; several requirements in one
R6: ok
R2 และ R3 ใช้คำที่วัดไม่ได้ R5 รวมสามเรื่องไว้ในข้อเดียว ทำให้ตรวจพิสูจน์แยกไม่ได้ ควรแยกเป็นสามข้อ ส่วน R1, R4 และ R6 ผ่านการตรวจเบื้องต้น แต่ยังต้องถามต่อว่าจำเป็นจริงไหมและเป็นไปได้ไหม ซึ่งโปรแกรมตอบแทนไม่ได้
จัดลำดับด้วย MoSCoW
โครงงานมีเวลาจำกัด ต้องรู้ว่าอะไรต้องมี อะไรตัดได้ MoSCoW ของ Agile Business Consortium แบ่งเป็น
- Must have ชุดขั้นต่ำที่ต้องส่งมอบ ถ้าขาดถือว่าล้มเหลว
- Should have สำคัญ แต่ถ้าขาดระบบยังใช้งานได้
- Could have อยากได้ เป็นส่วนเผื่อเมื่อเวลาไม่พอ
- Won’t have this time ตกลงว่าไม่ทำในรอบนี้ และบันทึกไว้ให้ชัด
คำแนะนำคือแรงงานของกลุ่ม Must ไม่ควรเกิน 60% ถ้าเกินจะเสี่ยงล้มเหลว เพราะไม่มีส่วนเผื่อเมื่อเกิดปัญหา
ตัวอย่างที่ 2 ตรวจสัดส่วน MoSCoW
effort = { # ข้อกำหนด: (ลำดับ, แรงงานประมาณ คน-สัปดาห์)
"R1 crack detection": ("Must", 6), "R4 round time": ("Must", 3), "R6 coordinates": ("Must", 2),
"R5a store images": ("Should", 2), "R5b send report": ("Should", 3),
"R5c alert office": ("Could", 2), "R7 night flight": ("Won't", 0), "R8 web dashboard": ("Could", 2),
}
total = sum(e for _, e in effort.values())
for group in ("Must", "Should", "Could"):
share = sum(e for g, e in effort.values() if g == group) / total
print(f"{group:<6} {share:.0%}")
must = sum(e for g, e in effort.values() if g == "Must") / total
print("Must share OK" if must <= 0.60 else "Must share too high: move items or cut scope")
Must 55%
Should 25%
Could 20%
Must share OK
วิธีพิสูจน์ข้อกำหนด
คู่มือของ NASA ระบุวิธีพิสูจน์สี่แบบ ข้อกำหนดทุกข้อต้องเลือกวิธีตั้งแต่ตอนเขียน ถ้าคิดวิธีพิสูจน์ไม่ออก แปลว่าข้อกำหนดยังไม่ดีพอ
| วิธี | ใช้เมื่อ | ตัวอย่าง |
|---|---|---|
| Inspection | ตรวจด้วยตาหรือเอกสาร | มีเครื่องหมายทะเบียนบนลำ |
| Analysis | คำนวณหรือจำลอง | เวลาบินจากงบพลังงาน |
| Demonstration | สาธิตการทำงานโดยไม่วัดละเอียด | ผู้ใช้เปิดรายงานได้เอง |
| Test | วัดค่าภายใต้เงื่อนไขควบคุม | ความแม่นยำของพิกัดเทียบจุดอ้างอิง |
ปฏิบัติการประจำโมดูล
ชิ้นงานโครงงาน: เอกสารข้อกำหนด
- แปลงความต้องการจากโมดูล 1 เป็นข้อกำหนดของระบบ 15–25 ข้อในรูปแบบ “shall” ทุกข้อมีเกณฑ์ที่วัดได้
- รันโค้ดตัวอย่างที่ 1 กับข้อกำหนดของทีม แก้ข้อที่ถูกทัก แล้วให้ทีมอื่นตรวจตามลักษณะ C1–C9
- จัดลำดับ MoSCoW ประมาณแรงงาน และตรวจว่ากลุ่ม Must ไม่เกิน 60%
- กำหนดวิธีพิสูจน์ของทุกข้อ (inspection, analysis, demonstration, test)
- นำข้อกำหนดกลุ่ม Must ไปให้ผู้มีส่วนได้เสียยืนยัน และบันทึกการเปลี่ยนแปลง
ข้อผิดพลาดที่พบบ่อย
ระวัง
- ใช้คำที่วัดไม่ได้ เช่น เร็ว ดี ใช้งานง่าย
- รวมหลายเรื่องในข้อเดียว
- เขียนวิธีแก้แทนความต้องการ เช่น ระบุรุ่นกล้องในข้อกำหนดระดับระบบ
- ทุกข้อเป็น Must จนไม่มีส่วนเผื่อ
- ไม่กำหนดวิธีพิสูจน์ จนถึงวันทดสอบ
สรุป
- ข้อกำหนดแปลความต้องการเป็นประโยค “shall” ที่มีเกณฑ์วัดได้
- ข้อกำหนดที่ดีมีลักษณะ C1–C9 ตาม INCOSE เช่น ไม่กำกวม เรื่องเดียว และตรวจพิสูจน์ได้
- MoSCoW จัดลำดับความสำคัญ และกลุ่ม Must ไม่ควรใช้แรงงานเกิน 60%
- ทุกข้อกำหนดต้องมีวิธีพิสูจน์: inspection, analysis, demonstration หรือ test
แบบฝึกตรวจความเข้าใจ
- “ระบบ shall ส่งรายงานอย่างรวดเร็ว” ผิดลักษณะใด และควรแก้อย่างไร
- ข้อกำหนดที่มีคำว่า “and” เชื่อมสามการกระทำ ผิดลักษณะใด
- งาน Must 7 คน-สัปดาห์ จากทั้งหมด 10 คน-สัปดาห์ ผ่านเกณฑ์ MoSCoW หรือไม่
- การตรวจว่ามีเครื่องหมายทะเบียนบนลำใช้วิธีพิสูจน์แบบใด
- Won’t have this time หมายความว่าอย่างไร
เฉลย
- กำกวม (unambiguous) และตรวจพิสูจน์ไม่ได้ ควรระบุเวลา เช่น “ภายใน 2 ชั่วโมงหลังลงจอด”
- ไม่เป็นเรื่องเดียว (singular) ควรแยกเป็นสามข้อ
- ไม่ผ่าน เพราะ 70% เกิน 60%
- Inspection
- ตกลงกันว่าไม่ทำในรอบนี้ และบันทึกไว้เพื่อให้ขอบเขตชัด
สรุปสูตรสำคัญ
| สัดส่วนแรงงานของกลุ่ม Must |
แหล่งอ้างอิงหลัก
- INCOSE Requirements Working Group. (2023). Guide to writing requirements (Version 4, INCOSE-TP-2010-006-04). INCOSE. link
- International Organization for Standardization. (2018). Systems and software engineering — Life cycle processes — Requirements engineering (ISO/IEC/IEEE 29148:2018). link
- National Aeronautics and Space Administration. (2016). NASA systems engineering handbook (NASA/SP-2016-6105 Rev 2). link
- Agile Business Consortium. MoSCoW prioritisation. DSDM project framework. link
- INCOSE. (2023). INCOSE systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley. link
อ่านเพิ่มเติม
ศึกษาหน่วยความรู้ที่กำหนดล่วงหน้า ดูสื่อประกอบ และทำ quiz ประจำโมดูล
ในชั้นเรียน / ภาคสนาม
พัฒนาโครงงานเป็นทีม ประชุมที่ปรึกษา และนำเสนอความก้าวหน้า
หลักฐานการเรียนรู้: ผลงานตามจุดตรวจของโครงงาน