Mở đầu — vì sao bài này quan trọng
Ở Bài 12, chúng ta đã đi qua nửa đầu của Knowledge Area thứ năm (KA5 — Requirements Analysis and Design Definition): cách specify và model requirements, cách verify và validate chúng. Đó là phần "đào sâu vào từng yêu cầu". Nhưng nếu bạn dừng lại ở đó, bạn sẽ chỉ có một đống yêu cầu rời rạc — đúng từng cái một nhưng không biết chúng ghép vào nhau ra sao, không biết nên chọn giải pháp nào để hiện thực hóa, và không có cơ sở để thuyết phục lãnh đạo phê duyệt.
Bài 13 này lấp đúng ba khoảng trống đó với ba task cuối cùng của KA5:
- Task 4 — Define Requirements Architecture: ghép các yêu cầu rời rạc thành một cấu trúc tổng thể, mạch lạc, có quan hệ với nhau.
- Task 5 — Define Design Options: từ yêu cầu, đề xuất các phương án thiết kế giải pháp khác nhau.
- Task 6 — Analyze Potential Value and Recommend Solution: phân tích giá trị từng phương án và đưa ra khuyến nghị chọn cái nào.
Khái niệm cốt lõi
Task 4 — Define Requirements Architecture (Cấu trúc yêu cầu)
Hãy tưởng tượng bạn đã thu thập được 300 yêu cầu cho một dự án ngân hàng số. Mỗi yêu cầu có thể đúng, nhưng nếu chúng nằm rải rác trong Excel không có trật tự, bạn sẽ không biết: yêu cầu nào hỗ trợ yêu cầu nào, có yêu cầu nào thừa hoặc mâu thuẫn không, và liệu toàn bộ tập yêu cầu đã đủ để đạt mục tiêu kinh doanh chưa.
Requirements Architecture chính là cách tổ chức, cấu trúc và liên kết tất cả các requirements lại thành một thể thống nhất. BABOK định nghĩa nó là cấu trúc của tất cả requirements của một change, thể hiện chúng phù hợp với nhau như thế nào và với bối cảnh tổng thể ra sao.
Ba thành phần quan trọng cần nhớ:
- Requirements viewpoints và views: viewpoint là một "góc nhìn" — một tập quy ước (ký hiệu, mức độ trừu tượng) để mô tả requirements cho một nhóm stakeholder cụ thể. View là sản phẩm cụ thể tạo ra theo viewpoint đó. Ví dụ: cùng một hệ thống, góc nhìn của lập trình viên (data model, sequence diagram) khác với góc nhìn của giám đốc kinh doanh (business capability map).
- Template architecture: nhiều tổ chức dùng các khung mẫu (như Zachman Framework, TOGAF) để định sẵn các viewpoint cần có.
- Completeness và relate requirements: kiến trúc giúp kiểm tra tính đầy đủ (mọi mục tiêu đều có requirement hỗ trợ) và truy vết (traceability) giữa các requirement.
Task 5 — Define Design Options (Định nghĩa các phương án thiết kế)
Đây là task khiến nhiều người Việt mới học BA bối rối nhất, vì ranh giới giữa "requirement" và "design" rất tinh tế.
- Requirement trả lời câu hỏi "Cần gì?" — ví dụ: "Khách hàng cần thanh toán đơn hàng nhanh chóng, an toàn."
- Design trả lời câu hỏi "Làm thế nào?" — ví dụ: "Tích hợp cổng thanh toán VNPay với xác thực OTP qua SMS."
- Allocation of requirements: phân bổ yêu cầu cho các thành phần giải pháp (con người, phần mềm, quy trình, phần cứng).
- Solution approach: cách tiếp cận — mua phần mềm có sẵn (buy), tự phát triển (build), hay thuê ngoài (outsource).
- Implementation các thành phần: kết hợp công nghệ, vai trò, quy trình nghiệp vụ.
Task 6 — Analyze Potential Value and Recommend Solution
Đây là task "chốt hạ". BA phân tích giá trị tiềm năng (potential value) của từng design option và khuyến nghị (recommend) phương án đáng theo đuổi nhất.
Giá trị ở đây là sự cân bằng giữa benefits (lợi ích) và costs (chi phí):
- Benefits: doanh thu tăng thêm, chi phí tiết kiệm, rủi ro giảm, trải nghiệm khách hàng tốt hơn, lợi thế cạnh tranh.
- Costs: chi phí phát triển, vận hành, đào tạo, rủi ro triển khai, chi phí cơ hội.
- Expected benefits vs. expected costs: ước lượng cả định lượng (con số) lẫn định tính (uy tín, sự hài lòng).
- Determine value: giá trị thực = lợi ích trừ chi phí, có xét đến rủi ro và độ không chắc chắn.
- Trade-offs: hiếm khi có phương án thắng tuyệt đối; BA phải so sánh đánh đổi.
- Recommendation: có thể là chọn một option, kết hợp nhiều option, hoặc thậm chí khuyến nghị không làm gì (do nothing) nếu không option nào tạo đủ giá trị.
Tình huống thực tế
Ví dụ 1 — Requirements Architecture cho Tiki khi mở rộng sang giao hàng tươi sống
Giả định Tiki muốn ra mắt dịch vụ "TikiFresh" giao thực phẩm tươi trong 2 giờ. Đội BA thu được hơn 200 requirements: từ đặt hàng, quản lý kho lạnh, định tuyến shipper, đến xử lý hoàn hàng do hư hỏng.
Ban đầu mọi thứ nằm trong một file Excel khổng lồ, và khi review, giám đốc vận hành hỏi: "Yêu cầu kiểm soát nhiệt độ kho có liên quan gì đến yêu cầu hiển thị thời gian giao dự kiến trên app?". Không ai trả lời được ngay.
BA trưởng quyết định xây requirements architecture. Họ chia thành các viewpoint: góc nhìn khách hàng (đặt hàng, theo dõi), góc nhìn vận hành (kho lạnh, định tuyến), góc nhìn tài chính (thanh toán, hoàn tiền). Sau đó họ vẽ traceability: yêu cầu "kiểm soát nhiệt độ kho" → hỗ trợ mục tiêu "giảm tỷ lệ hư hỏng xuống dưới 2%" → ảnh hưởng đến yêu cầu "hiển thị cảnh báo sản phẩm hết hạn" trên app.
Bài học: Khi có cấu trúc, họ phát hiện 12 requirements không truy vết được về bất kỳ mục tiêu kinh doanh nào (thừa, loại bỏ) và 3 mục tiêu chưa có requirement nào hỗ trợ (thiếu, bổ sung). Architecture biến một đống yêu cầu rời rạc thành bức tranh kiểm chứng được.
Ví dụ 2 — Define Design Options cho hệ thống chấm công của một chuỗi F&B
Một chuỗi cà phê 40 chi nhánh tại TP.HCM cần hệ thống chấm công thay thế việc ghi sổ tay. Requirements rõ ràng: nhân viên check-in/out chính xác, chống gian lận chấm hộ, đồng bộ về trung tâm để tính lương.
BA không vội chọn công nghệ. Thay vào đó, họ định nghĩa ba design options:
- Option A — Mua phần mềm SaaS chấm công bằng GPS điện thoại: chi phí 8 triệu/tháng, triển khai 2 tuần, nhưng có rủi ro nhân viên fake GPS.
- Option B — Tự phát triển app + máy chấm công vân tay tại quầy: chi phí đầu tư 600 triệu, triển khai 4 tháng, chống gian lận tốt nhưng đắt.
- Option C — Mua SaaS + chấm công bằng nhận diện khuôn mặt qua iPad có sẵn tại quầy: chi phí 12 triệu/tháng, triển khai 1 tháng, cân bằng giữa chống gian lận và chi phí.
Ví dụ 3 — Analyze Potential Value và khuyến nghị tại ví dụ chuỗi F&B trên
Tiếp nối ví dụ 2, BA lập bảng phân tích giá trị cho ba option, dựa trên dữ liệu: chuỗi đang thất thoát khoảng 90 triệu/tháng do chấm công gian lận và sai sót tính lương thủ công.
| Tiêu chí | Option A (GPS) | Option B (Vân tay) | Option C (Khuôn mặt) |
|---|---|---|---|
| Chi phí năm đầu | 96 triệu | 600 triệu | 144 triệu |
| Mức chống gian lận | Thấp | Cao | Cao |
| Thất thoát còn lại/tháng | 40 triệu | 5 triệu | 8 triệu |
| Thời gian triển khai | 2 tuần | 4 tháng | 1 tháng |
Bài học: BA khuyến nghị Option C, không phải vì nó rẻ nhất hay an toàn nhất, mà vì nó tối ưu giá trị ròng sau khi cân nhắc đánh đổi giữa chi phí, hiệu quả và tốc độ. Khuyến nghị luôn phải có lập luận về value, không phải cảm tính.
Hướng dẫn từng bước
Đây là quy trình thực hành để đi qua ba task của Bài 13:
Bước 1 — Xác định các viewpoint cần có (Task 4). Liệt kê các nhóm stakeholder chính và góc nhìn họ quan tâm. Với mỗi nhóm, chọn loại view phù hợp (process model cho vận hành, data model cho IT, capability map cho lãnh đạo).
Bước 2 — Sắp xếp và liên kết requirements (Task 4). Đặt từng requirement vào đúng view, rồi vẽ quan hệ traceability: requirement này hỗ trợ mục tiêu nào, phụ thuộc requirement nào. Đây là lúc bạn phát hiện thừa, thiếu, mâu thuẫn.
Bước 3 — Kiểm tra tính đầy đủ (Task 4). Đối chiếu: mọi business goal có ít nhất một requirement hỗ trợ chưa? Mọi requirement có truy về được mục tiêu không? Loại bỏ cái thừa, bổ sung cái thiếu.
Bước 4 — Brainstorm các design options (Task 5). Với tập requirements đã có cấu trúc, hỏi: "Có những cách nào để đáp ứng?" Cân nhắc buy/build/outsource, các tổ hợp công nghệ — quy trình — con người khác nhau. Cố gắng có ít nhất 2-3 option.
Bước 5 — Phân bổ requirements cho từng option (Task 5). Với mỗi option, xác định thành phần nào (phần mềm, người, quy trình) chịu trách nhiệm cho requirement nào.
Bước 6 — Phân tích giá trị tiềm năng (Task 6). Với mỗi option, ước lượng benefits và costs (cả định lượng lẫn định tính), xét đến rủi ro và độ không chắc chắn.
Bước 7 — So sánh đánh đổi và khuyến nghị (Task 6). Lập bảng so sánh, xác định giá trị ròng, rồi đưa ra recommendation kèm lập luận rõ ràng. Đừng quên cân nhắc cả phương án "do nothing".
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm requirements architecture với solution architecture. Architecture của requirements là cách tổ chức yêu cầu, không phải bản vẽ kỹ thuật của hệ thống. Trong đề thi, nếu đáp án mô tả "server, database, API" thì đó là design/solution, không phải requirements architecture.
Lỗi 2 — Nhảy thẳng vào một design option duy nhất. Nhiều BA mới (và cả PM) yêu việc nói ngay "ta dùng React + AWS". ECBA nhấn mạnh: phải đưa ra nhiều design options trước khi chọn. Bỏ qua bước này là tước đi cơ hội tìm phương án tốt hơn.
Lỗi 3 — Lẫn lộn requirement và design trong tài liệu. Mẹo: nếu câu mô tả "cái gì stakeholder cần" → requirement. Nếu mô tả "giải pháp hiện thực thế nào" → design. Khi viết, hãy giữ requirement ở mức trung lập về giải pháp (solution-neutral) càng lâu càng tốt.
Lỗi 4 — Phân tích giá trị chỉ nhìn chi phí. Value không chỉ là rẻ. Nó là benefits trừ costs, có xét rủi ro. Một phương án đắt hơn nhưng giảm rủi ro lớn vẫn có thể có giá trị ròng cao hơn.
Lỗi 5 — Quên phương án "do nothing". Trong Task 6, không làm gì cũng là một lựa chọn hợp lệ. Nếu không option nào tạo đủ giá trị vượt chi phí và rủi ro, khuyến nghị đúng đắn là chưa triển khai.
Mẹo ghi nhớ cho phòng thi: Task 4 = cấu trúc (sắp xếp yêu cầu), Task 5 = lựa chọn (đưa ra phương án), Task 6 = quyết định (phân tích giá trị + khuyến nghị). Ba chữ: Cấu trúc → Lựa chọn → Quyết định.
Bài tập thực hành
Bài tập 1 — Phân biệt requirement và design. Với mỗi câu sau, ghi R (requirement) hay D (design):
- "Hệ thống phải cho phép khách hàng hủy đơn trong vòng 30 phút."
- "Dùng Redis cache để tăng tốc độ tra cứu đơn hàng."
- "Nhân viên kho cần biết sản phẩm nào sắp hết hạn."
- "Gửi cảnh báo qua Telegram bot khi tồn kho dưới ngưỡng."
Bài tập 2 — Xây dựng design options. Một trường tiếng Anh có 5 cơ sở muốn hệ thống cho phép học viên đặt lịch học bù online. Hãy đề xuất ba design options khác nhau (gợi ý: dùng Google Calendar tích hợp, mua phần mềm booking SaaS, tự phát triển module trên website hiện có). Với mỗi option, ghi ước lượng chi phí, thời gian triển khai và một rủi ro chính.
Bài tập 3 — Phân tích giá trị và khuyến nghị. Dựa trên ba option ở Bài tập 2, giả sử trường đang mất 15 học viên/tháng vì lịch học bù rối loạn (mỗi học viên đóng 6 triệu/khóa). Lập bảng so sánh benefits — costs và viết một đoạn 3-4 câu khuyến nghị chọn option nào, có lập luận về giá trị ròng. Nhớ cân nhắc cả phương án "do nothing".
Tóm tắt
Bài 13 khép lại KA5 với ba task biến những yêu cầu rời rạc thành quyết định hành động:
- Task 4 — Define Requirements Architecture: sắp xếp và liên kết toàn bộ requirements thành cấu trúc mạch lạc qua các viewpoint/view, đảm bảo tính đầy đủ và truy vết. Đây là cấu trúc, không phải design.
- Task 5 — Define Design Options: từ requirements, đề xuất nhiều phương án thiết kế khác nhau (buy/build/outsource, các tổ hợp công nghệ — con người — quy trình), phân bổ requirements cho từng thành phần. Phải có nhiều lựa chọn, không áp đặt một giải pháp.
- Task 6 — Analyze Potential Value and Recommend Solution: phân tích giá trị tiềm năng (benefits trừ costs, xét rủi ro) của từng option, so sánh đánh đổi và khuyến nghị phương án tối ưu giá trị ròng — kể cả phương án "do nothing".