Làm rõ requirement là công việc cốt lõi của BA
Stakeholder thường không đưa ra requirement hoàn chỉnh ngay từ đầu. Họ có thể nói theo cảm giác, theo triệu chứng hoặc theo giải pháp họ nghĩ là đúng. Nhiệm vụ của BA là đặt câu hỏi để requirement rõ hơn, kiểm tra được hơn và gắn với mục tiêu hơn.
SMART là một khung tốt để BA biết cần hỏi thêm điều gì.
Câu hỏi làm rõ theo SMART
Specific
- Ai là người dùng?
- Họ cần làm gì?
- Xảy ra trong tình huống nào?
- Dữ liệu đầu vào là gì?
Measurable
- Đo bằng chỉ số nào?
- Thế nào là đạt?
- Có ngưỡng tối thiểu hoặc tối đa không?
- Ai xác nhận kết quả?
Achievable
- Có khả thi về kỹ thuật không?
- Có đủ dữ liệu không?
- Có đủ thời gian và nguồn lực không?
- Có ràng buộc nào cần biết không?
Relevant
- Requirement này phục vụ mục tiêu nào?
- Nếu không làm thì ảnh hưởng ra sao?
- Ai nhận giá trị từ requirement này?
- Có thật sự cần trong phạm vi hiện tại không?
Time-bound
- Có deadline nghiệp vụ không?
- Thời gian xử lý mong muốn là bao lâu?
- Báo cáo cần chạy theo ngày, tuần hay tháng?
- Yêu cầu này cần có trước milestone nào?
Ví dụ làm rõ yêu cầu
Stakeholder nói: “Tôi muốn hệ thống gửi thông báo cho khách hàng”. Đây là yêu cầu chưa đủ rõ.
BA có thể hỏi thêm:
- Thông báo trong trường hợp nào?
- Gửi qua email, SMS, Zalo hay trong ứng dụng?
- Ai là khách hàng nhận thông báo?
- Nội dung thông báo cần gồm những thông tin nào?
- Gửi ngay lập tức hay theo lịch?
- Nếu gửi thất bại thì xử lý thế nào?
Viết lại sau khi làm rõ
Sau khi hỏi, requirement có thể rõ hơn: “Khi đơn hàng được chuyển sang trạng thái Đã giao, hệ thống gửi email xác nhận cho khách hàng trong vòng 5 phút, nội dung gồm mã đơn hàng, ngày giao, tổng tiền và đường link đánh giá dịch vụ”.
Ghi nhớ
BA không cần làm stakeholder cảm thấy bị hỏi cung. Hãy giải thích rằng các câu hỏi làm rõ giúp giảm hiểu sai và giúp đội dự án xây đúng thứ họ cần.
Kết luận
Làm rõ requirement theo SMART giúp BA biến ý tưởng mơ hồ thành yêu cầu có thể hiểu, xây dựng và kiểm thử. Đây là kỹ năng bạn sẽ dùng trong hầu hết mọi dự án.