BAHUB.VN
Glossary

Functional Specification(FS / FSD)

DocumentationĐặc tả chức năng

Tài liệu mô tả chi tiết một tính năng hoạt động thế nào ở mức dev cầm là code được: từng màn hình, từng trường, luật kiểm tra dữ liệu, thông báo lỗi, luồng ngoại lệ.

Định nghĩa

Khi dev hỏi "cái trường này bắt buộc hay không, nhập quá 11 số thì báo gì", câu trả lời phải nằm sẵn ở đâu đó. Chỗ đó là FS. Đây là tài liệu ở mức chi tiết nhất trong họ tài liệu yêu cầu — mô tả từng màn hình, từng trường, từng luật, từng thông báo.

Ở nhiều công ty VN, cái được gọi là "spec" mà BA giao cho dev chính là FS, dù tên file có thể ghi là FRD hay SRS. Trên bìa tài liệu bạn cũng hay gặp tên đầy đủ Functional Specification Document, viết tắt FSD. Vẫn là thứ này, chỉ thêm chữ "document" cho ra dáng một bản bàn giao có ký duyệt. Tên gọi lộn xộn, nhưng vai trò thì rõ: đây là bản dev cầm để code, QC cầm để viết test case.

BRD nói vì sao, SRS nói phải làm gì, FS nói làm chính xác như thế nào.

Ai làm, làm lúc nào

BA viết, sau khi yêu cầu chức năng đã ổn định và đã có wireframe hoặc bản thiết kế. Viết trước khi có UI thì phải sửa lại, viết sau khi dev đã code thì thành biên bản chứ không còn là đặc tả.

Trong dự án Agile, FS ít khi tồn tại thành một tài liệu lớn. Nó bị chia nhỏ vào từng user story, nằm ở phần mô tả và acceptance criteria. Với các hệ thống nhiều luật nghiệp vụ (bảo hiểm, ngân hàng, ERP), FS dạng tài liệu vẫn sống khoẻ vì một story không chứa nổi 40 luật kiểm tra.

Gồm những gì

Với mỗi màn hình hoặc mỗi tính năng:

  • Mục đích và người dùng: ai vào màn này, để làm gì, vào từ đâu.
  • Bố cục và điều hướng: ảnh chụp wireframe hoặc mô tả vùng, các nút và đích đến.
  • Bảng đặc tả trường: tên trường, kiểu dữ liệu, độ dài, bắt buộc hay không, giá trị mặc định, nguồn dữ liệu, luật kiểm tra.
  • Luồng chính và luồng ngoại lệ: các bước, điều kiện rẽ nhánh.
  • Thông báo: mã, nội dung tiếng Việt, loại (lỗi, cảnh báo, thành công).
  • Phân quyền: vai trò nào xem, sửa, xoá, duyệt.
  • Ảnh hưởng dữ liệu: bản ghi nào được tạo, sửa, sự kiện nào phát ra.

Bảng đặc tả trường tốn công nhất. Đổi lại, đó là phần dev thật sự dùng. Một màn hình 20 trường mà mỗi trường có 3 luật thì đó là 60 dòng, và đúng 60 dòng đó quyết định dev có phải nhắn hỏi bạn lúc 10 giờ đêm hay không.

So sánh FS với BRD, FRD, SRS

BRDFRDSRSFS
Câu hỏi cốt lõiVì sao đầu tưNghiệp vụ cần gìPhần mềm phải làm gìMàn hình chạy ra sao
Ví dụ nội dungGiảm 30% thời gian duyệt hồ sơTrưởng nhóm duyệt hồ sơ theo lôFR-APR-07: hệ thống cho duyệt tối đa 50 hồ sơ một lầnNút Duyệt hàng loạt mờ khi chọn 0 dòng, chọn quá 50 dòng báo MSG-APR-12
Người kýChủ đầu tưTrưởng bộ phận nghiệp vụĐại diện nghiệp vụ phía khách ký duyệt, PM và kiến trúc sư ký xác nhận khả thiThường không ký, chỉ review
Đổi thường xuyênHiếmThỉnh thoảngThỉnh thoảngRất thường xuyên

Nhìn ô tần suất thay đổi thì thấy ngay vì sao FS không nên nằm chung file với BRD. Một cái ổn định cả dự án, một cái đổi mỗi tuần. Ghép chung thì mỗi lần đổi một dòng validation lại phải phát hành lại tài liệu và xin ký lại.

Ví dụ thực tế

Tháng thứ hai của một dự án chuỗi nhà thuốc 237 cửa hàng: wireframe đã chốt, và việc của BA tuần đó là màn hình tạo phiếu nhập kho. Mỗi ngày hệ thống nhận hơn ba nghìn phiếu.

Trích một phần bảng đặc tả trường:

TrườngKiểuBắt buộcLuật kiểm traThông báo lỗi
Số lôText 20Không trùng với lô đang còn tồn của cùng mã thuốcMSG-INV-04
Hạn dùngDatePhải sau ngày hiện tại tối thiểu 90 ngàyMSG-INV-05
Số lượngInteger> 0 và ≤ số lượng trên đơn đặt hàng gốcMSG-INV-06
Giá nhậpDecimal(15,2)Lệch quá 15% so với giá nhập gần nhất thì cần trưởng ca duyệtMSG-INV-07

Luật ở dòng giá nhập là thứ chỉ FS mới chứa nổi: nó chặn dữ liệu, đồng thời mở ra một luồng phê duyệt. Viết trong SRS thì quá chi tiết, viết trong BRD thì lạc chỗ. Không viết ở đâu cả thì dev cho qua, và kế toán phát hiện giá nhập sai lệch vào kỳ quyết toán quý.

Khi bàn giao FS, gửi kèm một danh sách các luật "khó chịu" như dòng đó, đánh dấu riêng. Dev đọc lướt 40 trang nhưng sẽ đọc kỹ 5 dòng bạn bảo là dễ sai.

Functional Specification (FS/FSD) là gì? Khác gì SRS? | BAHUB.VN