Cách viết tài liệu đặc tả yêu cầu phần mềm cho người không làm kỹ thuật (kèm mẫu)

Cách viết tài liệu đặc tả yêu cầu phần mềm cho người không làm kỹ thuật thực ra chỉ xoay quanh 5 nhóm thông tin: ai dùng, họ làm việc gì trên phần mềm, dữ liệu gì cần lưu, báo cáo gì cần xem và quy trình duyệt đi qua những ai. Bạn không cần biết lập trình, không cần vẽ giao diện, không cần dùng thuật ngữ IT — chỉ cần mô tả đúng công việc đang diễn ra ở công ty mình bằng tiếng Việt thường ngày. Một bản 1–2 trang viết rõ ràng thường đã đủ để bên làm phần mềm hiểu và báo giá, và tôi sẽ đưa mẫu bảng cụ thể ngay trong bài này.

Đặc tả yêu cầu phần mềm là gì — bản mô tả «phần mềm phải làm gì», không phải «làm bằng gì»

Đặc tả yêu cầu phần mềm là tài liệu mô tả phần mềm cần làm được những gì cho công việc của bạn, chứ không mô tả nó được xây bằng công nghệ nào. Chuyện dùng AppSheet, web app, Google Sheet hay SQL là việc của người làm; việc của bạn là nói rõ nghiệp vụ.

Tôi hay giải thích với khách bằng hình ảnh xây nhà: bạn là chủ nhà, bạn nói «nhà 3 phòng ngủ, bếp thông phòng khách, có chỗ để xe cho 2 ô tô, ngân sách khoảng chừng này». Bạn không cần chỉ định mác thép hay loại bê tông — đó là phần của kiến trúc sư và nhà thầu. Bản đặc tả yêu cầu cũng vậy.

Hai kiểu câu dưới đây cho thấy khác biệt rất rõ:

• Nên viết (nghiệp vụ): «Nhân viên kho tạo phiếu nhập trên điện thoại, chụp ảnh chứng từ; phiếu phải được kế toán xác nhận thì tồn kho mới thay đổi.»
• Không cần viết (kỹ thuật): «Dùng bảng quan hệ một–nhiều, viết hàm cập nhật tồn kho bằng công thức ảo.»

Khi bạn viết theo kiểu thứ nhất, người làm phần mềm có thể ước lượng được khối lượng việc. Khi bạn viết theo kiểu thứ hai mà hiểu chưa đúng, bạn vô tình trói tay người làm vào một giải pháp dở.

Người không làm kỹ thuật chỉ cần viết những gì?

Chỉ cần 5 nhóm thông tin. Nếu trả lời được 5 nhóm này cho từng phòng ban, bạn đã có một bản đặc tả dùng được.

Năm nhóm thông tin bắt buộc

1. Ai dùng (vai trò). Liệt kê theo chức danh thật trong công ty: nhân viên kinh doanh, thủ kho, kế toán, trưởng phòng, giám đốc. Ghi luôn số người mỗi nhóm và họ dùng điện thoại hay máy tính.
2. Họ làm việc gì trên phần mềm. Mỗi vai trò làm gì, theo thứ tự thời gian trong ngày. Ví dụ: «thủ kho: nhận hàng → tạo phiếu nhập → in phiếu → cuối ngày xem tồn».
3. Dữ liệu gì cần lưu. Cách nhanh nhất: mở các file Excel và sổ giấy đang dùng ra, chụp lại hoặc gửi luôn. Mỗi cột trong file là một trường dữ liệu.
4. Báo cáo gì cần xem. Ai xem, xem theo kỳ nào (ngày/tuần/tháng), lọc theo gì (chi nhánh, nhân viên, khách hàng). Đây là phần hay bị quên nhất.
5. Quy trình duyệt. Việc nào cần ai đồng ý trước khi chạy tiếp, duyệt mấy cấp, ai được xem dữ liệu của ai.

Viết xong 5 nhóm này là bạn đã nắm được cách viết đặc tả yêu cầu phần mềm ở mức đủ dùng cho doanh nghiệp vừa và nhỏ. Phần còn lại chỉ là trình bày cho gọn.

Kinh nghiệm của tôi: buổi đầu không cần tài liệu hoàn hảo

Nói thật là tôi chưa từng nhận được một bản đặc tả «chuẩn sách giáo khoa» từ khách hàng vừa và nhỏ, và cũng không cần. Với các dự án web app quản lý làm theo yêu cầu bên tôi triển khai, buổi đầu khách chỉ cần mô tả thông tin cơ bản hoặc gửi một file Excel/Docs đơn giản đang dùng; phần nào chưa rõ thì người làm hỏi lại. Chi phí những dự án kiểu này thường rơi vào khoảng 5–50 triệu tuỳ phạm vi, và sau 5–7 ngày là có bản chạy thử đạt trên 90% yêu cầu để khách bấm thử rồi góp ý tiếp.

Tôi kể con số đó không phải để quảng cáo, mà để bạn bớt áp lực: viết tài liệu đặc tả yêu cầu phần mềm không phải bài thi. Một bản mô tả 1–2 trang rõ ràng giúp bạn tiết kiệm được 2–3 vòng họp và giúp bên làm báo giá sát hơn — thế là đủ. Bản đặc tả tốt nhất là bản bạn viết được trong một buổi chiều, rồi sửa dần sau khi xem bản chạy thử.

Mẫu tài liệu đặc tả 1 trang — điền vào bảng là xong

Dưới đây là mẫu tôi hay gửi khách tự điền trước buổi làm việc đầu tiên. Bạn mở Google Docs hoặc Word, kẻ đúng bảng này và điền theo từng phòng ban.

Vai trò	Việc họ làm trên phần mềm	Dữ liệu cần lưu	Báo cáo cần xem	Ưu tiên
Nhân viên kinh doanh (8 người, dùng điện thoại)	Tạo đơn hàng, ghi nhận thanh toán, cập nhật trạng thái giao	Khách hàng, mặt hàng, số lượng, đơn giá, ngày giao	Doanh số của chính mình theo tháng	Phải có
Thủ kho (2 người, điện thoại)	Tạo phiếu nhập/xuất, chụp ảnh chứng từ, kiểm kê	Mã hàng, số lượng, kho, ảnh chứng từ	Tồn kho hiện tại, hàng dưới mức cảnh báo	Phải có
Kế toán (1 người, máy tính)	Xác nhận phiếu, theo dõi công nợ, xuất file	Phiếu thu/chi, công nợ theo khách	Công nợ quá hạn, thu chi theo tháng	Phải có
Giám đốc (1 người, điện thoại)	Duyệt chi trên 5 triệu, xem tổng quan	Lịch sử duyệt	Dashboard doanh số – tồn kho – công nợ	Nên có

Ngoài bảng trên, thêm 4 dòng ngắn ở đầu tài liệu là tài liệu của bạn đã tròn trịa:

• Bối cảnh: công ty làm gì, bao nhiêu người, đang quản lý bằng gì (Excel, sổ tay, Zalo).
• Vấn đề đang gặp: 2–3 câu. Ví dụ «số liệu tồn kho giữa kho và kế toán lệch nhau, cuối tháng mất 2 ngày đối chiếu».
• Kết quả mong muốn: «xem được tồn kho theo thời gian thực», «sếp duyệt chi trên điện thoại».
• Ràng buộc: ngân sách dự kiến, thời hạn, dữ liệu phải lưu ở đâu, có cần dùng offline không.

Về cột Ưu tiên: chỉ dùng hai mức «Phải có» và «Nên có». Tôi không khuyến khích mức «Có thì tốt» vì ai cũng tick vào đó và cuối cùng không ai biết nên làm trước cái gì. Giai đoạn 1 chỉ làm nhóm «Phải có», chạy thật 2–4 tuần rồi mới bổ sung — cách này giảm rủi ro hơn nhiều so với làm một lần thật to.

Ví dụ đặc tả một chức năng: «Đề nghị thanh toán»

Đây là chức năng tôi được hỏi nhiều nhất, nên lấy làm ví dụ mẫu. Cách mô tả một chức năng gồm 4 phần: ai tạo, ai duyệt, các trạng thái, và ai được thông báo.

Mục đích: thay cho việc nhân viên in giấy đề nghị thanh toán rồi cầm đi tìm sếp ký.

1. Người tạo: bất kỳ nhân viên nào. Điền: ngày đề nghị, nội dung chi, số tiền, nhà cung cấp, ngày cần chi, ảnh chứng từ (hoá đơn, báo giá), chọn khoản mục chi phí từ danh sách có sẵn.
2. Người duyệt cấp 1: trưởng phòng của người tạo. Xem được đề nghị của phòng mình, bấm Duyệt hoặc Từ chối kèm lý do.
3. Người duyệt cấp 2: giám đốc, chỉ áp dụng khi số tiền lớn hơn mức quy định (ví dụ 5 triệu). Dưới mức đó thì duyệt cấp 1 là xong.
4. Kế toán: nhìn thấy các đề nghị đã duyệt, đánh dấu Đã chi, ghi ngày chi và hình thức chi (tiền mặt / chuyển khoản).

Các trạng thái và ai thấy gì:

Trạng thái	Ai chuyển trạng thái	Phần mềm làm gì
Nháp	Người tạo	Cho sửa, cho xoá
Chờ duyệt	Người tạo bấm Gửi	Khoá không cho sửa, báo cho trưởng phòng
Đã duyệt cấp 1	Trưởng phòng	Nếu trên 5 triệu thì báo tiếp giám đốc, nếu không thì báo kế toán
Từ chối	Người duyệt	Bắt buộc nhập lý do, báo lại người tạo
Đã chi	Kế toán	Ghi ngày chi, báo người tạo, lên báo cáo chi phí tháng

Hai dòng cuối cùng bạn nên viết thêm: phân quyền («nhân viên chỉ thấy đề nghị của mình; trưởng phòng thấy của phòng mình; kế toán và giám đốc thấy tất cả») và báo cáo («chi phí theo khoản mục và theo phòng ban trong tháng; danh sách đề nghị quá 3 ngày chưa duyệt»). Nếu bạn muốn xem kỹ hơn cách các luồng duyệt này vận hành trên thực tế, tôi có viết riêng một bài về phần mềm phê duyệt online trên điện thoại.

Lỗi hay gặp khi viết yêu cầu — và cách sửa ngay

Bốn lỗi dưới đây chiếm phần lớn các bản đặc tả tôi nhận được. Chúng đều dễ sửa nếu biết trước.

Lỗi	Ví dụ câu viết sai	Sửa thành
Viết chung chung	«Quản lý khách hàng chuyên nghiệp»	«Lưu khách hàng gồm tên, điện thoại, địa chỉ, người phụ trách; lọc theo người phụ trách; nhắc chăm sóc lại sau 30 ngày»
Liệt kê tính năng rời rạc, không gắn quy trình	«Cần có: đơn hàng, kho, thu chi, báo cáo»	Kể lại một đơn hàng đi từ lúc khách đặt → xuất kho → thu tiền → ghi doanh số, nêu rõ ai làm bước nào
Quên báo cáo	Chỉ mô tả phần nhập liệu	Liệt kê mỗi lãnh đạo cần xem con số gì, bao lâu một lần — nhập liệu mà không ai xem thì nhân viên sẽ bỏ nhập
Quên phân quyền	Không nhắc gì đến quyền xem	Ghi rõ ai thấy dữ liệu của ai, ai được sửa, ai được xoá, ai xem được giá vốn và lương

Thêm một lỗi nữa ít ai nói: mô tả phần mềm mơ ước thay vì công việc thật. Có anh chủ xưởng từng gửi tôi danh sách 40 chức năng chép từ một phần mềm ERP nước ngoài, trong khi xưởng chỉ có 12 người và 80% công việc nằm ở ba việc: nhận đơn, theo dõi tiến độ tổ sản xuất, tính lương khoán. Tôi đề nghị anh viết lại theo đúng một ngày làm việc thật của xưởng, danh sách rút còn 11 chức năng — và app dùng được ngay từ tháng đầu. Nếu bạn đang đứng trước việc chuẩn hoá quy trình trước khi làm app, bài số hoá quy trình nội bộ cho doanh nghiệp nhỏ đi sâu hơn vào bước này.

Dùng AI để viết bản nháp đặc tả — prompt mẫu và cách tự kiểm lại

AI viết bản nháp đặc tả rất nhanh, nhưng chỉ tốt khi bạn bắt nó hỏi ngược lại bạn thay vì tự bịa. Mẹo quan trọng nhất: yêu cầu AI phỏng vấn bạn theo từng nhóm câu hỏi, trả lời xong mới viết.

Prompt mẫu bạn có thể dán thẳng vào ChatGPT, Claude hay Gemini (sửa phần in nghiêng cho đúng công ty bạn):

Tôi là trưởng phòng kế toán của một công ty thương mại 30 người, không biết lập trình. Tôi muốn làm một phần mềm quản lý đề nghị thanh toán. Hãy đóng vai người phân tích nghiệp vụ và phỏng vấn tôi: hỏi tối đa 10 câu, chia thành 5 nhóm (ai dùng, các bước duyệt, dữ liệu cần lưu, báo cáo cần xem, phân quyền). Hỏi từng nhóm một, chờ tôi trả lời rồi mới hỏi tiếp, không tự giả định thay tôi. Sau khi đủ thông tin, viết lại thành bảng đặc tả 1 trang gồm các cột: vai trò, chức năng, dữ liệu, báo cáo, mức ưu tiên (phải có / nên có). Cuối cùng liệt kê những điểm tôi mô tả còn mơ hồ.

Nếu muốn hiểu thêm về nguyên tắc viết prompt rõ ràng, bạn có thể xem tài liệu hướng dẫn viết prompt của Anthropic; nguyên tắc chung là nêu rõ vai trò, bối cảnh và định dạng đầu ra mong muốn.

Sau khi có bản nháp, tự kiểm lại bằng 5 câu hỏi này trước khi gửi cho bên làm phần mềm:

1. Mỗi chức năng đã ghi rõ ai thao tác chưa? Nếu câu nào không có chủ ngữ thì còn mơ hồ.
2. Có chỗ nào AI tự thêm chức năng mà công ty bạn không cần không? Xoá thẳng tay.
3. Các con số, mức duyệt, tên phòng ban đã đúng với thực tế công ty chưa? AI rất hay điền số đẹp.
4. Phần báo cáo và phân quyền có bị bỏ trống không?
5. Đưa cho một nhân viên sẽ dùng app đọc thử — họ có thấy giống công việc hằng ngày của họ không?

Câu số 5 quan trọng nhất. Tài liệu do sếp viết một mình thường thiếu những tình huống lặt vặt mà chỉ người làm trực tiếp mới biết: hàng trả lại, khách đặt rồi huỷ, phiếu ghi nhầm phải sửa. Những tình huống «ngoại lệ» đó mới là chỗ tốn thời gian làm phần mềm nhất.

Tóm tắt và việc nên làm tiếp

Tóm lại, cách viết tài liệu đặc tả yêu cầu phần mềm cho người không làm kỹ thuật gồm ba bước: (1) liệt kê 5 nhóm thông tin — vai trò, công việc, dữ liệu, báo cáo, quy trình duyệt; (2) đổ vào bảng mẫu 1 trang và đánh dấu «Phải có / Nên có»; (3) viết chi tiết thêm cho 2–3 chức năng quan trọng nhất theo kiểu ví dụ «Đề nghị thanh toán» ở trên. Đừng cố viết hoàn hảo ngay — bản đặc tả sẽ còn sửa sau khi bạn nhìn thấy bản chạy thử đầu tiên.

Việc nên làm ngay tối nay: mở một file Google Docs, kẻ bảng 5 cột theo mẫu, và điền cho một phòng ban mà bạn thấy lộn xộn nhất. Mất khoảng 30 phút. Hôm sau đưa nhân viên phòng đó đọc và bổ sung.

Hai bài liên quan bạn nên đọc tiếp: thuê làm app quản lý: chuẩn bị gì, hỏi gì và tránh mất tiền oan và làm phần mềm quản lý theo yêu cầu: quy trình, chi phí và bảo trì.

Nếu viết xong bản mô tả mà bạn muốn có người đọc qua và ước lượng phạm vi giúp, bên tôi có nhận tư vấn và báo giá làm phần mềm — gửi đúng file bạn vừa viết là đủ để trao đổi.