วิธีเขียน Requirement Spec สำหรับโครงการ ERP

Requirement Spec vs TOR vs RFP — ต่างกันอย่างไร?

หลายองค์กรสับสนระหว่าง 3 เอกสารนี้ จริงๆ แล้วมีจุดประสงค์ต่างกัน แต่ Requirement Spec เป็นแกนกลางของทั้ง TOR และ RFP — ถ้าเขียน Requirement Spec ดี จะนำไปใส่ในเอกสารใดก็ได้

รายการ	Requirement Spec	TOR (ภาครัฐ)	RFP (เอกชน)
จุดประสงค์	ระบุความต้องการทางเทคนิค	กำหนดขอบเขตงานจัดซื้อจัดจ้าง	เชิญชวน vendor เสนอ solution
ผู้จัดทำ	ทีม IT + Business Analyst	คณะกรรมการจัดซื้อ + ทีม IT	ทีม IT + Procurement
กฎหมาย	ไม่มีข้อบังคับ	พ.ร.บ.จัดซื้อจัดจ้าง 2560	นโยบายบริษัท
ระดับรายละเอียด	ละเอียดมาก (เทคนิค)	ละเอียด + มีเงื่อนไขทางกฎหมาย	ปานกลาง (เปิดให้ vendor เสนอ)
เผยแพร่ที่	ภายในองค์กร / ส่ง vendor	ระบบ e-GP (จัดซื้อจัดจ้างภาครัฐ)	ส่งตรงถึง vendor ที่เชิญ
มีราคากลาง	ไม่จำเป็น	ต้องมี (ภาครัฐบังคับ)	อาจมีหรือไม่มี
คุณสมบัติผู้เสนอ	ไม่ระบุ	ระบุชัดเจน (ทุนจดทะเบียน, ผลงาน)	แล้วแต่กำหนด

โครงสร้าง Requirement Spec ที่ดี — 12 หัวข้อที่ต้องมี

ไม่ว่าจะเขียนเป็น Requirement Spec, TOR, หรือ RFP โครงสร้างต่อไปนี้ครอบคลุมทุกมิติที่จำเป็น:

#	หัวข้อ	สิ่งที่ต้องระบุ
1	บทนำ + วัตถุประสงค์	ที่มาของโครงการ ปัญหาที่ต้องแก้ เป้าหมายหลัก KPI ที่วัดผลสำเร็จ
2	ขอบเขตโครงการ (Scope)	โมดูลที่ต้องการ จำนวนหน่วยงาน/สาขา สิ่งที่อยู่ใน scope และ สิ่งที่ไม่อยู่ใน scope (สำคัญมาก!)
3	Functional Requirements	ความต้องการเชิงฟังก์ชัน แยกตามโมดูล: งบประมาณ, การเงิน/บัญชี, จัดซื้อจัดจ้าง, พัสดุ/คลัง, บุคลากร, รายงาน
4	Non-Functional Requirements	Performance, Security, Availability, Scalability, Accessibility (WCAG 2.1) — ดูรายละเอียดในหัวข้อถัดไป
5	User Requirements	จำนวนผู้ใช้ (concurrent + total), กลุ่มผู้ใช้ (admin, approver, viewer), สิทธิ์ (RBAC), ภาษา (TH/EN)
6	Data Migration	ข้อมูลอะไรต้องย้าย รูปแบบ ปริมาณ ระบบต้นทาง วิธี (Big Bang / Phased) ข้อมูลย้อนหลังกี่ปี
7	Integration	ระบบที่ต้องเชื่อมต่อ: GFMIS, e-GP, ธนาคาร, e-Tax Invoice, DPIS, e-Saraban วิธีเชื่อมต่อ (API/File/DB)
8	Technical Requirements	OS, Database (PostgreSQL/Oracle), Browser, มาตรฐาน, Cloud/On-premise, Open Source/Proprietary
9	Training & Change Management	อบรมกี่คน กี่รอบ ที่ไหน คู่มือ (กี่ชุด พิมพ์/ออนไลน์) แผน Change Management
10	SLA & Support	เวลาตอบรับ (Response Time) เวลาแก้ไข (Resolution Time) ช่วงเวลาให้บริการ ช่องทางติดต่อ ระยะเวลา warranty
11	Acceptance Criteria	เกณฑ์ส่งมอบแต่ละ Phase, UAT (ใครทดสอบ กี่วัน กี่ test case), Performance Test, เกณฑ์ตรวจรับ
12	Timeline & Milestones	จำนวน Phase ระยะเวลาแต่ละ Phase deliverables แต่ละ milestone งวดเงิน เงื่อนไขการจ่าย

ตัวอย่าง Functional Requirement — ที่ดี vs ที่ไม่ดี

ปัญหาที่พบบ่อยที่สุดคือ เขียน spec กว้างเกินไป ทำให้ vendor ตีความได้หลายแบบ — ผลคือระบบที่ได้ "ถูกตาม spec" แต่ "ไม่ตรงความต้องการ" ดูตัวอย่างเปรียบเทียบ:

โมดูล	❌ ไม่ดี (กว้างเกินไป)	✅ ดี (เฉพาะเจาะจง)
งบประมาณ	"ระบบต้องบริหารงบประมาณได้"	"ระบบต้องรองรับการจัดสรรงบประมาณ 3 ระดับ (แผน/งาน/กิจกรรม) ตามผังงบประมาณที่กำหนด สามารถตั้งงบได้ทั้งเงินงบประมาณ เงินนอกงบประมาณ และเงินรายได้ โดยแสดงยอดตั้ง ยอดผูกพัน ยอดใช้จ่าย ยอดคงเหลือ แบบ real-time"
รายงาน	"ระบบต้องออกรายงานได้"	"ระบบต้องออกรายงานสถานะการใช้จ่ายงบประมาณ แยกตามแหล่งเงิน แผนงาน ผลผลิต กิจกรรม โดยแสดงยอดตั้ง ยอดใช้ ยอดผูกพัน ยอดคงเหลือ พร้อม Export เป็น Excel/PDF ได้ และรองรับการตั้งเวลาส่งรายงานอัตโนมัติ (Scheduled Report)"
ผู้ใช้	"ระบบต้องรองรับผู้ใช้หลายคน"	"ระบบต้องรองรับผู้ใช้งานพร้อมกัน (Concurrent Users) อย่างน้อย 200 คน โดย Response Time ≤ 3 วินาที สำหรับทุกหน้าจอ และ ≤ 10 วินาที สำหรับรายงานที่มีข้อมูลมากกว่า 100,000 แถว"
จัดซื้อ	"ระบบต้องจัดซื้อจัดจ้างได้"	"ระบบต้องรองรับกระบวนการจัดซื้อจัดจ้างตั้งแต่ PR → PO → GR → Invoice → Payment พร้อม Workflow อนุมัติอย่างน้อย 3 ระดับ (ผู้ขอ → หัวหน้ากลุ่ม → ผู้อำนวยการ) และสร้างเอกสาร e-GP ได้"
พัสดุ	"ระบบต้องดูแลสต็อกได้"	"ระบบต้องบริหารคลังพัสดุแบบ FIFO รองรับ Barcode/QR Code Scan สำหรับรับ-จ่าย แจ้งเตือนเมื่อสินค้าต่ำกว่า Minimum Stock รองรับการตรวจนับ (Stock Take) พร้อม Aging Report"
บุคลากร	"ระบบต้องจัดการ HR ได้"	"ระบบต้องเก็บข้อมูลบุคลากรตามมาตรฐาน DPIS (กรมบัญชีกลาง) รองรับการลา สาย ขาด OT พร้อมคำนวณเงินเดือนและเชื่อมต่อระบบโอนเงินธนาคารได้ (BAHTNET/Bulk Payment)"
ความปลอดภัย	"ระบบต้องปลอดภัย"	"ระบบต้องผ่านการทดสอบ OWASP Top 10 รองรับ 2FA (Two-Factor Authentication) มี RBAC (Role-Based Access Control) มี Audit Trail บันทึกทุกการเข้าถึงและแก้ไขข้อมูล เก็บ Log อย่างน้อย 1 ปี และเข้ารหัสข้อมูลด้วย TLS 1.2+"
Integration	"ระบบต้องเชื่อมต่อระบบอื่นได้"	"ระบบต้องเชื่อมต่อ GFMIS (ส่งข้อมูลการเบิกจ่ายรายวัน Format XML ตามมาตรฐานกรมบัญชีกลาง) e-GP (ดึงข้อมูลผู้ขายและสัญญา) และธนาคาร (โอนเงินผ่าน API/File Upload ตามมาตรฐาน BAHTNET)"

Non-Functional Requirements ที่มักถูกลืม

Functional Requirements บอกว่า "ระบบต้องทำอะไรได้" แต่ Non-Functional Requirements บอกว่า "ระบบต้องทำได้ดีแค่ไหน" — หลายองค์กรเขียนแค่ Functional แล้วลืม Non-Functional ซึ่งเป็นสาเหตุที่ระบบ "ใช้ได้ แต่ช้า/ไม่ปลอดภัย/ล่มบ่อย"

หมวด	ตัวอย่าง Requirement	วิธีทดสอบ
Performance	Response Time ≤ 3 วินาที (หน้าจอปกติ), ≤ 10 วินาที (รายงาน)	Load Testing ด้วย JMeter/k6
Availability	Uptime ≥ 99.5%, Planned Maintenance เฉพาะนอก Office Hours (18:00-06:00)	Monitoring (Uptime Robot, Grafana)
Security	ผ่าน OWASP Top 10, 2FA, RBAC, Audit Trail, TLS 1.2+, เก็บ Log ≥ 1 ปี	Penetration Testing + Security Audit
Scalability	รองรับขยาย 200 → 2,000 users ภายใน 3 ปี โดยไม่ต้องเปลี่ยน architecture	Capacity Planning + Stress Test
Accessibility	WCAG 2.1 Level AA — รองรับ Screen Reader, Keyboard Navigation	aXe / Lighthouse Audit
Backup & DR	Full Backup ทุกวัน, RPO ≤ 24 ชม., RTO ≤ 4 ชม., DR Site แยกจาก Production	DR Drill ปีละ 1 ครั้ง
Browser	รองรับ Chrome, Edge, Firefox (2 versions ล่าสุด) + Mobile Safari/Chrome	Cross-browser Testing
Data Retention	เก็บข้อมูลธุรกรรมย้อนหลัง 10 ปี ตาม พ.ร.บ.การบัญชี + PDPA	ตรวจสอบ Data Lifecycle Policy

Checklist 20 ข้อก่อนส่ง Requirement Spec

ก่อนส่ง spec ให้ vendor หรือยื่น TOR เข้าระบบ e-GP ต้องเช็คให้ครบทุกข้อ:

ขอบเขต (Scope)

1. ระบุ สิ่งที่อยู่ใน scope ชัดเจน (โมดูลอะไรบ้าง)
2. ระบุ สิ่งที่ไม่อยู่ใน scope ชัดเจน (สำคัญพอๆ กัน!)
3. ระบุจำนวนหน่วยงาน/สาขาที่ต้องใช้ระบบ
4. ระบุจำนวนผู้ใช้ (total + concurrent)

Functional Requirements

5. แยก Functional Requirements ตามโมดูลอย่างชัดเจน
6. ทุก requirement วัดได้ (มีตัวเลข/เกณฑ์)
7. ไม่มี requirement ที่ขัดแย้งกัน
8. ผู้ใช้จริง (ไม่ใช่แค่ IT) มีส่วนร่วมในการเขียน
9. ครอบคลุมกระบวนการ end-to-end (ไม่ใช่แค่ทำได้ แต่เชื่อมต่อกัน)
10. ระบุรายงานที่ต้องการ พร้อมรูปแบบ (Excel/PDF/Dashboard)

Non-Functional Requirements

11. ระบุ Performance เป็นตัวเลข (Response Time, Throughput)
12. ระบุ Security Requirements (OWASP, 2FA, RBAC, Audit Trail)
13. ระบุ Availability + Backup/DR (Uptime, RPO, RTO)
14. ระบุ Browser + Device ที่ต้องรองรับ

Integration & Data

15. ระบุทุกระบบที่ต้องเชื่อมต่อ + วิธีเชื่อมต่อ (API/File/DB)
16. ระบุข้อมูลที่ต้อง Migrate + ปริมาณ + รูปแบบ
17. ระบุ Data Retention Policy (เก็บข้อมูลกี่ปี)

อื่นๆ

18. ระบุแผนอบรม (จำนวนคน, รอบ, สถานที่, คู่มือ)
19. ระบุ SLA + เงื่อนไข Warranty อย่างชัดเจน
20. ระบุ Acceptance Criteria + วิธีตรวจรับแต่ละ Phase

"โครงการ ERP ที่ดี เริ่มจาก Requirement Spec ที่ดี — ไม่มีทางลัด ถ้าเขียน spec ไม่ชัด สิ่งที่ได้คือระบบที่ไม่ตรงความต้องการ ใช้เวลาอีก 1 สัปดาห์เขียน spec ให้ดี ดีกว่าใช้เวลาอีก 6 เดือนแก้ระบบที่ผิด"

แหล่งอ้างอิง

• Panorama Consulting Group — "ERP Report 2024: Common Causes of Project Failure"
• Gartner — "How to Write an Effective ERP RFP" (2024)
• สำนักงบประมาณ — "แนวทางการจัดทำ TOR สำหรับโครงการด้านเทคโนโลยีสารสนเทศ"
• OWASP Foundation — "OWASP Application Security Verification Standard (ASVS) v4.0"