Requirements Analysis and Design Definition(RADD)

Nếu bạn từng ngồi cả buổi chiều vẽ lại một luồng nghiệp vụ, cãi với dev về việc một trường có bắt buộc hay không, rồi viết acceptance criteria cho tám user story — bạn đang đứng giữa vùng này. Trong sáu knowledge area của BABOK v3, đây là vùng dày nhất với 6 task, và cũng là nơi BA Việt Nam sống phần lớn thời gian làm việc.

Elicitation mang thông tin thô về. Vùng này biến đống thô đó thành thứ dev đọc được và QC test được.

Sáu task

1. Specify and Model Requirements — viết ra và mô hình hoá: user story, use case, sơ đồ hoạt động, bảng business rule, wireframe.
2. Verify Requirements — soi chất lượng của chính tài liệu: rõ chưa, có mâu thuẫn không, có test được không.
3. Validate Requirements — soi xem yêu cầu có dẫn tới giá trị kinh doanh đã hứa hay không.
4. Define Requirements Architecture — sắp yêu cầu thành một cấu trúc mạch lạc, biết cái nào phụ thuộc cái nào và bộ yêu cầu đã đủ chưa.
5. Define Design Options — đưa ra các phương án: mua phần mềm đóng gói, mở rộng hệ đang có, tự viết, thuê dịch vụ.
6. Analyze Potential Value and Recommend Solution — cân giá trị với chi phí của từng phương án rồi khuyến nghị một cái.

Bốn task đầu là nửa "requirements analysis", hai task cuối là nửa "design definition". Cái tên dài loằng ngoằng của vùng này chính là hai nửa đó ghép lại.

Requirement và design, ranh giới ở đâu

BABOK tách rất kỹ hai thứ mà thực tế hay trộn. Requirement mô tả nhu cầu; design mô tả một cách đáp ứng nhu cầu đó. "Người duyệt phải nhận biết được hồ sơ quá hạn" là requirement. "Hiển thị chấm đỏ ở cột trạng thái khi hồ sơ quá 48 giờ" là design.

Ranh giới này trôi qua lại theo cấp độ: một design ở tầng trên có thể thành requirement cho tầng dưới. Đừng đốt hai tiếng họp để phân loại một câu. Thứ đáng giữ trong đầu là biết lúc nào bạn đang chốt nhu cầu, lúc nào bạn đang chốt cách làm — vì hai loại quyết định đó có người ra quyết cuối khác nhau.

Verify và validate

Ví dụ thực tế

Nhà phân phối dược phẩm, 4 kho, khoảng 9.000 mã hàng, muốn thay cách quản lý xuất nhập tồn đang chạy trên Excel và một phần mềm kế toán cũ.

Phần specify chạy hai tuần: 41 yêu cầu chức năng, 6 sơ đồ hoạt động cho các luồng nhập – xuất – kiểm kê – trả nhà cung cấp, một bảng 23 business rule riêng cho hạn dùng và số lô. Riêng bảng business rule đó về sau tiết kiệm cả chục vòng hỏi đáp, vì quy tắc "xuất theo lô cận date trước" có tới bốn ngoại lệ mà không ai kể ở buổi đầu.

Sang phần design options, đội đặt lên bàn ba phương án: mua một WMS đóng gói (khoảng 1,4 tỷ, 5 tháng, chỉnh sửa hạn chế), mở rộng module kho của ERP đang dùng (900 triệu, 4 tháng, phụ thuộc nhà cung cấp ERP), hoặc tự viết (700 triệu, 7 tháng, phải nuôi đội bảo trì). Khuyến nghị cuối cùng là phương án hai, vì dữ liệu master hàng hoá và công nợ đã nằm sẵn trong ERP, và chi phí đồng bộ hai chiều của hai phương án còn lại bị bỏ quên trong bảng giá ban đầu.

Con số làm thay đổi quyết định là chi phí tích hợp, chứ không phải giá phần mềm. Đó là thứ chỉ lộ ra khi có người làm task số 4 một cách nghiêm túc.

Vùng này chạy thế nào trong dự án Scrum

Không ai mở BABOK ra giữa sprint. Nhưng sáu task vẫn diễn ra, chỉ là ở dạng nhỏ và lặp lại:

• Specify and model = viết user story kèm sơ đồ luồng ngắn trước buổi refinement.
• Verify = chính buổi refinement, khi dev và QC đọc và bắt lỗi mơ hồ.
• Validate = câu hỏi "story này phục vụ Sprint Goal nào" trong sprint planning.
• Requirements architecture = story map, để biết mình đang thiếu mảnh nào của luồng.
• Design options = buổi 30 phút với tech lead trước khi chốt cách làm.

Nếu đội bạn hay gặp cảnh dev code xong rồi mới phát hiện thiếu một nhánh nghiệp vụ, khả năng cao task bị bỏ là số 4. Thử vẽ story map cho một luồng trọn vẹn trước sprint sau và đếm xem có bao nhiêu ô trống.