AI-Powered System Analysis & Design

Section 1: AI ในงานวิเคราะห์และออกแบบระบบ

• ขั้นตอนงาน SA แบบเดิมและจุดที่กินเวลามากที่สุดจนทีมมักข้ามไป

• งานที่ AI ช่วยได้ดีเทียบกับงานที่ยังต้องอาศัยการตัดสินใจของคน

• ภาพรวมเส้นทางทั้งหมด: Requirement, Use Case, Process Flow, ER Diagram, API, Architecture, Test

• แนวคิด Diagram as Code และเหตุผลที่ควรเก็บงานออกแบบไว้ใน Git

• การเตรียมเครื่องมือและการตั้งค่าให้พร้อมใช้ตลอดสองวัน

Section 2: เก็บและเรียบเรียง Requirement ด้วย AI

• ความต่างระหว่าง Business, Functional และ Non-functional Requirement

• การใช้ AI ช่วยสรุปบันทึกการประชุมและถอดความต้องการออกมาเป็นข้อ ๆ

• การเขียน Requirement ให้ชัดเจน วัดผลได้ และไม่กำกวม

• การให้ AI ตรวจหาความต้องการที่ขัดแย้งกันเองและจุดที่ยังขาดข้อมูล

• การจัดลำดับความสำคัญและการทำ Requirement Traceability

• Lab: แปลงบันทึกการประชุมดิบให้เป็นเอกสาร Requirement ที่พร้อมใช้

Section 3: Use Case และ Actor

• การระบุ Actor และขอบเขตของระบบให้ชัดก่อนเริ่มเขียน Use Case

• การแตก Requirement เป็น Use Case พร้อม Main Flow และ Alternate Flow

• การเขียนเงื่อนไขก่อนและหลังการทำงานให้ครบถ้วน

• การสร้าง Use Case Diagram ด้วย PlantUML และการปรับแก้เป็นโค้ด

• ข้อผิดพลาดที่พบบ่อย เช่น Use Case ละเอียดเกินไปหรือกว้างเกินไป

• Lab: สร้าง Use Case Diagram จาก Requirement ของโจทย์ตนเอง

Section 4: Process Flow และ Sequence Diagram

• การเขียน Business Process Flow ให้เห็นลำดับงานและผู้รับผิดชอบ

• การใช้ Mermaid เขียน Flowchart และการจัดวางให้อ่านง่าย

• การเขียน Sequence Diagram เพื่ออธิบายการคุยกันระหว่างส่วนของระบบ

• การจัดการเงื่อนไข การวนซ้ำ และกรณียกเว้นใน Diagram

• Lab: เขียน Process Flow และ Sequence Diagram ของกระบวนการหลักด้วย Mermaid

Section 5: ER Diagram และการออกแบบฐานข้อมูล

• การถอด Entity และความสัมพันธ์ออกมาจาก Requirement และ Use Case

• การกำหนด Primary Key, Foreign Key และ Cardinality ให้ถูกต้อง

• หลักการ Normalization และเมื่อใดที่การ Denormalize คุ้มกว่า

• การสร้าง ER Diagram ด้วย Mermaid และการแปลงเป็นสคริปต์สร้างตาราง

• Lab: ออกแบบ ER Diagram แล้วสร้างตารางจริงบน PostgreSQL เพื่อทดสอบ

Section 6: ตรวจทาน Data Model ก่อนไปต่อ

• การใช้ AI ตรวจสอบว่า Data Model รองรับทุก Use Case ที่เขียนไว้หรือไม่

• การทดสอบด้วยข้อมูลตัวอย่างและ Query จริงเพื่อหาจุดที่ออกแบบพลาด

• การพิจารณาปริมาณข้อมูลและ Index ที่จำเป็นตั้งแต่ตอนออกแบบ

• Lab: ตรวจทานและปรับ Data Model ของตนเองจนรองรับทุก Use Case

Section 7: ออกแบบ API ด้วย OpenAPI

• การถอดรายการ API ที่ต้องมีออกมาจาก Use Case

• หลักการออกแบบ REST: การตั้งชื่อ Resource, การเลือก Method และรหัสสถานะ

• การเขียนสเปกด้วย OpenAPI พร้อม Request, Response และ Error Model

• การใช้ AI ช่วยร่างสเปกและการตรวจว่าครอบคลุมทุกกรณี

• การใช้สเปกให้ทีม Frontend และ Backend ทำงานคู่ขนานได้ตั้งแต่ยังไม่มีระบบจริง

• Lab: เขียนสเปก OpenAPI ของระบบตนเองและตรวจสอบความถูกต้อง

Section 8: ออกแบบสถาปัตยกรรมระบบ

• องค์ประกอบของสถาปัตยกรรม: ส่วนหน้าจอ ส่วนประมวลผล ฐานข้อมูล และบริการภายนอก

• การเลือกรูปแบบสถาปัตยกรรมให้เหมาะกับขนาดทีมและความซับซ้อนของงาน

• การเขียน Architecture Diagram ด้วย Mermaid และการปรับแต่งด้วย Draw.io

• การระบุ Non-functional Requirement ลงในผัง เช่น ความปลอดภัยและการรองรับโหลด

• Lab: ร่างสถาปัตยกรรมของระบบตนเองพร้อมอธิบายเหตุผลของทุกองค์ประกอบ

Section 9: Test Scenario และ Test Case

• การแตก Test Scenario ออกมาจาก Use Case ให้ครบทั้งกรณีปกติและกรณียกเว้น

• การเขียน Test Case ที่ระบุเงื่อนไขเริ่มต้น ขั้นตอน และผลลัพธ์ที่คาดหวัง

• การใช้ AI ช่วยหากรณีทดสอบที่คนมักมองข้าม เช่น ค่าขอบเขตและข้อมูลผิดรูปแบบ

• การเชื่อม Test Case กลับไปยัง Requirement เพื่อให้ตรวจสอบความครอบคลุมได้

• Lab: สร้างชุด Test Scenario จาก Use Case ของระบบตนเอง

Section 10: การตรวจทานคุณภาพงานออกแบบ

• จุดที่ AI มักพลาดในงานออกแบบระบบและวิธีตรวจจับ

• การตรวจความสอดคล้องระหว่าง Requirement, Use Case, Data Model และ API

• การใช้ AI เป็นผู้ตรวจทานอีกชั้นด้วยการให้ตั้งคำถามกลับแทนการให้คำตอบ

• การจัดการเมื่อความต้องการเปลี่ยนและต้องแก้เอกสารทั้งชุด

Section 11: การส่งมอบเอกสารออกแบบระบบ

• องค์ประกอบของเอกสารออกแบบระบบที่ทีมพัฒนานำไปใช้ต่อได้จริง

• การจัดเก็บ Diagram as Code ไว้ใน Git และการทำให้เอกสารอัปเดตตามโค้ด

• การนำเสนองานออกแบบให้ผู้บริหารและผู้ใช้เข้าใจโดยไม่ต้องลงรายละเอียดเทคนิค

• Lab: ประกอบเอกสารออกแบบระบบฉบับสมบูรณ์จากงานที่ทำมาทั้งสองวัน

Section 12: Capstone และการนำไปใช้จริง

• โจทย์: ออกแบบระบบหนึ่งตัวครบทุกขั้นตอนตั้งแต่ Requirement จนถึง Test Scenario

• การนำเสนอเหตุผลของการตัดสินใจออกแบบในแต่ละจุด

• แนวทางนำกระบวนการนี้ไปใช้กับงานจริงและการปรับให้เข้ากับทีม

• Workshop: นำเสนอผลงานและทบทวนการออกแบบร่วมกันกับวิทยากร