Business Analysis and Requirements Engineering

Section 1: บทบาทของ Business Analyst

• BA ทำอะไร และต่างจาก System Analyst, Project Manager และ Product Owner อย่างไร

• งาน BA ในโครงการแบบ Waterfall เทียบกับ Agile และ Scrum

• วงจรของ Requirement และ BABOK Guide ในฐานะกรอบความรู้อ้างอิงของวิชาชีพ

• Workshop: อ่านโจทย์ระบบตัวอย่างและแยกอาการออกจากปัญหาที่แท้จริง

Section 2: Business Need ขอบเขต และ Stakeholder

• แยก Problem, Business Need และ Solution ที่ผู้ใช้เสนอ พร้อมตั้งตัวชี้วัดความสำเร็จ

• กำหนดขอบเขตด้วย Context Diagram และรายการ In Scope กับ Out of Scope

• วิเคราะห์ Stakeholder ด้วย Power/Interest Grid และกำหนดบทบาทด้วย RACI

• Workshop: ทำ Stakeholder Map และ Context Diagram ของระบบตัวอย่าง

Section 3: เทคนิคค้นหาความต้องการ (Elicitation)

• สัมภาษณ์: เตรียมคำถาม ถามปลายเปิด และถามเจาะจนเจอเหตุผลเบื้องหลัง

• Requirement Workshop และบทบาท Facilitator ที่พาห้องไปสู่ข้อสรุป

• สังเกตการทำงานจริง วิเคราะห์เอกสารเดิม และออกแบบแบบสอบถาม

• Lab: สัมภาษณ์แบบ Role-play แล้วสรุปผลเป็นบันทึกการประชุม

Section 4: วิเคราะห์และจัดระเบียบข้อมูลที่ได้มา

• แยกข้อเท็จจริง ความคิดเห็น ข้อสันนิษฐาน และข้อจำกัด

• จัดกลุ่มด้วย Affinity Diagram และหาสาเหตุรากด้วย 5 Whys และ Fishbone

• จัดการความเห็นที่ไม่ตรงกันระหว่าง Stakeholder

• Workshop: สรุป Problem Statement และรายการความต้องการเบื้องต้น

Section 5: Lab: Process Modelling แบบ As-Is และ To-Be

• สัญลักษณ์พื้นฐานของ BPMN: Event, Activity, Gateway, Pool และ Lane

• วาด As-Is และหาจุดคอขวด งานซ้ำซ้อน และจุดที่มักเกิดความผิดพลาด

• ออกแบบ To-Be และสรุป Gap Analysis ว่าระบบใหม่ต้องเปลี่ยนอะไร

• Lab: วาดกระบวนการอนุมัติของระบบตัวอย่างทั้ง As-Is และ To-Be

Section 6: Business Rules และข้อมูลที่ระบบต้องมี

• แยก Business Rule ออกจากกระบวนการและ Requirement

• เขียน Business Rule ให้ชัด ตรวจสอบได้ และใช้ Decision Table

• Glossary และ Conceptual Data Model เบื้องต้นเพื่อให้ทุกฝ่ายใช้คำเดียวกัน

• Workshop: สร้าง Decision Table สำหรับเงื่อนไขการอนุมัติของระบบตัวอย่าง

Section 7: Functional และ Non-functional Requirement

• ระดับของ Requirement: Business, Stakeholder, Solution และ Transition

• เขียน Functional Requirement ให้ชัด ไม่กำกวม และทดสอบได้

• Non-functional Requirement ด้าน Performance, Security, Usability และ Availability

• Lab: เขียนใหม่จาก Requirement ที่กำกวมในเอกสารตัวอย่าง

Section 8: Lab: User Story และ Acceptance Criteria

• รูปแบบ As a, I want, So that หลัก INVEST และการแตก Epic ด้วย Story Mapping

• เขียน Acceptance Criteria แบบ Given/When/Then ที่ QA นำไปทดสอบได้

• Definition of Ready, Definition of Done และ Backlog Refinement

• Lab: เขียน User Story พร้อม Acceptance Criteria ของระบบตัวอย่าง

Section 9: Use Case และการยืนยันหน้าจอ

• Use Case Diagram: Actor, Use Case และขอบเขตระบบ

• Use Case Specification: Main Flow, Alternative Flow และ Exception Flow

• เลือกใช้ Use Case หรือ User Story ให้เหมาะกับโครงการ

• Lab: เขียน Use Case Specification ครบทุก Flow และร่าง Wireframe ยืนยันกับผู้ใช้

Section 10: จัดลำดับความสำคัญและเอกสาร Requirement

• จัดลำดับด้วย MoSCoW โดยพิจารณาคุณค่า ความพยายาม และความเสี่ยง

• โครงสร้างของ BRD และ SRS และการเลือกระดับรายละเอียดให้พอดี

• Requirements Traceability Matrix เชื่อม Requirement กับ Design และ Test Case

• Workshop: จัดลำดับด้วย MoSCoW และสร้าง Traceability Matrix

Section 11: Validation, Change Control และการทำงานกับทีม

• Review, Walkthrough และการขอ Sign-off จาก Stakeholder

• Change Request: ประเมินผลกระทบ อนุมัติ และปรับ Baseline

• ส่งต่อ Requirement ให้ทีม UX, Developer และ QA และตอบคำถามระหว่างพัฒนา

• Lab: ใช้ AI Assistant ช่วยตรวจ User Story โดยไม่ส่งข้อมูลลับ แล้วคัดกรองข้อเสนอแนะเอง

Section 12: Workshop: Capstone Requirements Package

• รับโจทย์ระบบใหม่และวางแผนการค้นหาความต้องการเป็นทีม

• สรุป Stakeholder, กระบวนการ As-Is และ To-Be และ Business Rules

• จัดทำ User Story, Use Case, NFR และ Traceability Matrix เป็นชุดเดียว

• นำเสนอ รับ Feedback จากวิทยากรและเพื่อนร่วมคลาส และสรุป Checklist ของ BA