Nói cách khác, Deriving Requirements là “kéo requirement ra từ bối cảnh”
Khi stakeholder đưa ra một nhu cầu lớn, requirement chi tiết thường chưa xuất hiện ngay. BA cần nhìn vào bối cảnh, mục tiêu, quy trình, rule và dữ liệu để kéo ra các yêu cầu nhỏ hơn cần thiết.
Đây là lý do BA không chỉ ghi chép. BA phải phân tích và đặt câu hỏi để requirement trở nên đầy đủ.
Từ nhu cầu lớn đến requirement chi tiết
1
Nhu cầu lớn
Ví dụ: “Chúng tôi muốn cải thiện quy trình phê duyệt chi phí”.
2
Câu hỏi của BA
Ai tạo yêu cầu? Ai phê duyệt? Có hạn mức không? Có ngoại lệ không? Cần thông báo không?
3
Requirement được dẫn xuất
Hệ thống cần form tạo yêu cầu, rule hạn mức, workflow phê duyệt, email thông báo và log lịch sử.
4
Xác nhận lại
BA xác nhận các requirement này với stakeholder trước khi đưa vào tài liệu chính thức.
Ví dụ rất đơn giản
Nhu cầu: “Tôi muốn quản lý đơn hàng tốt hơn”.
BA có thể dẫn xuất các requirement:
- Người dùng có thể tạo đơn hàng mới.
- Đơn hàng có các trạng thái: mới, đang xử lý, đã giao, đã hủy.
- Hệ thống kiểm tra tồn kho trước khi xác nhận đơn.
- Khách hàng nhận email khi đơn hàng được giao.
- Quản lý có báo cáo số đơn theo trạng thái.
Cách tự kiểm tra requirement được dẫn xuất
Với mỗi requirement được dẫn xuất, hãy hỏi:
- Nó xuất phát từ nhu cầu, rule hoặc quy trình nào?
- Nếu bỏ requirement này, mục tiêu có bị ảnh hưởng không?
- Stakeholder nào cần xác nhận requirement này?
- Requirement này có thể kiểm thử được không?
Ghi nhớ
Dẫn xuất requirement là kỹ năng giúp BA không bỏ sót những điều cần thiết phía sau một nhu cầu nghe có vẻ đơn giản.
Kết luận
Khi hiểu deriving requirements theo cách đơn giản, bạn sẽ thấy BA luôn phải đi từ nhu cầu lớn đến requirement nhỏ, rõ, có căn cứ và có thể xác nhận.