How to Write Requirement Spec for ERP Projects

Requirement Spec vs TOR vs RFP — What's the Difference?

Many organizations confuse these three documents. In reality, they serve different purposes, but the Requirement Spec is the core of both TOR and RFP — if you write a good Requirement Spec, it can be incorporated into either document.

Item	Requirement Spec	TOR (Government)	RFP (Private Sector)
Purpose	Define technical requirements	Define procurement scope	Invite vendors to propose solutions
Prepared By	IT Team + Business Analyst	Procurement Committee + IT Team	IT Team + Procurement
Legal Basis	No mandatory regulations	Government Procurement Act 2017	Company policy
Level of Detail	Very detailed (technical)	Detailed + legal conditions	Moderate (open for vendor proposals)
Published On	Internal / sent to vendor	e-GP system (government procurement)	Sent directly to invited vendors
Reference Price	Not required	Required (government mandate)	May or may not be included
Vendor Qualifications	Not specified	Clearly specified (registered capital, track record)	Varies by organization

Structure of a Good Requirement Spec — 12 Essential Sections

Whether you are writing a Requirement Spec, TOR, or RFP, the following structure covers all the necessary dimensions:

#	Section	What to Specify
1	Introduction & Objectives	Project background, problems to solve, main goals, KPIs for measuring success
2	Project Scope	Required modules, number of departments/branches, what is in scope and what is out of scope (critically important!)
3	Functional Requirements	Functional needs organized by module: Budget, Finance/Accounting, Procurement, Inventory/Warehouse, HR, Reports
4	Non-Functional Requirements	Performance, Security, Availability, Scalability, Accessibility (WCAG 2.1) — see details in the next section
5	User Requirements	Number of users (concurrent + total), user groups (admin, approver, viewer), permissions (RBAC), languages (TH/EN)
6	Data Migration	What data to migrate, format, volume, source systems, method (Big Bang / Phased), how many years of historical data
7	Integration	Systems to integrate: GFMIS, e-GP, banks, e-Tax Invoice, DPIS, e-Saraban; integration method (API/File/DB)
8	Technical Requirements	OS, Database (PostgreSQL/Oracle), Browser, standards, Cloud/On-premise, Open Source/Proprietary
9	Training & Change Management	How many trainees, how many sessions, location, manuals (quantity, print/online), Change Management plan
10	SLA & Support	Response Time, Resolution Time, service hours, contact channels, warranty period
11	Acceptance Criteria	Deliverables per Phase, UAT (who tests, how many days, how many test cases), Performance Test, acceptance criteria
12	Timeline & Milestones	Number of Phases, duration per Phase, deliverables per milestone, payment installments, payment conditions

Functional Requirement Examples — Good vs Bad

The most common problem is writing specs that are too vague, allowing vendors to interpret them in multiple ways — the result is a system that "meets the spec" but "doesn't meet the actual needs." See the comparison examples below:

Module	❌ Bad (Too Vague)	✅ Good (Specific)
Budget	"The system must manage budgets"	"The system must support 3-level budget allocation (Plan/Program/Activity) according to the defined budget structure, supporting appropriated funds, non-appropriated funds, and revenue funds, displaying allocated amount, committed amount, spent amount, and remaining balance in real-time"
Reports	"The system must generate reports"	"The system must generate budget spending status reports by funding source, program, output, and activity, showing allocated, spent, committed, and remaining amounts, with Export to Excel/PDF and support for Scheduled Reports"
Users	"The system must support multiple users"	"The system must support at least 200 Concurrent Users with Response Time ≤ 3 seconds for all screens and ≤ 10 seconds for reports with more than 100,000 rows"
Procurement	"The system must handle procurement"	"The system must support the full procurement process from PR → PO → GR → Invoice → Payment with at least 3-level approval workflow (Requester → Section Head → Director) and generate e-GP documents"
Inventory	"The system must manage stock"	"The system must manage inventory using FIFO, support Barcode/QR Code Scan for receiving and issuing, alert when items fall below Minimum Stock, support Stock Take with Aging Report"
HR	"The system must manage HR"	"The system must store personnel data per DPIS standard (Comptroller General's Department), support leave, tardiness, absence, and OT management, calculate payroll, and integrate with bank transfer systems (BAHTNET/Bulk Payment)"
Security	"The system must be secure"	"The system must pass OWASP Top 10 testing, support 2FA (Two-Factor Authentication), implement RBAC (Role-Based Access Control), maintain Audit Trail logging all access and data modifications, retain logs for at least 1 year, and encrypt data with TLS 1.2+"
Integration	"The system must connect to other systems"	"The system must integrate with GFMIS (send daily disbursement data in XML format per Comptroller General's Department standard), e-GP (retrieve vendor and contract data), and banks (transfer funds via API/File Upload per BAHTNET standard)"

Non-Functional Requirements That Are Often Overlooked

Functional Requirements tell you "what the system must do", while Non-Functional Requirements tell you "how well the system must do it" — many organizations write only Functional Requirements and forget Non-Functional ones, which is why systems end up "working but slow / insecure / frequently crashing."

Category	Example Requirement	How to Test
Performance	Response Time ≤ 3 seconds (standard screens), ≤ 10 seconds (reports)	Load Testing with JMeter/k6
Availability	Uptime ≥ 99.5%, Planned Maintenance only outside Office Hours (18:00-06:00)	Monitoring (Uptime Robot, Grafana)
Security	Pass OWASP Top 10, 2FA, RBAC, Audit Trail, TLS 1.2+, retain Logs ≥ 1 year	Penetration Testing + Security Audit
Scalability	Scale from 200 → 2,000 users within 3 years without changing architecture	Capacity Planning + Stress Test
Accessibility	WCAG 2.1 Level AA — support Screen Reader, Keyboard Navigation	aXe / Lighthouse Audit
Backup & DR	Daily Full Backup, RPO ≤ 24 hrs, RTO ≤ 4 hrs, DR Site separate from Production	DR Drill once per year
Browser	Support Chrome, Edge, Firefox (latest 2 versions) + Mobile Safari/Chrome	Cross-browser Testing
Data Retention	Retain transaction data for 10 years per Accounting Act + PDPA	Review Data Lifecycle Policy

20-Point Checklist Before Submitting Your Requirement Spec

Before sending the spec to vendors or submitting a TOR to the e-GP system, make sure every item is checked:

Scope

1. Clearly define what is in scope (which modules)
2. Clearly define what is out of scope (equally important!)
3. Specify the number of departments/branches that will use the system
4. Specify the number of users (total + concurrent)

Functional Requirements

5. Separate Functional Requirements clearly by module
6. Every requirement is measurable (with numbers/criteria)
7. No conflicting requirements
8. Actual end users (not just IT) participated in writing
9. Cover end-to-end processes (not just individual functions, but how they connect)
10. Specify required reports with format (Excel/PDF/Dashboard)

Non-Functional Requirements

11. Specify Performance with numbers (Response Time, Throughput)
12. Specify Security Requirements (OWASP, 2FA, RBAC, Audit Trail)
13. Specify Availability + Backup/DR (Uptime, RPO, RTO)
14. Specify supported Browsers + Devices

Integration & Data

15. List all systems to integrate + integration method (API/File/DB)
16. Specify data to Migrate + volume + format
17. Specify Data Retention Policy (how many years to retain data)

Others

18. Specify training plan (number of people, sessions, location, manuals)
19. Clearly specify SLA + Warranty conditions
20. Specify Acceptance Criteria + acceptance process for each Phase

"A successful ERP project starts with a good Requirement Spec — there are no shortcuts. If the spec is unclear, the result is a system that doesn't meet your needs. Spending one more week writing a solid spec is far better than spending six more months fixing a system that was built wrong."

References

• Panorama Consulting Group — "ERP Report 2024: Common Causes of Project Failure"
• Gartner — "How to Write an Effective ERP RFP" (2024)
• Bureau of the Budget (Thailand) — "Guidelines for Writing TOR for IT Projects"
• OWASP Foundation — "OWASP Application Security Verification Standard (ASVS) v4.0"