Mở đầu — vì sao bài này quan trọng
Bạn đã đi qua gần như trọn vẹn Module 2. Bạn biết 6 Knowledge Area của BABOK, nắm 9 kỹ thuật elicitation, phân biệt được 4 cấp độ requirement, biết prioritize bằng MoSCoW/Kano/RICE, và biết validation khác verification ra sao. Nhưng tất cả những mảnh ghép đó chỉ thực sự có giá trị khi bạn ráp chúng lại thành một tài liệu mà developer cầm lên là code được, QA cầm lên là viết test case được, và sếp cầm lên là duyệt ngân sách được. Tài liệu đó chính là SRS — Software Requirements Specification.
Capstone này quan trọng vì nó mô phỏng đúng "bài thi cuối kỳ" của nghề BA: không ai chấm bạn bằng việc bạn thuộc lý thuyết, người ta chấm bạn bằng một deliverable thật. Và đề bài tôi chọn cho bạn — "Auto-reconcile sub-ledger với GL daily, xử lý FX, intercompany và accrual" — không phải ngẫu nhiên. Đây là một bài toán Finance thuần túy mà bạn, người từ nền kế toán/tài chính, hiểu rõ hơn 90% BA khác trên thị trường. Bạn biết sub-ledger là gì, biết tại sao đối chiếu (reconcile) lại đau đầu, biết accrual (dồn tích) và FX (chênh lệch tỷ giá) phá vỡ số liệu như thế nào. Lợi thế domain của bạn ở đây là vũ khí. Việc của bài học này là dạy bạn cách gói lợi thế đó vào một tài liệu chuẩn ngành.
Khái niệm cốt lõi
SRS là gì và khác PRD ra sao
SRS là tài liệu đặc tả đầy đủ những gì hệ thống phần mềm phải làm (functional) và phải đạt (non-functional). Nếu PRD (bài 4 bạn đã học) trả lời câu hỏi "tại sao xây và xây cái gì cho khách hàng", thì SRS trả lời "hệ thống phải hành xử chính xác như thế nào trong từng tình huống". PRD nghiêng về business và product; SRS nghiêng về solution và đủ chi tiết để dev triển khai. Một SRS tốt cho feature này dài 15–20 trang là hợp lý: không phải càng dài càng tốt, mà là đủ để loại bỏ mọi mơ hồ.
Cấu trúc xương sống của một SRS (theo chuẩn IEEE 830 / ISO 29148)
Tôi khuyên bạn bám một bộ khung quen thuộc, vì người review sẽ tìm đúng mục họ cần:
- Introduction — Purpose, Scope, Definitions/Glossary, References. Đây là nơi bạn định nghĩa "reconcile", "GL", "sub-ledger", "FX gain/loss", "accrual" để dev không hiểu sai.
- Overall Description — bối cảnh hệ thống, các actor (Accountant, Controller, System batch job), giả định và ràng buộc (đóng sổ T+1, múi giờ, nguồn tỷ giá).
- Functional Requirements — trái tim của SRS, viết theo use case hoặc user story kèm acceptance criteria.
- Data Requirements — data model, các trường khóa để match, business rules đối chiếu.
- Non-Functional Requirements — hiệu năng, bảo mật, audit trail, khả năng mở rộng.
- External Interfaces — tích hợp với hệ thống nguồn (POS, banking, ERP), định dạng file/API.
- Assumptions, Constraints, Open Issues — phần thật thà nhất, ghi rõ cái gì chưa chốt.
Đặc thù của bài toán reconciliation
Bài toán đối chiếu có ba "con quái vật" mà bạn phải đặc tả tường minh:
- Matching logic: ghép một dòng sub-ledger với một (hoặc nhiều) dòng GL theo tiêu chí nào — số tiền, ngày, mã chứng từ, cost center? Match 1-1, 1-n hay n-n?
- Tolerance (ngưỡng sai lệch): chênh 1 đồng do làm tròn có coi là khớp không? Đây là business rule, không phải quyết định của dev.
- Exception handling: khi không match được thì hệ thống làm gì — tạo "break", gán trạng thái, route cho ai xử lý? Phần lớn giá trị của tool reconcile nằm ở chỗ xử lý exception, không phải ở chỗ match số đẹp.
Tình huống thực tế
Ví dụ 1 — Chuỗi F&B "Phở Hồng" và bài học scope
Một BA mới chuyển từ kế toán, làm cho chuỗi 40 cửa hàng "Phở Hồng", được giao viết SRS cho tool đối chiếu doanh thu POS với GL. Bạn ấy viết 25 trang rất chi tiết về matching logic, nhưng quên một dòng: nguồn dữ liệu POS xuất file lúc mấy giờ. Khi dev build xong, batch job chạy 1h sáng nhưng file POS của một số cửa hàng tới 3h sáng mới về do mạng yếu ở tỉnh. Kết quả: mỗi sáng có 8–10 cửa hàng "lệch giả" chỉ vì dữ liệu chưa tới, gây 200+ exception rác mỗi ngày. Bài học: phần Assumptions và External Interfaces (data availability, cut-off time) quan trọng ngang với functional requirements. Một dòng giả định bị bỏ sót làm hỏng cả deliverable.
Ví dụ 2 — Fintech "VietPay" và rule FX viết mơ hồ
Tại một ví điện tử giả định "VietPay", BA viết requirement: "Hệ thống đối chiếu giao dịch USD và quy đổi sang VND để khớp với GL." Nghe có vẻ ổn. Nhưng khi UAT, kế toán phát hiện hệ thống dùng tỷ giá ngày T+1 (ngày reconcile) thay vì tỷ giá ngày phát sinh giao dịch, làm chênh lệch tỷ giá (FX gain/loss) bị tính sai hàng chục triệu đồng. Nguyên nhân: requirement không nói rõ dùng tỷ giá nào, nguồn nào (Vietcombank? liên ngân hàng?), tại thời điểm nào, làm tròn mấy chữ số. Khi BA viết lại, một rule duy nhất biến thành 4 rule con: tỷ giá ghi nhận theo ngày giao dịch, chênh lệch giữa ngày ghi nhận và ngày thanh toán hạch toán vào tài khoản 635/515, ngưỡng làm tròn 0 đồng cho VND, và nguồn tỷ giá là rate table nội bộ cập nhật 9h sáng. Bài học: với FX, mỗi từ mơ hồ là một con số sai. Lợi thế Finance của bạn nằm ở chỗ bạn biết phải hỏi những câu này.
Ví dụ 3 — Tập đoàn đa quốc gia và intercompany mismatch
Một controller tại tập đoàn sản xuất có công ty mẹ ở Singapore và nhà máy ở Bình Dương. Giao dịch intercompany (mua bán nội bộ) thường lệch vì hai bên ghi nhận ở hai thời điểm khác nhau và hai loại tiền khác nhau. BA viết SRS đã thêm hẳn một use case "Intercompany matching" với rule: ghép theo cặp mã giao dịch nội bộ (IC reference), cho phép độ trễ 2 ngày làm việc, và bất kỳ chênh lệch nào còn lại sau accrual reversal đều phải tạo break gán cho group controller chứ không phải kế toán địa phương. Nhờ rule routing rõ ràng này, thời gian đóng sổ hợp nhất giảm từ 6 ngày xuống 3 ngày. Bài học: đặc tả exception routing (ai xử lý loại break nào) tạo ra giá trị vận hành thực sự, không chỉ là số khớp trên màn hình.
Hướng dẫn từng bước
Đây là quy trình tôi muốn bạn theo để hoàn thành capstone:
Bước 1 — Viết Introduction và Glossary trước. Liệt kê mọi thuật ngữ: GL, sub-ledger, reconciliation, break, tolerance, FX gain/loss, accrual, accrual reversal, intercompany, cut-off. Định nghĩa từng cái bằng một câu. Đây vừa là phần dễ nhất vừa giúp bạn tự làm rõ phạm vi trong đầu.
Bước 2 — Vẽ context và xác định actor. Ai/cái gì tương tác với hệ thống: batch job hằng ngày, kế toán viên xem break, controller phê duyệt điều chỉnh, hệ thống nguồn (ERP, ngân hàng, rate table). Vẽ một sơ đồ ngữ cảnh đơn giản.
Bước 3 — Đặc tả luồng chính (happy path) bằng use case. Dùng định dạng Cockburn bạn học ở bài 16: tên use case "Auto-reconcile daily", actor chính là Scheduler, tiền điều kiện (GL đã đóng sổ ngày T-1, file sub-ledger đã về), các bước, hậu điều kiện (mọi dòng được gán trạng thái Matched/Break).
Bước 4 — Đặc tả từng business rule bằng bảng. Mỗi rule có ID (BR-01), mô tả, ví dụ số liệu, và tài khoản kế toán liên quan. Riêng FX, intercompany, accrual mỗi loại tối thiểu 2–3 rule.
Bước 5 — Viết acceptance criteria theo Given-When-Then (Gherkin, bài 16). Ví dụ: "Given một dòng sub-ledger 1.000 USD ngày 15/06, When đối chiếu với tỷ giá ngày 15/06 là 25.400, Then giá trị quy đổi 25.400.000 VND được khớp với GL trong ngưỡng 0 đồng."
Bước 6 — Đặc tả non-functional. Batch phải chạy xong trước 7h sáng, xử lý 500.000 dòng trong 30 phút, mọi điều chỉnh đều ghi audit log đầy đủ user/timestamp/before-after (bạn sẽ hiểu sâu phần audit ở bài 19).
Bước 7 — Liệt kê Assumptions và Open Issues. Thật thà ghi cái gì chưa chốt: nguồn tỷ giá cuối cùng, cut-off time của từng hệ thống nguồn, ai duyệt break trên ngưỡng X.
Bước 8 — Review chéo. Đọc lại bằng con mắt của dev (đủ chi tiết để code chưa?) và của QA (mỗi requirement có testable chưa?). Nếu một câu không kiểm thử được, viết lại.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết requirement bằng giải pháp thay vì nhu cầu. "Hệ thống dùng vòng lặp so sánh từng dòng" là cách dev code, không phải requirement. Hãy viết "Hệ thống phải khớp dòng sub-ledger với GL theo mã chứng từ và số tiền trong ngưỡng tolerance." Để dev tự chọn thuật toán.
Lỗi 2 — Bỏ quên đường đi của exception. Người mới chăm chăm tả happy path. Nhưng 80% giá trị nằm ở câu hỏi "khi KHÔNG match thì sao". Mỗi loại break phải có: trạng thái, người xử lý, SLA, hành động đóng break.
Lỗi 3 — Rule FX/accrual viết một câu. Như ví dụ VietPay, mỗi từ mơ hồ là một con số sai. Mẹo: với mỗi rule tài chính, tự hỏi "tỷ giá/ngày/tài khoản/ngưỡng làm tròn nào?" — bốn câu hỏi này lọc ra hầu hết lỗ hổng.
Lỗi 4 — Requirement không testable. Tránh từ "nhanh", "ổn định", "thân thiện". Thay bằng số: "chạy xong trước 7h00", "tối đa 0,1% break do lỗi hệ thống".
Mẹo vàng: tận dụng nền Finance. Bạn biết accrual cần được reverse ở kỳ sau, nên SRS của bạn phải có rule "accrual reversal không tạo break nếu khớp với accrual gốc theo mã". Đây là kiến thức BA thuần không biết — hãy biến nó thành điểm khác biệt trong portfolio.
Bài tập thực hành
- Viết SRS hoàn chỉnh 15–20 trang cho feature "Auto-reconcile sub-ledger với GL daily", đầy đủ 7 mục cấu trúc ở phần khái niệm. Đây là deliverable chính của capstone.
- Glossary tối thiểu 12 thuật ngữ, mỗi thuật ngữ một câu định nghĩa.
- Bảng business rule tối thiểu 12 rule, trong đó ít nhất 3 rule cho FX, 3 cho intercompany, 3 cho accrual, mỗi rule kèm ví dụ số liệu và tài khoản kế toán.
- 5 acceptance criteria viết theo Given-When-Then, trong đó ít nhất 1 cho trường hợp break không match được.
- 1 sơ đồ ngữ cảnh thể hiện actor và hệ thống nguồn.
- Một mục Open Issues liệt kê tối thiểu 3 điểm chưa chốt kèm người chịu trách nhiệm quyết định.
Tóm tắt
SRS là nơi mọi kiến thức Module 2 hội tụ thành một deliverable thật. Với bài toán reconciliation, ba điểm sống còn là matching logic, tolerance và exception handling — và FX, intercompany, accrual chính là ba nguồn exception lớn nhất cần rule riêng. Bám cấu trúc IEEE 830, viết requirement ở mức nhu cầu chứ không phải giải pháp, mỗi rule tài chính phải trả lời đủ tỷ giá/ngày/tài khoản/ngưỡng, và mỗi câu phải testable. Lợi thế Finance của bạn — hiểu accrual reversal, FX gain/loss, intercompany — là thứ biến một SRS bình thường thành tài liệu khiến nhà tuyển dụng nhớ mặt. Hãy viết capstone này nghiêm túc: nó sẽ là viên gạch đẹp nhất trong portfolio BA của bạn.