Thu thập được yêu cầu mới chỉ là nửa việc. Một đống ghi chú lộn xộn, chưa được kiểm chứng và chưa sắp xếp thứ tự ưu tiên thì vô giá trị — thậm chí nguy hiểm. Bài này khép lại chu trình: ghi nhận → xác thực → ưu tiên, và cảnh báo những sai lầm khiến BA mới trả giá đắt.
1. Ghi nhận yêu cầu (documenting)
Mục tiêu: biến lời nói thành thứ rõ ràng, không mơ hồ, kiểm chứng được.
Nguyên tắc viết yêu cầu tốt
- Cụ thể và đo được: "Hệ thống phải nhanh" là vô nghĩa. "Trang danh sách đơn tải xong dưới 2 giây với 1.000 đơn" mới dùng được.
- Một yêu cầu một ý: tránh gộp nhiều thứ vào một câu.
- Ngôn ngữ nghiệp vụ, không thuật ngữ kỹ thuật — để stakeholder đọc và xác nhận được.
- Ghi kèm nguồn và lý do (rationale): ai yêu cầu, vì sao. Sau này khi có tranh cãi, bạn biết truy về đâu.
Định dạng phổ biến
- User story: "Là [vai trò], tôi muốn [chức năng] để [lợi ích]." Ví dụ: "Là cộng tác viên, tôi muốn xem hoa hồng theo thời gian thực để biết thu nhập của mình."
- Tiêu chí chấp nhận (acceptance criteria): điều kiện cụ thể để coi là "làm xong đúng".
- Business rule: quy tắc nghiệp vụ tách riêng ("Đơn trên 20 triệu cần 2 cấp duyệt").
2. Xác thực yêu cầu (validation)
Yêu cầu chưa được xác thực chỉ là giả thuyết. Bạn có thể đã nghe nhầm, hiểu nhầm, hoặc stakeholder nói sai. Xác thực là bước bắt buộc.
Cách xác thực
- Đọc lại (walkthrough): trình bày lại yêu cầu cho stakeholder nghe/đọc và xác nhận. Đơn giản mà hiệu quả nhất.
- Đối chiếu chéo: so sánh giữa các stakeholder, giữa lời nói và tài liệu, giữa lời nói và quan sát. Mâu thuẫn = cần làm rõ.
- Prototype để xác nhận (Bài 5): cho họ thấy để chắc bạn hiểu đúng.
- Kiểm tra tính khả thi: hỏi đội kỹ thuật xem có làm được không, chi phí ra sao.
- Kiểm tra tính đầy đủ: đã xét các trường hợp ngoại lệ chưa? (Đơn bị hủy? Mất mạng giữa chừng? Khách nhập sai?)
3. Ưu tiên yêu cầu (prioritization)
Không bao giờ đủ thời gian và tiền để làm hết. BA phải giúp chọn làm gì trước. Đây là lúc BA tạo giá trị lớn nhất.
Phương pháp MoSCoW (phổ biến, dễ dùng)
- Must have — bắt buộc, thiếu là dự án thất bại.
- Should have — quan trọng nhưng có thể tạm hoãn.
- Could have — có thì tốt, không có cũng được.
- Won't have (this time) — lần này không làm.
Nguyên tắc ưu tiên
- Dựa trên giá trị kinh doanh và mức độ rủi ro, không dựa trên "ai nói to nhất".
- Người ra quyết định phải tham gia — BA đề xuất, business chốt.
- Làm rõ sự đánh đổi: "Nếu ưu tiên A thì B phải lùi sang giai đoạn sau — anh chị đồng ý không?"
Ví dụ thực tế Việt Nam
Dự án app bán mỹ phẩm ở Bài 1: yêu cầu "xem hoa hồng thời gian thực" là Must have (lý do CTV rời bỏ), còn "giao diện đổi theme màu" chỉ là Could have. Xác định đúng thứ tự này cứu cả dự án.4. Bảy sai lầm chết người của BA mới
- Chỉ hỏi sếp, bỏ quên người dùng cuối → làm ra thứ sếp thích nhưng người dùng ghét.
- Chép chính tả thay vì đào sâu → dừng ở "điều họ nói", bỏ lỡ "điều họ cần" (nhớ 5 Whys ở Bài 2).
- Bỏ qua trường hợp ngoại lệ → chỉ nghĩ đến luồng thuận lợi, quên lỗi/hủy/ngoại lệ. Đây là nguồn bug lớn nhất.
- Không xác thực → coi giả thuyết là sự thật, đến khi bàn giao mới vỡ lẽ.
- Dùng thuật ngữ mơ hồ — "thân thiện", "nhanh", "dễ dùng" — không đo được, không kiểm chứng được.
- Không ghi lại nguồn và lý do → khi có tranh cãi không truy được, dễ bị đổ lỗi.
- Tự quyết ưu tiên thay business → BA đề xuất, không được phép tự chốt cái nào làm trước.
Checklist khép chu trình elicitation
Ghi nhận:
- [ ] Mỗi yêu cầu cụ thể, đo được, một ý, có nguồn và lý do?
- [ ] Dùng định dạng nhất quán (user story / acceptance criteria)?
- [ ] Đã đọc lại cho stakeholder xác nhận?
- [ ] Đã đối chiếu chéo và giải quyết mâu thuẫn?
- [ ] Đã xét trường hợp ngoại lệ và tính khả thi?
- [ ] Đã phân loại MoSCoW dựa trên giá trị và rủi ro?
- [ ] Người ra quyết định đã tham gia và làm rõ đánh đổi?
- [ ] Đã hỏi cả người dùng cuối, không chỉ sếp?
- [ ] Đã đào tới yêu cầu thật, không dừng ở bề mặt?
Tổng kết toàn khóa
Elicitation là một chu trình: chọn đúng kỹ thuật (phỏng vấn, workshop, quan sát, khảo sát, phân tích tài liệu, prototyping) để thu thập, rồi ghi nhận rõ ràng, xác thực kỹ lưỡng, và ưu tiên theo giá trị kinh doanh. Làm chủ chu trình này, bạn không còn là thư ký ghi chép mà trở thành một BA thật sự — người biến nhu cầu mơ hồ của con người thành yêu cầu rõ ràng, đúng và có thể thực thi. Chúc bạn vững bước vào nghề!