Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đặt một chiếc bánh sinh nhật qua điện thoại và chỉ nói: "Cho tôi một cái bánh ngon nhé". Khi nhận bánh, bạn nhận ra nó vị sầu riêng — thứ bạn ghét nhất. Người làm bánh không sai, họ làm "bánh ngon" theo định nghĩa của họ. Vấn đề nằm ở chỗ yêu cầu bạn đưa ra quá mơ hồ.
Trong các dự án phần mềm và chuyển đổi số, hàng triệu đô-la "tan thành mây khói" mỗi năm cũng vì lý do tương tự: yêu cầu (requirements) được viết một cách mơ hồ, thiếu sót, mâu thuẫn hoặc không thể kiểm chứng. Theo nhiều khảo sát ngành (ví dụ các báo cáo thường niên của Project Management Institute), khoảng 35–47% nguyên nhân dự án thất bại bắt nguồn từ việc thu thập và quản lý yêu cầu kém. Một lỗi yêu cầu nếu phát hiện ở giai đoạn vận hành có thể tốn gấp 100 lần so với khi sửa ngay lúc viết tài liệu.
Ở các bài trước, bạn đã học cách thu thập yêu cầu từ stakeholder (elicitation). Bài 22 này tập trung vào một kỹ năng khác — và nói thật là khó hơn nhiều: diễn đạt những yêu cầu đó thành câu chữ rõ ràng, đầy đủ và kiểm tra được. Một BA giỏi không chỉ biết người dùng muốn gì, mà còn biết viết ra điều đó theo cách mà lập trình viên, tester, và sếp đều hiểu giống hệt nhau. Đó chính là nội dung cốt lõi của bài học hôm nay.
Khái niệm cốt lõi
Yêu cầu là gì và tại sao "viết" lại quan trọng
Yêu cầu (requirement) là một mô tả về điều mà giải pháp cần làm được hoặc đặc tính mà nó cần có để đáp ứng nhu cầu của stakeholder. Yêu cầu sống trong tài liệu, trong vé Jira, trong user story — và chính câu chữ là "hợp đồng" giữa người đặt hàng và người xây dựng. Nếu câu chữ sai, mọi thứ phía sau đều lệch.
Các loại yêu cầu khác nhau
Trước khi viết tốt, bạn phải biết mình đang viết loại gì. Cách phân loại phổ biến nhất (theo chuẩn BABOK) gồm:
- Business requirements (Yêu cầu nghiệp vụ): mục tiêu ở cấp tổ chức, lý do "vì sao" làm dự án. Ví dụ: "Giảm tỷ lệ khách hàng bỏ giỏ hàng từ 70% xuống 55% trong quý 4".
- Stakeholder requirements (Yêu cầu của bên liên quan): nhu cầu của một nhóm người dùng cụ thể. Ví dụ: "Nhân viên kho cần biết đơn hàng nào cần đóng gói gấp".
- Functional requirements (Yêu cầu chức năng): hệ thống phải làm gì. Ví dụ: "Hệ thống phải gửi email xác nhận trong vòng 60 giây sau khi thanh toán thành công".
- Non-functional requirements (Yêu cầu phi chức năng): hệ thống phải làm tốt đến mức nào — hiệu năng, bảo mật, khả năng mở rộng, trải nghiệm. Ví dụ: "Trang chủ phải tải xong dưới 2 giây với 1.000 người dùng đồng thời".
- Transition requirements (Yêu cầu chuyển đổi): những gì cần để chuyển từ trạng thái cũ sang mới — di chuyển dữ liệu, đào tạo. Loại này thường tồn tại tạm thời.
Bảy đặc điểm của một yêu cầu chất lượng
Đây là phần xương sống của bài học. Một yêu cầu tốt cần đạt các tiêu chí sau (tôi gọi vui là bộ tiêu chí "CCCUFAT"):
- Clear / Unambiguous (Rõ ràng, không mơ hồ): chỉ có một cách hiểu duy nhất. Tránh các từ "co giãn" như "nhanh", "thân thiện", "ổn định", "dễ dùng".
- Complete (Đầy đủ): mô tả trọn vẹn nhu cầu, không để hổng các trường hợp ngoại lệ. "Người dùng đăng nhập bằng email" — vậy nếu sai mật khẩu 5 lần thì sao?
- Consistent (Nhất quán): không mâu thuẫn với yêu cầu khác. Không thể vừa nói "lưu mọi giao dịch vĩnh viễn" vừa nói "xóa dữ liệu sau 90 ngày".
- Testable / Verifiable (Có thể kiểm tra được): phải có cách chứng minh nó đã được đáp ứng hay chưa. Đây là tiêu chí "vàng" — nếu tester không nghĩ ra được kịch bản kiểm thử, yêu cầu đó chưa đạt.
- Feasible (Khả thi): có thể thực hiện trong giới hạn ngân sách, thời gian, công nghệ.
- Atomic (Đơn nhất): mỗi yêu cầu chỉ nói về một điều. Tránh nhồi "và", "đồng thời", "cũng như" để gộp nhiều yêu cầu.
- Traceable (Truy xuất được): gắn được với mục tiêu nghiệp vụ gốc và với các thành phần kiểm thử (sẽ học sâu hơn ở Bài 43).
Mẹo diễn đạt: cấu trúc câu "EARS"
Một kỹ thuật rất hữu ích cho yêu cầu chức năng là mẫu EARS (Easy Approach to Requirements Syntax), giúp câu yêu cầu luôn có cấu trúc:
> [Điều kiện kích hoạt] + [chủ thể hệ thống] + shall + [hành vi cụ thể] + [tiêu chí đo lường].
Ví dụ: "Khi khách hàng nhấn nút 'Thanh toán', hệ thống phải hiển thị màn hình xác nhận đơn hàng trong vòng tối đa 2 giây." Câu này rõ điều kiện, rõ chủ thể, rõ hành vi, rõ con số kiểm tra được.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử Tiki và yêu cầu "tìm kiếm thông minh"
Giả định một đội sản phẩm tại một sàn TMĐT lớn ở Việt Nam (lấy bối cảnh tương tự Tiki) nhận yêu cầu từ giám đốc kinh doanh: "Làm cho ô tìm kiếm thông minh hơn, gợi ý tốt hơn."
Nếu BA viết nguyên văn câu này vào tài liệu, đội kỹ thuật sẽ bối rối: "thông minh" là gì? "Tốt hơn" là tốt hơn cái gì? Sau buổi làm rõ, BA viết lại thành ba yêu cầu đơn nhất, kiểm tra được:
- "Khi người dùng gõ tối thiểu 2 ký tự vào ô tìm kiếm, hệ thống phải hiển thị tối đa 8 gợi ý trong vòng 300 mili-giây."
- "Hệ thống phải ưu tiên gợi ý các sản phẩm có lượt mua trong 30 ngày gần nhất cao hơn."
- "Khi không có kết quả khớp, hệ thống phải hiển thị thông báo 'Không tìm thấy sản phẩm' kèm 4 sản phẩm gợi ý theo danh mục đang xem."
Ví dụ 2 — Ngân hàng số và yêu cầu mâu thuẫn
Một ngân hàng số tại Đông Nam Á (bối cảnh tương tự một neobank ở Singapore) triển khai tính năng chuyển tiền. Trong tài liệu có hai yêu cầu của hai phòng ban khác nhau:
- Phòng Trải nghiệm: "Để chuyển tiền nhanh, người dùng không cần nhập lại mật khẩu nếu đã đăng nhập."
- Phòng Bảo mật: "Mọi giao dịch trên 1 triệu đồng phải được xác thực bằng OTP."
Bài học rút ra: tính nhất quán (consistency) không tự nhiên có. BA phải chủ động đối chiếu chéo các yêu cầu, đặc biệt khi chúng đến từ các phòng ban có lợi ích khác nhau. Một ma trận đối chiếu yêu cầu đơn giản trên Excel cũng đủ để lộ ra mâu thuẫn.
Ví dụ 3 — Startup giao đồ ăn và yêu cầu thiếu trường hợp ngoại lệ
Một startup giao đồ ăn (bối cảnh tương tự GrabFood giai đoạn đầu) viết yêu cầu: "Khi tài xế nhận đơn, hệ thống hiển thị địa chỉ giao hàng trên bản đồ." Nghe có vẻ ổn. Nhưng khi ra thực địa, hàng loạt lỗi xảy ra: địa chỉ khách nhập sai định dạng, GPS không bắt được vị trí, khách ở hẻm sâu không có trên bản đồ.
Yêu cầu trên không đầy đủ (incomplete) vì chỉ mô tả "đường đi đẹp" (happy path) mà bỏ qua các tình huống ngoại lệ. Sau khi rút kinh nghiệm, đội bổ sung: "Nếu hệ thống không xác định được tọa độ từ địa chỉ trong 5 giây, hệ thống phải hiển thị số điện thoại khách hàng và nút gọi nhanh, đồng thời cho phép tài xế nhập ghi chú vị trí thủ công."
Bài học rút ra: một yêu cầu đầy đủ phải bao quát cả happy path lẫn các nhánh ngoại lệ (sai dữ liệu, mất kết nối, dữ liệu trống). Thói quen tự hỏi "Nếu điều này thất bại thì sao?" giúp bạn vá những lỗ hổng đắt giá trước khi viết code.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để viết một yêu cầu chất lượng:
- Xác định loại yêu cầu. Hỏi: đây là mục tiêu nghiệp vụ, nhu cầu stakeholder, chức năng, hay phi chức năng? Phân loại đúng để đặt đúng chỗ trong tài liệu.
- Viết bản nháp bằng ngôn ngữ tự nhiên. Đừng cầu toàn ngay. Cứ ghi lại điều bạn hiểu từ stakeholder.
- Áp dụng mẫu cấu trúc (EARS). Viết lại theo dạng "Khi [điều kiện], hệ thống phải [hành vi] [tiêu chí đo lường]".
- Loại bỏ từ mơ hồ. Gạch bỏ các từ "nhanh, dễ dùng, thân thiện, ổn định, linh hoạt" và thay bằng con số hoặc tiêu chí cụ thể.
- Tách yêu cầu gộp thành các yêu cầu đơn nhất. Mỗi câu chứa từ "và" hay "đồng thời" — hãy cân nhắc tách đôi.
- Kiểm tra tính kiểm chứng. Tự hỏi: "Làm sao tôi chứng minh được yêu cầu này đã đáp ứng?" Nếu không nghĩ ra cách test, viết lại.
- Bổ sung các trường hợp ngoại lệ. Liệt kê các nhánh: dữ liệu sai, trống, mất kết nối, vượt giới hạn.
- Đối chiếu chéo để bảo đảm nhất quán. So sánh với các yêu cầu liên quan, đặc biệt từ phòng ban khác.
- Gắn truy xuất (traceability). Ghi rõ yêu cầu này phục vụ mục tiêu nghiệp vụ nào, để sau dễ kiểm soát thay đổi.
- Rà soát với stakeholder và đội kỹ thuật. Đọc to yêu cầu lên; nếu hai người hiểu khác nhau, nó chưa đủ rõ.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng từ mơ hồ. "Hệ thống phải phản hồi nhanh." Nhanh là bao nhiêu? Mẹo: mỗi tính từ định tính phải đi kèm con số. "Phản hồi dưới 1 giây ở phân vị 95%."
Lỗi 2 — Mô tả giải pháp thay vì nhu cầu. "Thêm một nút màu xanh ở góc phải." Đó là thiết kế, không phải yêu cầu. Mẹo: tập trung vào "cái gì" và "vì sao", để phần "như thế nào" cho designer và developer.
Lỗi 3 — Yêu cầu gộp nhiều ý. "Người dùng có thể đăng nhập, đăng ký và đặt lại mật khẩu." Đây là ba yêu cầu. Mẹo: tách atomic để dễ ước lượng, dễ test, dễ theo dõi tiến độ.
Lỗi 4 — Bỏ quên yêu cầu phi chức năng. Đội thường chỉ liệt kê chức năng mà quên bảo mật, hiệu năng, khả năng truy cập. Mẹo: với mỗi tính năng quan trọng, hỏi thêm "Nhanh đến mức nào? An toàn đến mức nào? Phục vụ bao nhiêu người?".
Lỗi 5 — Không có tiêu chí chấp nhận (acceptance criteria). Yêu cầu không nói rõ "thế nào là xong". Mẹo: mỗi yêu cầu nên kèm tiêu chí chấp nhận dạng Given–When–Then để tester dùng trực tiếp.
Mẹo vàng: sau khi viết xong, đưa yêu cầu cho một người không tham gia buổi thu thập đọc thử. Nếu họ hiểu đúng ý mà không cần hỏi lại, yêu cầu của bạn đã đạt độ rõ ràng.
Bài tập thực hành
- Sửa yêu cầu mơ hồ. Cho yêu cầu gốc: "Hệ thống phải đăng nhập an toàn và nhanh." Hãy viết lại thành 2–3 yêu cầu đơn nhất, kiểm tra được, có con số cụ thể (gợi ý: thời gian phản hồi, số lần thử mật khẩu sai, cơ chế khóa tài khoản).
- Phân loại yêu cầu. Lấy một ứng dụng bạn dùng hằng ngày (ví dụ Momo hoặc Shopee), viết ra 5 yêu cầu và gán nhãn cho mỗi cái: business / stakeholder / functional / non-functional / transition.
- Săn mâu thuẫn. Viết hai yêu cầu cố tình mâu thuẫn cho một tính năng đặt vé xem phim, sau đó viết lại thành một yêu cầu nhất quán duy nhất.
- Bổ sung ngoại lệ. Cho yêu cầu: "Khi người dùng tải ảnh đại diện lên, hệ thống lưu ảnh vào hồ sơ." Hãy liệt kê ít nhất 4 trường hợp ngoại lệ và viết yêu cầu xử lý cho từng trường hợp.
- Áp dụng EARS. Chọn một tính năng bất kỳ trong một app bạn thích và viết 3 yêu cầu chức năng theo đúng mẫu "Khi [điều kiện], hệ thống phải [hành vi] [tiêu chí đo lường]".
Tóm tắt
Viết yêu cầu hiệu quả là kỹ năng biến mong muốn mơ hồ của con người thành câu chữ chính xác mà cả đội cùng hiểu giống nhau. Hãy ghi nhớ những điểm cốt lõi:
- Phân biệt rõ các loại yêu cầu: nghiệp vụ, stakeholder, chức năng, phi chức năng, chuyển đổi — và đặt đúng chỗ.
- Mọi yêu cầu chất lượng đều cần rõ ràng, đầy đủ, nhất quán, kiểm tra được, khả thi, đơn nhất, truy xuất được.
- Tiêu chí "vàng" là tính kiểm chứng: nếu không nghĩ ra cách test, yêu cầu chưa đạt.
- Dùng mẫu cấu trúc như EARS và luôn thay từ mơ hồ bằng con số cụ thể.
- Luôn tự hỏi "Nếu điều này thất bại thì sao?" để vá các trường hợp ngoại lệ trước khi code.