Trong kỳ thi CBAP, đây là nhóm kiến thức có khối lượng câu hỏi cao nhất chiếm đến 30%.
Mục đích: cấu trúc và tổ chức requirements được elicited, xác định thêm thuộc tính, mô tả bằng nhiều hình thức, xác nhận giá trị, và định nghĩa các giải pháp đáp ứng nhu cầu doanh nghiệp.
Điểm cốt lõi cần nhớ: Requirements tập trung vào nhu cầu (cần gì), còn Designs tập trung vào giải pháp (làm thế nào). Cùng một thông tin có thể là requirement hay design tùy góc nhìn và mức độ trừu tượng.
6 Tasks của RADD
1. Specify and Model Requirements
Mô tả requirements và designs bằng văn bản, ma trận, hoặc mô hình (diagram). Bao gồm ba nhóm mô hình: People and Roles, Rationale, Activity Flow, Capability, Data and Information. Phân biệt: specify (nắm bắt chi tiết) và model (biểu diễn trực quan). Kết quả tạo ra implementation-independent vs implementation-dependent requirements.
2. Verify Requirements
Đảm bảo requirements và designs đạt chất lượng “building it right”. Kiểm tra các đặc tính chất lượng: atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritized, understandable. Verify là hoạt động nội bộ, dựa trên checklist.
Có thể hiểu đơn giản là BA có đang mô tả/xây dựng giải pháp đúng cách không?(Building it right)
3. Validate Requirements
Đảm bảo requirements và designs mang lại giá trị, phù hợp với nhu cầu stakeholder “building the right thing”. Liên kết requirements với business goals/objectives, định nghĩa measurable evaluation criteria, xác định assumptions và điều kiện thành công.
BA có đang xây dựng đúng thứ cần thiết không?" (Building the right thing)
Bước này tránh việc xây dựng 1 sản phẩm có vẻ hoàn hảo nhưng không ai dùng. Nó giúp giải pháp được đáp ứng một mục tiêu kinh doanh cụ thể.
Xác định trước các chỉ số đo lường (KPI/metrics) để biết khi hệ thống go-live, giải pháp đó có thực sự đem lại giá trị (ROI) kỳ vọng hay không.
4. Define Requirements Architecture
Cấu trúc tất cả requirements thành một tổng thể mạch lạc (requirements viewpoints và views). Đảm bảo requirements hỗ trợ lẫn nhau, đầy đủ (completeness), và phù hợp với information architecture. Trả lời câu hỏi bộ requirements đã đủ hay chưa.
5. Define Solution Options
Xác định, khám phá và mô tả các giải pháp khả thi khác nhau. Bao gồm: define solution approaches (create/purchase/combination), identify improvement opportunities (automate, reduce complexity, improve access...). Tập trung vào options, chưa quyết định.
6. Analyze Potential Value and Recommend Solution
Đánh giá giá trị tiềm năng của từng solution option và khuyến nghị phương án tốt nhất đáp ứng nhu cầu doanh nghiệp. Phân tích benefits vs costs, đánh giá trade-offs, xác định expected value.
Điểm dễ nhầm khi thi CBAP
Cần phân biệt rõ Verify (đúng chất lượng, internal) và Validate (đúng giá trị, alignment với business). Đây là cặp câu hỏi bẫy phổ biến.
Requirements Architecture khác với việc mô hình hóa từng requirement đơn lẻ nó nói về mối quan hệ và tính toàn vẹn của cả bộ.
Phần tiếp theo mình sẽ chia sẻ thêm về từng task và dạng câu hỏi thường gặp. Các bạn quan tâm nhớ đăng ký theo dõi.
Bạn quan tâm khóa học có thể nhắn tin: https://www.facebook.com/congdongbusinessanalyst.vietnam.bazone