Functional Requirements Document(FRD)

Nếu BRD nói khách muốn gì thì FRD nói hệ thống sẽ làm gì để đáp lại. Đây là tài liệu dev mở ra lúc code và QC mở ra lúc viết test case, nên nó phải cụ thể đến mức hai người đọc cùng một dòng và hiểu giống nhau. Cụ thể, chứ chưa phải là thiết kế kỹ thuật — FRD không quyết định dùng Redis hay Kafka.

FRD là bản dịch từ nhu cầu nghiệp vụ sang hành vi hệ thống, chi tiết đủ để code được và test được, nhưng vẫn không nói chuyện công nghệ.

Ai viết, viết lúc nào

BA viết, sau khi BRD đã chốt phạm vi và trước hoặc song song với giai đoạn thiết kế. Người review bắt buộc gồm tech lead (xem có làm được không), QC lead (xem có test được không) và đại diện nghiệp vụ (xem có đúng ý không). Thiếu chữ ký QC lead là kiểu duyệt nguy hiểm nhất, vì lỗi mơ hồ chỉ lộ ra khi ai đó thử viết test case.

Trong dự án Agile, FRD hiếm khi được viết trọn gói một lần rồi đóng băng. Thực tế phổ biến ở các team product VN: một FRD khung cho toàn module, rồi mỗi user story bổ sung chi tiết dần. Cách này ổn miễn là có người bảo trì tài liệu. Không có người đó thì FRD tụt lại sau code chừng vài sprint, rồi cả team ngầm hiểu với nhau là "đọc code cho nhanh".

Một dòng requirement tốt trông ra sao

• Có mã: FR-ORD-014. Mã để truy vết ngược lên BR nào và xuôi xuống test case nào.
• Dùng "hệ thống phải" (shall), một requirement một câu, một hành vi.
• Nêu rõ điều kiện kích hoạt, dữ liệu đầu vào, quy tắc xử lý, kết quả và thông báo lỗi.
• Không có từ mờ: "nhanh", "thân thiện", "hợp lý", "vân vân". Thấy chữ "vân vân" trong FRD là thấy một cuộc cãi nhau đang chờ ở tháng sau.

Ví dụ một dòng viết được: FR-ORD-014 — Khi người dùng bấm Thanh toán, hệ thống phải kiểm tra tồn kho khả dụng của từng SKU trong giỏ. Nếu bất kỳ SKU nào có tồn kho khả dụng nhỏ hơn số lượng đặt, hệ thống phải chặn thanh toán và hiển thị thông báo E-207 kèm danh sách SKU thiếu hàng.

So sánh FRD với BRD và SRS — nhìn qua cùng một yêu cầu

Ranh giới FRD với SRS thì tranh cãi kinh niên. Theo IEEE 830, SRS bao trùm cả yêu cầu chức năng lẫn phi chức năng, còn FRD chỉ là phần chức năng. Nhiều công ty VN dùng một tài liệu duy nhất và gọi nó là "SRS" hoặc "FS" (Functional Specification), trong đó có luôn cả NFR. Không nơi nào sai, nhưng vào dự án mới nên hỏi ngay "ở đây tài liệu nào là nguồn sự thật" trước khi bắt đầu viết.

Ví dụ thực tế

"Kiểm đếm lệch 300 nghìn thì ai được quyền cho qua?" Câu hỏi của chị kế toán kho trong buổi rà soát thứ ba khiến cả phòng im. Đó là dự án thay hệ thống kho cho một chuỗi bán lẻ 174 cửa hàng, FRD phần nhập hàng có 74 requirement, riêng luồng xử lý chênh lệch chiếm 11 dòng — mỗi tháng chênh khoảng 0,4% giá trị hàng nhập, kế toán không truy được nguyên nhân.

Thứ đáng tiền trong FRD đó là bảng quy tắc, chứ màn hình thì ai vẽ cũng ra: chênh dưới 0,5% và dưới 2 triệu thì thủ kho tự duyệt; vượt một trong hai ngưỡng thì phải quản lý vùng duyệt; chênh trên 10 triệu thì khoá phiếu, bắt buộc kiểm đếm lại có hai người ký. Ba dòng đó thay thế cho một tập tục truyền miệng mà mỗi kho làm một kiểu.

Lỗi hay gặp

• Chép nguyên văn lời khách vào FRD rồi coi thế là xong. Khách nói bằng ngôn ngữ nghiệp vụ, dev cần hành vi hệ thống — phần dịch giữa hai thứ đó chính là việc của BA.
• Chỉ viết happy path. Luồng lỗi, dữ liệu rỗng, timeout, người dùng bấm hai lần: đó mới là chỗ bug sống.
• Viết requirement kèm luôn giải pháp kỹ thuật ("dùng bảng tạm để lưu"). Trói tay dev mà chẳng thêm giá trị nào.
• Không có ma trận truy vết. Đến lúc khách hỏi "yêu cầu BR-08 đã làm chưa" thì cả team ngồi tìm bằng Ctrl+F.

Mẹo nhỏ mà hiệu quả: viết xong một mục, đưa QC đọc và bảo "thử viết ba test case từ chỗ này". Phải hỏi lại nghĩa là mục đó chưa xong.