Mở đầu — vì sao bài này quan trọng
Bạn vừa đi qua trọn vẹn Module 2 — từ tổng quan 6 knowledge area của BABOK, 9 kỹ thuật elicitation, phân loại requirement, prioritization, validation, change management, cho tới solution evaluation và Agile BA. Rất nhiều kiến thức. Nhưng đây là sự thật phũ phàng mà mình muốn nói thẳng với bạn: nhà tuyển dụng BA ở Việt Nam không mua kiến thức của bạn, họ mua sản phẩm của bạn. Và sản phẩm nổi bật nhất, được hỏi nhiều nhất trong phỏng vấn, chính là một bộ SRS hoàn chỉnh.
SRS (Software Requirements Specification — Đặc tả yêu cầu phần mềm) là bản tài liệu "xương sống" mà dev, QA, PM và cả sếp doanh nghiệp đều đọc để hiểu hệ thống sẽ làm gì. Với một người từ nền Design chuyển sang, đây vừa là cơ hội vừa là thử thách: bạn có lợi thế tư duy người dùng và khả năng trình bày, nhưng bạn dễ viết mơ hồ, thiếu cấu trúc, thiếu tính "verifiable" (kiểm chứng được) — đúng những thứ mà một SRS chuyên nghiệp đòi hỏi.
Bài này là capstone của Module 2: mình sẽ giúp bạn hệ thống lại toàn bộ kiến thức đã học và biến nó thành hành động cụ thể — viết một SRS 15–20 trang cho một feature thật, có độ khó ngang với dự án ngân hàng số thực tế. Sau bài này, bạn không chỉ "biết" mà "làm được".
Khái niệm cốt lõi
SRS là gì và khác gì với BRD/FRD
Trước khi viết, phải phân biệt rõ. Trong bậc thang tài liệu BA:
- BRD (Business Requirements Document) trả lời câu hỏi "Tại sao?" — mục tiêu kinh doanh, bối cảnh, giá trị. Ví dụ: "Giảm 40% khách bỏ cuộc khi mở tài khoản do phải ra quầy."
- FRD/SRS trả lời câu hỏi "Cái gì?" — hệ thống phải làm những gì, một cách chi tiết và kiểm chứng được. SRS thường bao gồm cả functional lẫn non-functional requirements, và là chuẩn theo IEEE 830 / ISO/IEC/IEEE 29148.
Cấu trúc chuẩn của một SRS
Một SRS 15–20 trang chuyên nghiệp thường có các phần sau (ánh xạ theo IEEE 29148):
- Introduction — Purpose, Scope, Definitions/Acronyms, References.
- Overall Description — Product perspective, user classes (phân loại người dùng), assumptions & dependencies, constraints.
- Functional Requirements — mô tả bằng use case hoặc user story, kèm business rules.
- Data Requirements — các thực thể dữ liệu, data dictionary, mối quan hệ.
- External Interface Requirements — UI, API, tích hợp bên thứ ba.
- Non-Functional Requirements (NFR) — hiệu năng, bảo mật, tính khả dụng, tuân thủ pháp lý.
- Appendices — RTM (traceability matrix), wireframe, glossary.
Ba tiêu chí "vàng" của một requirement tốt
Ôn lại từ bài validation: mỗi câu requirement bạn viết phải đạt được ba chữ:
- Verifiable (kiểm chứng được): thay vì "hệ thống phản hồi nhanh", viết "hệ thống trả kết quả eKYC trong ≤ 3 giây với 95% request".
- Unambiguous (không đa nghĩa): tránh "nên", "thường", "nếu cần". Dùng "phải" (shall).
- Atomic (nguyên tử): một requirement chỉ nói một điều, để dễ trace và test.
Ngữ cảnh bài tập: eKYC mở tài khoản online
Đề bài của capstone là feature "Mở tài khoản thanh toán online cho khách hàng cá nhân" — sử dụng eKYC (electronic Know Your Customer — định danh khách hàng điện tử) qua camera. Đây là feature có thật, chịu sự điều chỉnh của Thông tư 17/2024/TT-NHNN và Nghị định 13/2023 về bảo vệ dữ liệu cá nhân. Nó có đủ độ phức tạp để bạn thực hành mọi thứ đã học: nhiều actor, nhiều luồng ngoại lệ, nhiều business rule tuân thủ, tích hợp bên thứ ba (NFC căn cước, OCR, liveness detection).
Tình huống thực tế
Ví dụ 1 — TPBank và bài học về "happy path fixation"
Một team BA tại một ngân hàng số kiểu TPBank triển khai luồng eKYC. SRS phiên bản đầu chỉ mô tả luồng thành công: khách chụp căn cước → hệ thống OCR → chụp selfie → so khớp khuôn mặt → tạo tài khoản. Nghe rất gọn. Nhưng khi go-live, 28% khách kẹt lại vì các tình huống không được đặc tả: căn cước bị lóa sáng, khuôn mặt không khớp do đeo kính, khách là người đã có tài khoản, hoặc nằm trong danh sách chống rửa tiền (AML).
Bài học: với feature nghiệp vụ nặng, phần alternative flow và exception flow trong use case thường dài gấp 2–3 lần happy path. Một SRS thiếu các luồng ngoại lệ là một SRS chưa xong. Khi làm capstone, hãy dành ít nhất một nửa dung lượng phần functional cho các luồng lỗi.
Ví dụ 2 — Timo và NFR bị bỏ quên
Ở một dự án ngân hàng số kiểu Timo, BA viết functional requirement rất kỹ nhưng phần NFR chỉ có một dòng "hệ thống phải bảo mật". Đến giai đoạn UAT, đội bảo mật hỏi: dữ liệu selfie lưu bao lâu? Có mã hóa at-rest không? Liveness detection chống được video giả mạo (spoofing) ở mức nào? Không ai trả lời được vì SRS không đặc tả. Kết quả: chậm phát hành 6 tuần để bổ sung.
Bài học: với fintech/banking, NFR về bảo mật, tuân thủ và hiệu năng quan trọng ngang functional. Một câu NFR tốt: "Ảnh sinh trắc học phải được mã hóa AES-256 at-rest và xóa khỏi tầng xử lý tạm trong ≤ 24 giờ theo Nghị định 13/2023." Đó là verifiable, unambiguous, có tham chiếu pháp lý.
Ví dụ 3 — Anh Minh, Designer chuyển BA, và cái bẫy "mô tả màn hình"
Anh Minh — một UX Designer 4 năm kinh nghiệm tại một agency ở TP.HCM — nộp SRS đầu tiên cho vị trí BA fresher tại một ví điện tử. Reviewer phản hồi: "Đây là bản mô tả wireframe, không phải SRS." Anh viết "màn hình có nút Tiếp tục màu xanh, khi bấm chuyển sang bước selfie" — tức là mô tả giải pháp UI chứ không phải yêu cầu hệ thống. Đáng lẽ phải viết: "Hệ thống phải cho phép khách hàng chuyển sang bước xác thực sinh trắc học sau khi hoàn tất bước nhập thông tin định danh và vượt qua kiểm tra hợp lệ."
Bài học: SRS mô tả hành vi hệ thống (system behavior), độc lập với UI cụ thể. Wireframe của bạn là appendix minh họa, không phải nội dung chính. Đây là điểm chuyển dịch tư duy lớn nhất từ Design sang BA.
Hướng dẫn từng bước
Đây là quy trình mình khuyên bạn theo để viết SRS capstone:
Bước 1 — Xác định scope và ranh giới (nửa trang). Viết rõ in-scope: mở tài khoản thanh toán cá nhân qua eKYC bằng căn cước công dân gắn chip. Out-of-scope: mở tài khoản doanh nghiệp, khách nước ngoài dùng hộ chiếu, tài khoản tiết kiệm. Ranh giới rõ ràng cứu bạn khỏi scope creep.
Bước 2 — Liệt kê actor và stakeholder. Actor chính: Khách hàng cá nhân. Actor phụ: Hệ thống OCR, Hệ thống Liveness/Face-match, Hệ thống AML/blacklist, Nhân viên hậu kiểm (manual review), Cổng CIC/NFC. Dùng lại kỹ thuật stakeholder analysis từ Module 1.
Bước 3 — Viết functional requirement dưới dạng use case. Với feature này, use case chính là "UC-01: Mở tài khoản thanh toán qua eKYC". Cấu trúc theo template Cockburn: Precondition, Main flow, Alternative flows, Exception flows, Postcondition. Mỗi bước đánh số để trace được.
Bước 4 — Bóc tách business rules thành catalog riêng. Ví dụ: BR-01 "Khách phải đủ 15 tuổi trở lên", BR-02 "Điểm face-match phải ≥ 85% mới auto-approve, 70–85% chuyển hậu kiểm, <70% từ chối", BR-03 "Một số CCCD chỉ được liên kết tối đa 1 tài khoản thanh toán tại thời điểm mở". Tách rule khỏi flow giúp maintain dễ hơn.
Bước 5 — Đặc tả data requirements. Lập data dictionary: mỗi field (họ tên, số CCCD, ngày sinh, ảnh chân dung, hash sinh trắc học...) kèm kiểu dữ liệu, ràng buộc, bắt buộc/tùy chọn, nguồn (nhập tay/OCR/NFC).
Bước 6 — Viết NFR đo được. Chia nhóm: Performance (thời gian OCR ≤ 2s, face-match ≤ 3s), Security (mã hóa, retention), Availability (uptime 99.5%), Compliance (Thông tư 17/2024, Nghị định 13/2023), Usability (hoàn tất trong ≤ 5 phút).
Bước 7 — Đặc tả interface. API tích hợp NFC đọc chip, API OCR, API face-match — mô tả input/output ở mức nghiệp vụ (không cần code, tham chiếu bài API spec).
Bước 8 — Lập RTM. Bảng truy vết: mỗi business requirement → functional requirement → test case. Đây là phần cho reviewer thấy bạn tư duy có hệ thống.
Bước 9 — Rà soát bằng checklist V&V. Đọc lại từng câu: có verifiable không? có atomic không? có "shall" không? Loại bỏ mọi câu mơ hồ.
Lỗi thường gặp & mẹo
- Lỗi mô tả UI thay vì hành vi hệ thống. Mẹo: mỗi khi định viết "màn hình có...", hãy đổi thành "hệ thống phải cho phép/phải hiển thị/phải xác thực...". Wireframe đưa xuống appendix.
- Bỏ quên exception flow. Mẹo: với mỗi bước main flow, tự hỏi "nếu bước này thất bại thì sao?". Căn cước mờ, mất mạng giữa chừng, timeout NFC, khách đã có tài khoản — mỗi cái là một exception flow.
- NFR viết chung chung. Mẹo: mọi NFR phải có con số và đơn vị. "Nhanh" không phải NFR; "≤ 3 giây với 95% request" mới là.
- Requirement không nguyên tử. Mẹo: nếu một câu có chữ "và" nối hai hành vi, tách thành hai requirement.
- Quên compliance của ngành. Mẹo: với fintech/banking VN, luôn có một mục riêng cho tuân thủ pháp lý và tham chiếu văn bản cụ thể — reviewer đánh giá rất cao điều này.
- Requirement không có ID. Mẹo: đánh mã nhất quán (FR-01, BR-02, NFR-03) ngay từ đầu để trace trong RTM.
- Viết quá dài, lan man. Mẹo: một requirement gói gọn trong 1–2 câu. Dung lượng đến từ số lượng requirement được đặc tả đầy đủ, không phải từ văn hoa.
Bài tập thực hành
Nhiệm vụ capstone của bạn: viết một SRS hoàn chỉnh 15–20 trang cho feature "Mở tài khoản thanh toán online cho khách hàng cá nhân (eKYC + camera)". Yêu cầu cụ thể:
- Phần Introduction & Overall Description (2–3 trang): purpose, scope (in/out), definitions, user classes, assumptions, constraints.
- Ít nhất 1 use case đầy đủ theo template Cockburn cho luồng mở tài khoản, với tối thiểu 3 alternative flow và 4 exception flow (căn cước mờ, face-match fail, khách đã có tài khoản, trúng danh sách AML).
- Business rule catalog tối thiểu 8 rule có mã BR, bao gồm rule về tuổi, ngưỡng face-match, giới hạn tài khoản/CCCD.
- Data dictionary cho tối thiểu 12 field, có kiểu dữ liệu và nguồn.
- NFR tối thiểu 10 mục chia theo 5 nhóm (performance, security, availability, compliance, usability), mỗi mục phải có con số đo được.
- RTM truy vết ít nhất 5 requirement từ business → functional → test case.
- Appendix: 2–3 wireframe minh họa (bạn có lợi thế Designer — tận dụng, nhưng để ở appendix).
Gợi ý nộp: xuất file PDF hoặc trang Confluence, đặt tên chuẩn "SRS_eKYC_OpenAccount_v1.0". Đây chính là artifact bạn sẽ đưa vào portfolio ở Module 3.
Tóm tắt
Module 2 đã trang bị cho bạn nền tảng BABOK, elicitation, phân loại và ưu tiên requirement, validation, change và solution evaluation. Bài capstone này gắn tất cả lại bằng một sản phẩm thật: bộ SRS.
Ba điều cần khắc cốt: (1) SRS mô tả hành vi hệ thống, không phải UI — đây là cú chuyển dịch tư duy lớn nhất của người từ Design; (2) phần exception flow và NFR đo được thường quyết định chất lượng SRS, đặc biệt trong fintech/banking Việt Nam nơi compliance là bắt buộc; (3) mỗi requirement phải verifiable, unambiguous, atomic và có mã để trace trong RTM.
Hoàn thành capstone này, bạn có trong tay một artifact đủ sức đặt lên bàn phỏng vấn và nói: "Đây là năng lực BA của tôi." Ở Module 3, chúng ta sẽ biến những artifact này thành portfolio và chiến lược xin việc thực chiến.