SRS (Software Requirements Specification) là tài liệu đặc tả yêu cầu phần mềm: ghi phần mềm phải làm gì, cho ai dùng, với dữ liệu nào và trong điều kiện nào, đủ chi tiết để đội phát triển làm theo và để bên mua nghiệm thu. Với người mua, SRS quan trọng vì nó là phạm vi thật của hợp đồng: thứ gì có trong SRS thì được làm và được kiểm, thứ gì không có thì là phát sinh. Dự án nhỏ, rõ việc có thể dùng bản rút gọn vài trang; dự án nhiều phân hệ, nhiều bên liên quan hoặc có yêu cầu pháp lý thì nên có bản đầy đủ.
SRS khác trang yêu cầu một trang thế nào
Trang yêu cầu một trang (tập trước của series) do người mua viết, để các nhà cung cấp hiểu việc và báo giá. SRS thường do bên làm phần mềm viết sau khi khảo sát, người mua đọc và duyệt. Một bên trả lời câu "cần gì", bên kia trả lời "sẽ làm chính xác cái gì".
| Trang yêu cầu một trang | SRS | |
|---|---|---|
| Ai viết | Người mua | Bên làm phần mềm, người mua duyệt |
| Khi nào | Trước khi chọn nhà cung cấp | Sau khảo sát, trước hoặc cùng lúc ký phạm vi |
| Mức chi tiết | Mục tiêu, vai trò, luồng việc chính | Từng chức năng, quy tắc, dữ liệu, yêu cầu phi chức năng |
| Dùng để | Báo giá so sánh được | Làm, kiểm thử và nghiệm thu |
Cấu trúc thường gặp của một SRS
Tiêu chuẩn quốc tế đang dùng cho kỹ thuật yêu cầu là ISO/IEC/IEEE 29148, thay cho IEEE 830 cũ. Chuẩn này gợi ý nội dung chứ không bắt buộc một mẫu cố định. Một SRS thực tế cho phần mềm doanh nghiệp thường có các phần sau:
- Mục đích và phạm vi: phần mềm giải quyết việc gì, phần nào nằm ngoài.
- Người dùng và vai trò: ai đăng nhập, mỗi vai trò thấy và sửa được gì.
- Yêu cầu chức năng: từng chức năng đánh mã (ví dụ CN-01, CN-02), mô tả đầu vào, xử lý, đầu ra.
- Quy tắc nghiệp vụ: công thức tính, điều kiện duyệt, ngưỡng cảnh báo.
- Dữ liệu: các đối tượng chính (khách hàng, đơn hàng, sản phẩm) và trường bắt buộc.
- Giao tiếp với hệ thống khác: phần mềm kế toán, hoá đơn điện tử, cổng thanh toán, định dạng trao đổi.
- Yêu cầu phi chức năng: tốc độ, số người dùng đồng thời, sao lưu, bảo mật, trình duyệt và thiết bị hỗ trợ.
- Tiêu chí nghiệm thu: với mỗi chức năng, kiểm thế nào thì coi là đạt.
Ba phần người mua phải đọc kỹ
Quy tắc nghiệp vụ
Đây là nơi phần mềm khác với quy trình thật mà không ai để ý cho tới lúc chạy. Đọc từng công thức và thử bằng một ví dụ có số: đơn 48 triệu có cần duyệt không, đơn đúng 50 triệu thì sao. Quy tắc "trên 50 triệu" và "từ 50 triệu" khác nhau đúng ở trường hợp đó.
Yêu cầu phi chức năng
Phần này hay bị để trống hoặc ghi chung chung ("hệ thống chạy nhanh, bảo mật"). Không có con số thì không nghiệm thu được. Nên có ít nhất: số người dùng cùng lúc, thời gian mở màn hình chính chấp nhận được, tần suất sao lưu, và ai được xem dữ liệu nhạy cảm như lương.
Tiêu chí nghiệm thu
Mỗi chức năng cần một câu kiểm được, dạng "khi làm A với dữ liệu B thì thấy kết quả C". SRS không có tiêu chí nghiệm thu thì buổi nghiệm thu sẽ thành cuộc tranh luận về cảm giác. Tập về UAT và nghiệm thu trong series đi sâu vào cách kiểm theo kịch bản.
Một cách đọc nhanh: lấy năm luồng việc trong trang yêu cầu một trang, đi tìm từng luồng trong SRS. Luồng nào không tìm thấy, hoặc bị chia nhỏ tới mức không nhận ra, thì hỏi lại ngay.
Khi nào cần bản đầy đủ, khi nào bản rút gọn là đủ
| Tình huống | Mức nên dùng |
|---|---|
| Website giới thiệu, công cụ nội bộ vài màn hình | Danh sách chức năng và tiêu chí nghiệm thu, vài trang |
| Phần mềm một phòng ban, một luồng nghiệp vụ chính | SRS rút gọn: chức năng, quy tắc, dữ liệu, nghiệm thu |
| Hệ thống nhiều phân hệ, nhiều phòng ban dùng chung | SRS đầy đủ, chia theo phân hệ |
| Có tích hợp ngân hàng, thuế, hoá đơn, dữ liệu cá nhân | SRS đầy đủ, phần giao tiếp và bảo mật viết kỹ |
| Sản phẩm đang thử thị trường, hướng đổi liên tục | Chia chặng ngắn, mỗi chặng một đặc tả nhỏ |
Làm theo đợt ngắn không có nghĩa là bỏ đặc tả. Ở cách làm của ALODEV, mỗi đợt 2 tuần kết thúc bằng một bản chạy thử và mỗi chặng được nghiệm thu riêng (trang Quy trình); đặc tả được viết theo chặng thay vì một lần cho cả dự án.
Ví dụ một dòng yêu cầu chức năng
| Mã | Chức năng | Quy tắc | Tiêu chí nghiệm thu |
|---|---|---|---|
| CN-07 | Duyệt đơn bán hàng | Đơn có tổng tiền từ 50.000.000 đồng trở lên chuyển trưởng phòng duyệt; dưới mức đó tự chuyển kho | Tạo đơn 49.999.000 đồng: trạng thái Chờ xuất kho. Tạo đơn 50.000.000 đồng: trạng thái Chờ duyệt, trưởng phòng nhận thông báo |
Duyệt SRS: làm gì trong một buổi chiều
Nhận SRS dày vài chục trang, người mua dễ ký cho xong vì không có thời gian đọc. Một buổi chiều là đủ nếu chia việc: giao mỗi trưởng bộ phận đọc đúng phần chức năng của bộ phận mình, người phụ trách dự án đọc phần phạm vi, phần không làm và tiêu chí nghiệm thu. Mỗi người ghi câu hỏi vào cùng một bảng, rồi gửi một lần cho bên làm.
- Tìm năm luồng việc chính trong trang yêu cầu một trang; đánh dấu luồng nào thiếu.
- Với mỗi quy tắc có ngưỡng, thử một ví dụ đúng bằng ngưỡng.
- Đọc phần không làm, xác nhận không có thứ mình cần ngay.
- Kiểm phần phi chức năng có con số.
- Ghi số phiên bản SRS được duyệt vào biên bản họp.
Bài viết tài liệu mà người làm thực sự đọc trên blog Trần Công Thắng nhìn cùng vấn đề từ phía người viết: tài liệu ngắn, có ví dụ, được đọc nhiều hơn tài liệu dài.
Câu hỏi thường gặp
SRS là viết tắt của gì?
SRS là Software Requirements Specification, tiếng Việt thường gọi là tài liệu đặc tả yêu cầu phần mềm.
Ai chịu trách nhiệm viết SRS?
Thường là người phân tích nghiệp vụ hoặc người phụ trách dự án phía bên làm phần mềm, dựa trên khảo sát. Người mua cung cấp thông tin, đọc và ký duyệt.
SRS có phải phụ lục hợp đồng không?
Nên là như vậy, hoặc hợp đồng dẫn chiếu tới phiên bản SRS đã duyệt. Không gắn vào hợp đồng thì phạm vi pháp lý chỉ còn vài dòng mô tả chung.
SRS và BRD khác nhau thế nào?
BRD (tài liệu yêu cầu nghiệp vụ) nói doanh nghiệp cần đạt điều gì; SRS nói phần mềm sẽ làm gì cụ thể để đạt điều đó. Dự án nhỏ thường gộp hai loại làm một.
Dự án làm theo Agile có cần SRS không?
Vẫn cần mô tả yêu cầu và tiêu chí nghiệm thu, chỉ khác là viết theo từng đợt thay vì một lần. Với hợp đồng trọn gói, phạm vi đã chốt vẫn phải có văn bản.
