Lỗi hay gặp của fresher với BRD, SRS, FS là thuộc lòng ba định nghĩa mà vẫn viết sai tài liệu. Giả sử ngày đầu đi làm bạn được giao viết SRS cho module này, trong khi tuần trước có người vừa gửi BRD, cả team thì cứ nói FS, ba cái tên mà câu hỏi thật chỉ có một, tài liệu này ai đọc và để quyết định việc gì.
ba tài liệu, ba câu hỏi#
Mỗi tài liệu trả lời một câu hỏi khác nhau, nhớ được câu hỏi thì tên gọi có đổi thế nào bạn cũng nhận ra. BABOK Guide v3 không dùng chữ BRD hay SRS, nó chia yêu cầu thành bốn loại, business requirements (mục tiêu, lý do thay đổi), stakeholder requirements (nhu cầu của từng bên), solution requirements (gồm functional và non-functional) và transition requirements (những thứ chỉ cần cho giai đoạn chuyển đổi như data conversion, đào tạo) (IIBA, 4.4 Understanding Requirements and Designs). Theo mình map gọn nhất là BRD chứa business và stakeholder requirements, còn SRS và FS chứa solution requirements ở hai mức chi tiết khác nhau.
BRD, doanh nghiệp cần gì và vì sao#
BRD (Business Requirements Document) trả lời tại sao làm dự án này và doanh nghiệp cần đạt được gì, nói bằng ngôn ngữ nghiệp vụ, mục tiêu, phạm vi, stakeholder, vấn đề hiện tại, yêu cầu nghiệp vụ ở mức cao. Người viết thường là BA hoặc người đại diện nghiệp vụ, người đọc là ban lãnh đạo, sponsor, trưởng các bộ phận, những người quan tâm làm xong thì được lợi gì chứ chẳng quan tâm màn hình có mấy nút.
SRS, hệ thống phải làm gì#
SRS (Software Requirements Specification) trả lời hệ thống phải làm được những gì, mô tả yêu cầu chức năng (tính năng, luồng) và yêu cầu phi chức năng (hiệu năng, bảo mật, khả năng mở rộng). Người đọc là dev, tester, kiến trúc sư, những người cần biết chính xác hệ thống phải chạy thế nào, nên SRS giống một bản hợp đồng giữa nghiệp vụ và kỹ thuật.
FS hoặc FRD, chức năng chạy chi tiết thế nào#
FS (Functional Specification) hay FRD (Functional Requirements Document) đi sâu thêm một bước, một chức năng cụ thể có những màn hình nào, field nào, rule nào, validation ra sao, luồng xử lý từng bước. SRS nói hệ thống phải quản lý được đơn mua hàng, thì FS nói rõ màn hình tạo đơn mua có các field mã PO, nhà cung cấp, ngày giao, danh sách dòng hàng, nhập mã nhà cung cấp thì hệ thống tự điền thông tin, thiếu ngày giao thì chặn lưu.
| Tiêu chí | BRD | SRS | FS/FRD |
|---|---|---|---|
| Trả lời câu hỏi | Vì sao làm, cần gì | Hệ thống làm gì | Chức năng chạy chi tiết thế nào |
| Người viết | BA, đại diện nghiệp vụ | BA, kiến trúc sư | BA, đôi khi cả dev |
| Người đọc | Sponsor, lãnh đạo, trưởng bộ phận | Dev, tester, kiến trúc sư | Dev, tester |
| Thời điểm | Đầu dự án | Sau khi chốt phạm vi | Thiết kế chi tiết |
| Độ chi tiết | Thấp | Trung bình | Cao |
ngoài đời tên gọi lộn xộn hơn nhiều#
Tới đây chắc bạn nghĩ vậy là rõ rồi, cứ ba loại mà viết, nhưng ra đời thì lộn xộn hơn nhiều. Cùng một nội dung, công ty này gọi SRS, công ty kia gọi FS, công ty nữa gọi PRD (Product Requirements Document), ví dụ tin Senior BA BHXH của MISA trên Devwork yêu cầu nắm “PRD, SRS, use case, user story” (xem tin), bốn cái tên mà đều trỏ về việc viết tài liệu yêu cầu, tên gọi đổi theo văn hóa công ty và loại dự án chứ chẳng theo chuẩn cứng nào.
Dự án ERP có một nét riêng. Hệ thống đã có sẵn, SAP, Oracle hay IFS Cloud, nên người ta không viết SRS cho cả hệ thống, việc đó nhà sản xuất làm rồi, thay vào đó là viết FSD cho phần gap, chỗ nào quy trình khách khác sản phẩm chuẩn thì mô tả chi tiết phần đó cần cấu hình hay phát triển thêm, nên trong dự án ERP bạn sẽ nghe FSD, gap, fit-gap nhiều hơn SRS.
Dự án Agile lại khác nữa, backlog và user story thay phần lớn FS, mỗi user story kèm acceptance criteria là đủ để dev làm, nhưng rule chung, quy ước toàn hệ thống vẫn cần một chỗ để ghi, thường là một tài liệu gọn hoặc wiki. Agile không vứt hết tài liệu, nó chỉ dời trọng tâm đi chỗ khác.
khung tối thiểu cho từng tài liệu#
Bạn không cần một mẫu dài mười trang, chỉ cần một checklist tối thiểu để khỏi sót mục quan trọng. BRD tối thiểu có bối cảnh và vấn đề, mục tiêu, phạm vi gồm làm gì và không làm gì, stakeholder, yêu cầu nghiệp vụ chính, rủi ro và giả định. SRS tối thiểu có tổng quan hệ thống, yêu cầu chức năng theo từng module, yêu cầu phi chức năng, ràng buộc và các luồng chính. FS cho một chức năng thì có mục đích, danh sách màn hình và field, rule xử lý, validation, luồng bình thường, luồng ngoại lệ và các trường hợp lỗi.
trả lời phỏng vấn trong 30 giây#
Phỏng vấn hỏi phân biệt BRD và SRS thì trả lời gọn kiểu này:
“BRD trả lời vì sao làm và doanh nghiệp cần gì, viết cho lãnh đạo đọc. SRS trả lời hệ thống phải làm gì, viết cho dev và tester đọc. Còn FS đi sâu chi tiết từng chức năng, màn hình, rule. Còn dự án ERP thì thường viết FSD cho phần gap, thay vì SRS cho cả hệ thống.”
Câu trả lời như vậy cho thấy bạn hiểu bản chất chứ không học vẹt định nghĩa, mà đó chính là thứ người phỏng vấn muốn thấy.
việc đầu tiên khi vào team mới#
Đừng học thuộc ba cái tên, hãy nhớ ba câu hỏi, vì sao làm, hệ thống làm gì, chức năng chạy thế nào, rồi vào team mới thì việc đầu tiên là hỏi tài liệu của mình ai đọc, vì chính người đọc quyết định nên viết gì và viết dài bao nhiêu.
Muốn thấy một chức năng viết thành use case và user story khác nhau ra sao thì đọc Use case và user story khác nhau thế nào, phần yêu cầu phi chức năng trong SRS hay bị bỏ quên thì có bài riêng Non-functional requirement: những yêu cầu BA hay quên, còn sắp đi phỏng vấn thì xem Phỏng vấn BA fresher: những câu hỏi thật.
Chỗ bạn đang làm gọi tài liệu yêu cầu là BRD, SRS hay PRD? Kể mình nghe qua Facebook hoặc LinkedIn nhé.
