Business Rule
Chính sách hoặc quy định của doanh nghiệp quyết định điều gì được phép, điều gì bị cấm và tính toán ra sao — tồn tại độc lập với phần mềm, phần mềm chỉ là nơi thực thi nó.
Định nghĩa
"Khách hàng hạng Bạc mua từ 2 triệu trở lên được giảm 5%, không cộng dồn với mã khuyến mãi." Câu này đúng kể cả khi công ty đó bán hàng bằng sổ giấy. Nó là business rule — chính sách của doanh nghiệp, không phải đặc tính của phần mềm.
Ranh giới đó nghe hiển nhiên nhưng rất hay bị xoá nhoà trong tài liệu. Và mỗi lần bị xoá nhoà, hậu quả xuất hiện đúng lúc chính sách thay đổi: con số 5% nằm rải rác trong 6 mục của FRD, sửa sót một chỗ là hệ thống tính sai.
Business rule trả lời "doanh nghiệp cho phép điều gì", yêu cầu chức năng trả lời "hệ thống làm điều đó ra sao".
Phân loại
Cách chia đơn giản và dùng được:
- Rule ràng buộc (constraint rule): cấm hoặc bắt buộc điều gì. "Không cho xuất kho khi tồn khả dụng bằng 0." "Hồ sơ vay trên 500 triệu bắt buộc có chữ ký giám đốc chi nhánh."
- Rule tính toán (computation rule): công thức. "Phí trả chậm = 0,05% × số tiền quá hạn × số ngày quá hạn, tối đa 8% dư nợ."
- Rule suy luận (derivation rule): rút ra dữ liệu mới từ dữ liệu có sẵn. "Khách hàng được xếp hạng Vàng khi tổng chi tiêu 12 tháng gần nhất từ 50 triệu."
- Rule kích hoạt hành động: khi điều kiện xảy ra thì phải làm gì. "Khi hàng còn dưới 30 ngày hạn dùng, tự động chuyển sang nhóm cần thanh lý."
Nguồn của rule không phải lúc nào cũng là khách. Có ba nguồn chính: pháp luật và quy định ngành, chính sách nội bộ, và thoả thuận với đối tác. Loại đầu tiên không thương lượng được, loại thứ hai đổi liên tục, loại thứ ba nằm trong hợp đồng mà BA hay không được đọc.
So sánh với functional requirement
| Business Rule | Functional Requirement | |
|---|---|---|
| Tồn tại khi không có phần mềm | Có | Không |
| Chủ thể | Doanh nghiệp | Hệ thống |
| Ví dụ | Đơn trên 5 triệu được miễn phí giao hàng | Hệ thống tự động áp mã miễn phí giao khi giá trị đơn đạt ngưỡng cấu hình |
| Ai sở hữu | Bộ phận nghiệp vụ, pháp chế | BA và đội phát triển |
| Đổi thì sao | Đổi cấu hình, có thể không cần sửa code | Thường phải sửa code |
Dòng cuối là lý do thực dụng nhất để tách chúng ra. Nếu bạn viết FR theo kiểu tham chiếu tới rule ("áp dụng theo BR-DIS-03") thay vì nhúng con số vào, thì khi phòng kinh doanh đổi chính sách, đội phát triển chỉ cần đổi giá trị cấu hình.
Ví dụ thực tế
Phòng marketing của một chuỗi cà phê 43 cửa hàng gửi sang ba trang Word mô tả chương trình tích điểm mới. Chương trình cũ đang có 187.000 thành viên.
Bảng rule được tách riêng trong tài liệu:
| Mã | Nội dung | Nguồn | Đổi được không |
|---|---|---|---|
| BR-LOY-01 | 10.000 đồng chi tiêu = 1 điểm, làm tròn xuống | Chính sách marketing | Có, cấu hình |
| BR-LOY-02 | Điểm hết hạn sau 12 tháng kể từ ngày tích | Chính sách marketing | Có, cấu hình |
| BR-LOY-03 | Không tích điểm cho đơn thanh toán bằng voucher toàn phần | Chính sách marketing | Có, cấu hình |
| BR-LOY-04 | Một số điện thoại chỉ gắn với một tài khoản thành viên | Quy định nội bộ chống gian lận | Không |
Sáu tháng sau go-live, marketing đổi BR-LOY-01 thành 20.000 đồng = 1 điểm cho ngày thường, giữ 10.000 cho cuối tuần. Vì rule đã tách và đã được thiết kế thành cấu hình theo khung thời gian, việc đó mất một buổi chiều. Nếu con số 10.000 nằm rải trong code và trong 4 mục của spec, nó là một CR hai tuần.
Mẹo khi đi làm
Giữ một danh sách rule riêng, đánh mã, ghi nguồn và ngày hiệu lực. Cột "ngày hiệu lực" hay bị quên, nhưng nó cứu bạn khi kế toán hỏi "đơn hàng tháng Ba năm ngoái tính phí theo công thức nào".
Hỏi thẳng câu này trong buổi khảo sát: "Có trường hợp ngoại lệ nào không, và ai được duyệt ngoại lệ." Gần như lần nào cũng có, và ngoại lệ chính là phần dev không đoán ra được.
Khi hai phòng ban đưa ra hai rule mâu thuẫn — chuyện thường ở doanh nghiệp lớn — đừng tự chọn một cái. Ghi cả hai vào tài liệu, đánh dấu xung đột, và đẩy lên người có thẩm quyền quyết. BA làm rõ mâu thuẫn, không phải người phán xử chính sách công ty.
