Bỏ qua menu, vào nội dung chính

← Tin tức · Hướng dẫn

26/03/2026 · 8 phút đọc

Cách viết tài liệu nghiệp vụ cho dự án phần mềm — template 8 phần

Tài liệu nghiệp vụ (BRD - Business Requirement Document) là cầu nối giữa doanh nghiệp và vendor. Viết tốt → dự án thành công 80%. Viết tệ → dự án overrun 50-100% scope creep. Bài này là template 8 phần + ví dụ cụ thể cho doanh nghiệp Việt.

BRDTài liệuQuy trình

Tại sao BRD quan trọng

Vendor báo giá dựa scope không rõ → end up tranh chấp. Có BRD rõ: vendor báo giá đúng, không phát sinh "feature ngoài scope". Đầu tư 2-4 tuần viết BRD tiết kiệm 30-60% cost overrun sau.

Template 8 phần

1. Context + Objective (1-2 trang)

Doanh nghiệp đang ở đâu, vấn đề gì, dự án này giải quyết điều gì. Vd: "Công ty C có 8 cửa hàng F&B, doanh thu 50 tỷ/năm. Hiện tổng hợp doanh thu manual mất 6h/ngày. Mục tiêu: tự động hoá báo cáo, BGĐ có dashboard realtime".

2. Stakeholder + Role (1 trang)

Ai liên quan dự án: sponsor (CEO), product owner (manager), end users (ai dùng), vendor team. Mỗi vai trò làm gì, decision authority đến đâu.

3. Current state + Pain (2-4 trang)

Quy trình hiện tại chi tiết: ai làm gì, dùng tool gì, mất bao lâu. Pain point cụ thể với metric. Vd: "Ca trưởng cửa hàng A xuất Excel cuối ngày 23h, gửi qua Zalo group. Kế toán tổng hợp 12 file vào master sheet, mất 4-6h. Doanh thu tổng available 11h trưa hôm sau".

4. Future state (2-3 trang)

Quy trình mong muốn sau dự án: ai làm gì, mất bao lâu. Vd: "POS từng cửa hàng auto-sync data về DB trung tâm mỗi 5 phút. Kế toán mở dashboard 8h sáng, doanh thu sẵn — không cần tổng hợp manual. CEO check trên iPhone bất kỳ lúc nào".

5. Functional requirements (5-10 trang)

Chi tiết từng feature như user story:

  • "Là ca trưởng, tôi muốn đóng ca cuối ngày với 1 click để báo cáo doanh thu tự động."
  • "Là kế toán, tôi muốn xem dashboard tổng hợp 8 cửa hàng realtime để không cần tổng hợp manual."
  • "Là CEO, tôi muốn nhận notification Zalo 23h hằng ngày với tổng doanh thu + top 3 cửa hàng."

6. Non-functional (1-2 trang)

  • Performance: dashboard load < 3s.
  • Concurrent users: 30 (8 cửa hàng + 5 head office).
  • Uptime: 99% (cho phép 7 giờ downtime/tháng).
  • Security: HTTPS, audit log, role-based access.
  • Compliance: ND13 + e-invoice tích hợp.

7. Constraints (1 trang)

  • Budget: 300tr.
  • Timeline: go-live trước Tết (5 tháng).
  • Tech stack preferred: web app, không native mobile.
  • Integration cần thiết: với MISA accounting hiện tại.

8. Success criteria + KPI (1-2 trang)

  • Thời gian tổng hợp báo cáo: < 30 phút (giảm 90%).
  • Báo cáo available cho CEO: trước 23h thay 11h trưa.
  • Sai sót doanh thu/tháng: < 0.5%.
  • Adoption rate ca trưởng: > 95% sau 1 tháng.
  • Doanh thu năm 2 sau triển khai: tăng 15% (target).

Best practices

  • Viết BRD bằng ngôn ngữ business, không kỹ thuật.
  • User story format cho functional req — dễ hiểu cho non-tech.
  • Có wireframe sơ bộ (Figma đơn giản hoặc paper sketch).
  • Review BRD với 5-7 end users trước khi share vendor.
  • Version control — mỗi revision đánh số rõ.

Sai lầm phổ biến của doanh nghiệp Việt

  • Mô tả "như Lazada" hoặc "giống Tiki" — quá vague, vendor diễn giải khác doanh nghiệp.
  • Bỏ qua workflow đặc thù (Zalo OA notification, e-invoice VN, tích hợp VNPay/Momo).
  • Viết BRD bằng English khi team đọc chính là người Việt — mất nuance.
  • Skip review với end-user thật, chỉ CEO + IT đọc.
  • Không cập nhật BRD khi scope thay đổi — phiên bản floating gây tranh chấp.

Cần Alodev hỗ trợ viết BRD cho dự án doanh nghiệp Việt? Gói 25-60tr cho 2-4 tuần audit + viết tài liệu. Liên hệ tại /lien-he.

Cần tư vấn?

Founder phản hồi
trong 24 giờ.