1145 204 · WEEK 03 SOPHOMORE PROJECT · GROCERY POS PLATFORM
01 / 10
LECTURE BRIEFING · สัปดาห์ที่ 3 รายวิชา 1145 204 โครงงานระดับชั้นปีที่ 2 · ระดับพัฒนาการ: Practiced (P)
ปุ่มลูกศรซ้าย/ขวา เพื่อเปลี่ยนสไลด์

การวิเคราะห์ความต้องการและ Agile User Stories สำหรับแพลตฟอร์ม Grocery POS

เปลี่ยนโจทย์ร้านขายของชำให้เป็นเอกสารความต้องการเชิงวิศวกรรม (SRS), Product Backlog ที่ประเมินขนาดได้จริง และทะเบียนความเสี่ยงเริ่มต้นก่อนเริ่ม Sprint 1

LEARNING OUTCOMES · ผลลัพธ์การเรียนรู้ประจำสัปดาห์

เมื่อจบบทเรียนสัปดาห์ที่ 3 นักศึกษาจะสามารถ:

  • จำแนกความต้องการของระบบ (FR & NFR) สำหรับระบบขายหน้าร้านของชำและคลังสินค้าได้อย่างชัดเจนและวัดผลได้
  • จัดทำโครงร่างเอกสาร SRS ที่เชื่อมโยงบริบทธุรกิจ สถาปัตยกรรมฐานข้อมูลเชิงสัมพันธ์ (3NF) และข้อกำหนดด้านประสิทธิภาพ
  • เขียน User Stories ตามหลัก INVEST และ MoSCoW พร้อม Acceptance Criteria (Given-When-Then) ที่ทดสอบได้จริง
  • ประเมินขนาดงานด้วย Story Points (Planning Poker) และระบุ Initial Risk Register เช่น ปัญหาตัดสต็อกพร้อมกัน (Race Condition)
COURSE CONTEXT · ความเชื่อมโยงในหลักสูตร
4 ขั้นตอน

จากข้อมูล Log ยอดขายในชั้นปีที่ 1 สู่ระบบ POS แบบทีมด้วยกระบวนการ Agile/Scrum ในชั้นปีที่ 2

ปี 1 (1145 103) วิเคราะห์ CSV Log ยอดขายและ PDPA
ปี 2 (1145 204) พัฒนา Web/Desktop POS + คลังวัตถุดิบ (Agile)
ปี 3 (DS / SI) AI Forecasting หรือ Cloud Microservices
บันทึกผู้สอน (Slide 1): ชี้ให้นักศึกษาเห็นความต่อเนื่องจากสัปดาห์ที่ 1–2 (การตั้งทีมและโจทย์ Grocery POS) สัปดาห์นี้เป็นจุดเปลี่ยนจากแนวคิดทางธุรกิจไปสู่ข้อกำหนดทางเทคนิคที่นำไปแตกเป็น Sprint Backlog ได้จริง และมีผลต่อคะแนนเกณฑ์ "ดีเยี่ยม (22–25 คะแนน)" ของวิชา
02 · DOMAIN CONTEXT ทำไมต้องเข้าใจบริบทธุรกิจก่อนเขียน REQUIREMENT
GROCERY POS PLATFORM

บริบทแพลตฟอร์ม Grocery POS: ผู้มีส่วนได้ส่วนเสียและแกนข้อมูลหลัก

ระบบขายหน้าร้านขายของชำไม่ได้มีแค่หน้าคิดเงิน แต่ต้องคุมสินค้าหมดอายุ บาร์โค้ด สต็อกตัดทันที และการชำระเงินหลายช่องทาง

STAKEHOLDER 01

พนักงานคิดเงิน (Cashier)

ต้องการสแกนบาร์โค้ดเร็ว คิดเงินทอนไม่ผิด รองรับ PromptPay/เงินสด/บัตร และพักบิลลูกค้าเมื่อเกิดปัญหา

STAKEHOLDER 02

ผู้จัดการร้าน (Store Manager)

ต้องการเห็นสินค้าใกล้หมด (Reorder Level) สินค้าใกล้วันหมดอายุ และสรุปยอดขายรายกะ/รายวันแบบเรียลไทม์

STAKEHOLDER 03

พนักงานคลัง (Inventory Clerk)

ต้องการรับสินค้าเข้าคลัง ตรวจนับสต็อก (Stock Adjustment) และผูกหน่วยนับปลีก-ส่ง (แพ็ก vs ชิ้น)

RELATIONAL SCHEMA BASELINE (3NF)

โครงสร้างตารางฐานข้อมูลที่ Requirement ต้องอ้างอิง

อ้างอิงจากต้นแบบชิ้นงานชั้นปีที่ 2 (1145 204): ปรับให้รองรับสินค้าของชำที่มีบาร์โค้ด หน่วยนับ และวันหมดอายุ

Users (role_enum) Categories Products (barcode, price) Inventory_Items (stock_qty, reorder_level, expiry) Orders (total_amount, status) Order_Items (qty, subtotal)
บันทึกผู้สอน (Slide 2): เน้นย้ำว่าปัญหาหลักของทีมปี 2 มักเขียน User Story โดยลืมบทบาทผู้ใช้งาน (Actor) หรือออกแบบตาราง Database ไม่สอดคล้องกับ Requirement เช่น ลืม field `reorder_level` หรือ `barcode` ในตารางสินค้า
03 · FR VS NFR FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS
INTERACTIVE CLASSIFIER

ความต้องการเชิงหน้าที่ (FR) เทียบกับความต้องการเชิงคุณภาพ (NFR)

FR ตอบคำถามว่า "ระบบต้องทำอะไรได้บ้าง" ส่วน NFR กำหนดว่า "ระบบต้องทำงานได้ดี ปลอดภัย และเสถียรแค่ไหน"

FUNCTIONAL REQUIREMENTS (FR)

สิ่งที่ระบบต้องดำเนินการ (Behavior)

  • FR-01 การสแกนและค้นหาสินค้า: ระบบอ่านบาร์โค้ด EAN-13 หรือค้นหาชื่อสินค้าเพื่อเพิ่มลงตะกร้า
  • FR-02 การคำนวณและชำระเงิน: คำนวณส่วนลด ภาษีมูลค่าเพิ่ม และออกใบเสร็จพร้อมบันทึกช่องทางชำระเงิน
  • FR-03 การตัดสต็อกอัตโนมัติ: ลดจำนวนสินค้าคงคลังทันทีเมื่อยืนยันการชำระเงิน และแจ้งเตือนเมื่อต่ำกว่าจุดสั่งซื้อซ้ำ
  • FR-04 การจัดการสิทธิ์ผู้ใช้: แยกสิทธิ์ Cashier กับ Manager ในการยกเลิกบิล (Void) หรือแก้ไขราคา
NON-FUNCTIONAL REQUIREMENTS (NFR)

คุณลักษณะเชิงระบบที่วัดผลเป็นตัวเลขได้

  • NFR-01 Performance: การค้นหาบาร์โค้ดและเพิ่มสินค้าลงตะกร้าต้องตอบสนองภายในไม่เกิน 300 มิลลิวินาที
  • NFR-02 Data Integrity: การตัดสต็อกหลายจุดพร้อมกันต้องเป็น Atomic Transaction ไม่มีสต็อกติดลบ
  • NFR-03 Security & PDPA: รหัสผ่านต้องเข้ารหัส Hash (bcrypt/Argon2) และปิดบังข้อมูลส่วนบุคคลลูกค้าในรายงานสรุป
  • NFR-04 Reliability: ระบบต้องทำงานออฟไลน์ชั่วคราวหรือกู้คืนบิลล่าสุดได้เมื่ออินเทอร์เน็ตสะดุด
CHECKPOINT · ฝึกแยกแยะ FR กับ NFR (บันทึกคำตอบอัตโนมัติ)

ลองคลิกจำแนกข้อกำหนดของ Grocery POS ต่อไปนี้

คะแนน: 0 / 4

บันทึกผู้สอน (Slide 3): เตือนนักศึกษาเรื่อง "NFR ที่คลุมเครือ" เช่น ห้ามเขียนว่า "ระบบต้องเร็ว" หรือ "ระบบต้องปลอดภัย" แต่ให้บังคับระบุเกณฑ์ตัวเลข เช่น "< 300 ms" หรือ "เข้ารหัสด้วย bcrypt" เพื่อใช้ตรวจรับงานใน Sprint Review ได้
04 · SRS BLUEPRINT IEEE 830 / ISO 29148 ADAPTED FOR AGILE SOPHOMORE PROJECT
คลิกเพื่อเปิดดูโครงร่างแต่ละหมวด

เอกสารข้อกำหนดความต้องการซอฟต์แวร์ (SRS) แบบกระชับสำหรับทีม Agile

เอกสาร SRS ไม่ใช่การเขียนนิยาย 100 หน้า แต่คือ "สัญญาความเข้าใจร่วมกัน" ระหว่างทีมพัฒนากับอาจารย์/เจ้าของร้าน ก่อนลงมือเขียนโค้ด

วัตถุประสงค์: พัฒนาระบบ Grocery POS สำหรับร้านค้าปลีกขนาดกลาง รองรับแคชเชียร์ 2–3 จุดพร้อมกัน

ขอบเขตที่ทำ (In-Scope): ขายหน้าร้าน, รับชำระ PromptPay/เงินสด, ตัดสต็อก, แจ้งเตือนสินค้าใกล้หมด และรายงานยอดขาย
ขอบเขตที่ยังไม่ทำในเฟสนี้ (Out-of-Scope): ระบบบัญชีภาษีเต็มรูปแบบ และแอปสั่งซื้อออนไลน์สำหรับลูกค้า

กลุ่มผู้ใช้ (User Classes): Cashier (ใช้งานทุกวัน เน้นความเร็ว), Manager (ดูรายงาน/อนุมัติ Void), Admin (จัดการผู้ใช้)

ข้อจำกัดทางเทคนิค: ใช้ฐานข้อมูลเชิงสัมพันธ์ MySQL/PostgreSQL (3NF), รองรับเครื่องอ่านบาร์โค้ด USB HID และเครื่องพิมพ์ใบเสร็จความร้อน 80mm

Use Cases หลัก: UC-01 Check Out Item (สแกนบาร์โค้ด → แสดงราคา → ชำระเงิน → พิมพ์ใบเสร็จ), UC-02 Manual Price/Barcode Fallback (กรณีบาร์โค้ดอ่านไม่ออก)

Data & Traceability: ทุก FR ต้องผูกกับรหัส User Story (US-xxx) และ Test Case (TC-xxx) เพื่อยืนยันความครบถ้วน

บันทึกผู้สอน (Slide 4): ยกตัวอย่าง Use Case "Check Out Item" จากหนังสือ Agile Principles โดยชี้ให้เห็นว่า Alternative Course (เช่น สแกนบาร์โค้ดไม่ติด) มักเป็นจุดที่นักศึกษาลืมเขียนใน SRS แต่สำคัญมากในร้านขายของชำจริง
05 · STORY MAPPING BACKBONE → TASKS → RELEASE SLICES (WALKING SKELETON)
3-SPRINT ROADMAP

User Story Mapping: จัดลำดับความสำคัญด้วย Walking Skeleton และ MoSCoW

Backlog แบบรายการเรียงเดี่ยวทำให้หลงทางได้ง่าย Story Map ช่วยให้เห็นเส้นทางการทำงานของร้านชำตั้งแต่รับของจนปิดกะ

1. เข้าสู่ระบบและตั้งค่ากะ
ยืนยันตัวตน / เปิดลิ้นชักเงิน
SPRINT 1 · MUST HAVE
US-01: ล็อกอินแยกสิทธิ์ Cashier / Manager
SPRINT 2 · SHOULD HAVE
US-08: บันทึกเงินทอนตั้งต้นเปิดกะ (Shift Open)
2. ขายหน้าร้าน (POS Checkout)
สแกนสินค้า / คำนวณ / พักบิล
SPRINT 1 · MUST HAVE
US-02: สแกนบาร์โค้ดและเพิ่มสินค้าลงตะกร้า
SPRINT 2 · MUST HAVE
US-04: พักบิลชั่วคราว (Hold Bill) เพื่อรับลูกค้าถัดไป
3. ชำระเงินและออกใบเสร็จ
รับเงินสด / PromptPay / ตัดสต็อก
SPRINT 2 · MUST HAVE
US-03: ชำระเงินสด/PromptPay พร้อมตัดสต็อกอัตโนมัติ
SPRINT 3 · COULD HAVE
US-09: สะสมแต้มสมาชิกด้วยเบอร์โทรศัพท์
4. คลังสินค้าและรายงาน
แจ้งเตือนหมด / ตรวจวันหมดอายุ
SPRINT 3 · MUST HAVE
US-05: แจ้งเตือนเมื่อสต็อกต่ำกว่า Reorder Level
ICEBOX · WON'T HAVE NOW
US-10: พยากรณ์ยอดสั่งซื้อด้วย AI (ไว้ทำในชั้นปี 3)
Must Have

ขาดไม่ได้ ระบบจะใช้งานจริงหรือปล่อย Release ไม่ได้

Should Have

สำคัญ แต่มีวิธีแก้ขัดชั่วคราวได้ใน Sprint แรก

Could Have

มีก็ดี (Wish-list) ตัดออกก่อนหากเวลาไม่พอ

Won't Have

ตกลงไม่ทำในรอบนี้ ย้ายไป Icebox ไว้พิจารณาภายหลัง

บันทึกผู้สอน (Slide 5): อธิบายแนวคิด "Walking Skeleton" — ใน Sprint 1–2 เราต้องได้ End-to-End Flow ที่ล็อกอิน สแกนขาย ชำระเงิน และตัดสต็อกได้ครบวงจรก่อน ไม่ใช่ทำหน้า Login กับหน้าเพิ่มสินค้าจนสมบูรณ์ 100% แต่ยังคิดเงินไม่ได้
06 · PRODUCT BACKLOG USER STORY TEMPLATE: AS A [ROLE], I WANT [GOAL], SO THAT [BENEFIT]
INTERACTIVE BACKLOG EXPLORER

Agile User Story Backlog สำหรับระบบ Grocery POS

User Story คือ "ตัวแทนบทสนทนา" (Mnemonic Token) ที่บอกบทบาท เป้าหมาย และคุณค่าทางธุรกิจ โดยไม่ยัดไส้รายละเอียดโค้ด

รหัส Epic User Story (As a / I want / So that) MoSCoW Sprint Points
WORKSHOP · ลองเพิ่ม User Story ของทีมคุณลงในตารางข้างบน

บันทึกผู้สอน (Slide 6): ให้นักศึกษาสังเกตว่า Story Points ของทั้ง 3 Sprint ต้องสมดุลกับ Velocity ของทีม (เช่น ทีม 4 คนทำได้ ~13–15 Points ต่อ Sprint) และห้ามเขียน User Story กว้างเกินไปเช่น "ทำระบบคลังสินค้า" — ต้องแตก (Split) ออกเป็นส่วนย่อยที่ประเมินได้
07 · ACCEPTANCE CRITERIA DEFINITION OF DONE · GIVEN-WHEN-THEN FORMAT
คลิกเลือก Story เพื่อดูเงื่อนไขการตรวจรับ

เกณฑ์การยอมรับงาน (Acceptance Criteria) ด้วยรูปแบบ Given–When–Then

Story จะยังไม่ถือว่า "Done" จนกว่าจะผ่าน Automated หรือ Manual Acceptance Tests ทุกกรณีทั้งสภาวะปกติและกรณีผิดพลาด

US-02 · ACCEPTANCE CRITERIA

บันทึกผู้สอน (Slide 7): ย้ำว่า Acceptance Criteria คือส่วนที่มักทำให้นักศึกษาถูกหักคะแนนเหลือ "พอใช้ (14–17 คะแนน)" หากเขียนลอยๆ เช่น "ระบบตัดสต็อกถูกต้อง" ให้เปลี่ยนเป็น Given (สต็อกมี 10 ชิ้น) → When (ขาย 2 ชิ้นสำเร็จ) → Then (สต็อกเหลือ 8 ชิ้น และบันทึกประวัติตัดสต็อก)
08 · STORY POINTS & VELOCITY RELATIVE SIZING · PLANNING POKER (FIBONACCI)
SIMULATOR

การประเมินขนาดงานด้วย Story Points และการคำนวณ Sprint Capacity

Story Points วัด "ขนาดสัมพัทธ์ ความซับซ้อน และความไม่แน่นอน" ไม่ใช่จำนวนชั่วโมงตรงๆ — ทีมใช้ Planning Poker เพื่อสร้างความเข้าใจร่วมกัน

PLANNING POKER · เลือกไพ่ประเมินเพื่อเทียบความหมาย
3 POINTS · งานขนาดมาตรฐาน (BASELINE)

ตัวอย่าง Grocery POS: หน้าสแกนบาร์โค้ดและเพิ่มรายการลงตะกร้า (US-02) มีการเชื่อมต่อ DB พื้นฐานและจัดการ Error กรณีไม่พบบาร์โค้ด

SPRINT VELOCITY PLANNER · คำนวณจำนวนสปรินต์
ผลลัพธ์แผนปล่อยงาน (RELEASE FORECAST)
3 Sprints

Backlog รวม 0 Points · เพียงพอต่อแผน 3 สปรินต์ตามกรอบวิชา 1145 204

บันทึกผู้สอน (Slide 8): อธิบายเหตุผลที่ 8 หรือ 13 Points ควรแตกเป็น Story ย่อย (Splitting) เพราะ Story ใหญ่เกิน 8 Points มักประเมินคลาดเคลื่อนและทำให้จบไม่ทันในสปรินต์เดียว ("Done 90% of tasks แต่ 0 completed stories")
09 · INITIAL RISK REGISTER PROJECT RISK MANAGEMENT & MITIGATION PLAN
คลิกช่องตาราง Heatmap เพื่อกรองความเสี่ยง

ทะเบียนความเสี่ยงเริ่มต้น (Initial Risk Register) สำหรับระบบ Grocery POS

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

RISK MATRIX (LIKELIHOOD × IMPACT)
สูง
โอกาสสูง / ผลกลางR-04
โอกาสสูง / ผลสูงR-01, R-02
วิกฤตสูงสุด—
กลาง
ต่ำ—
ปานกลางR-03
สูงR-05
ต่ำ
ต่ำR-06
ต่ำ—
เฝ้าระวัง—
รหัส ความเสี่ยง (Risk Event) ระดับ แผนบรรเทาความเสี่ยง (Mitigation Plan)
บันทึกผู้สอน (Slide 9): ชี้ให้นักศึกษาดู R-01 (Concurrency / Race Condition ตอนตัดสต็อกพร้อมกัน) ซึ่งเป็นตัวอย่างตรงจากเอกสารโครงงาน 1145 204 การใช้ SQL Transaction + Row-level Locking (`SELECT ... FOR UPDATE`) หรือ Optimistic Locking เป็นจุดที่กรรมการสอบมักถาม
10 · DELIVERABLES & RUBRIC เกณฑ์การประเมินและสิ่งที่ต้องส่งมอบในสัปดาห์ถัดไป
EXPORT & CHECKLIST

เกณฑ์การให้คะแนนและรายการส่งมอบงานของทีม (Week 3 Workshop)

ตรวจสอบความครบถ้วนของเอกสาร SRS, Backlog และ Risk Register เทียบกับเกณฑ์ประเมินระดับ "ดีเยี่ยม (22–25 คะแนน)"

ระดับคุณภาพ ช่วงคะแนน ลักษณะงานตามเกณฑ์รายวิชา 1145 204
ดีเยี่ยม 22–25 วิเคราะห์ FR/NFR ได้ถูกต้อง ครอบคลุม เขียน User Stories ตามมาตรฐาน Agile พร้อมประเมิน Story Points และระบุ Acceptance Criteria ได้อย่างสมบูรณ์
ดี 18–21 Requirements และ User Stories ครอบคลุมฟังก์ชันหลักของระบบ มีการประเมิน Story Points โดยมีจุดที่ต้องปรับแก้เล็กน้อย
พอใช้ 14–17 User Stories เขียนไม่ถูกรูปแบบ ขาดรายละเอียด Acceptance Criteria หรือวิเคราะห์ Requirements ไม่ครอบคลุม
ปรับปรุง 0–13 ไม่มีการวิเคราะห์ Requirements หรือจัดทำ User Story Backlog ตามหลักวิศวกรรมซอฟต์แวร์
TEAM CHECKLIST · ตรวจความพร้อมก่อนส่ง

SOURCES & REFERENCES

เรียบเรียงจากแนวทางโครงงานรายวิชา 1145 204 (โครงงานระดับชั้นปีที่ 2), เกณฑ์รูบริกการวิเคราะห์ความต้องการของหลักสูตร, คู่มือ Scrum Guide (Ken Schwaber & Jeff Sutherland), หนังสือ Agile Estimating and Planning (Mike Cohn), Agile Principles, Patterns, and Practices (Robert C. Martin) และแนวทาง User Story Mapping และ GitHub Projects for Agile

บันทึกผู้สอน (Slide 10): ให้นักศึกษาแต่ละกลุ่มใช้เวลา 30 นาทีท้ายคาบปรับปรุง Backlog และกดปุ่ม "ส่งออก Backlog (CSV)" เพื่อนำไป Import เข้า GitHub Projects / Jira พร้อมเตรียมนำเสนอความเสี่ยง R-01 ถึง R-05 ในสัปดาห์หน้า
สไลด์ 1 จาก 10