Bỏ qua tới nội dung
Kinh nghiệm làm phần mềm

Tài liệu yêu cầu phần mềm: cách viết để báo giá đúng, làm không lệch

Tài liệu yêu cầu phần mềm: cách viết để báo giá đúng, làm không lệch

Hai công ty phần mềm báo cho cùng một “phần mềm quản lý bán hàng” hai mức giá chênh nhau gấp ba. Không bên nào báo sai: mỗi bên hiểu “quản lý bán hàng” theo một kiểu. Phần lớn chuyện lệch giá, lệch tiến độ và cãi nhau lúc nghiệm thu đều bắt đầu từ chỗ hai bên chưa viết ra cùng một bản mô tả.

Bản mô tả đó gọi là tài liệu yêu cầu phần mềm. Bài này hướng dẫn doanh nghiệp tự soạn tài liệu yêu cầu phần mềm ở mức đủ dùng, không cần biết lập trình, trước khi đi hỏi giá.

Tóm tắt nhanh

  • Tài liệu yêu cầu phần mềm mô tả phần mềm phải làm được gì, cho ai dùng, dữ liệu nào đi vào và đi ra.
  • Không cần viết theo chuẩn kỹ thuật. Viết bằng ngôn ngữ công việc hằng ngày là đủ để bên làm phần mềm báo giá sát.
  • 9 mục nên có: mục tiêu, người dùng, quy trình, chức năng, dữ liệu, báo cáo, kết nối, ràng buộc, tiêu chí nghiệm thu.
  • Tài liệu yêu cầu phần mềm tốt giúp so sánh báo giá giữa các bên trên cùng một phạm vi và là căn cứ khi nghiệm thu.
Tài liệu yêu cầu phần mềm mẫu: mục tiêu, quy trình, chức năng, phân quyền
Tài liệu yêu cầu phần mềm mẫu: mục tiêu, quy trình, chức năng, phân quyền

Tài liệu yêu cầu phần mềm là gì?

Tài liệu yêu cầu phần mềm (trong ngành hay gọi là SRS – Software Requirements Specification) là văn bản mô tả phần mềm cần làm được những gì. Nó trả lời ba câu hỏi: ai sẽ dùng, họ dùng để làm việc gì, và kết quả họ cần nhận được là gì.

Tài liệu này không phải bản thiết kế kỹ thuật. Doanh nghiệp không cần ghi dùng ngôn ngữ lập trình nào hay đặt máy chủ ở đâu. Phần đó là việc của bên làm phần mềm. Việc của doanh nghiệp là mô tả đúng cách mình đang làm việc và mong muốn thay đổi điều gì.

Vì sao nên có tài liệu yêu cầu phần mềm trước khi hỏi giá?

Báo giá sát và so sánh được

Khi gửi cùng một tài liệu yêu cầu phần mềm cho nhiều bên, các báo giá nằm trên cùng một phạm vi. Bên rẻ hơn có thể vì thiếu hạng mục, bên đắt hơn có thể vì làm kỹ hơn. Có tài liệu thì doanh nghiệp đối chiếu được từng dòng thay vì chỉ nhìn tổng tiền.

Ít phát sinh giữa chừng

Phần lớn chi phí phát sinh đến từ các yêu cầu “tưởng là hiển nhiên” nhưng chưa ai nói ra, ví dụ phân quyền cho từng chi nhánh hay in hóa đơn theo mẫu riêng. Viết ra từ đầu thì những thứ này được tính vào báo giá ngay.

Có căn cứ khi nghiệm thu

Lúc nghiệm thu, hai bên đối chiếu phần mềm với tài liệu yêu cầu phần mềm đã ký: chức năng nào có, chức năng nào thiếu. Không có tài liệu, nghiệm thu dễ thành tranh luận cảm tính.

9 mục cần có trong tài liệu yêu cầu phần mềm

Bảng dưới đây tóm tắt 9 mục. Phần sau giải thích cách viết từng mục kèm ví dụ.

MụcTrả lời câu hỏiVí dụ ngắn
1. Mục tiêuLàm phần mềm để giải quyết việc gì?Giảm sai lệch tồn kho giữa 3 cửa hàng
2. Người dùngAi dùng, mỗi người được làm gì?Thu ngân, thủ kho, quản lý, chủ doanh nghiệp
3. Quy trìnhCông việc đang chạy qua những bước nào?Nhận đơn → xuất kho → giao → thu tiền
4. Chức năngPhần mềm phải làm được những gì?Tạo đơn, trừ kho tự động, in phiếu giao
5. Dữ liệuThông tin nào cần lưu, lấy từ đâu?Danh mục 1.200 mặt hàng đang ở Excel
6. Báo cáoCần xem số liệu gì, theo kỳ nào?Doanh thu theo cửa hàng, theo tuần
7. Kết nốiPhải nối với hệ thống nào khác?Hóa đơn điện tử, Zalo OA, phần mềm kế toán
8. Ràng buộcThiết bị, thời hạn, ngân sách, quy định?Dùng được trên điện thoại, xong trước tháng 3
9. Nghiệm thuThế nào là “làm xong, đạt”?Tạo và giao 20 đơn mẫu không lỗi

1. Mục tiêu

Viết một đến ba câu về vấn đề đang gặp và kết quả mong muốn. Mục tiêu nên đo được. “Quản lý tốt hơn” khó kiểm tra; “chốt sổ cuối ngày trong 15 phút thay vì 2 giờ” thì kiểm tra được.

2. Người dùng và quyền

Liệt kê từng nhóm người dùng, số lượng dự kiến và việc mỗi nhóm được làm. Mục này quyết định phần phân quyền, vốn là phần hay bị bỏ sót.

  • Nhân viên bán hàng: tạo đơn, xem tồn kho, không xem giá vốn.
  • Thủ kho: nhập, xuất, kiểm kê.
  • Quản lý chi nhánh: duyệt đơn giảm giá, xem báo cáo chi nhánh mình.
  • Chủ doanh nghiệp: xem toàn bộ.

3. Quy trình hiện tại

Mô tả công việc đang chạy thế nào, kể cả phần đang làm bằng giấy, Excel hay Zalo. Cách dễ nhất là kể lại một đơn hàng hoặc một hồ sơ đi từ đầu đến cuối: ai nhận, ai kiểm, ai duyệt, giấy tờ gì được tạo ra. Có thể chụp ảnh các mẫu phiếu, sổ sách đang dùng và đính kèm.

Ghi thêm những điểm đang gây vướng: chờ duyệt lâu, nhập trùng, sai số. Đây chính là chỗ phần mềm tạo ra giá trị.

4. Chức năng cần có

Liệt kê chức năng theo dạng “người dùng làm được việc gì”. Mỗi dòng một việc. Sau đó đánh dấu mức ưu tiên:

  • Bắt buộc: thiếu là không dùng được.
  • Nên có: dùng được nhưng còn bất tiện.
  • Để sau: làm ở giai đoạn hai.

Chia ưu tiên giúp làm phần lõi trước, chạy thử sớm rồi mới mở rộng. Cách làm từng phần này được giải thích kỹ trong bài MVP là gì của Việt Thái Group.

5. Dữ liệu

Ghi các loại thông tin cần lưu (khách hàng, mặt hàng, hợp đồng…), dữ liệu cũ đang nằm ở đâu và khoảng bao nhiêu dòng. Chuyển dữ liệu cũ sang phần mềm mới là một hạng mục riêng, có công riêng, nên cần nói rõ ngay từ đầu.

6. Báo cáo

Liệt kê báo cáo đang dùng và báo cáo muốn có. Tốt nhất đính kèm một file Excel báo cáo mẫu. Ghi rõ ai xem, xem theo ngày, tuần hay tháng và có cần xuất ra Excel hay in không.

7. Kết nối với hệ thống khác

Các kết nối thường gặp: hóa đơn điện tử, phần mềm kế toán, Zalo OA để gửi thông báo, cổng thanh toán hoặc mã VietQR, máy chấm công, website bán hàng. Mỗi kết nối là một phần việc có chi phí riêng và đôi khi phụ thuộc vào nhà cung cấp bên kia, nên cần liệt kê đầy đủ.

8. Ràng buộc

Ghi những điều kiện không thể đổi: dùng trên điện thoại hay máy tính, có cần chạy khi mất mạng không, hạn chót phải dùng, ngân sách dự kiến, quy định ngành (ví dụ khai báo lưu trú, hóa đơn). Nói trước ngân sách không làm doanh nghiệp bị “báo giá theo túi tiền”; ngược lại, nó giúp bên làm phần mềm đề xuất phạm vi vừa ngân sách.

9. Tiêu chí nghiệm thu

Với mỗi chức năng bắt buộc, viết một tình huống kiểm tra cụ thể. Ví dụ: “Tạo đơn 5 mặt hàng, áp mã giảm 10%, tồn kho trừ đúng, in được phiếu giao”. Đến lúc nghiệm thu chỉ cần chạy lại các tình huống này.

Ví dụ: tài liệu yêu cầu phần mềm rút gọn một trang

Không phải dự án nào cũng cần tài liệu yêu cầu phần mềm dày. Với phần mềm nhỏ, một đến hai trang là đủ. Ví dụ cho một cửa hàng vật liệu xây dựng có 2 chi nhánh:

  • Mục tiêu: biết tồn kho thật của 2 chi nhánh theo thời gian thực; hết cảnh gọi điện hỏi kho.
  • Người dùng: 4 bán hàng, 2 thủ kho, 1 kế toán, chủ cửa hàng.
  • Chức năng bắt buộc: tạo đơn, trừ kho theo chi nhánh, chuyển kho giữa 2 chi nhánh, công nợ khách quen.
  • Dữ liệu: 800 mặt hàng và 300 khách quen đang ở Excel.
  • Báo cáo: doanh thu ngày theo chi nhánh, hàng sắp hết, công nợ quá hạn.
  • Kết nối: xuất hóa đơn điện tử.
  • Ràng buộc: dùng được trên điện thoại; chạy thử trong 6 tuần.
  • Nghiệm thu: chuyển 50 bao xi măng từ kho A sang kho B, tồn hai kho cập nhật đúng.

5 lỗi hay gặp khi viết tài liệu yêu cầu phần mềm

  1. Viết quá chung: “quản lý khách hàng” mà không nói quản lý những gì. Hãy viết thành việc cụ thể: lưu số điện thoại, lịch sử mua, nhắc chăm sóc sau 30 ngày.
  2. Sao chép tính năng phần mềm khác: liệt kê cả trăm tính năng của một phần mềm nổi tiếng trong khi chỉ dùng mười. Chi phí tăng mà không thêm giá trị.
  3. Bỏ qua người dùng thật: chỉ chủ doanh nghiệp viết, nhân viên trực tiếp làm không được hỏi. Kết quả là phần mềm đúng ý sếp nhưng khó dùng ở quầy.
  4. Không nói dữ liệu cũ: đến cuối dự án mới phát hiện phải chuyển 5 năm dữ liệu Excel.
  5. Không có tiêu chí nghiệm thu: hai bên không thống nhất được thế nào là “xong”.

Không tự viết được tài liệu yêu cầu phần mềm thì sao?

Doanh nghiệp không bắt buộc phải tự viết toàn bộ. Ở bước tiếp nhận và khảo sát của Viết Phần Mềm, chuyên viên làm việc trực tiếp với người dùng, hỏi theo bộ câu hỏi khảo sát và soạn tài liệu yêu cầu để doanh nghiệp duyệt. Bước này miễn phí. Doanh nghiệp chỉ cần chuẩn bị mẫu giấy tờ, file Excel đang dùng và dành thời gian trả lời.

Nếu đang phân vân nên làm phần mềm riêng hay dùng phần mềm có sẵn, xem thêm bài mua phần mềm hay làm riêng. Khi đã có tài liệu, có thể xem dịch vụ viết phần mềm và bảng giá tham khảo để hình dung chi phí.

Câu hỏi thường gặp về tài liệu yêu cầu phần mềm

Tài liệu yêu cầu phần mềm cần dài bao nhiêu trang?

Không có số trang cố định. Phần mềm nhỏ chỉ cần một đến hai trang theo 9 mục trong bài; hệ thống nhiều phân hệ có thể vài chục trang. Quan trọng là mỗi chức năng bắt buộc đều được mô tả và có tình huống nghiệm thu.

Có cần biết lập trình để viết tài liệu yêu cầu không?

Không. Doanh nghiệp viết bằng ngôn ngữ công việc hằng ngày: ai làm gì, giấy tờ gì, cần xem số liệu gì. Phần chuyển sang thiết kế kỹ thuật là việc của bên làm phần mềm.

Tài liệu yêu cầu có đưa vào hợp đồng không?

Nên đưa vào. Tài liệu đã thống nhất thường là phụ lục hợp đồng, làm căn cứ cho phạm vi công việc, báo giá và nghiệm thu. Yêu cầu thêm sau đó được tính là thay đổi phạm vi.

Viết Phần Mềm có hỗ trợ soạn tài liệu yêu cầu không?

Có. Ở bước tiếp nhận và khảo sát, chúng tôi soạn tài liệu yêu cầu cùng doanh nghiệp, miễn phí, rồi báo giá dựa trên tài liệu đó.

Cần tư vấn cho dự án của bạn?

Gửi cho chúng tôi những gì bạn đang có: file Excel, mẫu phiếu, ảnh sổ sách. Chúng tôi giúp soạn tài liệu yêu cầu và báo giá theo từng hạng mục, miễn phí.

ZaloNhắn Zalo 0941 388 887 Báo giá