Skip to main content
Thông tin
Dịch vụ
  • Số điện thoại

    (+84) 97 531 9889

    (+84) 86 929 1771

  • Email

    infor@beau.vn

  • Văn phòng đại diện

    Tầng 5, 33 Giang Văn Minh, Kim Mã, Ba Đình, Hà Nội

Kỹ năng làm rõ yêu cầu (Requirement Elicitation) dành cho IT Business Analyst (Phần 1)

01 Dec, 2025 /
Chiến lược
Kỹ năng làm rõ yêu cầu (Requirement Elicitation) (Phần 1)

Đối với một IT Business Analyst, kỹ năng về việc làm rõ yêu cầu (Requirement Elicitation) là một trong những kỹ năng quan trọng nhất. 

Việc thu thập, khám phá và làm rõ các yêu cầu từ các bên liên quan sẽ giúp cho BA hiểu rõ vấn đề hoặc nhu cầu của doanh nghiệp và người dùng, từ đó xác định các yêu cầu chính xác cho hệ thống, sản phẩm hoặc giải pháp cần xây dựng. Trong bài viết này, chúng ta sẽ tifm hiểu bức tranh tổng quan về một kỹ năng mà bất kỳ IT Business Analyst nào cũng cần nắm vững: kỹ năng làm rõ yêu cầu (Requirement Elicitation)

Làm rõ yêu cầu (Requirement Elicitation) là gì?

Một sản phẩm tốt là một sản phẩm giải quyết được đúng nhu cầu từ khách hàng. Sẽ có nhiều trường hợp khách hàng không thực sự hiểu mình muốn gì, và nhiệm vụ của một IT BA là tìm ra được vấn đề trọng tâm mà khách hàng muốn cho sản phẩm phần mềm hoặc tính năng mới. Trong mỗi một dự án phần mềm, IT BA cần xác định được đúng trọng tâm về nhu cầu của khách hàng. Nhu cầu đó có thể là xử lý một vấn đề đang hiện hữu hoặc nắm bắt một cơ hội mới để cải thiện quy trình kinh doanh. Để có được thông tin trọng tâm, IT BA sẽ cần thu thập thông tin từ phía khách hàng để phân tích, từ đó tìm ra được nhu cầu trọng tâm của khách hàng. Quá trình thu thập thông tin này chính là lúc đòi hỏi kỹ năng khơi gợi yêu cầu (Requirement Elicitation) từ một Business Analyst.

"Kỹ năng làm rõ yêu cầu (Requirement Elicitation) (Phần 1)"

Khác với việc nghe và ghi chép thụ động các thông tin tiếp nhận được, kỹ năng khơi gợi nhu cầu đòi hỏi Business Analyst phải có sự chủ động trong việc tìm hiểu, phân tích, đặt câu hỏi và khám phá sâu nhu cầu thực sự từ khách hàng. Mục tiêu chủ yếu trong giai đoạn này là hiểu rõ nhu cầu thực sự của khách hàng thay vì chỉ nghe thụ động về nhu cầu mà khách hàng trình bày. Việc hiểu đúng và cụ thể về nhu cầu sẽ giúp cho sản phẩm đi đúng hướng và thực sự phù hợp với nhu cầu thực tế của khách hàng.

Đọc thêm: Vòng đời phát triển sản phẩm (Software Life Cycle Development) và vai trò của IT Business Analyst

Các thông tin cần xác định trước quá trình làm rõ thông tin

Việc chuẩn bị cho quá trình khơi gợi thông tin là rất quan trọng khi BA nhận dự án từ PM. Sẽ rất có lợi cho BA khi BA đã nắm chắc các thông tin cơ bản về dự án trước khi gặp mặt các stakeholders liên quan để trao đổi. Trong quá trình tiếp nhận dự án, BA cần nắm rõ các thông tin sau để có thể lên danh sách các câu hỏi và các vấn đề cần làm rõ với các stakeholders một cách chiến lược: 

Context - Bối cảnh dự án và mục tiêu tổng quát: Đây là thông tin quan trọng nhất mà BA cần phải nắm chắc trước khi trao đổi với khách hàng về chi tiết dự án. Bằng cách sử dụng những model như BACCM, PESTEL, SWOT và Mckinsey 7S, BA có thể xác định rõ về mục tiêu chính của dự án, bối cảnh nội bộ công ty khách hàng cũng như các yếu tố bên ngoài ảnh hưởng đến dự án để lên chiến lược tìm ra giải pháp hiệu quả nhất cho khách hàng.

Stakeholders - Lên danh sách các bên liên quan: Trước khi tìm kiếm thông tin, BA cần lên danh sách những người trực tiếp ảnh hưởng đến dự án để khai thác thông tin chính xác. BA có thể sử dụng các công cụ như Power - Interest Grid để tìm ra người có ý kiến quan trọng đóng góp và dự án để khai thác thông tin. Một số các cá nhân hay tổ chức được coi là stakeholders phổ biến có thể kể đến bao gồm:

  • Đội ngũ phát triển (Project team members): Xác định về nguồn lực và thời gian đang có để triển khai dự án.
  • Khách hàng/Người dùng cuối (Customer/Client/End user): Đay là nhóm người quan trọng nhất, là những người trực tiếp sử dụng sản phẩm.
  • Nhà cung cấp (Suppliers): Là người bị ảnh hưởng bởi các quyết định thay đổi chiến lược hay quy trình nội bộ của doanh nghiệp.
  • Nhân viên và Giám đốc công ty khách hàng (Employee/Employers): Là những bên có quyền lợi bị ảnh hưởng từ sự thay đổi. Ở cáp cấp cao hơn, đây sẽ là nơi đưa quyết định dự án có được phê duyệt hay không.
  • Cộng đồng (Community): Khi làm sản phẩm hay tính năng cho mỗi cộng đồng khác nhau, việc lắng nghe ý kiến của cộng đồng đó là vô cùng quan trọng để đưa ra những giải pháp phù hợp nhất.
  • Tổ chức chuyên môn (Professional organizations): Đây sẽ là nhóm người đưa ra những tiêu chuẩn, quy định và đạo đức nghề nghiệp gây ảnh hưởng đến cách triển khai dự án.
  • Cá nhân bị ảnh hưởng hoặc hỗ trợ (Individuals impacted by or supporting the project): Đây là những cá nhân gián tiếp ảnh hưởng tới dự án, do đó ý kiến của nhóm người này cũng đem lại giá trị cho một dự án thành công.

"Kỹ năng làm rõ yêu cầu (Requirement Elicitation) (Phần 1)"

Roles - Xác định các vai trò trong dự án: Trước khi tiến hành khơi gợi yêu cầu và triển khai dự án, việc xác định rõ vai trò của từng cá nhân và phòng ban liên quan là điều hết sức quan trọng. Điều này giúp tránh xung đột trách nhiệm, lãng phí nguồn lực, và hiểu lầm giữa các bên liên quan trong suốt vòng đời dự án. Một phương pháp hữu ích mà BA có thể sử dụng là RASCI Model – một công cụ phân vai trò phổ biến giúp xác định 5 vai trò chính: Người trực tiếp thực hiện (Responsible), Người chịu trách nhiệm chính (Accountable), Người hỗ trợ (Support), người tham vấn (Consult), Người cần được thông báo (Informed).

Risk – Xác định rủi ro: Trong quá trình chuẩn bị khơi gợi yêu cầu, BA cần dự đoán trước các rủi ro tiềm ẩn để xây dựng phương án dự phòng. Việc này không chỉ giúp chủ động ứng phó, mà còn tăng độ tin cậy trong kế hoạch làm việc. Một công cụ hữu hiệu để thực hiện việc này là RAID Log, bao gồm các rủi ro (Risks), Các giả định (Assumptions), Các vấn đề (Issues), Các phụ thuộc (Dependencies). Có 4 nhóm rủi ro chính cần chú ý bao gồm:

  • Yếu tố con người (People): Thiếu sự phối hợp, năng lực hạn chế, nghỉ việc đột xuất.
  • Yếu tố quy trình (Process): Thiếu quy trình chuẩn, thay đổi quy trình giữa chừng.
  • Yếu tố quản lý (Project): Không có timeline rõ ràng, thay đổi ưu tiên dự án.
  • Yếu tố công nghệ (Technology): Hệ thống cũ, thiếu công cụ hỗ trợ, vấn đề tích hợp.

Knowledge – Kiến thức nghiệp vụ: Để buổi trao đổi với stakeholder diễn ra hiệu quả, BA cần chuẩn bị kỹ lưỡng về mặt kiến thức. Cần nắm rõ cả kiến thức nghiệp vụ (domain knowledge) lẫn kiến thức kỹ thuật cơ bản (technical knowledge) để hiểu đúng vấn đề và đặt câu hỏi chính xác. Nguồn tham khảo kiến thức có thể đến từ Người nắm nghiệp vụ nội bộ (SME, Line Manager…), Tài liệu hệ thống và quy trình cũ (BRD, SRS), kinh nghiệm từ chính BA hay các công cụ hỗ trợ học tập nhanh như Google, ChatGPT.

Đọc thêm: BACCM – Mô hình cơ bản dành cho các Business Analyst

Kết

Việc chuẩn bị kỹ lưỡng trước buổi làm rõ thông tin với khách hàng sẽ giúp cho việc tìm kiếm thông tin trở nên hiệu quả hơn. Không chỉ vậy, sự chuẩn bị cũng làm tăng sự tự tin khi trình bày với khách hàng, giúp cho các IT Business Analyst có được hình ảnh chuyên nghiệp. Trong bài viết sau, chúng ta sẽ tìm hiểu chi tiết về các bước khai thác thông tin khi gặp khách hàng và các stakeholders.

Đăng ký
nhận tin tức.