CẨM NANG CHUYÊN SÂU BIÊN SOẠN TÀI LIỆU BRD VÀ SRS TRONG DOMAIN BANKING

Trong ngành Tài chính - Ngân hàng (BFSI), hệ thống phần mềm không chỉ phục vụ vận hành kinh doanh mà còn liên quan trực tiếp đến dòng tiền thật, dữ liệu nhạy cảm và sự tuân thủ pháp lý nghiêm ngặt của Ngân hàng Nhà nước (NHNN). Khác với các dự án phần mềm thương mại thông thường (E-commerce, Social App), hệ thống phần mềm ngân hàng thuộc nhóm Mission-Critical — nơi một sai sót nhỏ trong khâu đặc tả nghiệp vụ có thể dẫn đến lệch sổ cái (GL Imbalance), thất thoát tài chính hoặc vi phạm quy định pháp lý.

Do đó, bộ đôi tài liệu BRD (Business Requirements Document) và SRS (Software Requirements Specification) chính là "hợp đồng nghiệp vụ & kỹ thuật" giữa Khối Nghiệp vụ (Business Units) và Khối Công nghệ (IT Units).

Bài viết chuyên sâu này sẽ phân tích chi tiết quy trình từng bước xây dựng tài liệu BRD và SRS chuẩn quốc tế cho domain Banking, kèm theo các lưu ý "xương máu" và bộ câu hỏi thường gặp giúp các IT Business Analyst (IT BA) tự tin chủ trì các dự án tài chính - ngân hàng phức tạp.

1. PHÂN BIỆT BRD VÀ SRS TRONG CONTEXT NGÂN HÀNG

Rất nhiều BA trẻ khi mới bước chân vào domain Ngân hàng thường nhầm lẫn giữa BRD và SRS. Việc mơ hồ này dẫn đến cạm bẫy: viết SRS quá chung chung như BRD khiến Dev/Tester không thể triển khai, hoặc đưa quá nhiều giải pháp kỹ thuật vào BRD khiến các Trưởng khối nghiệp vụ không thể phê duyệt (Sign-off).

2. QUY TRÌNH 4 BƯỚC BIÊN SOẠN TÀI LIỆU BRD CHUẨN NGÂN HÀNG

Tài liệu BRD trong ngân hàng đóng vai trò là căn cứ pháp lý để Ban Dự án xin phê duyệt ngân sách và cam kết chỉ số KPI kinh doanh.

Bước 1: Khai Thác Nhu Cầu Kinh Doanh & Định Hình Bối Cảnh (Business Context)

Xác định bài toán gốc: Phỏng vấn Ban Giám đốc các Khối nghiệp vụ để làm rõ động lực dự án.

Ví dụ: Khối Khách hàng Cá nhân muốn triển khai tính năng Mở tài khoản thanh toán qua eKYC trên Mobile App nhằm tăng 30% lượng tài khoản CASA mới trong Quý 3.

Xác định chỉ số ROI & KPI: Định lượng kết quả bằng con số cụ thể (Rút ngắn thời gian mở tài khoản từ 15 phút xuống 2 phút; Tỷ lệ tự động duyệt khoản vay đạt 60%).

Bước 2: Rà Soát Khung Pháp Lý Và Compliance (Regulatory & Risk Assessment)

Đây là bước bắt buộc đối với mọi tài liệu BRD trong ngành ngân hàng:

Rà soát các Thông tư, Quy định của Ngân hàng Nhà nước liên quan trực tiếp đến tính năng (Ví dụ: Thông tư về xác thực sinh trắc học trong thanh toán trực tuyến, quy định về hạn mức giao dịch qua kênh số).

Tham vấn Khối Quản trị Rủi ro & Compliance để đưa các ràng buộc pháp lý vào tài liệu làm tiêu chuẩn bắt buộc (Non-negotiable requirements).

Bước 3: Mô Hình Hóa Quy Trình Nghiệp Vụ Tổng Quan (As-Is vs To-Be)

Quy trình As-Is (Hiện trạng): Mô tả chi tiết cách thức khách hàng và chi nhánh đang vận hành (Ví dụ: Khách hàng phải ra quầy xuất trình CCCD, Giao dịch viên nhập liệu, Kiểm soát viên ký duyệt giấy).

Quy trình To-Be (Mục tiêu): Mô hình hóa quy trình số hóa hoàn toàn (Khách hàng quét NFC CCCD gắn chip -> eKYC bóc tách OCR -> Gọi sang CSDL Quốc gia về Dân cư -> Tự động khởi tạo mã CIF và tài khoản trên Core Banking).

Bước 4: Chốt Phạm Vi Dự Án (In-Scope & Out-of-Scope Boundary)

Liệt kê danh sách các Module và Kênh giao dịch được áp dụng (In-Scope: Mobile App iOS/Android, Admin Portal cho Chi nhánh).

Liệt kê rõ ràng các tính năng CHƯA triển khai trong pha này (Out-of-Scope: Mở tài khoản cho khách hàng doanh nghiệp SME, Mở tài khoản cho người nước ngoài) để tránh bị phình phạm vi (Scope Creep).

3. QUY TRÌNH 5 BƯỚC BIÊN SOẠN TÀI LIỆU SRS CHUYÊN SÂU DOMAIN BANKING

Tài liệu SRS chuyển hóa các nhu cầu kinh doanh từ BRD thành các quy tắc kỹ thuật nghiêm ngặt mà lập trình viên có thể thực thi chính xác 100%.

Bước 1: Thiết Lập Sơ Đồ Ma Trận Hạch Toán Kế Toán (Accounting Entry Matrix)

Mọi giao dịch liên quan đến tiền trong ngân hàng đều phải sinh ra bút toán hạch toán Nợ/Có (Debit/Credit). IT BA bắt buộc phải xây dựng Ma trận hạch toán trong SRS:

Tên giao dịch: Nộp tiền tiết kiệm có kỳ hạn tại quầy.

Bút toán hạch toán:

Nợ (Debit): Tài khoản Tiền mặt tại quỹ chi nhánh (GL Account: 1011xxxx).

Có (Credit): Tài khoản Tiền gửi tiết kiệm của khách hàng (GL Account: 4232xxxx).

Sơ đồ tài khoản (Chart of Accounts - COA): Đặc tả mã phân hệ GL, mã loại tiền (VND/USD), quy tắc tính thuế GTGT (nếu có).

Bước 2: Đặc Tả Quy Tắc Phân Quyền & Hạn Mức Kiểm Soát Kép (Maker - Checker Rules)

Hệ thống ngân hàng áp dụng nguyên tắc kiểm soát kép (Four-Eyes Principle) để ngừa rủi ro gian lận nội bộ:

Hạn mức giao dịch (Transaction Limit Thresholds):

Giao dịch < 100 triệu VND: Điện viên (Maker) thực hiện -> Hệ thống tự động duyệt.

Giao dịch 100 triệu - 1 tỷ VND: Maker nhập lệnh -> Chuyển sang hàng chờ của Kiểm soát viên (Checker) phê duyệt.

Giao dịch > 1 tỷ VND: Maker nhập lệnh -> Checker duyệt -> Giám đốc Chi nhánh ký đè trút quyền (Override).

Quy tắc ngăn ngừa xung đột (Conflict of Interest): Người khởi tạo giao dịch (Maker) tuyệt đối không được tự phê duyệt (Checker) cho chính giao dịch đó.

Bước 3: Đặc Tả Luồng Giao Dịch & Xử Lý Ngoại Lệ Đảo Bút Toán (Storno / Reversal Logic)

Trong ngân hàng, tuyệt đối KHÔNG BAO GIỜ dùng câu lệnh DELETE để xóa bản ghi giao dịch trong CSDL.

Main Flow (Luồng chính): Khách hàng chuyển khoản thành công -> Tài khoản người gửi bị trừ tiền -> Tài khoản người nhận tăng tiền -> Sinh bản ghi Audit Log.

Exception Flow - Reversal / Storno (Giao dịch đảo): Nếu bước ghi Có cho tài khoản người nhận bị lỗi (Timeout hoặc sai số tài khoản), hệ thống phải tự động sinh ra một Giao dịch đảo ngược chiều (ngược Nợ/Có) với đúng mã ref giao dịch ban đầu để trả lại tiền cho người gửi, đảm bảo vết kiểm toán (Audit Trail) phục vụ công tác thanh tra.

Bước 4: Tích Hợp API Lớp Trung Gian & Định Dạng Chuẩn Dữ Liệu (ESB / API Gateway Integration)

Đặc tả chi tiết các luồng giao tiếp giữa ứng dụng vệ tinh (Mobile App/LOS/CMS) với hệ thống Core Banking qua Trục tích hợp (ESB):

Định dạng dữ liệu: Chuẩn tin nhắn tài chính quốc tế ISO 20022 (XML) hoặc RESTful API (JSON).

Trường dữ liệu bắt buộc (Data Dictionary): Tên trường, Kiểu dữ liệu (String, Numeric, DateTime), Độ dài, Quy tắc Validation (Ví dụ: CIF_NUMBER phải đủ 8 chữ số, AMOUNT phải lớn hơn 0).

Cơ chế xử lý Timeout & Reconcile: Nếu kết nối từ Mobile App sang Core Banking bị gãy ở giây thứ 25 (Timeout):

Lớp ESB giữ trạng thái giao dịch là PENDING.

Đẩy bản ghi vào danh sách chờ đối soát (Reconciliation Queue).

Tuyệt đối không tự ý báo lỗi ảo cho khách hàng làm họ thực hiện lại giao dịch gây trừ tiền hai lần.

Bước 5: Đặc Tả Tiến Trình Chốt Sổ Cuối Ngày (End of Day - EOD Batch Jobs)

Tiến trình EOD là chuỗi công việc tự động chạy theo lô vào đêm muộn để khóa sổ kế toán ngày. IT BA cần đặc tả trong SRS:

Thứ tự ưu tiên phụ thuộc (Job Dependency):

Job 1: Khóa sổ giao dịch ban ngày (Cut-off Time: 17h00).

Job 2: Tính lãi dồn tích tự động (Interest Accrual) cho toàn bộ tài khoản Tiết kiệm và CASA.

Job 3: Quét tự động nhóm nợ quá hạn và thực hiện trích lập dự phòng (Lending module).

Job 4: Cân đối Sổ cái và tổng hợp Báo cáo tài chính (GL Balance Sheet).

Tính khả lặp (Idempotency) & Rollback: Nếu Job 2 bị crash giữa chừng do mất điện, hệ thống phải cho phép chạy lại từ đúng điểm lỗi (Resume) mà không làm tính trùng số tiền lãi của khách hàng.

4. NHỮNG LƯU Ý "XƯƠNG MÁU" KHI VIẾT BRD VÀ SRS TRONG DOMAIN BANKING

1. Bẫy sử dụng từ ngữ mơ hồ, thiếu định lượng

Sai: "Hệ thống phải xử lý giao dịch chuyển tiền nhanh chóng và bảo mật cao."

Đúng: "Thời gian phản hồi API chuyển tiền nội bộ (End-to-End Latency) phải < 1.5 giây với tải lượng 5,000 concurrent requests. Mã hóa dữ liệu truyền tải theo chuẩn TLS 1.3 và dữ liệu lưu trữ theo chuẩn AES-256."

2. Bỏ quên kịch bản xử lý lệch sổ cái (Unbalanced GL Entries)

Trong các giao dịch phức tạp (như thanh toán quốc tế SWIFT hoặc giải ngân khoản vay kèm thu phí dịch vụ), tổng tiền Nợ (Debit) và tổng tiền Có (Credit) bắt buộc phải bằng nhau từng xu. BA phải kiểm tra kỹ điều kiện cân bằng hạch toán trước khi bàn giao SRS cho Dev.

3. Thiếu thủ tục xác nhận (Sign-off) đa tầng

Tài liệu BRD/SRS trong ngân hàng chỉ có hiệu lực khi có đủ chữ ký của:

Đại diện Khối Nghiệp vụ (Business Owner) - Xác nhận đúng nhu cầu kinh doanh.

Đại diện Khối Công nghệ (IT Solution Architect) - Xác nhận khả thi về mặt kỹ thuật.

Đại diện Khối Quản trị Rủi ro & Compliance - Xác nhận an toàn bảo mật và đúng pháp lý.

5. CÁC CÂU HỎI THƯỜNG GẶP (FAQS) KHONG BIÊN SOẠN BRD & SRS NGÂN HÀNG

Q1: Làm sao để IT BA không xuất thân từ ngành Kế toán vẫn có thể viết chính xác Ma trận hạch toán (Accounting Matrix) trong SRS?

Trả lời: IT BA không cần tự nghĩ ra các tài khoản GL. Quy trình chuẩn là BA sẽ tổ chức các buổi Workshop làm việc trực tiếp với Khối Kế toán tài chính (Financial Accounting Department) của ngân hàng. BA đưa ra kịch bản giao dịch nghiệp vụ (User Flow), Kế toán sẽ cung cấp Sơ đồ tài khoản (Chart of Accounts) và cặp Nợ/Có tương ứng. Nhiệm vụ của BA là chuẩn hóa thông tin đó thành bảng Field Mapping trong SRS cho đội ngũ Dev.

Q2: Sự khác biệt lớn nhất giữa Change Request (CR) và Out of Scope trong một dự án Core Banking là gì?

Trả lời:

Out of Scope: Là các tính năng đã được thống nhất loại trừ ngay từ giai đoạn lập tài liệu BRD ban đầu (được ghi rõ trong phần Boundary).

Change Request (CR): Là các yêu cầu phát sinh mới hoặc sự thay đổi logic so với bản BRD/SRS đã được ký duyệt (Sign-off). Trong dự án Core Banking, mọi CR bắt buộc phải trải qua quy trình đánh giá tác động (Impact Analysis) về chi phí, tiến độ và rủi ro an toàn hệ thống trước khi phê duyệt thực hiện.

Q3: Khi biên soạn SRS cho dự án Chuyển đổi Core Banking (Core Migration), làm sao để xử lý bất đồng bộ cấu trúc Số tài khoản giữa Core cũ và Core mới? kho Trả lời: IT BA phải thiết kế Bảng quy tắc ánh xạ dữ liệu (Data Mapping Rules).

Ví dụ: Core cũ dùng số tài khoản 10 chữ số, Core mới dùng 14 chữ số.

BA phải đặc tả thuật toán sinh số tài khoản mới (Thêm mã Chi nhánh + Mã sản phẩm ở đầu) và viết logic Alias/Legacy Mapping. Khi khách hàng gõ số tài khoản 10 chữ số cũ trên Mobile App hay cây ATM, hệ thống trung gian (ESB) phải tự động tra cứu Bảng ánh xạ để chuyển đổi thành số tài khoản 14 chữ số mới trước khi gửi câu lệnh truy vấn sang Core mới.

6. LỜI KẾT VÀ NÂNG TẦM NĂNG LỰC IT BA NGÂN HÀNG

Biết cách biên soạn bộ tài liệu BRD và SRS chuẩn mực trong domain Banking không chỉ giúp bạn hoàn thành xuất sắc các dự án công nghệ tài chính phức tạp mà còn khẳng định uy tín chuyên môn tuyệt đối trước các cấp quản lý và đối tác.

Để rút ngắn nhiều năm tự thử sai và nâng cao phản xạ phân tích nghiệp vụ ngân hàng thực tế. Bạn sẽ được cọ xát trực tiếp trên các bộ tài liệu thật, thực hành viết SRS/BRD cho bài toán Core Banking, eKYC, LOS và nhận phản hồi chi tiết từng dòng chữ (Line-by-line review) để nhanh chóng làm chủ sự nghiệp IT BA đẳng cấp.