...

3 CÁCH GIÚP IT BA VIẾT YÊU CẦU RÕ RÀNG HƠN

Cập nhật 14:32, 23/06/2025

1353 lượt xem

Admin

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.
Lưu lại cùng True Skill Center để tìm hiểu nhé!

– – –
 
Xem thêm thông tin bổ ích miễn phí và tham gia cộng đồng True Skill tại:
 
 
Facebook: True Skill Center 
 
 
Youtube: Quý Nguyễn 

CÓ THỂ BẠN QUAN TÂM

ITBA

Làm BA trong Fintech: Bí kíp để không chỉ là người ghi yêu cầu!

Fintech đang là “đỉnh của chóp” với ví điện tử, ngân hàng số, blockchain, crypto – cơ hội cho BA tụi mình đầy rẫy ngoài kia. Nhưng làm BA trong fintech không chỉ là ngồi viết BRD hay vẽ sơ đồ đâu nha. Muốn nổi bật, bạn cần vài “vũ khí bí mật” ngoài nghiệp vụ. Hôm nay, mình chia sẻ 5 bí kíp siêu thực tế, cộng thêm cách dùng AI để học fintech nhanh như chớp và lý do vì sao dân BA mê mẩn ngành này.

ITBA

[NHẢY VIỆC] Khi Nào Là Đúng Lúc? Kinh Nghiệm Qua Từng Giai Đoạn Sự Nghiệp

Đây là một chủ đề mình từng viết cách đây 4 năm – và đến giờ vẫn thấy còn nguyên giá trị. Khác với chuyện chọn vợ/chồng, sự nghiệp là thứ ta có thể chủ động lựa chọn và thay đổi khi không còn phù hợp. Nhảy việc – dù êm đềm hay kịch tính – là một phần không thể thiếu của hành trình phát triển.

ITBA

3 TIPS ĐỂ CÓ MỘT CUỘC HỌP ONLINE HIỆU QUẢ

Làm Business Analyst (BA) không chỉ là phân tích nghiệp vụ hay viết tài liệu – mà còn là kết nối, thấu hiểu và dẫn dắt. Khi môi trường làm việc chuyển dịch sang online, bạn có đang loay hoay để giữ vững hiệu quả cộng tác?

ITBA

BA/PO/PM Xử lý khi Dev nói:"Cái này không làm được đâu?"

Anh chị em làm nghề BA/PO/PM nhà mình chắc không lạ gì câu này. :)) Có điều thì ở mỗi hoàn cảnh khác nhau, đôi khi bản thân chúng ta cũng không biết nên reply câu này như thế nào cho hợp lý. Mình chia sẻ tý trải nghiệm cá nhân nha.

Đăng kí nhận tư vấn

Hãy nhập ngay email của bạn vào form bên dưới để được nhận tư vấn trực tiếp từ trung tâm.