Checklist BA gửi yêu cầu cho Dev & QA lần đầu
Để không bị hỏi lại 7749 lần
Một trong những khoảnh khắc “đau nhẹ” của BA mới là:
Gửi requirement xong, tưởng đã ổn.
5 phút sau khứa Dev hỏi:
“Case này xử lý sao?”
“Rule đâu?”
“Data lấy từ đâu?”
QA hỏi tiếp:
“Pass/fail thế nào?”
“Exception đâu?”
“Message lỗi là gì?”
=> Không phải Dev/QA khó tính.
=> Mà có thể requirement của bạn chưa đủ rõ để build và test.
Trước khi gửi yêu cầu lần đầu, BA nên tự check 10 mục này.
1️⃣ Requirement đã nói rõ user muốn gì chưa?
Đừng chỉ viết:
“Làm chức năng thanh toán.”
Hãy viết rõ:
User muốn thanh toán đơn hàng bằng ví điện tử để hoàn tất giao dịch online.
Công thức nhanh:
As a [user], I want [goal], so that [value].
Nếu không rõ user – goal – value, Dev sẽ không hiểu mục tiêu thật.
2️⃣ Scope đã rõ chưa?
Phải có cả:
In-scope
Làm gì trong phase này
Out-of-scope
Chưa làm gì trong phase này
Ví dụ:
In-scope:
Thanh toán bằng ví điện tử
Xử lý success / failed / timeout
Out-of-scope:
Thanh toán quốc tế
Trả góp
Loyalty point payment
Không có out-of-scope = change request rất dễ xuất hiện.
3️⃣ Business Rule đã tách riêng chưa?
Đừng chôn rule trong flow.
Ví dụ:
Business Rules
BR-01: Một order chỉ có một payment thành công.
BR-02: Payment timeout sau 60 giây.
BR-03: User không được retry nếu order đã Paid.
Rule rõ → Dev không đoán, QA dễ viết test case.
4️⃣ Flow đã đủ happy case chưa?
Flow nên viết theo bước ngắn gọn:
User chọn phương thức thanh toán.
User xác nhận thanh toán.
System gửi request sang payment gateway.
Gateway trả kết quả.
System cập nhật trạng thái đơn hàng.
System hiển thị kết quả cho user.
Flow không cần văn chương. Flow cần rõ thứ tự.
5️⃣ Exception Flow đã có chưa?
Happy case không đủ.
BA cần ghi các case xấu:
User nhập sai dữ liệu
Network fail
API timeout
Double click
Dữ liệu thay đổi giữa chừng
Hệ thống thứ ba trả lỗi
Callback về trễ hoặc về nhiều lần
80% bug thường nằm ở exception, không nằm ở happy flow.
6️⃣ Acceptance Criteria đã test được chưa?
AC không nên viết kiểu:
“Hệ thống xử lý chính xác.”
Hãy viết rõ:
Nếu payment success → order status = Paid.
Nếu payment failed → order status = Pending Payment.
Nếu timeout sau 60 giây → hiển thị “Payment is being processed.”
User không bị charge 2 lần cho cùng một order.
AC test được = QA biết pass/fail.
7️⃣ Data cần hiển thị / lưu / cập nhật đã rõ chưa?
BA nên ghi rõ:
Field nào cần hiển thị?
Field nào bắt buộc?
Data lấy từ hệ thống nào?
Khi thao tác thành công, field nào được cập nhật?
Có trạng thái nào thay đổi không?
Ví dụ:
orderId
paymentId
transactionId
paymentStatus
amount
createdAt
updatedAt
Không rõ data = Dev phải tự đoán mapping.
8️⃣ API / Integration có liên quan không?
Nếu có hệ thống khác tham gia, phải ghi rõ:
Tích hợp với hệ thống nào?
Gửi dữ liệu gì?
Nhận dữ liệu gì?
Nếu API lỗi thì xử lý sao?
Có retry không?
Có callback/webhook không?
Ví dụ:
Order Service → Payment Gateway → Callback → Order Service
Integration là nơi rất dễ phát sinh bug nếu requirement mơ hồ.
9️⃣ NFR đã có chưa?
Đừng chỉ viết functional requirement.
Cần thêm NFR như:
Performance
API phản hồi trong ≤ 3 giây với 95% request.
Security
Giao dịch trên 5 triệu cần OTP.
Availability
Payment service uptime 99.9%.
Audit Log
Mọi thay đổi trạng thái payment phải được log.
Hệ thống chạy được chưa chắc đã chạy tốt.
🔟 Message / UX state đã rõ chưa?
Dev và QA rất cần phần này.
BA nên ghi:
Success message là gì?
Error message là gì?
Loading state hiển thị thế nào?
Empty state hiển thị gì?
User có được retry không?
Ví dụ:
Success: “Thanh toán thành công.”
Timeout: “Giao dịch đang được xử lý. Vui lòng không đóng ứng dụng.”
Failed: “Thanh toán thất bại. Vui lòng thử lại.”
Message rõ giúp giảm hiểu nhầm cho user và giảm ticket CSKH.
✅ Checklist 30 giây trước khi gửi requirement
Trước khi gửi cho Dev & QA, hãy tự tick:
User story / mục tiêu đã rõ
In-scope / Out-of-scope đã rõ
Business Rule đã tách riêng
Happy flow đã đủ
Exception flow đã có
Acceptance Criteria test được
Data field / status đã rõ
API / integration đã ghi
NFR đã có
Message / UX state đã rõ
Nếu chưa tick đủ, khả năng cao bạn sẽ bị hỏi lại.
Kết
BA không cần viết tài liệu thật dài.
BA cần gửi requirement đủ rõ để Dev build, QA test, stakeholder review được.
Một requirement tốt không làm team im lặng vì “ngại hỏi”.
Nó làm team im lặng vì:
“Ok, rõ rồi. Làm được.”
Nếu bạn là newbie ITBA, hãy lưu checklist này lại.
Trước mỗi lần gửi requirement cho Dev & QA, mở ra check một lượt.
