Cách viết tài liệu yêu cầu phần mềm (SRS) cho người không làm IT

Tài liệu yêu cầu phần mềm là văn bản mô tả phần mềm cần làm gì, cho ai dùng và thế nào là làm xong. Người không làm IT hoàn toàn viết được bản này, vì nội dung chính là nghiệp vụ: quy trình hiện tại, ai làm việc gì, cần những màn hình, biểu mẫu, báo cáo nào. Phần kỹ thuật như kiến trúc, cơ sở dữ liệu là việc của đơn vị phát triển. Bài viết đưa ra cấu trúc 8 phần, cách viết từng phần và một mẫu để bạn bắt đầu.

SRS là gì và người không làm IT cần viết đến đâu

SRS (Software Requirements Specification) là tài liệu đặc tả yêu cầu phần mềm. Một bản SRS đầy đủ do chuyên viên phân tích nghiệp vụ (BA) viết thường có cả đặc tả chi tiết từng màn hình, quy tắc dữ liệu, yêu cầu kỹ thuật.

Doanh nghiệp không cần tự viết bản đầy đủ đó. Điều doanh nghiệp nên chuẩn bị là bản yêu cầu nghiệp vụ: mô tả đủ rõ để đơn vị phát triển hiểu vấn đề, ước lượng được khối lượng và đặt đúng câu hỏi. Từ bản này, BA của đơn vị phát triển sẽ làm việc cùng bạn để hoàn thiện thành SRS. Bước này nằm ở giai đoạn đầu của quy trình phát triển phần mềm theo yêu cầu.

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

• Báo giá sát hơn: không có tài liệu, đơn vị phát triển phải đoán phạm vi, giá có thể chênh nhau nhiều lần giữa các bên. Xem thêm các yếu tố quyết định chi phí làm phần mềm theo yêu cầu.
• So sánh được các đơn vị: cùng một tài liệu gửi cho nhiều bên, các báo giá mới so sánh được với nhau.
• Thống nhất nội bộ: khi viết, các phòng ban buộc phải thống nhất quy trình, nhiều vướng mắc lộ ra từ bước này.
• Căn cứ nghiệm thu: cuối dự án, tài liệu là cơ sở để kiểm tra phần mềm đã đúng yêu cầu chưa.

Cấu trúc tài liệu yêu cầu phần mềm 8 phần

1. Bối cảnh và mục tiêu

Doanh nghiệp làm gì, đang gặp vấn đề gì, phần mềm giải quyết vấn đề nào. Mục tiêu nên đo được, ví dụ “kế toán không phải nhập lại đơn hàng từ Excel”, thay vì “nâng cao hiệu quả quản lý”.

2. Người dùng và vai trò

Liệt kê các nhóm người sẽ dùng phần mềm: nhân viên kinh doanh, thủ kho, kế toán, quản lý chi nhánh, khách hàng… Với mỗi nhóm, ghi số người dự kiến, dùng trên máy tính hay điện thoại, và được xem, sửa những gì.

3. Quy trình hiện tại và quy trình mong muốn

Mô tả từng bước công việc hiện tại: ai làm, dùng công cụ gì, dữ liệu chuyển đi đâu, chỗ nào hay sai hoặc chậm. Sau đó mô tả quy trình mong muốn khi có phần mềm. Không cần vẽ sơ đồ chuyên nghiệp, gạch đầu dòng theo thứ tự là đủ.

4. Danh sách chức năng

Cách dễ viết nhất là theo mẫu câu chuyện người dùng (user story):

Là [vai trò], tôi muốn [làm việc gì], để [đạt được điều gì].

Mỗi chức năng nên kèm tiêu chí nghiệm thu: những điều kiện cụ thể để coi chức năng đó là làm xong.

5. Dữ liệu, biểu mẫu và báo cáo

Đính kèm các file Excel, mẫu phiếu, mẫu báo cáo đang dùng. Đây là phần giúp đơn vị phát triển hiểu dữ liệu nhanh nhất. Ghi rõ dữ liệu cũ có cần chuyển sang phần mềm mới không, khối lượng khoảng bao nhiêu.

6. Tích hợp với hệ thống khác

Phần mềm cần lấy hoặc gửi dữ liệu sang đâu: phần mềm kế toán, hóa đơn điện tử, cổng thanh toán, Zalo OA, website, sàn thương mại điện tử. Ghi tên phần mềm cụ thể đang dùng.

7. Yêu cầu phi chức năng

Những yêu cầu không phải tính năng nhưng ảnh hưởng lớn đến thiết kế và chi phí:

• Số người dùng đồng thời dự kiến, hiện tại và vài năm tới.
• Thiết bị: máy tính, điện thoại, máy quét, máy in tem.
• Có cần dùng khi mất mạng không.
• Dữ liệu đặt ở đâu, yêu cầu bảo mật, sao lưu.
• Ngôn ngữ giao diện, múi giờ, đơn vị tiền tệ.

8. Phạm vi, ưu tiên và những gì không làm

Không phải chức năng nào cũng cần có ngay ở phiên bản đầu. Phân loại ưu tiên giúp kiểm soát chi phí và thời gian. Một cách phổ biến là phân thành bốn nhóm: bắt buộc có, nên có, có thì tốt, và chưa làm ở giai đoạn này. Ghi rõ nhóm cuối giúp tránh hiểu nhầm về phạm vi.

Mẫu tài liệu yêu cầu để bắt đầu

Mẹo viết cho người không làm IT

• Viết bằng ngôn ngữ nghiệp vụ của doanh nghiệp, không cần dùng thuật ngữ kỹ thuật.
• Tránh từ mơ hồ như “nhanh”, “dễ dùng”, “đầy đủ”. Thay bằng mô tả cụ thể: “thủ kho tạo phiếu xuất trên điện thoại khi đứng ở kệ hàng”.
• Ghi cả trường hợp ngoại lệ: khách trả hàng, đơn bị hủy giữa chừng, người duyệt nghỉ phép. Ngoại lệ thường chiếm nhiều công sức phát triển hơn luồng chính.
• Đưa ví dụ thật: một đơn hàng, một phiếu đề nghị đã xóa thông tin nhạy cảm giúp đơn vị phát triển hiểu nhanh hơn nhiều trang mô tả.
• Để người dùng thật góp ý: người làm việc hằng ngày biết những chi tiết mà quản lý thường bỏ sót.

Những sai lầm thường gặp

• Mô tả giải pháp thay vì vấn đề. “Cần một nút xuất Excel” có thể thực chất là “kế toán cần số liệu để nhập vào phần mềm kế toán”, và giải pháp tốt hơn là kết nối trực tiếp.
• Sao chép tính năng của phần mềm khác mà không xác định doanh nghiệp có thật sự cần.
• Muốn có tất cả ở phiên bản đầu. Phạm vi lớn làm tăng chi phí, kéo dài thời gian và tăng rủi ro.
• Coi tài liệu là bất biến. Yêu cầu sẽ thay đổi khi người dùng thấy phần mềm thật. Cần thống nhất cách xử lý thay đổi ngay từ đầu.

Nếu bạn đã có bản mô tả sơ bộ, dù chỉ vài trang, DTCSoft có thể cùng bạn phân tích và hoàn thiện thành tài liệu yêu cầu trước khi báo giá. Tìm hiểu thêm về dịch vụ phát triển phần mềm theo yêu cầu.

Câu hỏi thường gặp