Thu thập và phân tích yêu cầu
Thu thập và Phân tích Yêu cầu trong Dự án CNTT
(Requirement Gathering and Analysis)
1. Khái niệm Thu thập và Phân tích Yêu cầu là gì?
Thu thập và phân tích yêu cầu là giai đoạn đầu tiên và quan trọng nhất trong quy trình phát triển phần mềm hoặc hệ thống CNTT. Mục tiêu của giai đoạn này là: ✅ Hiểu rõ vấn đề của doanh nghiệp cần giải quyết. ✅ Xác định chính xác những gì hệ thống cần thực hiện. ✅ Làm nền tảng để thiết kế, phát triển và kiểm thử phần mềm.
Nếu yêu cầu không rõ ràng, thiếu chính xác, phần mềm phát triển sẽ không đáp ứng được kỳ vọng, gây lãng phí thời gian, chi phí.
2. Vai trò của IT Business Analyst (BA) trong Thu thập và Phân tích Yêu cầu
Vai trò chính
Ý nghĩa và nhiệm vụ
Cầu nối giữa nghiệp vụ và kỹ thuật
Truyền tải nhu cầu kinh doanh thành yêu cầu phần mềm dễ hiểu cho kỹ thuật.
Lắng nghe và làm rõ yêu cầu
Làm việc với khách hàng, các bên liên quan để hiểu sâu vấn đề.
Tài liệu hóa yêu cầu
Xây dựng tài liệu yêu cầu nghiệp vụ (BRD), tài liệu yêu cầu chức năng (FRD).
Kiểm soát thay đổi yêu cầu (Scope Management)
Đảm bảo yêu cầu rõ ràng, kiểm soát thay đổi hợp lý.
Xác nhận yêu cầu với khách hàng
Đảm bảo sự đồng thuận, tránh hiểu nhầm.
3. Các bước Thu thập và Phân tích Yêu cầu
Bước
Hoạt động chi tiết
Kết quả
1. Xác định các bên liên quan (Stakeholders)
Ai là người ảnh hưởng hoặc sử dụng hệ thống?
Danh sách Stakeholders.
2. Khảo sát, phỏng vấn, thu thập yêu cầu
Phỏng vấn, workshop, bảng câu hỏi, quan sát.
Danh sách yêu cầu thô.
3. Phân loại yêu cầu
Yêu cầu nghiệp vụ, chức năng, phi chức năng.
Danh sách yêu cầu phân loại.
4. Phân tích, làm rõ yêu cầu
Hiểu chi tiết, làm rõ điểm mâu thuẫn, chưa rõ.
Yêu cầu rõ ràng, dễ hiểu, nhất quán.
5. Xác nhận yêu cầu với các bên liên quan
Trình bày lại để được phê duyệt.
Yêu cầu được xác nhận.
6. Tài liệu hóa yêu cầu
Viết thành BRD, FRD, Use Case, User Story.
Tài liệu chính thức làm căn cứ phát triển.
4. Các kỹ thuật Thu thập Yêu cầu phổ biến
Kỹ thuật
Ý nghĩa, khi sử dụng
Phỏng vấn (Interview)
Gặp trực tiếp từng người để hiểu chi tiết vấn đề.
Khảo sát, bảng hỏi (Survey/Questionnaire)
Lấy ý kiến nhanh từ nhiều người.
Hội thảo (Workshop)
Tập hợp nhiều bên liên quan để cùng trao đổi.
Quan sát (Observation)
Xem thực tế quy trình làm việc để phát hiện vấn đề.
Phân tích tài liệu (Document Analysis)
Nghiên cứu quy trình, tài liệu hiện có để hiểu hệ thống.
Prototyping (Mẫu thử)
Xây dựng giao diện mẫu để khách hàng dễ hình dung.
Brainstorming (Động não nhóm)
Tìm ra các yêu cầu mới, sáng tạo giải pháp.
5. Các loại yêu cầu cần thu thập
Loại yêu cầu
Giải thích
Ví dụ
Yêu cầu nghiệp vụ (Business Requirements)
Mong muốn tổng thể của doanh nghiệp.
"Hệ thống giúp quản lý đơn hàng tự động."
Yêu cầu người dùng (User Requirements)
Mong muốn từ phía người dùng cụ thể.
"Người bán cần theo dõi trạng thái đơn hàng."
Yêu cầu chức năng (Functional Requirements)
Tính năng hệ thống phải có.
"Cho phép tạo, sửa, xóa đơn hàng."
Yêu cầu phi chức năng (Non-Functional Requirements)
Hiệu suất, bảo mật, tính khả dụng.
"Phải đáp ứng 1,000 đơn hàng cùng lúc."
6. Tài liệu hóa Yêu cầu - Những tài liệu quan trọng
Tên tài liệu
Ý nghĩa
BRD (Business Requirements Document)
Mô tả yêu cầu nghiệp vụ tổng thể.
FRD (Functional Requirements Document)
Mô tả yêu cầu chức năng chi tiết.
Use Case/ User Stories
Mô tả từng kịch bản sử dụng hoặc chức năng.
Wireframe/Prototype
Giao diện mẫu giúp hình dung giải pháp.
Acceptance Criteria
Tiêu chí chấp nhận để nghiệm thu hệ thống.
7. Kết quả của Thu thập và Phân tích Yêu cầu
✅ Bộ tài liệu yêu cầu rõ ràng, đầy đủ, được phê duyệt. ✅ Cơ sở để đội phát triển, thiết kế, kiểm thử dựa theo. ✅ Giảm thiểu rủi ro sai lệch giữa mong muốn và thực tế. ✅ Dễ kiểm soát phạm vi (Scope) và thay đổi (Change request).
8. Rủi ro khi thu thập yêu cầu không tốt & Cách phòng tránh
Rủi ro
Cách phòng tránh
Yêu cầu mơ hồ, không rõ ràng
Phân tích chi tiết, xác nhận nhiều lần với khách hàng.
Yêu cầu xung đột giữa các bên
Tổ chức workshop, làm rõ ưu tiên và mục tiêu chung.
Bỏ sót yêu cầu quan trọng
Sử dụng checklist, khảo sát nhiều nguồn.
Không kiểm soát được thay đổi yêu cầu
Quản lý yêu cầu chặt, dùng quy trình phê duyệt rõ ràng.
Không hiểu quy trình nghiệp vụ hiện tại
Quan sát thực tế, phỏng vấn nhiều cấp độ.
9. Kết luận
✅ Thu thập và phân tích yêu cầu là nền tảng quan trọng quyết định thành công của dự án CNTT. 🎯 BA cần phối hợp tốt với khách hàng và các bên liên quan để:
Hiểu đúng, hiểu đủ yêu cầu.
Tài liệu hóa rõ ràng.
Kiểm soát và xác nhận đầy đủ.
🌟 Thông điệp cho BA và doanh nghiệp:
"Yêu cầu được hiểu đúng ngay từ đầu là chìa khóa để phần mềm thành công và tối ưu hóa chi phí."
Last updated