🧭 Requirement คือ “แผนที่ของโปรเจกต์”
ลองจินตนาการว่า Dev คือคนขับรถ, SA คือคนวางแผนเส้นทาง
ถ้าไม่มี Requirement ชัด ๆ ก็เหมือน เปิด GPS แล้วไม่มีจุดหมาย
สุดท้าย… ขับวนไปมา เปลืองน้ำมัน (และงบ!) 🚗💸
📘 คำจำกัดความ (แบบไม่จำกัดความรู้)
Requirement = สิ่งที่ระบบต้องทำ หรือมี เพื่อให้ตอบโจทย์ของผู้ใช้งานได้จริง
ไม่ใช่ความหวังลอย ๆ — แต่ต้อง “จับต้อง-เขียน-ทดสอบ” ได้
Requirement มีกี่แบบ?
| ประเภท | คืออะไร | ตัวอย่างแบบไทย ๆ |
|---|---|---|
| Functional | ระบบ “ต้องทำอะไร” | “พนักงานต้องสามารถขอวันลาได้” |
| Non-Functional | ระบบ “ต้องเป็นยังไง” | “ระบบต้องรองรับผู้ใช้งานพร้อมกัน 1,000 คน” |
| Business Rule | กฎบริษัท/ข้อบังคับ | “พนักงานต้องแจ้งลาล่วงหน้าอย่างน้อย 3 วัน” |
| Constraint | ข้อจำกัด | “ต้องพัฒนาด้วยภาษา Java ภายใน 3 เดือน” |
🔍 Requirement ไม่ใช่แค่ “อยากได้”
คนพูดว่า “อยากได้ระบบแจ้งเตือนผ่านไลน์”
SA ต้องถามต่อว่า
- ใครจะได้รับแจ้งเตือน?
- แจ้งเรื่องอะไร?
- ต้องส่งกี่โมง?
- งบประมาณมีไหม?
- มีบัญชี LINE OA แล้วหรือยัง?
เพราะ “Requirement จริง” มักซ่อนอยู่หลังคำว่า อยากได้อะไรซักอย่าง
ถ้าไม่เก็บ Requirement ดี จะเกิดอะไรขึ้น?
- ❌ ระบบทำออกมาแล้วใช้ไม่ได้
- ❌ Dev กับ User เข้าใจไม่ตรงกัน
- ❌ งบบานปลาย เพราะต้องแก้ใหม่
- ❌ เสียเวลา เสียเครดิต เสียใจ (และบางทีเสียงาน)
Requirement ที่ดีต้องเป็นยังไง?
จำง่าย ๆ ว่า “SMART”
Specific (ชัดเจน)
Measurable (วัดได้)
Agreeable (ทุกฝ่ายเห็นพ้อง)
Realistic (ทำได้จริง)
Testable (สามารถทดสอบได้)
💡 กลับบ้าน
- Requirement คือ เข็มทิศของโปรเจกต์ — ไม่มี = หลง
- ไม่ใช่แค่สิ่งที่ “อยากได้” แต่คือสิ่งที่ “ต้องมีเพื่อให้ระบบทำงานได้จริง”
- Requirement ที่ดีจะช่วยให้ Dev, Tester, PM, User ทุกคนไปทางเดียวกัน
SA-Me.life 
ใส่ความเห็น