โมดูล 2/5 · สัปดาห์ 4–6 · 27 ชม.

ข้อกำหนดและเกณฑ์ความสำเร็จ

UAT 493 โครงงานเทคโนโลยีระบบอากาศยานไร้คนขับและระบบอัตโนมัติ 1

เวลาเรียนประมาณ 90 นาทีร่าง รอตรวจปรับปรุงล่าสุด 27 กันยายน 2569

บทเรียน

เมื่อเรียนจบโมดูลนี้ ผู้เรียนจะสามารถ

  1. แปลงความต้องการของผู้มีส่วนได้เสียเป็นข้อกำหนดของระบบที่ตรวจพิสูจน์ได้
  2. ตรวจคุณภาพข้อกำหนดตามลักษณะ C1–C9 ของ INCOSE Guide to Writing Requirements
  3. จัดลำดับความสำคัญด้วย MoSCoW และตรวจสัดส่วนแรงงานของกลุ่ม Must
  4. กำหนดวิธีพิสูจน์ของแต่ละข้อกำหนดเป็น inspection, analysis, demonstration หรือ test

ความรู้พื้นฐานที่ควรมี: UAT 493 โมดูล 1

ทำไมต้องรู้

“ระบบต้องตรวจจับรอยแตกได้ดี” ฟังดูชัด แต่เมื่อถึงวันส่งงาน ทีมกับผู้ใช้อาจเถียงกันว่า “ดี” แปลว่าอะไร ข้อกำหนดที่เขียนดีทำหน้าที่เป็นสัญญา บอกว่าต้องสร้างอะไร วัดอย่างไร และเมื่อไรถือว่าเสร็จ มาตรฐาน ISO/IEC/IEEE 29148 และคู่มือของ INCOSE ให้หลักการเขียนข้อกำหนดที่ใช้กันทั่วโลก

จากความต้องการสู่ข้อกำหนด

สี่ชั้นจากบนลงล่าง ความต้องการของผู้มีส่วนได้เสีย เช่น อยากรู้จุดชำรุดก่อนน้ำรั่ว ข้อกำหนดของระบบ เช่น ระบบ shall ระบุรอยแตกตั้งแต่ 5 cm ข้อกำหนดของระบบย่อย เช่น กล้อง shall ให้ GSD ไม่เกิน 2 cm และวิธีพิสูจน์ inspection analysis demonstration test
ภาพที่ 1 จากความต้องการสู่ข้อกำหนดและวิธีพิสูจน์

ข้อกำหนดนิยมเขียนรูปแบบ “[ระบบ] 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
แถบแนวนอนแบ่งเป็น Must 55 เปอร์เซ็นต์ Should 25 เปอร์เซ็นต์ และ Could 20 เปอร์เซ็นต์ เส้นประที่ 60 เปอร์เซ็นต์คือเพดานของ Must ด้านล่างเขียนว่า Won't have this time บันทึกไว้แต่ไม่ทำในรอบนี้
ภาพที่ 2 สัดส่วนแรงงานตาม MoSCoW ของโครงงาน

วิธีพิสูจน์ข้อกำหนด

คู่มือของ NASA ระบุวิธีพิสูจน์สี่แบบ ข้อกำหนดทุกข้อต้องเลือกวิธีตั้งแต่ตอนเขียน ถ้าคิดวิธีพิสูจน์ไม่ออก แปลว่าข้อกำหนดยังไม่ดีพอ

วิธีใช้เมื่อตัวอย่าง
Inspectionตรวจด้วยตาหรือเอกสารมีเครื่องหมายทะเบียนบนลำ
Analysisคำนวณหรือจำลองเวลาบินจากงบพลังงาน
Demonstrationสาธิตการทำงานโดยไม่วัดละเอียดผู้ใช้เปิดรายงานได้เอง
Testวัดค่าภายใต้เงื่อนไขควบคุมความแม่นยำของพิกัดเทียบจุดอ้างอิง

ปฏิบัติการประจำโมดูล

ชิ้นงานโครงงาน: เอกสารข้อกำหนด

  1. แปลงความต้องการจากโมดูล 1 เป็นข้อกำหนดของระบบ 15–25 ข้อในรูปแบบ “shall” ทุกข้อมีเกณฑ์ที่วัดได้
  2. รันโค้ดตัวอย่างที่ 1 กับข้อกำหนดของทีม แก้ข้อที่ถูกทัก แล้วให้ทีมอื่นตรวจตามลักษณะ C1–C9
  3. จัดลำดับ MoSCoW ประมาณแรงงาน และตรวจว่ากลุ่ม Must ไม่เกิน 60%
  4. กำหนดวิธีพิสูจน์ของทุกข้อ (inspection, analysis, demonstration, test)
  5. นำข้อกำหนดกลุ่ม Must ไปให้ผู้มีส่วนได้เสียยืนยัน และบันทึกการเปลี่ยนแปลง

ข้อผิดพลาดที่พบบ่อย

ระวัง

  • ใช้คำที่วัดไม่ได้ เช่น เร็ว ดี ใช้งานง่าย
  • รวมหลายเรื่องในข้อเดียว
  • เขียนวิธีแก้แทนความต้องการ เช่น ระบุรุ่นกล้องในข้อกำหนดระดับระบบ
  • ทุกข้อเป็น Must จนไม่มีส่วนเผื่อ
  • ไม่กำหนดวิธีพิสูจน์ จนถึงวันทดสอบ

สรุป

  • ข้อกำหนดแปลความต้องการเป็นประโยค “shall” ที่มีเกณฑ์วัดได้
  • ข้อกำหนดที่ดีมีลักษณะ C1–C9 ตาม INCOSE เช่น ไม่กำกวม เรื่องเดียว และตรวจพิสูจน์ได้
  • MoSCoW จัดลำดับความสำคัญ และกลุ่ม Must ไม่ควรใช้แรงงานเกิน 60%
  • ทุกข้อกำหนดต้องมีวิธีพิสูจน์: inspection, analysis, demonstration หรือ test

แบบฝึกตรวจความเข้าใจ

  1. “ระบบ shall ส่งรายงานอย่างรวดเร็ว” ผิดลักษณะใด และควรแก้อย่างไร
  2. ข้อกำหนดที่มีคำว่า “and” เชื่อมสามการกระทำ ผิดลักษณะใด
  3. งาน Must 7 คน-สัปดาห์ จากทั้งหมด 10 คน-สัปดาห์ ผ่านเกณฑ์ MoSCoW หรือไม่
  4. การตรวจว่ามีเครื่องหมายทะเบียนบนลำใช้วิธีพิสูจน์แบบใด
  5. Won’t have this time หมายความว่าอย่างไร
เฉลย
  1. กำกวม (unambiguous) และตรวจพิสูจน์ไม่ได้ ควรระบุเวลา เช่น “ภายใน 2 ชั่วโมงหลังลงจอด”
  2. ไม่เป็นเรื่องเดียว (singular) ควรแยกเป็นสามข้อ
  3. ไม่ผ่าน เพราะ 70% เกิน 60%
  4. Inspection
  5. ตกลงกันว่าไม่ทำในรอบนี้ และบันทึกไว้เพื่อให้ขอบเขตชัด

สรุปสูตรสำคัญ

สัดส่วนแรงงานของกลุ่ม Must

แหล่งอ้างอิงหลัก

  1. INCOSE Requirements Working Group. (2023). Guide to writing requirements (Version 4, INCOSE-TP-2010-006-04). INCOSE. link
  2. International Organization for Standardization. (2018). Systems and software engineering — Life cycle processes — Requirements engineering (ISO/IEC/IEEE 29148:2018). link
  3. National Aeronautics and Space Administration. (2016). NASA systems engineering handbook (NASA/SP-2016-6105 Rev 2). link
  4. Agile Business Consortium. MoSCoW prioritisation. DSDM project framework. link
  5. INCOSE. (2023). INCOSE systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley. link

อ่านเพิ่มเติม

ศึกษาหน่วยความรู้ที่กำหนดล่วงหน้า ดูสื่อประกอบ และทำ quiz ประจำโมดูล

ในชั้นเรียน / ภาคสนาม

พัฒนาโครงงานเป็นทีม ประชุมที่ปรึกษา และนำเสนอความก้าวหน้า

หลักฐานการเรียนรู้: ผลงานตามจุดตรวจของโครงงาน

แบบทดสอบประจำโมดูล

แบบทดสอบนี้ใช้ตรวจความเข้าใจ (formative) ไม่ใช่การสอบเก็บคะแนน

โดเมนความรู้: การจัดการ นวัตกรรม และวิชาชีพ · อากาศยาน โครงสร้าง และการออกแบบ