SRS là gì? Đó là viết tắt của Software Requirements Specification, tức tài liệu đặc tả yêu cầu phần mềm. Nói đơn giản, đây là bản ghi rõ phần mềm phải làm những việc gì, cho ai dùng, theo quy tắc nào, để hai bên (bạn và đơn vị làm phần mềm) cùng hiểu một thứ trước khi bắt tay vào làm.
Sách giáo khoa mô tả SRS rất dài và nhiều khuôn mẫu. Với doanh nghiệp vừa và nhỏ, bạn không cần như vậy. Một tài liệu gọn, đọc được trong một buổi và chốt được những điểm hay gây tranh cãi sau này mới là thứ có ích.
SRS khác gì brief
Brief là bản bạn viết để mô tả nhu cầu, xem cách viết brief dự án phần mềm. SRS đi sâu hơn một bậc và thường do đơn vị làm phần mềm soạn sau khi khảo sát, rồi bạn xem lại và xác nhận. Brief nói "tôi cần gì". SRS nói "phần mềm sẽ làm đúng những gì, hoạt động ra sao".
Những phần nên có trong bản SRS gọn
Mục tiêu và phạm vi
Vài đoạn nêu phần mềm giải quyết vấn đề gì, và điều quan trọng không kém: những gì nằm ngoài phạm vi. Ghi rõ "không bao gồm" giúp tránh hiểu nhầm về sau.
Vai trò người dùng
Liệt kê từng vai trò (chủ doanh nghiệp, kế toán, kho, nhân viên, khách hàng) và việc mỗi vai trò được làm, được xem, được sửa. Đây là nền cho việc phân quyền.
Chức năng theo từng quy trình
Mỗi chức năng nên mô tả bằng câu chuyện ngắn: ai làm gì, ở màn hình nào, kết quả là gì. Ví dụ giả định: "Nhân viên bán hàng tạo đơn, chọn khách và sản phẩm, hệ thống tính tổng, quản lý duyệt, kho nhận lệnh xuất." Câu chuyện như vậy dễ kiểm chứng hơn một dòng "quản lý đơn hàng".
Quy tắc nghiệp vụ
Đây là phần dễ bị bỏ quên nhất mà lại gây lỗi nhiều nhất. Ví dụ: chiết khấu áp dụng thế nào, đơn quá hạn mức công nợ có được duyệt không, ai được hủy đơn đã xuất kho. Hãy ghi từng quy tắc thành câu rõ ràng.
Dữ liệu và báo cáo
Phần mềm lưu những loại thông tin nào, báo cáo nào cần xem, ai xem. Nếu có dữ liệu cũ cần chuyển sang, nêu nguồn và tình trạng của nó.
Kết nối với hệ thống khác
Kế toán, Zalo OA, cổng thanh toán, máy in tem, hệ thống có sẵn. Ghi rõ hướng trao đổi dữ liệu và ai cung cấp thông tin truy cập.
Yêu cầu phi chức năng
Nghe kỹ thuật nhưng thực ra là những câu hỏi rất đời thường:
- Bao nhiêu người dùng cùng lúc
- Dùng trên máy tính, điện thoại hay cả hai
- Yêu cầu bảo mật, phân quyền, nhật ký thao tác
- Sao lưu dữ liệu và khôi phục
- Ngôn ngữ, định dạng ngày, tiền tệ
Tiêu chí nghiệm thu
Với mỗi nhóm chức năng, ghi cách bạn kiểm tra là đạt. Ví dụ: "tạo được đơn, duyệt được, in được phiếu, báo cáo cuối ngày khớp số liệu". Tiêu chí nghiệm thu rõ là thứ bảo vệ cả hai bên khi bàn giao.
Cách đọc SRS khi bạn không phải người kỹ thuật
Bạn không cần hiểu mọi thuật ngữ. Hãy đọc theo ba câu hỏi:
- Những quy trình mô tả có đúng với cách doanh nghiệp bạn làm không
- Có trường hợp ngoại lệ nào bạn thấy ngoài đời mà tài liệu chưa nhắc tới (đơn trả hàng, hủy đơn, khách đổi địa chỉ)
- Phần "để sau" và "ngoài phạm vi" có đúng như hai bên đã thỏa thuận không
Gặp chỗ chưa rõ, hãy yêu cầu đổi sang một ví dụ cụ thể. Tài liệu tốt phải đọc được bằng ví dụ.
SRS và việc chia giai đoạn
Một SRS gọn cho từng giai đoạn thường hiệu quả hơn một tài liệu khổng lồ cho toàn hệ thống. Bạn mô tả kỹ giai đoạn đầu, phần sau chỉ phác thảo và chi tiết hóa khi tới lượt. Cách chia này được bàn trong giao phần mềm theo giai đoạn.
Khi nào chưa cần SRS đầy đủ
- Công cụ rất nhỏ, một chức năng, ít người dùng: một trang mô tả và vài ví dụ là đủ.
- Bạn còn đang thử ý tưởng và chưa rõ quy trình: tài liệu viết quá sớm sẽ nhanh lỗi thời, hãy làm một bản nhỏ để học trước.
- Hai bên chưa thống nhất quy trình nội bộ: SRS sẽ ghi lại sự mâu thuẫn chứ không giải quyết được nó.
Ngược lại, SRS càng đáng viết khi có nhiều bộ phận dùng chung, có tiền và dữ liệu nhạy cảm đi qua, hoặc khi người ký hợp đồng không phải người dùng hằng ngày.
Tài liệu sống, không phải giấy tờ đóng băng
Yêu cầu sẽ thay đổi khi người dùng thấy bản chạy thật. Điều đáng làm là thỏa thuận cách thay đổi: ai đề xuất, ai chấp thuận, ảnh hưởng đến phạm vi và báo giá ra sao. Một SRS có phiên bản và có ghi chú thay đổi rõ ràng giúp mọi người cùng biết mình đang ở đâu.
Bước tiếp theo
Nếu bạn muốn một tài liệu như vậy cho dự án của mình, bắt đầu bằng brief rồi trao đổi với chúng tôi. Cách chúng tôi làm việc từ khảo sát đến bàn giao nằm ở trang dịch vụ viết phần mềm theo yêu cầu cho doanh nghiệp. Nếu hệ thống của bạn thiên về quản lý nội bộ, hãy xem thêm phần mềm quản lý theo yêu cầu.
