Khi danh sách yêu cầu ngày càng dài, rất dễ bỏ sót một chức năng hoặc ghi cùng một việc ở nhiều chỗ. FDD giúp gom chúng thành một cây chức năng để nhìn rõ hệ thống cần làm những gì trước khi viết Use Case hay đặc tả.
Note này dùng để làm gì
Mở note này khi đã có yêu cầu ban đầu nhưng chưa biết nên chia hệ thống thành những nhóm chức năng nào. Kết quả cần có là một cây chức năng và bảng cho biết mỗi chức năng xuất phát từ yêu cầu nào.
Đầu vào lấy từ Requirement Elicitation và Scope, Assumptions & Constraints. Sau khi thống nhất cây, dùng Use Case cho BA để làm rõ cách người dùng thực hiện từng mục tiêu.
Bài dùng ShopFlow làm ví dụ. Các yêu cầu và quyết định bên dưới được đặt ra để thực hành, không mô tả nguyên trạng dự án.
1. FDD cho mình thấy điều gì?
Functional decomposition là cách chia một chức năng lớn thành những phần nhỏ hơn để dễ phân tích. IIBA dùng kỹ thuật này trong việc mô hình hóa và truy vết yêu cầu; chia sâu đến đâu tùy vào việc mình đang cần làm [1].
Với FDD trong bài này, hãy hình dung một cây: trên cùng là hệ thống, bên dưới là các nhóm chức năng, rồi đến những việc cụ thể hệ thống phải làm. Đường nối từ cha xuống con có nghĩa là “gồm những chức năng này”. Nó không cho biết chức năng nào chạy trước hay gọi chức năng nào.
| Mình muốn biết… | Nên dùng |
|---|---|
| Hệ thống cần có những chức năng nào? | FDD |
| Người dùng làm gì để đạt một mục tiêu? | Use Case và mô tả chi tiết kịch bản |
| Các bước diễn ra thế nào, rẽ nhánh ở đâu? | UML Activity; dùng BPMN khi cần mô hình quy trình nghiệp vụ giữa các bên |
| Ai quản lý ai? | Sơ đồ tổ chức |
| Team cần làm những đầu việc nào? | Work breakdown structure (WBS) |
| Chức năng sẽ được triển khai bằng những thành phần nào? | Mô hình kiến trúc kỹ thuật |
FDD ở đây là sơ đồ cây, không dùng ký hiệu UML. Ví dụ được vẽ bằng cú pháp WBS của PlantUML vì công cụ này có sẵn cách vẽ cây. Các ô vẫn chứa chức năng của hệ thống, như “Tạo đơn hàng”, chứ không phải đầu việc của team như “Code API tạo đơn”.
2. Khi nào cần FDD?
| Tình huống | Cách xử lý |
|---|---|
| Yêu cầu nằm rải rác, mỗi người hiểu phạm vi một kiểu | Vẽ FDD rồi cùng stakeholder rà lại |
| Nghi ngờ thiếu chức năng hoặc có chức năng bị lặp | Đối chiếu cây với danh sách yêu cầu và người hiểu nghiệp vụ |
| Chỉ đổi một quy tắc nhỏ trong Use Case đã rõ | Sửa đặc tả và AC hiện có; thường không cần thêm FDD |
| Đang cần làm rõ luồng, trạng thái hoặc tương tác | Dùng thêm Activity, State Machine hoặc Sequence |
| Yêu cầu còn nhiều điểm chưa xác nhận | Vẽ nháp để đặt câu hỏi, đánh dấu chỗ đang giả định |
Cây giúp nhìn tổng thể, nhưng quan hệ giữa các chức năng đôi khi phức tạp hơn một đường cha–con. IIBA cũng lưu ý giới hạn này [1]. Chẳng hạn “Tạo đơn hàng” cần dữ liệu tồn kho; không vì thế mà phải đặt nó dưới nhánh “Quản lý tồn kho”.
3. Trước khi vẽ, cần biết gì?
Ít nhất phải trả lời được:
- Hệ thống phục vụ ai, và giúp họ đạt kết quả gì?
- Đang phân tích toàn bộ hệ thống hay chỉ một đợt bàn giao?
- Yêu cầu nào đã được xác nhận, ai xác nhận, dựa vào thông tin nào?
- Phần nào do hệ thống khác hoặc con người xử lý?
- Có quy tắc nào ảnh hưởng đến chức năng: quyền thao tác, trạng thái đơn, cách tính tồn kho, yêu cầu lưu lịch sử?
- Câu hỏi nào còn bỏ ngỏ, cần hỏi ai?
Bắt đầu với ba cấp
Handbook này chọn ba cấp làm điểm bắt đầu:
| Cấp | Nội dung | Ví dụ |
|---|---|---|
| 1 | Hệ thống hoặc phạm vi đang xét | ShopFlow — phạm vi thực hành v1 |
| 2 | Nhóm chức năng | Quản lý đơn hàng |
| 3 | Chức năng cụ thể | Tạo đơn hàng, Tra cứu đơn hàng |
Ở đây đếm cả hệ thống là cấp 1. Trong quy tắc của nhóm, “nhánh cấp 1” là nhánh ngay dưới hệ thống, tức cấp 2 trong bảng này.
Ba cấp thường đủ để bắt đầu trao đổi. Nếu một nhánh vẫn quá rộng, chia riêng nhánh đó sâu hơn; không cần chia các nhánh còn lại cho cân hình. IIBA không ấn định số cấp, mà khuyên chọn độ sâu đủ cho mục tiêu phân tích [1].
Các nhánh cùng cấp nên được chia theo cùng một cách. Ví dụ, “Danh mục sản phẩm”, “Đơn hàng” và “Tồn kho” đều nhóm theo nghiệp vụ. Đặt “Đơn hàng”, “Màn hình admin” và “PostgreSQL” cạnh nhau sẽ khiến cây khó hiểu vì đang trộn nghiệp vụ, giao diện và công nghệ.
Tên chức năng cụ thể nên có động từ + đối tượng: “Tra cứu đơn hàng”, “Ghi nhận nhập kho”. Nếu chỉ ghi “Order” hay “Quản lý X”, người đọc vẫn chưa biết hệ thống phải làm gì.
4. Từ danh sách yêu cầu đến cây chức năng
Có thể làm theo sáu bước sau:
- Ghi rõ phạm vi. Hệ thống nào, đợt bàn giao nào, phần nào làm và phần nào để sau? Kèm ngày và phiên bản để biết đang review bản nào.
- Tìm chức năng trong từng yêu cầu. Xác định việc hệ thống phải làm, giữ mã yêu cầu để còn đối chiếu về sau.
- Gom thành nhóm. Chọn các nhóm có cùng mục đích, rồi kiểm tra với stakeholder xem cách chia đó có dễ hiểu không.
- Chia đến chức năng cụ thể. Chia đủ để bắt đầu viết Use Case hoặc user story. Nếu còn mơ hồ, ghi câu hỏi cần làm rõ.
- Rà chỗ trùng và chỗ thiếu. Kiểm tra từng yêu cầu đã có chỗ trên cây chưa; soát CRUD đối với các nhóm “Quản lý X”.
- Review và chốt. Ghi lại quyết định, lý do và việc chưa thống nhất. Cây chưa được người có thẩm quyền xác nhận vẫn là bản nháp.
Kiểm tra “không trùng, không sót” bằng MECE
MECE hữu ích để tự hỏi xem cách chia đã hợp lý chưa:
- Hai chức năng giống tên có đang mô tả cùng một việc không? Hay khác người dùng, quy tắc hoặc phạm vi?
- Mỗi yêu cầu trong phạm vi đã gắn với chức năng nào?
- Có chức năng nào tự thêm vào mà chưa có yêu cầu hoặc lý do rõ ràng?
- Hai nhóm cùng dùng dữ liệu sản phẩm có thực sự bị trùng chức năng, hay chỉ cần cùng truy cập một nguồn dữ liệu?
Một yêu cầu có thể liên quan đến nhiều chức năng. Với chức năng dùng chung, chọn một chỗ để mô tả rồi ghi rõ các chức năng cần dùng đến nó.
Ví dụ, ở một phạm vi rộng hơn v1, hệ thống có thể cần gửi thông báo khi đặt đơn và khi tồn kho thấp. Đặt “Gửi thông báo” trong nhóm “Thông báo”, rồi ghi hai quan hệ: “Tạo đơn → Gửi thông báo” và “Cảnh báo tồn thấp → Gửi thông báo”. Nếu cách gửi hoặc quy tắc khác nhau, mô tả phần khác đó; đừng gom hai việc chỉ vì chúng cùng tên.
Dù cây đã gọn và ít trùng lặp, vẫn cần đối chiếu với yêu cầu gốc. Nhìn vào hình thôi chưa đủ để biết đã hết thiếu sót.
Với “Quản lý X”, nhớ soát CRUD
Hỏi lần lượt: có cần tạo, xem, sửa và xóa không? Nếu bỏ một thao tác, ghi lại lý do. Soát đủ CRUD giúp phát hiện thiếu sót, chứ không có nghĩa mọi đối tượng đều phải có đủ bốn thao tác.
Chẳng hạn, đơn đã thanh toán cần giữ lịch sử. “Hủy đơn” là thay đổi trạng thái theo quy tắc nghiệp vụ, không phải xóa bản ghi. Ai được hủy, hủy khi nào và dữ liệu được giữ lại ra sao vẫn phải viết trong đặc tả.
5. Ví dụ: ShopFlow — phạm vi thực hành v1
Trong ví dụ này, ứng dụng cho phép tìm và xem sản phẩm, tạo và tra cứu đơn, ghi nhận nhập kho và xem tồn. Sản phẩm đã được nạp sẵn, chỉ có một kho, người dùng đăng nhập bằng cơ chế hiện có.
Để bài tập gọn, chưa xét đăng ký tài khoản, thanh toán, vận chuyển, trả hàng và báo cáo doanh thu.
| Mã | Yêu cầu giả định | Xuất phát từ |
|---|---|---|
| R-01 | Khách hàng tìm và xem sản phẩm để chọn mua | Nhu cầu chọn sản phẩm |
| R-02 | Khách hàng tạo đơn; hệ thống từ chối nếu không đủ tồn khả dụng | Nhu cầu đặt hàng và quy tắc tồn kho |
| R-03 | Khách hàng tra cứu đơn của mình | Nhu cầu theo dõi đơn |
| R-04 | Nhân viên kho ghi nhận hàng nhập | Công việc nhập kho |
| R-05 | Nhân viên kho xem tồn của từng sản phẩm | Công việc kiểm tra tồn |
Cây chức năng
Sơ đồ dùng cây phân cấp tự do, vẽ bằng cú pháp WBS của PlantUML [2].
Mã F-… giúp đối chiếu chức năng trên hình với bảng bên dưới.
“Đủ tồn mới tạo đơn” là quy tắc của F-03, không cần tách thành một ô cho mỗi điều kiện kiểm tra. F-03 cần dữ liệu tồn kho, nhưng hình chưa cho biết lúc nào giữ tồn, lúc nào trừ tồn hoặc cách xử lý khi nhiều người cùng đặt. Những điểm đó cần được làm rõ trong đặc tả.
Mỗi chức năng đến từ yêu cầu nào?
| Chức năng | Yêu cầu | Phần cần viết tiếp |
|---|---|---|
| F-01, F-02 | R-01 | Use Case tìm/xem sản phẩm; điều kiện lọc và thông tin hiển thị |
| F-03 | R-02 | Use Case tạo đơn; AC đủ/thiếu tồn, quyền thao tác, lỗi và cách cập nhật tồn |
| F-04 | R-03 | Use Case tra cứu đơn; AC chỉ xem đơn của khách hàng hiện tại |
| F-05 | R-04 | Use Case nhập kho; kiểm tra số lượng và lưu lịch sử nhập |
| F-06 | R-05 | Use Case xem tồn; làm rõ tồn thực tế và tồn khả dụng |
Bảng này chỉ ra việc cần làm tiếp, chưa phải đặc tả để dev/test triển khai. Khi viết chi tiết, xem Use Case cho BA và User Story & Acceptance Criteria.
Rà CRUD để xem có bỏ sót gì không
| Đối tượng | Create | Read | Update | Delete / lý do bỏ |
|---|---|---|---|---|
| Sản phẩm | Chưa làm: dữ liệu nạp sẵn | F-01, F-02 | Chưa làm | Chưa làm; cần xác nhận lại nếu bổ sung quản trị danh mục |
| Đơn hàng | F-03 | F-04 | Sửa/hủy đơn để sau v1 | Giả định không xóa cứng để giữ lịch sử; cần xác nhận |
| Tồn kho | Có số dư ban đầu; F-05 tạo bản ghi nhập | F-06 | F-05 tăng tồn; F-03 còn cần chốt cách giữ/trừ tồn | Không cho xóa số dư/lịch sử qua giao diện trong v1 |
Còn phải hỏi gì trước khi chốt?
Các vai trò trong bảng cũng được giả định cho bài tập:
| Câu hỏi | Cần hỏi ai? | Nếu chưa có câu trả lời… |
|---|---|---|
| Tạo đơn giữ tồn hay trừ tồn ngay? | PO và đại diện kho; dev xem tính khả thi | Chưa chốt được quy tắc F-03 và số tồn hiển thị ở F-06 |
| Ai được phép nhập kho? | Người phụ trách kho và người duyệt phân quyền | Chưa chốt được quyền của F-05 |
| Đơn chưa thanh toán bị bỏ dở thì xử lý thế nào? | PO và đại diện vận hành bán hàng | Chưa rõ có cần thêm xử lý đơn hết hạn và hoàn lại tồn đã giữ không |
BA ghi lại câu trả lời và lý do chọn phương án. Hình FDD giúp thấy chức năng cần có; các quyết định này vẫn cần trao đổi với người hiểu nghiệp vụ.
6. Chia đến đâu thì dừng?
Dừng khi stakeholder hiểu chức năng đó làm gì, BA nối được nó với yêu cầu và có thể bắt đầu viết kịch bản hoặc AC. Nếu đang chia tiếp thành “code API”, “viết unit test” hay từng nút trên màn hình, mình đã chuyển sang lập kế hoạch công việc hoặc thiết kế giao diện.
Khi yêu cầu thay đổi, cập nhật cây và bảng truy vết cùng nhau. Giữ mã chức năng khi chuyển nó sang nhánh khác để dễ theo dõi.
Vị trí trên cây không nói lên mức ưu tiên. Các nhánh chính thường chứa nhiều việc cần làm, nhưng việc nào là Must-have vẫn phải chốt riêng cho từng đợt bàn giao.
Anti-patterns
| Cách làm dễ mắc | Vấn đề | Cách sửa |
|---|---|---|
| Chia theo phòng ban hoặc màn hình | Khó thấy chức năng dùng chung; cây phụ thuộc vào tổ chức/giao diện hiện tại | Nhóm theo chức năng, ghi người dùng và kênh sử dụng trong phần chi tiết |
| Chỉ ghi “Quản lý X” ở ô cuối | Chưa rõ gồm những thao tác nào | Soát CRUD và quy trình, đặt tên cụ thể |
| Đưa mọi ý tưởng vào cây | Người đọc tưởng tất cả đã được duyệt | Tách việc đã chốt, việc để sau và câu hỏi còn mở |
| Dùng đường nối để chỉ thứ tự chạy | Người đọc nhầm cây chức năng với luồng xử lý | Vẽ thêm Activity hoặc Sequence |
| Cố chia đều ba cấp hoặc chia tới từng nút | Quá sơ sài để review hoặc quá vụn để nhìn tổng thể | Chia theo mức cần trao đổi, nhánh phức tạp có thể sâu hơn |
| Mỗi ô là một story hoặc microservice | Bỏ qua mục tiêu người dùng, cách chia story và thiết kế kỹ thuật | Phân tích các phần đó riêng; không ép quan hệ một–một |
| Soát CRUD/MECE xong là coi như đủ | Vẫn có thể thiếu quyền, ngoại lệ, NFR và tích hợp | Đối chiếu yêu cầu, quy tắc và các mô hình liên quan |
Checklist nhanh
- Đã ghi hệ thống, đợt bàn giao, phiên bản và những gì chưa làm?
- Những điều đang giả định đã được ghi riêng?
- Các nhóm cùng cấp được chia theo cùng một cách?
- Mỗi chức năng có việc làm rõ ràng và có yêu cầu hoặc lý do đi kèm?
- Mỗi yêu cầu đã có chỗ trên cây; chỗ chưa rõ biết cần hỏi ai?
- Đã soát CRUD và giải thích vì sao bỏ thao tác?
- Chức năng dùng chung được ghi một chỗ, quan hệ phụ thuộc được ghi riêng?
- Quyền, trạng thái, NFR và ngoại lệ đã có chỗ để phân tích tiếp?
- Stakeholder đã review phạm vi và hiểu đúng ý nghĩa đường nối?
References
- [1] IIBA — Functional Decomposition: Insight — đọc thêm về cách dùng functional decomposition và chọn mức chi tiết phù hợp.
- [2] PlantUML — WBS syntax — cách vẽ sơ đồ cây như ví dụ trong bài.
Đã đọc các nguồn trên ngày 07/10/2026. Cách đặt tên, các bước rà soát và ví dụ ShopFlow là cách thực hành được chọn cho handbook này.
Internal Sources
Mẫu 008 FDD-1.pdf trong library/04-specification/ của SecondBrain
(SRC-COURSE-FDD) minh họa cây chức năng của hệ thống quản lý camera,
chia theo nhóm người dùng và kênh web/mobile. Có thể xem mẫu để tham khảo
cách trình bày; chọn cách chia phù hợp với hệ thống mình đang phân tích.
PDF này chỉ có trong vault, không đính kèm trên blog.