Mở đầu — vì sao bài này quan trọng
Suốt cả Module 2, bạn đã học từng mảnh ghép riêng lẻ: BABOK với 6 knowledge area, 9 kỹ thuật elicitation, 4 cấp độ requirement, các framework prioritization như MoSCoW/Kano/RICE, validation, change management, tool stack. Tất cả những thứ đó giống như học từng nốt nhạc. Bài Capstone này là lúc bạn phải chơi trọn bản nhạc — gộp tất cả lại thành một tài liệu duy nhất mà một ex-Sales như bạn có thể tự hào đưa ra trong buổi phỏng vấn.
SRS (Software Requirements Specification — Đặc tả Yêu cầu Phần mềm) là "deliverable" quan trọng nhất chứng minh bạn là một BA thực thụ chứ không phải người chỉ biết nói chuyện hay. Khi nhà tuyển dụng tại các công ty như Techcombank, MoMo hay VNG nhìn portfolio của bạn, một bản SRS hoàn chỉnh nói lên nhiều điều hơn 10 dòng "kinh nghiệm" trên CV. Nó cho thấy bạn biết tư duy có cấu trúc, biết viết để dev và stakeholder cùng hiểu, biết biến một mong muốn mơ hồ thành thứ có thể build được.
Đề bài Capstone của chúng ta: viết một SRS hoàn chỉnh (15–20 trang) cho feature "CRM 360 view cho Relationship Manager (RM): tổng hợp tài chính + lịch sử giao dịch + cảnh báo cơ hội bán chéo" — một bài toán cực kỳ hợp với người từ nền Sales/BD, vì bạn đã từng đứng ở vị trí người dùng cuối của loại công cụ này.
Khái niệm cốt lõi
SRS là gì và khác BRD ở đâu
SRS là tài liệu mô tả phần mềm sẽ làm gì — chi tiết đến mức dev có thể code và tester có thể kiểm thử. Nó nằm dưới BRD (Business Requirements Document — tài liệu nói "vì sao làm, mục tiêu kinh doanh") và cụ thể hơn nhiều. Nếu BRD trả lời "tại sao", thì SRS trả lời "cái gì" và một phần "như thế nào" ở mức logic (không phải mức code).
Một ex-Sales hay nhầm: bạn quen viết proposal để thuyết phục, văn phong "bán hàng". SRS thì ngược lại — phải khô, chính xác, không mơ hồ, không câu chữ cảm tính. "Hệ thống phải nhanh" là sai; "Trang 360 view phải load trong vòng 2 giây với 95% request" mới đúng.
Bộ khung chuẩn IEEE 830 / ISO 29148
Một SRS chuyên nghiệp thường theo cấu trúc:
- Introduction — Purpose, Scope, Definitions/Glossary, References.
- Overall Description — Product perspective, User classes (ai dùng), Operating environment, Assumptions & Dependencies, Constraints.
- Functional Requirements — Trái tim của SRS: từng tính năng, mô tả qua use case hoặc user story + acceptance criteria.
- External Interface Requirements — UI, API, integration với hệ thống khác.
- Non-Functional Requirements (NFR) — performance, security, usability, availability.
- Data Requirements — data model, data dictionary.
- Appendices — wireframe, business rules, traceability matrix.
Đặc tính của một requirement tốt (tiêu chí INVEST + SMART)
Mỗi requirement bạn viết phải: rõ ràng (unambiguous), kiểm chứng được (verifiable/testable), khả thi (feasible), nhất quán (consistent), và truy vết được (traceable — gắn ngược về mục tiêu business). Đây chính là thứ phân biệt một SRS "nghiệp dư" và một SRS đáng tiền.
Tình huống thực tế
Ví dụ 1 — Techcombank và bài toán 360 view cho RM
Tại một ngân hàng quy mô như Techcombank, mỗi RM (Relationship Manager — chuyên viên quan hệ khách hàng) quản lý khoảng 150–300 khách hàng ưu tiên (Priority Banking). Trước khi có 360 view, để chuẩn bị cho một cuộc gặp, RM phải mở 4 hệ thống khác nhau: core banking xem số dư, hệ thống thẻ xem chi tiêu, hệ thống đầu tư xem danh mục, và Excel cá nhân ghi note. Trung bình mất 25 phút chuẩn bị mỗi khách.
Khi viết SRS cho 360 view, một học viên ex-Sales đã làm rất tốt một việc: vì từng là người bán, anh hiểu RM cần gì ở "phút thứ nhất" của cuộc gọi. Anh đặt functional requirement đầu tiên là "Hiển thị tổng tài sản ròng (Total AUM) và xu hướng 6 tháng ngay khi mở hồ sơ, không cần click". Một BA thuần tech có thể bỏ sót sắc thái này.
Bài học: lợi thế domain của ex-Sales giúp bạn ưu tiên đúng requirement, nhưng bạn vẫn phải viết nó dưới dạng đặc tả đo được: "Khu vực header hiển thị Total AUM cập nhật T-1 (cuối ngày hôm trước), với chỉ báo tăng/giảm so với 6 tháng trước bằng màu xanh/đỏ."
Ví dụ 2 — MoMo và phần cảnh báo bán chéo (cross-sell alert)
Phần khó nhất của đề bài là "cảnh báo cơ hội bán chéo". Tại một fintech như MoMo, đội product muốn hệ thống tự gợi ý: khách A vừa nhận lương lớn → gợi ý sản phẩm tiết kiệm; khách B chi tiêu thẻ tăng 40% → gợi ý nâng hạn mức. Một BA mới hay viết kiểu: "Hệ thống tự động đề xuất sản phẩm phù hợp." Câu này VÔ DỤNG với dev vì không có business rule.
Cách viết đúng là tách thành Business Rule Catalog trong phụ lục:
- BR-01: NẾU số dư tài khoản tăng ≥ 50 triệu trong 3 ngày VÀ khách chưa có sản phẩm tiết kiệm THÌ tạo alert "Cơ hội tiết kiệm" mức ưu tiên Cao.
- BR-02: NẾU chi tiêu thẻ tín dụng 3 tháng gần nhất > 80% hạn mức THÌ tạo alert "Đề xuất nâng hạn mức" mức ưu tiên Trung bình.
Ví dụ 3 — Một SRS "đẹp nhưng vô dụng" tại startup SaaS
Một startup SaaS B2B ở TP.HCM từng có BA viết SRS dài 40 trang, trình bày đẹp, nhưng dev không build được. Lý do: tài liệu toàn đoạn văn dài, không có acceptance criteria, không có wireframe, không có data dictionary. Khi dev hỏi "field 'lịch sử giao dịch' lấy bao nhiêu bản ghi, sắp xếp thế nào?", SRS im lặng. Kết quả: 3 vòng làm lại, trễ 6 tuần.
Bài học: độ dài không bằng độ rõ. Một SRS 15 trang có acceptance criteria và data dictionary đầy đủ thắng một bản 40 trang "văn vẻ". Mục tiêu của Capstone này không phải viết dài, mà viết để build được.
Hướng dẫn từng bước
Bước 1 — Viết Introduction và Scope (1–2 trang). Nêu rõ mục đích, và đặc biệt là In Scope / Out of Scope. Ví dụ: In scope — hiển thị tài chính, lịch sử giao dịch, alert bán chéo. Out of scope — chỉnh sửa thông tin khách hàng, thực hiện giao dịch ngay trên màn hình (chỉ xem, không transact). Việc khoanh vùng out-of-scope ngăn "scope creep" và là dấu hiệu BA trưởng thành.
Bước 2 — Định nghĩa User Classes. Liệt kê các nhóm: RM (người dùng chính), Trưởng nhóm RM (xem dashboard tổng), Admin (phân quyền). Mỗi nhóm có nhu cầu và quyền khác nhau — đây là đầu vào cho phần phân quyền sau này.
Bước 3 — Viết Functional Requirements dưới dạng có ID. Đánh số FR-01, FR-02… Mỗi FR gồm: mô tả ngắn, user story ("Là một RM, tôi muốn… để…"), và acceptance criteria theo Given-When-Then. Gom các FR vào 3 module: (A) Tổng quan tài chính, (B) Lịch sử giao dịch, (C) Cảnh báo bán chéo.
Bước 4 — Đặc tả Non-Functional Requirements. Với một sản phẩm ngân hàng, NFR cực quan trọng: Performance (load < 2s), Security (mã hóa, masking số tài khoản, audit log mọi lượt xem hồ sơ — yêu cầu tuân thủ của NHNN), Availability (99.9%), Usability (dùng được trên tablet khi RM đi gặp khách).
Bước 5 — Vẽ Data Dictionary và Wireframe. Lập bảng từng trường dữ liệu: tên field, kiểu, nguồn (source system), tần suất cập nhật, quy tắc tính. Đính kèm wireframe phác thảo bố cục 3 vùng. Không cần đẹp, cần đúng logic.
Bước 6 — Lập Traceability Matrix. Bảng ánh xạ: mỗi FR truy về business objective nào, và sẽ được test case nào kiểm chứng. Đây là phần khiến nhà tuyển dụng gật gù — nó chứng minh bạn tư duy end-to-end.
Bước 7 — Rà soát theo checklist. Đọc lại từng requirement và tự hỏi: "Câu này có đo được không? Có mơ hồ không? Dev có hỏi lại được không?"
Lỗi thường gặp & mẹo
Lỗi 1 — Văn phong bán hàng. Bỏ hết tính từ cảm tính ("tuyệt vời", "thân thiện", "mạnh mẽ"). Thay bằng con số đo được.
Lỗi 2 — Requirement không testable. "Hệ thống dễ dùng" → đổi thành "RM hoàn thành xem hồ sơ khách trong ≤ 3 click". Quy tắc: nếu QA không viết được test case từ câu của bạn, câu đó chưa đạt.
Lỗi 3 — Bỏ quên NFR và edge case. Khách hàng không có giao dịch nào thì màn hình hiển thị gì? Dữ liệu T-1 chưa cập nhật thì sao? Một BA giỏi luôn đặc tả trạng thái rỗng (empty state) và lỗi.
Lỗi 4 — Trộn lẫn "what" và "how". SRS nói cái gì, không nói dùng React hay Vue, không chọn database. Để dành cho team tech.
Mẹo vàng: dùng template có sẵn (IEEE 830) để không sót mục, nhưng cắt bớt phần thừa cho gọn. Và luôn nhờ một dev đọc thử bản nháp — nếu họ không hỏi lại câu nào, bạn đã viết tốt.
Bài tập thực hành
Hoàn thành bản SRS 15–20 trang cho feature 360 view với cấu trúc bắt buộc sau:
- Introduction + Scope (gồm In/Out of Scope rõ ràng).
- User Classes — tối thiểu 3 nhóm với quyền khác nhau.
- Functional Requirements — tối thiểu 12 FR, chia 3 module (tài chính / lịch sử giao dịch / cảnh báo bán chéo), mỗi FR có user story + acceptance criteria Given-When-Then.
- Business Rule Catalog — tối thiểu 5 rule cho phần bán chéo, viết dạng NẾU–THÌ định lượng.
- Non-Functional Requirements — đủ 5 nhóm: performance, security, availability, usability, compliance.
- Data Dictionary — tối thiểu 10 trường, ghi rõ nguồn và tần suất cập nhật.
- Wireframe phác thảo + Traceability Matrix.
Tóm tắt
Capstone Module 2 là bài kiểm tra tổng hợp: bạn lấy toàn bộ kiến thức BABOK, elicitation, prioritization, validation và gói thành một SRS hoàn chỉnh — deliverable đáng giá nhất trong portfolio của một ex-Sales. Hãy nhớ ba điều cốt lõi: requirement phải đo được và testable, "cơ hội bán chéo" phải mã hóa thành business rule định lượng (đây là sân nhà của bạn), và độ rõ luôn thắng độ dài. Bản SRS này không chỉ là bài tập — đặt nó lên đầu portfolio, nó sẽ là bằng chứng mạnh nhất rằng bạn đã thực sự chuyển mình từ người bán hàng thành một Business Analyst.