kittissk pannutiyarak
Kittisak Pannutiyarak
Kittisak Pannutiyarak is the founder of HaNonn and the designer of Intent-to-Income™, a Reference Decision Architecture for AI-first Decision Intelligence.
13 Min Read
Decision Intelligence Requirements
ภาพสรุปการเปลี่ยนจาก Decision Need สู่ข้อกำหนดที่ตรวจสอบได้ เพื่อออกแบบระบบสนับสนุนการตัดสินใจและเลือกใช้ Rules หรือ AI ให้เหมาะสม

Decision Intelligence Requirements คืออะไร: จาก Decision Need สู่ข้อกำหนดระบบที่ตรวจสอบได้

Decision Need · Requirements · Traceability · Verification

Decision Intelligence Requirements ในบทความนี้หมายถึงการประยุกต์หลัก Requirements Engineering เพื่อกำหนดว่า ระบบที่เกี่ยวข้องกับการตัดสินใจต้องตอบ Decision Need ใด ใช้หลักฐานและเงื่อนไขอะไร มีข้อจำกัดอย่างไร และจะตรวจสอบได้อย่างไรว่าระบบทำงานตามข้อกำหนด


Q.

THE DESIGN QUESTION
ก่อนพัฒนาระบบ AI เราระบุได้หรือยังว่าผู้ใช้ต้องตัดสินใจอะไร ระบบต้องสนับสนุนสิ่งใด และจะตรวจสอบได้อย่างไรว่าระบบทำได้ตามข้อกำหนด?

ตัวอย่าง: ร้านค้าต้องการระบบช่วยลูกค้าพิจารณาโปรโมชันที่สามารถใช้ได้

FEATURE REQUEST
“ใช้ AI แนะนำโปรโมชันที่ดีที่สุดให้ลูกค้า”

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

🔍 VERIFICATION
ทดสอบกรณีลูกค้าไม่ผ่านเงื่อนไขหรือโปรโมชันหมดอายุ แล้วตรวจว่าระบบไม่แสดงรายการดังกล่าวเป็นสิทธิ์ที่ใช้งานได้

REQUIREMENTS SPECIFICATION

จาก Decision Need สู่ Requirements Specification

เมื่อทราบโจทย์การตัดสินใจแล้ว ให้กำหนดพฤติกรรมระบบ เงื่อนไข และหลักฐานที่ใช้ตรวจสอบ เพื่อให้ทีมออกแบบ พัฒนา และทดสอบเข้าใจข้อกำหนดตรงกัน

REQUIREMENTS TRACEABILITY VIEW

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

01

Decision Need

ลูกค้าต้องการทราบว่าโปรโมชันใดสามารถใช้ได้ตามสิทธิ์และเงื่อนไขของตน
DEC-01: ระบุโจทย์และผู้ตัดสินใจ

02

Evidence

ต้องใช้เงื่อนไขโปรโมชัน วันที่มีผล สิทธิ์สมาชิก และสถานะความครบถ้วนของข้อมูล
EVD-01 / EVD-02: แหล่งข้อมูลและข้อจำกัด

03

Requirements

กำหนดให้ระบบแสดงตัวเลือกที่ผ่านเงื่อนไข และไม่สรุปสิทธิ์เมื่อข้อมูลยังไม่เพียงพอ
REQ-01–03: พฤติกรรมที่ระบบต้องรองรับ

04

Verification

ตรวจการแสดงผลในกรณีสิทธิ์ไม่ผ่าน โปรโมชันหมดอายุ และข้อมูลสมาชิกไม่ครบ
AC / TC: Acceptance Criteria และ Test Cases
Illustrative Design View — EVD-01/02 คือข้อมูลที่ใช้ตรวจสิทธิ์ ไม่ใช่หลักฐานยืนยัน Decision Need ซึ่งในตัวอย่างนี้ยังเป็นสมมติฐาน

REQUIREMENTS & ACCEPTANCE CRITERIA
ตัวอย่างการใช้ Requirement ID เชื่อมข้อกำหนดเข้ากับ Acceptance Criteria และ Test Case

REQ-01
ระบบต้องแสดงโปรโมชันที่ผ่านเงื่อนไข ตามข้อมูลที่ตรวจแล้ว
↳ Criteria: ไม่แสดงโปรโมชันที่หมดอายุ หรือไม่ผ่านเงื่อนไขเป็นตัวเลือกที่ใช้ได้
🔍 TC-01: ทดสอบกรณีสิทธิ์ไม่ผ่านและหมดอายุ

REQ-02
แสดงเงื่อนไข แหล่งข้อมูลโปรโมชัน และเวลาอัปเดตข้อมูล
↳ Criteria: ข้อมูลตรงกับแหล่งอ้างอิง และระบุสถานะชัดเจนเมื่อข้อมูลไม่พร้อม
🔍 TC-02: ตรวจข้อมูลเทียบกับแหล่งข้อมูลต้นทาง

REQ-03
แยกสถานะที่ “ยังไม่ยืนยันสิทธิ์” ออกจาก “ผ่านเงื่อนไขแล้ว”
↳ Criteria: หากข้อมูลสมาชิกไม่ครบ ระบบต้องไม่แสดงว่าลูกค้ามีสิทธิ์ใช้โปรโมชัน
🔍 TC-03: ทดสอบกรณีข้อมูลสมาชิกไม่ครบ


เพิ่มเติมReference IDs & Quality Check

QUALITY CHECK:

01 Traceable โยงกลับโจทย์ได้
02 Clear เข้าใจตรงกัน
03 Verifiable วัดผลได้จริง
04 Feasible ทำได้จริง

REF IDs:

DEC=Decision Need •
EVD=Evidence •
REQ=Requirements •
AC=Acceptance Criteria •
TC=Test Case

TRACEABILITY & CHANGE IMPACT

Requirements Traceability: ติดตามผลกระทบ เมื่อหลักฐานเปลี่ยน

การกำหนด Requirements และ Test Cases เป็นเพียงจุดเริ่มต้น เพราะข้อมูลและเงื่อนไขที่ใช้ประกอบการตัดสินใจอาจเปลี่ยนได้ Requirements Traceability ช่วยให้ทีมตรวจสอบย้อนกลับได้ว่าข้อกำหนดหนึ่งเชื่อมกับโจทย์และแหล่งข้อมูลใด รวมถึงต้องตรวจส่วนไหนเมื่อเกิดการเปลี่ยนแปลง

BIDIRECTIONAL TRACEABILITY

เมื่อข้อมูลต้นทางเปลี่ยน ต้องตรวจอะไรบ้าง และเมื่อระบบทดสอบไม่ผ่าน ต้องย้อนกลับไปตรวจที่ใด

01

Source → Impact
เมื่อข้อมูลหรือเงื่อนไขเปลี่ยน
เมื่อโปรโมชันหมดอายุ ตรวจ Requirements และ Test Cases รองรับสถานะนี้ถูกต้องหรือไม่
TRACE PATH
EVD-01 — ข้อมูลโปรโมชัน
↓
REQ-01 / REQ-02
↓
TC-01 / TC-02
คำถาม:
มีข้อกำหนดหรือการทดสอบใดได้รับผลกระทบบ้าง?

02

Test → Source
เมื่อการทดสอบพบข้อผิดพลาด
เมื่อระบบยืนยันสิทธิ์ทั้งที่ข้อมูลไม่ครบ ต้องตรวจ Requirements และ Evidence
TRACE PATH
TC-03 — ผลทดสอบไม่ผ่าน
↓
REQ-03
↓
EVD-02 — ข้อมูลสิทธิ์สมาชิก
คำถาม:
เกิดจากข้อมูล ข้อกำหนด หรือการทำงานของระบบ?

CHANGE IMPACT RECORD
เหตุการณ์ Evidence ผลกระทบ สิ่งที่ต้องดำเนินการ
โปรโมชันหมดอายุ EVD-01 REQ-01 / REQ-02 อัปเดตสถานะ และทดสอบ TC-01 / TC-02 ซ้ำ
ข้อมูลสมาชิกไม่ครบ EVD-02 REQ-03 แสดงสถานะยังไม่ยืนยันสิทธิ์ และตรวจ TC-03
ยอดซื้อขั้นต่ำเปลี่ยน EVD-01 REQ-01, Acceptance Criteria ตรวจ Eligibility Logic และปรับ Test Cases

CHANGE REVIEW : BEFORE ACCEPTING

01 What Changed?
ข้อมูล/เงื่อนไขใดเปลี่ยน? แหล่งที่มาคืออะไร ตรวจล่าสุดเมื่อใด?

02 What Is Affected?
REQ, AC, Design หรือ TC ใดบ้างที่ต้องถูกตรวจหรือปรับแก้?

03 What Was Verified?
ตรวจส่วนที่กระทบหรือยัง? ผลเป็นอย่างไร มีประเด็นค้างไหม?

SOLUTION SELECTION & DESIGN CONSTRAINTS

จาก Requirements สู่ Solution ที่เหมาะสม

เมื่อกำหนด Requirements แล้ว ต้องพิจารณาว่า แต่ละข้อกำหนดควรใช้กลไกใด และมีข้อจำกัดอะไรที่ระบบต้องรักษา โดยเปรียบเทียบทางเลือกก่อนตัดสินใจใช้ Rules, Analytics หรือ AI

REQUIREMENTS-TO-SOLUTION MATRIX
Requirement Solution Design Constraint Verification
REQ-01 Business Rules + Data Lookup ยืนยันสิทธิ์จากข้อมูลที่ตรวจสอบได้ TC-01: สิทธิ์ไม่ผ่าน/โปรโมชันหมดอายุ
REQ-02 Data Retrieval + Interface ข้อมูลตรงต้นทาง พร้อมเวลาอัปเดตและสถานะเมื่อข้อมูลไม่พร้อม TC-02: เทียบข้อมูลต้นทาง
REQ-03 State Logic ข้อมูลไม่ครบ ต้องไม่ยืนยัน TC-03: ข้อมูลสมาชิกไม่ครบ

DESIGN ALTERNATIVES

จาก Requirements ชุดเดียวกัน ทีมอาจมีหลายทางเลือก แต่ไม่จำเป็นต้องเพิ่ม AI หากกลไกที่ง่ายกว่าสามารถตอบโจทย์และตรวจสอบได้

SELECTED
Business Rules + Data
ใช้ตรวจสิทธิ์ตามเงื่อนไขโปรโมชันและข้อมูลสมาชิกที่ยืนยันได้
เหตุผล:
เงื่อนไขชัดเจนและตรวจผลได้โดยตรง

NOT REQUIRED
Predictive AI
ยังไม่มี Requirement ให้คาดการณ์พฤติกรรมหรือผลลัพธ์ของลูกค้า
เหตุผล:
การยืนยันสิทธิ์ไม่ใช่โจทย์ Prediction

CONDITIONAL
Generative AI
อาจใช้ช่วยอธิบายเงื่อนไข หากมี Requirement เพิ่มเติมและวิธีตรวจความถูกต้องของคำอธิบาย
ข้อจำกัด:
ไม่ให้ AI เปลี่ยนผลการตรวจสิทธิ์


เพิ่มเติมDesign Decision Record
Selected Solution:
Business Rules และ Data Lookup สำหรับตรวจสิทธิ์ พร้อม Interface ที่แสดงเงื่อนไขและสถานะข้อมูล
Critical Constraint:
ระบบต้องไม่ยืนยันสิทธิ์จากข้อมูลที่ยังไม่ครบหรือไม่ผ่านเงื่อนไข
Reconsider When:
มี Requirement ใหม่ที่จำเป็นต้องใช้การคาดการณ์หรือคำอธิบายภาษาธรรมชาติ และมีวิธีประเมินความเหมาะสมของ Capability นั้น

RESPONSIBILITY & EXCEPTION HANDLING

Operational Responsibility: ผู้รับผิดชอบเมื่อระบบพบข้อยกเว้น

Requirements ต้องระบุทั้งพฤติกรรมของระบบ ผู้รับผิดชอบ และวิธีจัดการเมื่อข้อมูลไม่เพียงพอ

OPERATIONAL RESPONSIBILITY MAP

Business Owner
กำหนดเงื่อนไขและอนุมัติเปลี่ยนกฎโปรโมชัน
Authority: Promotion Policy

Rules & Data
ตรวจสิทธิ์ตามเงื่อนไข และแสดงสถานะหากข้อมูลไม่ครบ
Responsibility: Eligibility Verification

Customer
ตรวจเงื่อนไข เปรียบเทียบโปรโมชัน และเลือกว่าจะใช้สิทธิ์ใด
Authority: Final Selection

EXCEPTION RESPONSE

UNVERIFIED
ไม่ยืนยันสิทธิ์ → ลูกค้าให้ข้อมูลเพิ่ม

DATA CONFLICT
ระงับการยืนยัน → ผู้รับผิดชอบตรวจสอบ
VERIFICATION & EVIDENCE

Requirements Verification: จาก Test Case สู่หลักฐานการตรวจสอบ

Test Case ระบุสิ่งที่ต้องตรวจ แต่ยังไม่ยืนยันว่าระบบทำได้จริง
Verification ต้องเปรียบเทียบผลที่คาดหวังกับผลที่เกิดขึ้น และบันทึกหลักฐานที่ตรวจสอบย้อนกลับได้

TEST EXECUTION RECORD

ตัวอย่างสมมติ TC-03: ตรวจสิทธิ์เมื่อข้อมูลสมาชิกไม่ครบ

Run 01 · ก่อนแก้ไข
FAIL

EXPECTED

ไม่ยืนยันสิทธิ์ (Unverified)

OBSERVED

ระบบแสดงสถานะ Eligible

Issue: ระบบยืนยันสิทธิ์ทั้งที่ข้อมูลไม่ครบ

Run 02 · ทดสอบซ้ำ
PASS

EXPECTED

ไม่ยืนยันสิทธิ์ (Unverified)

OBSERVED

ระบบแสดงสถานะ Unverified

Resolution: แก้ State Logic และทดสอบผ่าน

EVIDENCE TO RECORD
INPUT
ชุดข้อมูลทดสอบ
VERSION
รุ่นระบบ / กฎ
EVIDENCE
Log / ภาพผลทดสอบ
EXECUTION
ผู้ทดสอบ / เวลา / Issue


PRACTICAL APPLICATION & HANDOFF

Requirements Handoff Kit: จาก Decision Need สู่ข้อกำหนดที่นำไปพัฒนาต่อได้

เครื่องมือนี้จัดทำ Requirement Brief ที่เชื่อม Decision Need, Evidence, พฤติกรรมระบบ และวิธีตรวจสอบ เพื่อส่งต่อให้ Business Analyst, Developer และ QA พิจารณาและพัฒนาต่อ

HOW TO USE

Copy Brief
→Adapt & Specify
→Review & Handoff


TemplateRequirement Brief — แม่แบบพร้อมคัดลอก

คัดลอกแม่แบบไปใช้ในเอกสารหรือระบบจัดการงาน โดยกรอกหนึ่งชุดต่อหนึ่ง Requirement และเชื่อม ID กับรายการที่เกี่ยวข้อง

# DECISION-CENTERED REQUIREMENT BRIEF

PROJECT: [ชื่อโครงการ]
REQUIREMENT ID: REQ-[...]
DRAFT VERSION: [เวอร์ชัน / วันที่]
OWNER: [ผู้รับผิดชอบข้อกำหนด]

A. DECISION & CONTEXT
Customer Decision:
[ผู้ใช้กำลังตัดสินใจเรื่องอะไร]

Decision Context:
[สถานการณ์ เงื่อนไข และข้อจำกัด]

Need Basis:
[Signals / Research / Stakeholder Evidence / Source]
Need Status:
[SUPPORTED / WORKING HYPOTHESIS]

Decision Need:
[ผู้ใช้ยังต้องการอะไรเพื่อให้ตัดสินใจได้]

B. DECISION SUPPORT REQUIREMENT
System Shall:
[หนึ่งพฤติกรรมที่ชัดเจนและตรวจสอบได้]

Intended Support:
[ระบบช่วยเรื่อง Evidence / Criteria /
Comparison / Clarification / Next Step อย่างไร]

C. DATA & CONSTRAINTS
Operational Source:
[Source of Truth / EVD-ID / Version]

Required Inputs:
[ข้อมูลที่ต้องใช้]

Expected Output:
[ผลลัพธ์หรือสถานะที่ต้องแสดง]

Exceptions:
[ข้อมูลขาด / ขัดแย้ง / แหล่งข้อมูลใช้ไม่ได้]

Constraints:
[ข้อจำกัดทางธุรกิจ ระบบ ความปลอดภัย
หรือประสิทธิภาพที่เกี่ยวข้อง]

D. ACCEPTANCE & TEST
Acceptance Criteria:
Given [เงื่อนไขตั้งต้น]
When [เหตุการณ์]
Then [ผลลัพธ์ที่สังเกตและตรวจได้]

Test Reference:
[TC-ID / Test Method / Test Data]

E. RESPONSIBILITY & REVIEW
Data Owner: [...]
Requirement Owner: [...]
Approval Authority: [...]
Open Items: [Issue / Owner / Due Date]

F. EVALUATION LINK
Post-Implementation Evaluation:
[สิ่งที่จะตรวจว่าระบบช่วยการตัดสินใจ
ได้เหมาะสมหรือไม่ / หรือ NOT IN SCOPE]

G. HANDOFF
Review Result: [READY / REVISE / HOLD]
Reviewer: [...]
Review Date: [...]
Approved Baseline: [หลังอนุมัติเท่านั้น]
Change Reference: [ถ้ามี]
ใช้ DRAFT VERSION ระหว่างจัดทำ และกำหนด Approved Baseline เมื่อผู้มีอำนาจอนุมัติแล้วเท่านั้น ส่วน Need Status ระบุสถานะของหลักฐาน ไม่ใช่ความพร้อมของระบบ


ExampleWorked Example — REQ-03: ข้อมูลสมาชิกไม่ครบ

ตัวอย่างสมมติที่เชื่อมกับระบบตรวจสิทธิ์โปรโมชันในบทความ โดยแยก Customer Decision ออกจาก Decision Need และ Requirement

# EXAMPLE REQUIREMENT BRIEF

PROJECT: Promotion Eligibility (Illustration)
REQUIREMENT ID: REQ-03
DRAFT VERSION: v0.1
OWNER: To Be Assigned

A. DECISION & CONTEXT
Customer Decision:
เลือกโปรโมชันที่สามารถใช้ได้

Decision Context:
สิทธิ์สมาชิกและเงื่อนไขโปรโมชัน

Need Basis:
ยังไม่มีหลักฐานการศึกษาผู้ใช้ในตัวอย่างนี้

Need Status:
WORKING HYPOTHESIS

Decision Need:
ต้องทราบสิทธิ์ เงื่อนไข และข้อจำกัด
ก่อนตัดสินใจเลือกโปรโมชัน

B. DECISION SUPPORT REQUIREMENT
System Shall:
เมื่อข้อมูลระดับสมาชิกที่จำเป็นไม่ครบ
ระบบต้องแสดงสถานะ UNVERIFIED
แทนการยืนยันสิทธิ์

Intended Support:
สื่อสารความไม่แน่นอนและข้อมูลที่ขาด

C. DATA & CONSTRAINTS
Operational Source:
EVD-02 — ข้อมูลสิทธิ์สมาชิก
Source of Truth: ต้องยืนยันกับทีมข้อมูล

Required Input:
membership_tier

Expected Output:
UNVERIFIED และระบุข้อมูลที่ขาด

Exception:
membership_tier = NULL

Constraint:
ห้ามยืนยันสิทธิ์จากข้อมูลไม่ครบ

D. ACCEPTANCE & TEST
AC-03:
Given membership_tier = NULL
When ระบบตรวจสิทธิ์โปรโมชัน
Then eligibility_status = UNVERIFIED
And ไม่แสดง Eligible

Test Reference:
TC-03 — Functional Test

E. RESPONSIBILITY & REVIEW
Data Owner: To Be Assigned
Requirement Owner: To Be Assigned
Approval Authority: To Be Assigned

Open Items:
ยืนยัน Source of Truth
ยืนยันว่า membership_tier เป็นฟิลด์จำเป็น
ระบุ Owner และผู้อนุมัติ

F. EVALUATION LINK
ตรวจภายหลังว่าผู้ใช้เข้าใจความแตกต่าง
ระหว่างสิทธิ์ที่ยืนยันแล้วกับที่ยังไม่ยืนยัน
โดยออกแบบวิธีประเมินตามบริบท

G. HANDOFF
Review Result: HOLD
Reason: มี Open Items สำคัญ
Approved Baseline: NONE
Example Only — ชื่อฟิลด์ สถานะ และข้อกำหนดเป็นสมมติฐานสำหรับสาธิต ต้องยืนยันกับระบบและผู้รับผิดชอบจริงก่อนอนุมัติ


AdvancedTechnical Implementation Pack — สำหรับ Developer & QA

ตัวอย่างข้อกำหนดเชิงเทคนิคที่ใช้ต่อยอด REQ-03 โดยต้องปรับชื่อฟิลด์ Interface, Business Rules และ Source of Truth ให้ตรงกับระบบจริง

A · INPUT / OUTPUT EXAMPLE — JSONC
// Input — paste into Mini Lab
{
  "membership_tier": null,
  "promotion_active": true,
  "source_conflict": false
}

// Output — from Mini Lab engine.js
{
  "eligibility_status": "UNVERIFIED",
  "reason_code": "MISSING_REQUIRED_DATA",
  "missing_fields": ["membership_tier"]
}
ตัวอย่าง JSONC แสดง Input และ Output แยกกัน ให้คัดลอกเฉพาะ JSON ในวงเล็บ { } โดยไม่รวม Comments ทั้งนี้ Regression Tests ของ Lab ตรวจ status และ reason_code แต่ยังไม่ได้ตรวจ missing_fields และตัวอย่างนี้ไม่ใช่ JSON Schema หรือ API Contract ที่อนุมัติแล้ว

B · DECISION TABLE — STATE HANDLING
Condition Output System Rule
ข้อมูลครบและผ่านเงื่อนไข ELIGIBLE ยืนยันสิทธิ์ตามกฎ
ข้อมูลครบแต่ไม่ผ่านเงื่อนไข NOT_ELIGIBLE แสดงว่าไม่ผ่านพร้อมเหตุผล
ข้อมูลจำเป็นไม่ครบ UNVERIFIED ไม่ยืนยันสิทธิ์
แหล่งข้อมูลขัดแย้งกัน DATA_CONFLICT พักการยืนยันและส่งตรวจสอบ
Decision Table นี้เป็น Design Proposal ต้องตกลงลำดับการประเมินกฎ การจัดการข้อมูลเก่าหรือแหล่งข้อมูลไม่พร้อม และสิทธิ์ในการ Override ก่อน Implementation

C · ACCEPTANCE SCENARIOS — GHERKIN
Feature: Promotion eligibility status

  Scenario: Required membership tier is null
    Given membership_tier is null
    And promotion_active is true
    And source_conflict is false
    When promotion eligibility is evaluated
    Then status should be UNVERIFIED
    And reason_code should be MISSING_REQUIRED_DATA

  Scenario: Verified eligible membership
    Given membership_tier is GOLD
    And promotion_active is true
    And source_conflict is false
    When promotion eligibility is evaluated
    Then status should be ELIGIBLE

  Scenario: Conflicting authoritative data
    Given membership_tier is GOLD
    And promotion_active is true
    And source_conflict is true
    When promotion eligibility is evaluated
    Then status should be DATA_CONFLICT
เป็น Gherkin Specification ตัวอย่าง ยังไม่ใช่ Automated Test ที่รันได้ทันที ต้องเชื่อม Step Definitions, Test Data และระบบจริงก่อน

D · IMPLEMENTATION HANDOFF NOTES
Source & Freshness — ยืนยัน Source of Truth และเกณฑ์ข้อมูลล่าสุดที่ยอมรับได้
Failure & Fallback — กำหนดผลเมื่อระบบต้นทางล่ม ข้อมูลหมดอายุ หรือข้อมูลขัดแย้ง
Traceability & Version — เชื่อม REQ-03, AC-03, TC-03 และรุ่นของ Business Rules
Audit & Privacy — บันทึกเหตุผลและเวอร์ชันการประเมิน โดยจำกัดข้อมูลส่วนบุคคลตามความจำเป็น

MINI LAB
Hands-on: REQ-03
ทดลอง REQ-03 ปรับ JSON Policy และดูผล Regression Tests
(ไม่ครอบคลุม REQ-01/02 ทั้งหมด)

HANDOFF QUALITY GATE


4 Checks → 1 Decision

01

Need & Basis

โจทย์และสถานะหลักฐานชัดเจน

02

Requirement

ไม่กำกวมและตรวจสอบได้

03

Test & Exception

มีเกณฑ์ผ่านและกรณีผิดปกติ

04

Governance

มี Owner, Open Items และผู้อนุมัติ

● READY
— พร้อมส่ง

● REVISE
— แก้ก่อนส่ง

● HOLD
— รอข้อสรุปสำคัญ

DECISION-CENTERED ASSURANCE

Requirements ในมุมมองของ HaNonn และ Intent-to-Income™

Requirements ที่ตรวจสอบได้เป็นพื้นฐานสำคัญของการพัฒนาระบบ แต่ในมุมมองของ HaNonn ยังต้องพิจารณาว่า สิ่งที่ระบบส่งมอบตอบ Decision Need ของผู้ใช้ได้เหมาะสมเพียงใด โดยแยกหลักฐานด้าน Technical Correctness, Decision Support และ Decision Quality ออกจากกัน

EVIDENCE ASSURANCE MATRIX

Review Lens หลักฐานที่ต้องใช้ ขอบเขตข้อสรุป
Need Evidence Status Research / Signals / Decision Context มีหลักฐานรองรับ Decision Need หรือยังเป็นสมมติฐาน
Functional Correctness Acceptance Tests / Execution Records ระบบทำงานตรงตามข้อกำหนดในกรณีที่ทดสอบ
Decision Support Fit User Tasks / Observed Interpretation ผู้ใช้ตีความข้อมูลและข้อจำกัดได้เหมาะสมหรือไม่
Decision Quality & Outcomes Context-specific Evaluation / Outcome Data ต้องประเมิน Decision Quality และ Outcomes แยกกัน โดยไม่สรุปเหตุและผลจากตัวชี้วัดเดียว
Applied Review Lenses — ใช้จัดประเภทคำถามและหลักฐาน ไม่ใช่ Core Flow หรือขั้นตอนบังคับของ Intent-to-Income™

DECISION SUPPORT EVALUATION — REQ-03

แม้ Mini Lab จะคืนสถานะ UNVERIFIED ได้ถูกต้อง แต่ยังต้องตรวจว่าผู้ใช้เข้าใจความหมายของสถานะนั้นอย่างไร

01 · UNDERSTANDING
เข้าใจสถานะถูกต้องหรือไม่?
แยกได้ว่า Unverified ไม่ได้หมายถึงไม่มีสิทธิ์

02 · CONFIDENCE
มั่นใจสอดคล้องกับหลักฐานหรือไม่?
ไม่เข้าใจผิดว่าระบบยืนยันสิทธิ์แล้ว ทั้งที่ข้อมูลยังไม่ครบ

03 · READINESS
รู้ว่าควรดำเนินการอย่างไรต่อ?
ระบุข้อมูลที่ต้องเพิ่มเติมหรือช่องทางตรวจสอบสิทธิ์ได้
ทั้งสามด้านเป็นเป้าหมายการประเมินเชิงแนวคิดตาม Decision Context ไม่ใช่ผลการวัดที่ยืนยันแล้ว และไม่ควรถูกรวมเป็นคะแนนสากลโดยไม่มีการตรวจสอบวิธีวัด อ่านเพิ่มเติมที่ Decision Quality และ Intent-to-Income™ Reference Architecture


AdvancedEvaluation Protocol — วิธีตรวจสอบกับผู้ใช้จริง

ตัวอย่างการออกแบบการศึกษาเพื่อประเมินว่า Decision Support จาก REQ-03 ถูกตีความเหมาะสมหรือไม่ โดยใช้ผู้เข้าร่วมและสถานการณ์ที่สอดคล้องกับกลุ่มผู้ใช้เป้าหมาย

Test Scenario คำถามที่ให้ผู้ใช้ตอบ สิ่งที่สังเกต
UNVERIFIED
ข้อมูลสมาชิกไม่ครบ
ตอนนี้คุณทราบหรือยังว่ามีสิทธิ์ใช้โปรโมชัน? การแยกความไม่แน่นอนออกจากการไม่มีสิทธิ์
NOT_ELIGIBLE
ตรวจแล้วไม่ผ่านเงื่อนไข
เพราะเหตุใดจึงไม่สามารถใช้โปรโมชันนี้? ความเข้าใจเหตุผลและข้อจำกัดของสิทธิ์
DATA_CONFLICT
ข้อมูลต้นทางขัดแย้งกัน
คุณคิดว่าควรทำอย่างไรต่อ? การเลือก Next Step โดยไม่สมมติว่าสิทธิ์ได้รับการยืนยัน

EVALUATION EVIDENCE RECORD
Evaluation ID: DSE-REQ03-01
Linked Requirement: REQ-03
Functional Test: TC-03

Study Context:
[Target Users / Device / Scenario]

Evaluation Questions:
- Understand the eligibility status?
- Interpret uncertainty appropriately?
- Identify an appropriate next step?

Observed Response:
[Record actual participant response]

Evidence Reference:
[Study notes / Recording / Task results]

Finding:
[Supported / Issue Found / Inconclusive]

Follow-up:
[Design change / Additional study]

Evaluation Status: NOT CONDUCTED
กำหนดเกณฑ์ประเมินและวิธีวิเคราะห์ก่อนศึกษา บันทึกข้อผิดพลาดตามจริง และระบุจำนวนผู้เข้าร่วมกับข้อจำกัดของหลักฐาน ไม่ถือว่าการทดสอบเชิงคุณภาพกลุ่มเล็กพิสูจน์ผลได้ทั่วไป

FURTHER LEARNING & REFERENCES

แหล่งอ้างอิงและแนวทางศึกษาต่อ

แหล่งเรียนรู้ด้าน Requirements Engineering, Software Testing และการประเมินระบบ เพื่อศึกษาหลักการและวิธีปฏิบัติจากต้นทาง


References International Standards & Engineering Guidance

NASA, ISO, NIST, IREB +

ISO
29148:2018 — Req Engineering
มาตรฐานด้านกระบวนการและเอกสารข้อกำหนดของระบบและซอฟต์แวร์

NASA
Tech Requirements & Quality
แนวทางกำหนด Requirements ให้ชัดเจน ตรวจสอบได้ และพิจารณาทางเลือกในการออกแบบ

NASA
Req Traceability & Change
การติดตามความเชื่อมโยงของข้อกำหนด การควบคุม Baseline และผลกระทบ

IREB
CPRE Foundation
กรอบความรู้สำหรับ Business Analyst และผู้จัดการ Requirements

TOOL
Cucumber — Gherkin
รูปแบบอธิบายสถานการณ์ทดสอบด้วย Given–When–Then เพื่อสื่อสารผลลัพธ์

NASA
Verification vs Validation
Verification ตรวจความสอดคล้องกับข้อกำหนด ส่วน Validation ประเมินว่าระบบตอบโจทย์การใช้งาน

ISO
9241-11:2018 — Usability
นิยามและแนวคิดการประเมิน Usability ตาม Context of Use

NIST
AI Risk Management
แนวทางบริหารความเสี่ยงสำหรับระบบที่มี AI หรือ Human Oversight

EXPLORE NEXT
  • Decision Support
    — เข้าใจสิ่งที่ระบบต้องสนับสนุนก่อนกำหนด Requirements
  • Decision Interface
    — ออกแบบการนำเสนอข้อมูล หลักฐาน และ Next Step ให้ผู้ใช้
  • Research & Evidence Guide
    — ตรวจความน่าเชื่อถือของหลักฐานที่ใช้ระบุ Decision Need
Share This Article
Kittisak Pannutiyarak is the founder of HaNonn and the designer of Intent-to-Income™, a Reference Decision Architecture for AI-first Decision Intelligence.
Leave a Comment