Track C — เปลี่ยนจาก QC/QA Support → BA · Stage 7
Requirement Engineering
จาก stakeholder ถึง acceptance criteria — เขียนความต้องการให้ทีมพัฒนาทำต่อได้จริง
4 Lesson
ถ้าคุณมาจาก Customer Support
ถ้าคุณมาจาก Customer Support รายชื่อ stakeholder ของคุณคือ: Customer, Support Agent, Support Lead, Product Manager, Developer, IT, Security (และ Legal ถ้าข้อมูลลูกค้ามี PII) — แทนที่ Production/Engineering ด้วยทีม Product/Dev
ตัวอย่าง requirement แปลงได้ตรงตัว: Functional เช่น “The system shall allow support agents to search past tickets by product, issue type and free-text query” ส่วน Non-functional ที่สำคัญเป็นพิเศษฝั่ง support คือ Privacy (ข้อมูลลูกค้า) และ Availability (ระบบต้องพร้อมใช้ตลอดช่วงเวลาให้บริการ)
User story ตัวอย่าง: “As a support agent, I want to search past tickets using the customer's symptom description, so that I can find similar resolved cases quickly” — โครง Given/When/Then ของ acceptance criteria ใช้เหมือนกันทุกประการ เปลี่ยนแค่ field ในผลลัพธ์ (Ticket ID, Product, Issue Type, Resolution แทน Part Number/Defect)
Lesson
Exercise
Exercise: เขียนชุด Requirement ของ Use Case ตัวเอง
ใช้ use case จาก proposed-ai-workflow.md (Stage 5) เป็นตัวตั้ง แล้วเขียน:
- Stakeholder list — ใครเกี่ยวข้องบ้าง แต่ละคนต้องการอะไร (อย่างน้อย 5 ราย)
- Functional requirements — อย่างน้อย 5 ข้อ ใช้รูปแบบ “The system shall ...”
- Non-functional requirements — อย่างน้อย 3 ข้อ พร้อมค่าที่วัดได้ถ้าเป็นไปได้
- User stories — อย่างน้อย 3 stories ตามรูปแบบ As a / I want / So that
- Acceptance criteria — เขียน Given/When/Then ให้ story ที่สำคัญที่สุดอย่างน้อย 1 story
Deliverable ที่ควรได้
ไฟล์ requirements.md — ครบทั้ง 5 ส่วนข้างบน จะกลายเป็นแกนของ BA Deliverables ใน Capstone (Stage 9)
ถ้า sign in แล้วสามารถบันทึก Deliverable นี้เก็บไว้กับบัญชีของคุณบนเว็บได้
เข้าสู่ระบบ เพื่อบันทึกงานของคุณ — ไม่มีบัญชีก็ทำ Exercise ได้ตามปกติ เพียงแต่ระบบจะไม่เก็บงานให้
ความคืบหน้าของคุณ
4 ข้อนี้เป็นบันทึกส่วนตัวของคุณ — สถานะ Complete ของ Stage มาจากแถวล่างสุดเท่านั้น
เข้าสู่ระบบ เพื่อบันทึกความคืบหน้าของคุณ