Mở đầu — vì sao bài này quan trọng
Nếu Elicitation (KA2) là lúc bạn "đào" thông tin từ stakeholder, thì Requirements Analysis & Design Definition (KA5) chính là lúc bạn biến đống thông tin thô, rời rạc, mâu thuẫn đó thành những requirement và design có cấu trúc, rõ ràng, đủ tốt để đội phát triển xây dựng được sản phẩm. Đây là Knowledge Area thứ năm trong BABOK Guide v3, và theo kinh nghiệm của tôi, nó là nơi phân biệt một BA "ghi chép họp" với một BA thực thụ.
Tại sao? Vì stakeholder không bao giờ nói cho bạn một requirement hoàn chỉnh. Họ nói "tôi muốn khách hàng đăng nhập nhanh hơn". Câu đó chưa phải requirement — đó là một mong muốn mơ hồ. Việc của BA trong KA5 là phân rã nó, mô hình hóa nó, định nghĩa thuộc tính, xác minh nó đúng, kiểm tra giá trị nó mang lại, rồi đề xuất phương án thiết kế. KA5 là "trái tim phân tích" của nghề BA — nơi tư duy logic, kỹ năng mô hình hóa và khả năng đánh giá giá trị kinh doanh hội tụ.
Một điểm rất quan trọng mà nhiều người Việt học BA hay bỏ qua: BABOK v3 đã chính thức gộp "Requirements Analysis" và "Design Definition" vào chung một KA. Lý do là ranh giới giữa "yêu cầu" (what) và "thiết kế" (how) trong thực tế rất mờ và lặp đi lặp lại liên tục. Hiểu được sự liền mạch này sẽ giúp bạn làm việc tự nhiên hơn với cả team waterfall lẫn agile.
Khái niệm cốt lõi
KA5 gồm 6 task chính. Hãy nắm chắc tên và mục đích của từng task, vì đề thi ECBA/CCBA/CBAP hỏi rất nhiều ở đây.
1. Specify and Model Requirements (Đặc tả và Mô hình hóa)
Đây là task nền tảng: bạn vừa viết requirement (specify) bằng văn bản, vừa vẽ nó (model) bằng các sơ đồ. Hai cách bổ trợ nhau — văn bản cho chi tiết, mô hình cho bức tranh tổng thể và các mối quan hệ.
Các loại mô hình thường dùng:
- Process model — BPMN, flowchart (mô tả luồng nghiệp vụ).
- Data model — ERD, data dictionary (mô tả dữ liệu và quan hệ).
- Behavioral/Interaction model — Use Case, sequence diagram, state diagram (mô tả hành vi hệ thống).
- User experience model — wireframe, prototype (mô tả giao diện).
- Rule model — decision table, business rules (mô tả quy tắc nghiệp vụ).
2. Verify Requirements (Xác minh)
Verify trả lời câu hỏi: "Requirement này có được viết ĐÚNG chuẩn chất lượng không?" Đây là kiểm tra nội tại, không cần stakeholder. Bạn dùng bộ tiêu chí chất lượng (atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritized, understandable). Nói nôm na: requirement có rõ ràng, không mâu thuẫn, không thừa, có thể kiểm thử được không?
3. Validate Requirements (Thẩm định)
Validate trả lời câu hỏi khác hẳn: "Requirement này có mang lại GIÁ TRỊ kinh doanh đúng như mong đợi không?" Đây là kiểm tra với stakeholder và đối chiếu với mục tiêu/giải pháp. Một requirement có thể viết rất chuẩn (verify pass) nhưng lại vô dụng vì không phục vụ mục tiêu nào (validate fail).
> Mẹo nhớ: Verify = Are we building the requirement RIGHT? (đúng cách). Validate = Are we building the RIGHT requirement? (đúng thứ).
4. Define Requirements Architecture (Kiến trúc yêu cầu)
Task này đảm bảo tất cả requirement gắn kết thành một tổng thể mạch lạc, không lỗ hổng, không trùng lặp, không mâu thuẫn. Nó dùng các viewpoint và view để tổ chức requirement theo nhiều góc nhìn, đảm bảo "bộ requirement" hỗ trợ nhau và hỗ trợ mục tiêu chung. Đây cũng là nền cho Requirements Traceability (sẽ học sâu ở Bài 32).
5. Define Design Options (Định nghĩa phương án thiết kế)
Sau khi đã hiểu rõ nhu cầu, BA bắt đầu đề xuất các phương án giải pháp: tự xây (build), mua phần mềm có sẵn (buy), thuê ngoài, hoặc kết hợp. Mỗi option mô tả cách tiếp cận, các thành phần giải pháp, và đánh đổi liên quan.
6. Analyze Potential Value and Recommend Solution (Phân tích giá trị và khuyến nghị)
Cuối cùng, BA đánh giá giá trị tiềm năng của từng option (lợi ích, chi phí, rủi ro) rồi khuyến nghị phương án tối ưu cho bối cảnh. Đây là lúc BA thể hiện tư duy tư vấn, không chỉ là người ghi chép.
Requirements vs Designs — ranh giới mờ
Một khái niệm cốt lõi của KA5: cùng một thông tin có thể là requirement hay design tùy góc nhìn. "Hệ thống phải xác thực người dùng" là requirement; "dùng OTP qua SMS" là design. Nhưng với team triển khai SMS gateway, "dùng OTP qua SMS" lại trở thành requirement của họ. BABOK gọi đây là quá trình lặp đi lặp lại (iterative elaboration) — bạn liên tục đi từ what sang how rồi lại có what mới ở tầng chi tiết hơn.
Tình huống thực tế
Ví dụ 1 — Ngân hàng TPBank: Verify vs Validate trong tính năng chuyển khoản nhanh
Giả định một dự án tại TPBank nâng cấp tính năng chuyển khoản qua Napas 24/7. Stakeholder business viết: "Khách hàng chuyển tiền phải nhanh."
BA tên Linh phân rã thành requirement đo được: "Giao dịch chuyển khoản liên ngân hàng dưới 5 triệu VND phải hoàn tất trong vòng 5 giây kể từ khi khách bấm Xác nhận, đạt 99% số giao dịch."
- Verify: Linh kiểm tra requirement này có atomic không (chỉ nói một việc), có testable không (có thể đo "5 giây", "99%"), có unambiguous không. Pass — viết chuẩn.
- Validate: Linh ngồi với Head of Retail Banking và đối chiếu mục tiêu: mục tiêu kinh doanh là "giảm tỷ lệ khách rời bỏ giao dịch giữa chừng từ 8% xuống 3%". Câu hỏi đặt ra: liệu rút thời gian xuống 5 giây có thực sự giảm churn không, hay vấn đề thật nằm ở bước nhập OTP rườm rà? Sau khi xem data, hóa ra 60% khách bỏ cuộc ở màn hình OTP chứ không phải vì tốc độ. Requirement "5 giây" verify pass nhưng validate fail — nó đúng chuẩn nhưng không nhắm trúng nguyên nhân giá trị.
Ví dụ 2 — Tiki: Define Design Options cho hệ thống gợi ý sản phẩm
Một sàn TMĐT giả định tương tự Tiki muốn tăng tỷ lệ chuyển đổi bằng "gợi ý sản phẩm cá nhân hóa". BA không nhảy ngay vào code. Anh ấy định nghĩa 3 design option:
- Option A — Build in-house: Đội data tự xây mô hình ML. Chi phí ~2,5 tỷ, 6 tháng, kiểm soát hoàn toàn, nhưng rủi ro nhân sự cao.
- Option B — Buy SaaS (ví dụ một recommendation engine bên thứ ba): ~800 triệu/năm, triển khai 6 tuần, nhanh nhưng dữ liệu khách hàng phải gửi ra ngoài — vướng vấn đề tuân thủ Nghị định 13/2023 về bảo vệ dữ liệu cá nhân.
- Option C — Hybrid: Dùng SaaS giai đoạn đầu để có kết quả nhanh, song song xây in-house, chuyển dần trong 12 tháng.
Bài học: Define Design Options không phải việc của riêng kỹ sư. BA mang góc nhìn giá trị, rủi ro, tuân thủ — những thứ kỹ sư dễ bỏ sót — vào quyết định thiết kế.
Ví dụ 3 — Một startup logistics tại TP.HCM: Define Requirements Architecture cứu một dự án rối
Một startup giao hàng nội thành có 4 BA làm 4 module: đặt đơn, gán tài xế, theo dõi real-time, đối soát. Mỗi BA viết requirement riêng. Khi ráp lại, phát sinh xung đột: module Đặt đơn định nghĩa "trạng thái đơn" có 6 giá trị, module Theo dõi lại dùng 8 giá trị khác tên. Tài xế thấy trạng thái không khớp với app khách.
Lead BA áp dụng Define Requirements Architecture: lập một state model thống nhất cho "Đơn hàng" làm nguồn sự thật duy nhất, định nghĩa các viewpoint (góc nhìn khách hàng, góc nhìn tài xế, góc nhìn vận hành) cùng trỏ về một tập trạng thái chuẩn. Sau 1 tuần chuẩn hóa, các mâu thuẫn biến mất và team dev giảm 30% số bug liên quan trạng thái.
Bài học: Khi nhiều người cùng viết requirement, thiếu kiến trúc yêu cầu là thảm họa. Architecture đảm bảo các mảnh ghép khớp nhau.
Hướng dẫn từng bước
Đây là quy trình thực chiến áp dụng KA5 cho một tính năng cụ thể:
- Gom và phân loại đầu vào. Lấy thông tin từ elicitation (KA2), phân loại theo Requirements Classification Schema (business / stakeholder / functional / non-functional — sẽ học kỹ ở Bài 20).
- Specify — viết requirement. Với mỗi nhu cầu, viết thành câu requirement atomic, đo được. Tránh "nhanh", "thân thiện", "dễ dùng" — thay bằng con số.
- Model — chọn và vẽ mô hình. Hỏi: ai sẽ đọc? Nếu là business, ưu tiên BPMN/use case. Nếu là dev, có thể cần ERD, sequence. Vẽ ít nhất một process model và một data model cho tính năng phức tạp.
- Verify — tự soát chất lượng. Chạy checklist: atomic, complete, consistent, testable, unambiguous... Sửa ngay những requirement không đạt.
- Validate — soát giá trị với stakeholder. Với mỗi requirement, hỏi "cái này phục vụ mục tiêu kinh doanh nào?". Nếu không trả lời được, cân nhắc loại bỏ hoặc truy lại.
- Define Requirements Architecture. Sắp xếp toàn bộ requirement thành tổng thể: kiểm tra trùng lặp, lỗ hổng, mâu thuẫn. Bắt đầu dựng traceability sơ bộ.
- Define Design Options. Đề xuất 2–3 phương án giải pháp (build/buy/hybrid). Mô tả thành phần và đánh đổi của từng phương án.
- Analyze Value & Recommend. Lập bảng so sánh lợi ích – chi phí – rủi ro. Đưa khuyến nghị rõ ràng kèm lý do, để người ra quyết định (decision maker) chọn.
Lỗi thường gặp & mẹo
- Nhầm Verify với Validate. Đây là lỗi kinh điển và bị hỏi rất nhiều trong kỳ thi. Nhớ: Verify = đúng chuẩn (build it right), Validate = đúng giá trị (build the right thing). Verify làm một mình; Validate cần stakeholder.
- Viết requirement bằng từ mơ hồ. "Nhanh", "ổn định", "dễ dùng" không kiểm thử được. Luôn quy ra số: thời gian (giây), tỷ lệ (%), tần suất, ngưỡng. Mẹo: tự hỏi "tester sẽ kiểm cái này bằng cách nào?". Nếu không trả lời được, requirement chưa đạt.
- Specify mà không Model (hoặc ngược lại). Chỉ viết văn bản dài lê thê thì stakeholder không thấy bức tranh; chỉ vẽ sơ đồ thì thiếu chi tiết để dev code. Luôn kết hợp cả hai.
- Nhảy thẳng vào một design option. Nhiều BA mới chỉ đưa ra một phương án rồi bảo vệ nó. Hãy luôn trình bày ít nhất 2–3 option để decision maker thực sự có lựa chọn — đó là dấu hiệu của một BA chín chắn.
- Bỏ qua Requirements Architecture trong dự án nhiều người. Khi team đông, thiếu kiến trúc yêu cầu dẫn tới mâu thuẫn dữ liệu, trạng thái, thuật ngữ. Thống nhất một glossary và các model nguồn-sự-thật-duy-nhất từ sớm.
- Mẹo Agile: Trong môi trường Scrum, 6 task của KA5 không biến mất mà được thực hiện ở quy mô nhỏ hơn, liên tục — specify/model/verify/validate diễn ra ngay trong backlog refinement cho từng user story, thay vì một pha lớn trước dự án.
Bài tập thực hành
Bối cảnh: Một chuỗi cà phê tại Việt Nam (giả định "Coffee79") muốn thêm tính năng tích điểm thành viên trên app. Stakeholder nói: "Khách mua nhiều thì được ưu đãi nhiều, app phải dễ dùng và đừng để khách chờ lâu."
- Specify: Viết lại câu trên thành 3 requirement atomic, đo được (gợi ý: tỷ lệ tích điểm, thời gian phản hồi, ngưỡng hạng thành viên).
- Model: Vẽ phác một process model (BPMN hoặc flowchart) cho luồng "khách quét mã tích điểm khi thanh toán", và một bảng quy tắc (decision table) cho việc nâng hạng thành viên (ví dụ: <2 triệu/tháng = Bạc, 2–5 triệu = Vàng, >5 triệu = Kim cương).
- Verify: Lấy 3 requirement vừa viết, chấm điểm theo 4 tiêu chí: atomic, testable, unambiguous, consistent. Ghi chú cái nào chưa đạt và sửa.
- Validate: Với mỗi requirement, viết một câu trả lời cho "requirement này phục vụ mục tiêu kinh doanh nào?" (ví dụ: tăng tần suất quay lại, tăng giá trị đơn trung bình).
- Design Options & Recommend: Đề xuất 2 phương án triển khai tính năng tích điểm (ví dụ: tự xây module loyalty vs tích hợp một nền tảng loyalty bên thứ ba). Lập bảng so sánh chi phí – thời gian – rủi ro và đưa ra khuyến nghị kèm lý do.
Tóm tắt
- KA5 — Requirements Analysis & Design Definition là "trái tim phân tích" của nghề BA: biến thông tin thô từ elicitation thành requirement và design có cấu trúc, chất lượng cao.
- 6 task: Specify and Model Requirements, Verify Requirements, Validate Requirements, Define Requirements Architecture, Define Design Options, Analyze Potential Value and Recommend Solution.
- Verify ≠ Validate: Verify kiểm chất lượng nội tại (build it right); Validate kiểm giá trị kinh doanh (build the right thing). Đây là điểm thi và điểm thực chiến quan trọng nhất của bài.
- Specify đi cùng Model: văn bản cho chi tiết, mô hình cho bức tranh và quan hệ — luôn kết hợp.
- Requirements Architecture giữ cho bộ requirement gắn kết, không lỗ hổng/mâu thuẫn — sống còn khi nhiều người cùng làm.
- Define Design Options + Recommend là nơi BA chuyển từ người ghi chép sang người tư vấn: luôn đưa nhiều phương án và khuyến nghị có lý do.
- Ranh giới requirement (what) và design (how) là mờ và lặp — đi từ what sang how rồi lại có what mới ở tầng sâu hơn.