Software Requirements Specification(SRS)
Tài liệu gom toàn bộ yêu cầu chức năng, phi chức năng, ràng buộc và giao diện của một phần mềm vào một chỗ, đủ chi tiết để đội phát triển xây và đội kiểm thử nghiệm thu.
Định nghĩa
SRS là tài liệu "một cửa" cho phần mềm: mở ra là thấy hệ thống phải làm gì, đạt chất lượng nào, tích hợp với ai, chịu ràng buộc gì. Chuẩn tham chiếu quen thuộc nhất là IEEE 830 (đã bị thay bởi ISO/IEC/IEEE 29148), nhưng ở thị trường VN gần như không ai áp nguyên bản — mỗi công ty có một template riêng, thường là bản rút gọn.
SRS mô tả yêu cầu đối với phần mềm. Mục tiêu kinh doanh nằm ở BRD, và trộn hai thứ vào một file là cách nhanh nhất để không ai biết phải đọc phần nào.
Nếu một câu trong tài liệu không nói về hành vi hoặc chất lượng của phần mềm, nó không thuộc SRS.
Gồm những gì
Bộ khung hay dùng, đã lược bớt cho hợp thực tế:
- Giới thiệu: phạm vi, đối tượng đọc, thuật ngữ, tài liệu tham chiếu.
- Mô tả tổng thể: bối cảnh hệ thống, các nhóm người dùng, giả định và phụ thuộc, ràng buộc.
- Yêu cầu giao diện: giao diện người dùng, giao diện với hệ thống ngoài (API, file, hàng đợi), giao diện phần cứng nếu có.
- Yêu cầu chức năng: theo module hoặc theo use case, mỗi yêu cầu một mã số.
- Yêu cầu phi chức năng: hiệu năng, bảo mật, khả dụng, tương thích, sao lưu phục hồi.
- Phụ lục: data dictionary, quy tắc nghiệp vụ, ma trận truy vết.
Phần 3 là phần bị bỏ nhiều nhất và trả giá đắt nhất ở dự án tích hợp. Hệ thống gọi sang core banking bằng giao thức gì, timeout bao nhiêu, retry mấy lần, ai chịu trách nhiệm đối soát khi lệch — không viết thì đến giai đoạn SIT mới bắt đầu bàn.
So sánh BRD, FRD, SRS và FS
Bốn tên này ở VN bị dùng lẫn lộn tới mức hỏi ra là nhiều ứng viên lúng túng. Cách phân biệt gọn nhất:
| BRD | FRD | SRS | FS | |
|---|---|---|---|---|
| Trả lời | Vì sao làm | Nghiệp vụ cần hệ thống làm gì | Phần mềm phải làm gì và tốt đến đâu | Cụ thể phần mềm làm điều đó thế nào |
| Người đọc chính | Lãnh đạo, chủ đầu tư | Nghiệp vụ, BA, PM | Dev, QC, kiến trúc sư | Dev, QC, designer |
| Có NFR không | Rất ít | Ít | Có, đầy đủ | Chỉ phần liên quan tính năng |
| Mức chi tiết | Mục tiêu, phạm vi | Luồng nghiệp vụ, chức năng | Yêu cầu đánh số, tiêu chí kiểm chứng | Màn hình, trường, validation, thông báo lỗi |
Thực tế ở VN: nhiều công ty chỉ làm hai tài liệu — một bản BRD kiểu tổng hợp và một bản FRD/SRS gộp. Dự án Agile thì thay bằng backlog + tiêu chí chấp nhận. Không có cái nào sai, miễn là ai cũng biết yêu cầu chốt nằm ở đâu.
Ví dụ thực tế
Ba hãng sản xuất, ba kiểu mã trạng thái, và một chuỗi trung tâm điện máy đang ghi phiếu bảo hành bằng sổ tay. Đó là hiện trạng lúc bắt đầu viết SRS.
Tài liệu ra lò dày 90 trang. Phần khiến dự án chạy được nằm ở ba chỗ: bảng trạng thái phiếu bảo hành với 11 trạng thái và các phép chuyển hợp lệ; đặc tả 3 giao diện API của các hãng kèm bảng ánh xạ mã trạng thái; và NFR về đồng bộ trạng thái, chậm nhất 3 phút so với hãng, sai lệch dưới 0,2% mỗi ngày. Phần còn lại là mô tả CRUD, đọc hay không đọc cũng không đổi kết quả.
90 trang, và giá trị nằm ở ba chỗ. Phần còn lại viết đều tay chỉ để tài liệu trông đầy đặn khi khách lật.
Lỗi hay gặp
Viết SRS xong rồi để đó. Sprint chạy, yêu cầu đổi, không ai cập nhật, ba tháng sau tài liệu và hệ thống là hai thứ khác nhau. Khi đó SRS còn tệ hơn không có, vì người mới vào đọc và tin.
Chữa bằng cách "cập nhật chăm chỉ hơn" thì chưa đội nào mình gặp làm nổi. Cách chữa thật là chọn đúng một nguồn sự thật. Nếu đội chạy Scrum, để chi tiết ở user story và AC trong Jira, còn SRS chỉ giữ phần ổn định: kiến trúc, NFR, giao diện tích hợp, quy tắc nghiệp vụ. Nếu dự án outsourcing ký theo tài liệu, thì SRS là nguồn sự thật và mọi thay đổi phải đi qua change request.
Còn một lỗi nhỏ mà hậu quả dai: đánh số yêu cầu bằng số thứ tự đoạn văn. Xoá một mục là toàn bộ tham chiếu ở test case lệch theo. Đánh mã cố định, không tái sử dụng mã đã xoá.
