SA-Me.life

เขียนดี = Dev ไม่ต้องเดา
Tester ไม่ต้องถาม
ลูกค้าไม่ต้องแก้!

💡 ก่อนอื่น: Requirement คืออะไร?

สิ่งที่ระบบ “ต้องทำ” หรือ “ต้องมี” เพื่อให้ตอบโจทย์ของผู้ใช้งาน
เขียนให้ชัดตั้งแต่ต้น = งานเร็ว ลดแก้ ลดบั๊ก!

📦 Requirement ที่ดีควรเป็นยังไง?

อักษร	ความหมาย	ตัวอย่างดี	ตัวอย่างไม่ดี
Specific	ชัดเจน ไม่คลุมเครือ	“ผู้ใช้สามารถกดปุ่มยืนยันเพื่อบันทึกข้อมูลได้”	“ทำให้มันเวิร์ก ๆ หน่อย”
Measurable	วัดได้	“ระบบต้องตอบสนองภายใน 3 วินาที”	“โหลดให้เร็ว”
Agreeable	ทุกฝ่ายเข้าใจตรงกัน	“แสดงชื่อผู้ใช้ตามชื่อในระบบ HR”	“ชื่อผู้ใช้จากระบบนู่นนั่นแหละ”
Realistic	ทำได้จริงในเวลาที่มี	“รองรับผู้ใช้ 100 คนพร้อมกัน”	“รองรับ 1 ล้านคนในงบ 2 วัน”
Testable	ทดสอบได้ มีเงื่อนไขชัด	“ถ้าไม่ได้กรอกอีเมล ระบบขึ้นข้อความ ‘กรุณากรอกอีเมล’”	“ป้องกัน error ทุกกรณี”

🔍 ตัวอย่าง Requirement ที่เขียนดี vs ไม่ดี

❌ เขียนไม่ดี	✅ เขียนใหม่ให้เข้าใจง่าย
ระบบแจ้งเตือนตอนมีปัญหา	“ระบบส่งอีเมลแจ้งผู้ดูแล หากเซิร์ฟเวอร์มี Error 500 ภายใน 1 นาที”
ทำระบบจองห้องให้ใช้ได้	“ผู้ใช้สามารถจองห้องประชุมผ่านฟอร์ม โดยเลือกวันที่, เวลา, และห้อง”
อยากให้หน้า UI ใช้ง่าย	“UI ต้องแสดงชื่อห้อง, ความจุ, และปุ่ม ‘จอง’ ชัดเจนบนจอมือถือ”

🧠 เทคนิคเขียน Requirement ให้เป๊ะ

• ✅ เริ่มด้วยคำว่า “ผู้ใช้สามารถ…” / “ระบบต้อง…“
• ✅ แยก Requirement เป็นข้อ ๆ (ไม่เขียนรวบ)
• ✅ ใช้ศัพท์กลาง ไม่ใช่คำเฉพาะที่แค่ Dev เข้าใจ
• ✅ ระบุเงื่อนไข, ข้อยกเว้น, ขอบเขตให้ครบ
• ✅ ถ้ามี flow ซับซ้อน → แนบ Diagram

---

🎯 Requirement ที่ดี = ประหยัดเวลา x3

ฝ่าย	ได้ประโยชน์อะไร
👩‍💻 Dev	เขียนโค้ดตรงเป้า ไม่ต้องเดา
🧪 Tester	เขียน Test Case ได้ทันที
🧑‍💼 ลูกค้า	ตรวจสอบว่า “ใช่สิ่งที่ต้องการ” หรือไม่