Sự Khơi Gợi Yêu Cầu Trong IT Business Analysis Là Gì

Sự khơi gợi yêu cầu trong Business Analysis là quá trình chủ động tìm kiếm, khám phá, và thu thập các mong muốn, nhu cầu thực tế từ khách hàng/các bên liên quan (stakeholders) nhằm xây dựng hệ thống phần mềm.

Để tránh khả năng xảy ra những sai lầm nghiêm trọng cản trở dự án, việc nghiên cứu và chuẩn bị đầy đủ cho quá trình requirements elicitation là vô cùng quan trọng. Hãy cùng Cole tìm hiểu về sự khơi gợi yêu cầu trong Business Analysis và các kỹ thuật requirements elicitation phổ biến trong bài viết dưới đây.

Requirements elicitation là gì?

Requirements Elicitation là một trong những giai đoạn phức tạp, dễ xảy ra lỗi, cần nhiều giao tiếp và đầy thử thách nhất của quy trình phát triển phần mềm vì nó đóng vai trò then chốt trong việc xác định ngân sách, ước tính thời gian và phạm vi của dự án. Sự rõ ràng của việc gợi ra các yêu cầu phải thật đặc biệt để cung cấp các giải pháp mà người dùng cuối thấy hữu ích và hài lòng.

Business Analysis Body of Knowledge (BABOK) Guide nêu rõ rằng trách nhiệm chính của Business Analyst là làm cho quy trình rút ra các yêu cầu trở nên đầy đủ và rõ ràng. Việc kết hợp việc gợi ra các yêu cầu vào thực tiễn phân tích kinh doanh cho phép Business Analyst đóng vai trò là cầu nối giữa các developers, stakeholders và người dùng cuối, từ đó tạo điều kiện cho sự phát triển liền mạch của các ứng dụng đáp ứng yêu cầu của khách hàng.

Tầm quan trọng của requirements elicitation trong IT Business Analysis 

Sự khơi gợi yêu cầu thành công thường phụ thuộc vào khả năng xác định và ghi lại chính xác nhu cầu của các stakeholders. Quá trình quan trọng này được gọi là requirements elicitation, là nền tảng trong lĩnh vực business analysis.

Hiểu rõ Requirements Elicitation

Requirements elicitation là quá trình thu thập, phân tích và ghi lại thông tin một cách có hệ thống để xác định các mục tiêu và ràng buộc của dự án. Giai đoạn này thường liên quan đến việc tương tác với các stakeholders để hiểu nhu cầu, mong đợi và kết quả mong muốn của họ. Nó đóng vai trò là nền tảng để tạo ra các yêu cầu dự án toàn diện và chính xác nhằm hướng dẫn các giai đoạn phát triển và triển khai.

Đảm bảo sự liên kết của các stakeholders

Một trong những mục tiêu chính của requirements elicitation là đảm bảo sự liên kết giữa mục tiêu dự án và mong đợi của các stakeholder. Việc thu hút các stakeholder tham gia vào các cuộc thảo luận cởi mở và hợp tác cho phép các business analysts hiểu rõ hơn về quan điểm, yêu cầu và mối quan tâm của họ. Sự liên kết này rất quan trọng để tránh những hiểu lầm và khác biệt có thể dẫn đến thất bại của dự án hoặc sự không hài lòng giữa các stakeholders.

Giảm thiểu việc mất kiểm soát

Scope creep hay việc mở rộng dần dần các mục tiêu của dự án vượt ra ngoài ranh giới được xác định ban đầu, có thể là mối đe dọa đáng kể đối với sự thành công của dự án. Việc khơi gợi các yêu cầu hiệu quả giúp xác định và ghi lại rõ ràng phạm vi dự án, ngăn chặn việc vượt ngoài tầm kiểm soát bằng cách thiết lập các ranh giới và đảm bảo rằng các project team luôn tập trung vào việc cung cấp các tính năng và chức năng đã thỏa thuận.

Tăng cường trao đổi

Requirements elicitation thúc đẩy giao tiếp hiệu quả giữa các stakeholders của dự án. Bằng cách tạo điều kiện cho các cuộc đối thoại mở, các business analyst có thể thu hẹp khoảng cách giao tiếp giữa các technical và non-technical stakeholders. Điều này đảm bảo rằng tất cả mọi người tham gia vào dự án đều hiểu được mục tiêu, ràng buộc và kỳ vọng, thúc đẩy một môi trường làm việc hợp tác và gắn kết.

Giảm thiểu rủi ro

Việc xác định và giải quyết sớm các rủi ro tiềm ẩn trong vòng đời dự án là điều cần thiết để thực hiện dự án thành công. Thông qua việc khởi gợi các yêu cầu, các business analyst có thể chủ động xác định các rủi ro liên quan đến những kỳ vọng xung đột của các stakeholders, các yêu cầu không rõ ràng hoặc các thách thức công nghệ. Chiến lược giảm thiểu rủi ro sớm này góp phần thực hiện dự án suôn sẻ hơn và có cơ hội đạt được mục tiêu dự án cao hơn trong các mốc thời gian đã thiết lập.

Các kỹ thuật Requirements Elicitation phổ biến nhất

Các yếu tố, chẳng hạn như customer’s profile và cơ cấu doanh nghiệp, cũng như loại dự án, cần được business analysis team xem xét trước khi áp dụng kỹ thuật gợi ý yêu cầu hoặc kết hợp các kỹ thuật khác. Có nhiều requirements elicitation techniques để thu thập thông tin quan trọng từ các Subject Matter Experts (SME) và các stakeholders. Những kỹ thuật phổ biến nhất được liệt kê dưới đây:

Brainstorming

Quá trình khơi gợi các yêu cầu bắt đầu bằng việc brainstorm. Để tạo điều kiện cho các brainstorm sessions tập trung và hiệu quả, các business analysts nên thành lập một nhóm gồm đại diện của tất cả các stakeholders để nắm bắt các ý tưởng mới. Những đề xuất từ ​​các brainstorm sessions cần được ghi lại một cách hợp lý để soạn thảo kế hoạch hành động.

• Use case: Các giải pháp hiện tại có thể không đủ sáng tạo để đáp ứng mục tiêu của dự án.
• Designed to: Khám phá những ý tưởng và giải pháp mới mẻ, có tính sáng tạo.
• How to: Tập hợp các key stakeholders để có một cuộc trò chuyện cởi mở về các ý tưởng và giải pháp đổi mới. Với tư cách là người điều phối, business analyst đảm bảo rằng cuộc trò chuyện vẫn đi đúng chủ đề và ghi lại các ý tưởng đã thảo luận.

Focus groups

Trong một focus group, các stakeholders cung cấp phản hồi để tinh chỉnh các quy trình, ý tưởng hoặc giải pháp xuất hiện nhờ kết quả của các hoạt động khơi gợi trước đó, chẳng hạn như brainstorming và document analysis. Các phản hồi và nhận xét được ghi lại để sử dụng trong các giai đoạn sau của việc khơi gợi yêu cầu.

• Use case: Business analysts cần thêm thông tin về các khía cạnh cụ thể của dự án. Thời gian là vàng.
• Designed to: Giúp stakeholders đưa ra các giải pháp rõ ràng và rõ ràng hơn, nhận được nhiều thông tin cùng một lúc.
• How to: Tập hợp đại diện từ stakeholder groups. Người hướng dẫn đặt câu hỏi để các thành viên trong nhóm thảo luận về các lĩnh vực quan tâm cụ thể và ghi lại các ý tưởng đã thảo luận.

Interviews

Một cách tuyệt vời để trích xuất dữ liệu quan trọng là thông qua các cuộc phỏng vấn. Các business analysts tham gia vào các cuộc phỏng vấn nhóm hoặc từng người một trong môi trường không chính thức hoặc chính thức để đưa ra các yêu cầu của dự án thông qua các câu hỏi hướng đến SME, các stakeholders và người dùng cuối. Bằng cách khám phá các ý kiến ​​​​khác nhau, các business analysts có được kiến ​​thức chuyên sâu về các yêu cầu.

• Use case: Có được cái nhìn sâu sắc từ một chuyên gia về chủ đề cụ thể (subject matter expert – SME).
• Designed to: Có được cái nhìn sâu sắc trực tiếp của các stakeholder về nhu cầu kinh doanh hoặc khả năng tồn tại của các giải pháp nhất định.
• How to: Tạo các câu hỏi cho phép SME cởi mở về các vấn đề đang được thảo luận. Các câu hỏi có thể được chia sẻ trước hoặc được thực hiện dưới dạng một cuộc trò chuyện. Người phỏng vấn nên ghi chép và chia sẻ chúng với SME để đảm bảo họ hiểu đúng quan điểm của SME.

Observation

Còn được gọi là theo dõi công việc, observation – quan sát là một kỹ thuật khơi gợi tuyệt vời giúp hiểu các yêu cầu dựa trên các quan sát liên quan đến quy trình và môi trường làm việc của các stakeholders. Những hiểu biết thực tế về quy trình làm việc thực tế làm cơ sở cho việc sửa đổi và cải tiến. Cách tiếp cận quan sát cho phép các business analysts gợi ra dữ liệu trong thế giới thực mà các phương pháp requirements elicitation khác không thể nắm bắt được.

• Use case: Khi dự án phát triển là phần mở rộng của quy trình làm việc hiện tại.
• Designed to: Cung cấp cái nhìn trực tiếp về cách các stakeholder thực hiện một quy trình cụ thể.
• Cách thực hiện: Việc quan sát có thể được tiến hành một cách thụ động – người điều phối quan sát công việc của các bên liên quan mà không làm gián đoạn – hoặc chủ động – người điều phối đặt câu hỏi về công việc khi nó đang được thực hiện. Trong cả hai trường hợp, người điều phối nên ghi chép và nhận phản hồi từ các stakeholder về thông tin thu thập được.

Prototyping

Một trong những giai đoạn quan trọng nhất của quy trình khơi gợi yêu cầu – prototyping cho phép chủ doanh nghiệp và người dùng cuối hình dung các mô hình ứng dụng thực tế trước khi chúng được phát triển lần cuối cùng. Việc tạo prototype giúp tạo ra phản hồi sớm và tăng cường sự tham gia của các stakeholder vào việc đưa ra yêu cầu.

• Use case: Khi các stakeholders không hiểu các yêu cầu kỹ thuật bằng văn bản và sẽ được hưởng lợi từ việc xem phiên bản của sản phẩm.
• Designed to: Thu thập phản hồi từ các non-technical stakeholders bằng cách cho họ xem một ví dụ mà họ có thể tương tác vật lý.
• How to: Lúc đầu, việc tạo prototypes có thể được thực hiện thông qua storyboard, interactive screen, virtual mock-up, navigation flow,… Phương pháp chính xác tùy thuộc vào dự án, nhưng nó thường là một quá trình lặp đi lặp lại được cải thiện dựa trên đầu vào. Khi có nhiều yêu cầu hơn, các prototypes chi tiết hơn sẽ được tạo ra để đảm bảo chúng đáp ứng được những mong đợi như đã ghi.

Requirements workshops

Đối với các dự án phức tạp, có nhiều stakeholders, workshops là một trong những phương pháp tiết kiệm tài nguyên nhất để đưa ra yêu cầu. Các cuộc hội thảo chuyên sâu, tập trung và hiệu quả cao có vai trò quan trọng trong việc đưa tất cả các bên tập hợp vào cùng một chỗ. Các sự kiện workshops giúp các SME và các stakeholders cộng tác, giải quyết xung đột và đi đến thỏa thuận.

• Use case: Khi không có nhiều thời gian và business need không rõ ràng.
• Designed to: Tập hợp stakeholders lại với nhau trong một môi trường có cấu trúc, dựa trên thời gian để đưa ra, tinh chỉnh và chỉnh sửa các yêu cầu. Các stakeholders có thể thảo luận và đưa ra ý kiến ​​đầu vào ngay lập tức về các business needs đã được xác định.
• How to: Đặt khung thời gian và chương trình làm việc cụ thể cho hội thảo. Bao gồm brainstorming, focus group và prototyping (nếu có) trong lịch trình. Sử dụng những thông tin này để hướng dẫn cuộc thảo luận và ghi lại ý kiến ​​đóng góp.

Surveys

Khi có nhiều SME và các stakeholders tham gia vào một dự án, các business analysts sẽ tiến hành một cuộc khảo sát để đưa ra các yêu cầu. Mọi người tham gia đều được phát một bảng câu hỏi để điền vào. Sau đó, các phản hồi sẽ được phân tích để tinh chỉnh các yêu cầu. Khảo sát ít tốn kém hơn so với các kỹ thuật gợi ý yêu cầu khác, dễ quản lý và có thể tạo ra cả kết quả định tính và định lượng.

• Use case: Khi các business analysts cần dữ liệu từ các nhóm lớn người tham gia.
• Designed to: Nhận được phản hồi khách quan từ nhiều nhóm khách hàng hoặc người dùng cuối.
• How to: Chọn người tham gia một cách khôn ngoan dựa trên các tiêu chí mong muốn. Đặt câu hỏi rõ ràng, không dẫn dắt người trả lời. Các câu hỏi có thể có một số lựa chọn hữu hạn hoặc có kết thúc mở. Để có kết quả tốt nhất, hãy cân nhắc mục tiêu của câu hỏi cũng như số lượng người trả lời để xác định cấu trúc tốt nhất cho phân tích phù hợp.

Như thường lệ, có thể sử dụng nhiều phương pháp khơi gợi yêu cầu khác nhau để tìm ra nhu cầu kinh doanh của một dự án. Ví dụ: một business analyst có thể đặt các câu hỏi về yêu cầu cụ thể trong một nhóm focus group, trong một brainstorming session hoặc trong observation. Business analyst cũng có thể tiến hành khảo sát trước requirements workshop hoặc tạo prototype để sử dụng trong quá trình quan sát. Biết được nên sử dụng elicitation techniques nào cho một dự án nhất định sẽ luôn đi kèm với kinh nghiệm.

Sau cùng, mục tiêu của việc sự khơi gợi các yêu cầu vẫn là xác định một cách thấu đáo các giả định, rủi ro và nhu cầu liên quan đến bất kỳ dự án nào. Theo dõi Cole và tham gia Khóa học IT Business Analyst tại Cole để cập nhật các kiến thức mới nhất về lập trình và khoa học dữ liệu.

> Xem thêm: Sự khơi gợi yêu cầu là gì (Phần 1)