Cùng True Skill Center tìm hiểu 3 nguyên tắc giúp bạn cải thiện cách viết yêu cầu rõ ràng hơn nhé!
1. Viết ở thì hiện tại chủ động (Active Present Tense)
Một lỗi phổ biến là sử dụng câu bị động – thường xuất hiện khi người viết không xác định rõ ai là người thực hiện hành động.
Ví dụ sai (bị động, thiếu chủ thể rõ ràng):
- Yêu cầu đặt hàng được gửi đi.
- Email xác nhận được gửi đến khách hàng.
Viết lại (chủ động, rõ ràng hơn):
- End user gửi yêu cầu đặt hàng.
- Hệ thống gửi email xác nhận đến end user.
Khi sử dụng câu chủ động, bạn xác định rõ “ai” đang thực hiện hành động – điều này giúp giảm mơ hồ và tăng tính chính xác trong triển khai. Đây cũng là cách thể hiện rõ mối quan hệ giữa end user và hệ thống – yếu tố quan trọng trong bất kỳ use case nào.
2. Dùng thuật ngữ nhất quán trong toàn bộ tài liệu
Một lỗi phổ biến khi viết yêu cầu là dùng nhiều thuật ngữ khác nhau để nói về cùng một đối tượng, dẫn đến sự hiểu lầm hoặc gây khó khăn cho các bên liên quan – đặc biệt là khi có người mới tham gia dự án (developer mới, QA, tester, hoặc một BA khác tiếp nhận tài liệu).

Ví dụ không nhất quán:
- Ở phần đầu tài liệu: Khách hàng đăng nhập vào hệ thống.
- Ở phần giữa tài liệu: Người dùng chọn sản phẩm.
- Ở phần cuối: End user tiến hành thanh toán.
3 cụm từ: “Khách hàng”, “Người dùng”, “End user” có thể đang nói về cùng một đối tượng, nhưng cách gọi thay đổi khiến người đọc không chắc chắn: đây có phải là 3 vai trò khác nhau, hay chỉ là một? Việc này dễ gây hiểu nhầm cho người phát triển, kiểm thử hoặc người phê duyệt.

Viết lại nhất quán:
- End user đăng nhập vào hệ thống.
- End user chọn sản phẩm cần mua.
- End user tiến hành thanh toán.

Mẹo hữu ích:
- Tạo một glossary (bảng thuật ngữ) để định nghĩa rõ từng vai trò, đối tượng, hoặc khái niệm.
- Duy trì sự nhất quán khi dùng thuật ngữ trong toàn bộ user story, use case, process flow, v.v.
- Luôn tự hỏi: “Nếu tôi là người mới, tôi có hiểu được không?”
- Đảm bảo các thuật ngữ được sử dụng thống nhất trong user stories, process flow, và functional requirements.
3. Tránh gộp nhiều yêu cầu trong một câu
Khi viết yêu cầu, nếu bạn cố gắng “nhét” nhiều hành động vào cùng một câu, bạn sẽ vô tình làm giảm độ rõ ràng. Điều này khiến người đọc (dev, tester, end user…) dễ bỏ sót một phần yêu cầu – dẫn đến việc phát triển hoặc kiểm thử không đầy đủ.

Ví dụ (gộp nhiều hành động):
- End user điền thông tin thanh toán và xác nhận đơn hàng trước khi nhận email xác nhận.
Bạn có thể thấy câu này gồm ít nhất 3 hành động khác nhau:
1. Điền thông tin thanh toán
2. Xác nhận đơn hàng
3. Nhận email xác nhận
Khi viết như vậy, rất dễ xảy ra tình trạng chỉ tập trung vào bước “điền thông tin”, rồi quên xác minh logic cho việc gửi email xác nhận.

Viết lại tách biệt, rõ ràng hơn:
- End user điền thông tin thanh toán.
- End user xác nhận đơn hàng.
- Hệ thống gửi email xác nhận đến end user.

Lợi ích của việc tách yêu cầu rõ ràng:
- Tester dễ tạo test case cho từng hành động.
- Developer không bỏ sót logic nghiệp vụ.
- Business dễ dàng rà soát và xác nhận từng phần yêu cầu.
Kết luận: Viết yêu cầu rõ ràng giúp IT Business Analyst truyền đạt đúng ý tưởng đến team kỹ thuật và end user, giảm hiểu lầm và tiết kiệm thời gian. Chỉ cần áp dụng 3 nguyên tắc: viết chủ động, dùng thuật ngữ nhất quán và tách riêng từng yêu cầu – bạn đã nâng cao đáng kể chất lượng tài liệu và hiệu quả dự án.