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

Trong bài viết trước chúng ta đã cùng tìm hiểu về các bước để chuẩn bị cho buổi khai thác thông tin và yêu cầu từ phía khách hàng và các stakeholders. Trong bài viết hôm nay, chúng ta sẽ tìm hiểu sâu các bước cơ bản và các thông tin cần khai thác thông qua kỹ năng làm rõ yêu cầu (Requirement Elicitation) trong quá trình trao đổi với khách hàng để định hình sản phẩm.

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

Sau khi đã chuẩn bị kỹ lưỡng cho quá trình làm rõ thông tin, BA sẽ trực tiếp gặp mặt khách hàng và các stakeholders liên quan đến dự án để thực hiện việc khai thác và làm rõ các yêu cầu. Một buổi gặp mặt khách hàng được coi là hiệu quả khi BA có khả năng làm rõ các chủ đề sau:

Confirm - Xác nhận các thông tin đã chuẩn bị: Trong quá trình chuẩn bị những thong tin cơ bản về dự án, BA sẽ không thể tránh khỏi những mơ hồ cần làm rõ với khách hàng. Buổi trao đổi với khách hàng sẽ là lúc BA cần làm rõ các thông tin cơ bản nhất để triển khai dự án, bao gồm các thông tin về bối cảnh (Context), mục tiêu kinh doanh (Business Objective), Danh sách Stakeholders, các vai trò của các cá nhân từ hai phía (Roles).

Scope - Phạm vi của dự án: Việc xác định phạm vi giúp tránh tình trạng “trượt yêu cầu” (scope creep) trong quá trình phát triển. Bạn cần phân biệt rõ những gì nằm trong phạm vi dự án và những gì không. Đồng thời, cũng cần ghi nhận những yêu cầu phát sinh nằm ngoài phạm vi hiện tại để xử lý sau. Điều này sẽ giúp việc quản lý kỳ vọng của stakeholder hiệu quả hơn. Những phần chính khi xác định scope bao gồm phạm vi về tổ chức (Organization Scope), phạm vi về người dung (Users Scope), phạm vi chức năng (Functional Scope), phạm vi tích hợp (Integration Scope) và những gì nằm ngoài phạm vi (Out of Scope).

Business Case – Viễn cảnh cụ thể cho từng phạm vi: Mỗi một Scope sẽ bao gồm các Business Case khác nhau. Việc xác định các business case cụ thể sẽ giúp cho BA hệ thống hóa những trường hợp cụ thể mà sản phẩm phần mềm có thể giải quyết, qua đó có được một hệ thống hoàn chỉnh để bắt đầu phân tích và phát triển sản phẩm.

Constraints - Các giới hạn của dự án: Trong quá trình triển khai dự án, sẽ có những ràng buộc nhất định mà nhóm phát triển cần lưu ý từ sớm đẻ đảm bảo xây dựng giải pháp phù hợp và khả thi. Nhiệm vụ của BA là phải làm rõ những giới hạn của dự án với khách hàng, qua đó đưa ra những giải pháp phù hợp. Những giới hạn này có thể đến từ:

• Công Nghệ: Nền tảng công nghệ đang sử dụng và đang hiện hữu trên thị trường có hỗ trợ tính năng mới không? Có cần nâng cấp hay thay thế công nghệ không?
• Nguồn lực: Nguồn lực nhân sự và chi phí được giới hạn thế nào và có đủ để thực hiện yêu cầu của dự án không?
• Thời gian: Giới hạn thời gian của dự án là bao lâu?
• Pháp lý: Dữ liệu nào được phép sử dụng và được sử dụng như thế nào? Đã có đầy đủ giấy phép để đưa các tính năng cụ thể lên phần mềm chưa? Các tính năng có tuân thủ quy định về bảo mật và quyền riêng tư không?
• Tích hợp: Có giới hạn nào về việc tích hợp với hệ thống nội bộ cũng như các hệ thống bên ngoài không?

Requirements - Xác định yêu cầu từ khách hàng và stakeholders: Đây là bước cốt lõi và quan tọng nhất của giai đoạn làm rõ yêu cầu, vì toàn bộ định hướng sản phẩm và giải pháp về sau sẽ dựa vào thông tin thu thập được ở giai đoạn này. Khách hàng và các stakeholders sẽ chia sẻ quan điểm, mong muốn và nhu cầu của họ đối với sản phẩm. Tuy nhiên không phải tất cả yêu cầu đều được thể hiện một cách chính xác. Sẽ những yêu cầu rõ ràng (Explicit Requirements) là những điều mà stakeholder có thể mô tả hoặc theo yêu cầu một cách cụ thể. Ngoài ra, sẽ có một lượng lớn những yêu cầu tiềm ẩn hoặc không rõ ràng (Implicit Requirements), là những yêu cầu mà khách hàng chưa nhận thức được hoặc không thể diễn đạt rõ ràng, hoặc hiểu sai yêu cầu thực sự của chính mình. Lúc này, nhiệm vụ của BA là khéo léo khai thác, phân tích và làm rõ, ghi nhận đúng bản chất của các yêu cầu, bao gồm cả điều khách hàng nói và điều họ thực sự cần để đảm bảo không bị hiểu sai, bỏ sót hoặc thu thập sai lệch thông tin. Để hệ thống hóa và phân tích hiệu quả, BA cần chia các yêu cầu thành 4 nhóm chính cho mỗi Business Case, bao gồm:

• Business Objective Requirements – Yêu cầu về mục tiêu kinh doanh: Mô tả mục tiêu kinh doanh mà khách hàng muốn đạt được thông qua dự án và giải pháp.
• Stakeholder Requirements – Yêu cầu của các bên liên quan: Nêu rõ nhu cầu, mong muốn và vai trò của từng bên liên quan đến sản phẩm.
• Solution Requirements – Yêu cầu về giải pháp: Bao gồm hai loại chính:
• Functional Requirements – Yêu cầu chức năng: Mô tả các chức năng mà hệ thống cần thực hiện.
• Non – Functional Requirements – Yêu cầu phi chức năng: Mô tả về các yêu cầu không liên quan đến tính năng cụ thể như hiệu suất, độ bảo mật, khả năng mở rộng, tính khả dụng. Ở bước này, BA có thể kết hợp mô hình FURPS (Functionality, Usability, Reliability, Performance, Supportability) và MoSCoW (Must, Should, Could, Won’t have) để phân loại và ưu tiên các yêu cầu.
• Transition Requirements – Yêu cầu về chuyển đổi:  Đây là các yêu cầu trung gian cần thiết để chuyển từ hệ thống hiện tại sang hệ thống mới như đào tạo, chuyển đổi dữ liệu hay thay đổi quy trình.

Risks - Rủi ro tiềm ẩn liên quan đến yêu cầu và hiểu sai: Tiếp theo, BA cần chủ động ghi nhận các rủi ro có thể phát sinh nếu giả định không đúng, hoặc nếu có sự thay đổi trong yêu cầu. Việc nhận diện sớm rủi ro giúp nhóm có kế hoạch xử lý, thay vì bị động khi sự cố xảy ra. Ở bước này, BA có thể sử dụng model RAID log đã chuẩn bị từ trước đó để cập nhật và bổ sung những rủi ro mới từ khách hàng.

Criteria - Định nghĩa hoàn thành (Definition of Done) và Success Criteria: Để đảm bảo các bên thống nhất về kết quả đầu ra, cần xác định rõ “khi nào thì tính năng được xem là hoàn thành”. Điều này bao gồm việc hoàn thiện mã nguồn, kiểm thử thành công, và được người dùng chấp thuận. Định nghĩa này càng rõ ràng thì càng giảm thiểu khả năng hiểu sai hoặc tranh cãi khi nghiệm thu sản phẩm.

Đọ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

Những hoạt động cần có sau quá trình làm rõ thông tin

Sau khi kết thúc giai đoạn trao đổi và làm rõ yêu cầu với stakeholders, Business Analyst cần thực hiện các hoạt động sau để đảm bảo thông tin thu thập được được tổ chức, xác thực và sẵn sàng phục vụ cho bước phân tích – thiết kế tiếp theo:

Tổng hợp và làm sạch thông tin: Đây là bước quan trọng để chuyển đổi dữ liệu thô từ các buổi trao đổi thành tài liệu có cấu trúc rõ ràng. BA sẽ thu thập toàn bộ ghi chú, biểu mẫu, sơ đồ, audio hoặc bảng khảo sát đã thực hiện, sau đó loại bỏ thông tin trùng lặp, mâu thuẫn hoặc không rõ ràng. Đồng thời, BA cần chuẩn hóa cách trình bày và ngôn ngữ để tài liệu dễ hiểu cho tất cả các bên liên quan. Một số đầu mục tài liệu thường được tạo ra trong giai đoạn này gồm: Stakeholder Register – ghi lại vai trò, ảnh hưởng và mức độ liên quan của từng bên liên quan; Raw Requirements – bản ghi thô các yêu cầu chưa phân tích; hoặc Context Diagram – sơ đồ ngữ cảnh mô tả hệ thống và các tác nhân tương tác với hệ thống.

Phân loại tài liệu: BA cần phân loại thông tin theo các cấu trúc khác nhau để phục vụ cho việc phân tích. Phân loại theo định dạng giúp đảm bảo thông tin được trình bày rõ ràng và dễ đọc, ví dụ như sử dụng bảng, sơ đồ hoặc mô hình. Phân loại theo mục tiêu cho phép nhóm các yêu cầu theo từng mục tiêu nghiệp vụ hoặc hệ thống cụ thể, ví dụ: nhóm yêu cầu về tối ưu quy trình bán hàng, nhóm yêu cầu về tích hợp dữ liệu khách hàng... Cuối cùng, phân loại theo loại yêu cầu sẽ giúp chia các yêu cầu thành từng nhóm rõ ràng như Business Requirements, Stakeholder Requirements, Solution Requirements, và Transition Requirements – tạo nền tảng để viết tài liệu đặc tả chi tiết sau này.

Xác nhận lại các yêu cầu với Stakeholders: Đây là bước then chốt để đảm bảo tất cả thông tin đã được hiểu đúng và đồng thuận giữa các bên. BA sẽ tổng hợp và gửi lại bản tóm tắt các yêu cầu đã ghi nhận, tổ chức cuộc họp hoặc gửi tài liệu để các bên xem xét, phản hồi. Mọi điểm còn mơ hồ hoặc chồng chéo sẽ được làm rõ và cập nhật lại vào tài liệu phiên bản mới. Mục tiêu cuối cùng của bước này là đạt được sự thống nhất trước khi tiến sang giai đoạn thiết kế giải pháp.

Cập nhật các tài liệu hỗ trợ quản lý dự án: Cuối cùng, sau khi đã xác nhận yêu cầu, BA cần cập nhật thông tin vào các tài liệu quản lý dự án để đồng bộ với các nhóm liên quan như quản lý dự án, phát triển, kiểm thử... Các tài liệu như Requirement Traceability Matrix, Project Scope Document hoặc Product Backlog cần được chỉnh sửa, cập nhật theo thông tin mới nhất. Điều này giúp đảm bảo toàn bộ team nắm được đúng phạm vi, yêu cầu và hướng đi của dự án, từ đó giảm thiểu rủi ro trong quá trình thực hiện.

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

Kết

Việc làm rõ yêu cầu không chỉ là một bước quan trọng mà còn là nền tảng để đảm bảo thành công cho dự án. Một Business Analyst giỏi sẽ biết cách tổ chức, phân tích và xác nhận thông tin một cách hiệu quả, giúp các bên liên quan hiểu rõ và đồng thuận về mục tiêu. Điều này không chỉ tối ưu hóa quy trình phát triển sản phẩm mà còn giảm thiểu rủi ro, tăng cường sự hợp tác và đảm bảo chất lượng đầu ra tốt nhất. Trong bài viết tiếp theo, chúng ta sẽ đi sâu và những kỹ thuật làm rõ yêu cầu phổ biến.