IT Business Analyst - Phân Tích Việc Khơi Gợi Yêu Cầu và UML và Tư duy thiết kế trong BA

Đăng ký tham gia

Là một IT Business Analyst (BA), một trong những nhiệm vụ quan trọng nhất của chúng ta chính là khơi gợi yêu cầu từ khách hàng. Đây không đơn thuần là việc đặt câu hỏi và ghi chú lại, mà là một nghệ thuật cần sự thấu hiểu, giao tiếp khéo léo và phương pháp tiếp cận hợp lý. Nếu làm không tốt, dự án sẽ đi chệch hướng, kéo dài thời gian, phát sinh chi phí và quan trọng nhất là không đáp ứng được nhu cầu thực sự của người dùng. Hãy cùng tìm hiểu các bước chi tiết từ lập kế hoạch đến triển khai và phần Q&A giúp bạn hiểu rõ hơn về cách khơi gợi yêu cầu hiệu quả.

1. Lập Kế Hoạch Khơi Gợi Yêu Cầu

Trước khi nhảy ngay vào buổi họp với khách hàng, BA cần chuẩn bị kỹ lưỡng để việc khơi gợi yêu cầu diễn ra suôn sẻ.

a. Xác Định Mục Tiêu

Trước tiên, BA cần làm rõ mục tiêu của việc thu thập yêu cầu. Bạn cần trả lời các câu hỏi:

  • Dự án này nhằm giải quyết vấn đề gì?

  • Đối tượng sử dụng hệ thống là ai?

  • Yêu cầu cụ thể mà chúng ta cần thu thập là gì?

  • Những ràng buộc nào cần lưu ý (thời gian, ngân sách, công nghệ)?

b. Xác Định Đối Tượng Tham Gia

Không phải lúc nào chỉ có một người đưa ra yêu cầu. Trong doanh nghiệp có nhiều nhóm người dùng khác nhau, mỗi nhóm có góc nhìn riêng về hệ thống:

  • Stakeholders (các bên liên quan): Ban lãnh đạo, quản lý cấp trung.

  • End Users (người dùng cuối): Nhân viên trực tiếp sử dụng hệ thống.

  • Technical Team (đội kỹ thuật): Những người hiện thực hóa yêu cầu thành sản phẩm.

  • Regulators (cơ quan pháp lý, kiểm soát): Nếu hệ thống cần tuân thủ quy định cụ thể.

c. Chọn Phương Pháp Khơi Gợi Yêu Cầu

Dựa trên tính chất dự án và đối tượng tham gia, BA cần chọn phương pháp phù hợp, có thể là phỏng vấn trực tiếp, khảo sát, workshop, mô phỏng tình huống...vv

2. Các Bước Khơi Gợi Yêu Cầu

Sau khi lập kế hoạch xong, bước tiếp theo là triển khai quá trình thu thập yêu cầu. Đây là giai đoạn quan trọng quyết định sự thành công của dự án.

a. Xây Dựng Mối Quan Hệ

Một BA giỏi không chỉ hỏi mà còn phải lắng nghe và tạo niềm tin với khách hàng. Nếu khách hàng cảm thấy thoải mái, họ sẽ chia sẻ nhiều thông tin hữu ích hơn. Hãy nhớ:

  • Dùng ngôn ngữ thân thiện, dễ hiểu.

  • Đặt câu hỏi mở để khách hàng có cơ hội giải thích.

  • Không phán xét mà luôn tìm cách hiểu sâu vấn đề của họ.

b. Sử Dụng Kỹ Thuật Khơi Gợi Yêu Cầu

Dưới đây là một số kỹ thuật phổ biến giúp BA thu thập yêu cầu hiệu quả:

  1. Phỏng Vấn (Interviews): Đối thoại trực tiếp với từng bên liên quan để hiểu mong muốn của họ.

  2. Khảo Sát (Surveys/Questionnaires): Nếu có nhiều người tham gia, khảo sát giúp thu thập ý kiến nhanh chóng.

  3. Workshop (Hội Thảo): Tổ chức các buổi họp nhóm để thảo luận yêu cầu theo cách tập trung.

  4. Quan Sát (Observation): Theo dõi trực tiếp cách người dùng làm việc để hiểu những điểm vướng mắc.

  5. Prototyping (Dựng Mô Hình): Dựng mô hình hệ thống sơ bộ để người dùng trải nghiệm và phản hồi.

  6. Use Case & User Stories: Xây dựng các tình huống thực tế giúp định hình rõ ràng yêu cầu.

c. Ghi Chép & Xác Nhận Yêu Cầu

Sau khi thu thập thông tin, BA cần hệ thống lại dữ liệu và xác nhận với khách hàng:

  • Viết lại yêu cầu một cách rõ ràng.

  • Đưa vào tài liệu SRS (Software Requirements Specification) hoặc BRD (Business Requirement Document).

  • Gửi lại khách hàng để họ kiểm tra và xác nhận.

3. Q&A - Giải Đáp Một Số Tình Huống Phổ Biến

Q1: Nếu khách hàng không biết họ muốn gì thì sao?

Rất nhiều khách hàng chỉ biết vấn đề họ gặp phải nhưng không biết cách giải quyết. Trong trường hợp này, hãy dùng phương pháp 5 Why’s (hỏi “Tại sao?” 5 lần) để đào sâu vấn đề gốc rễ. Ngoài ra, bạn có thể đề xuất các giải pháp dựa trên kinh nghiệm của mình.

Q2: Nếu khách hàng đưa ra yêu cầu không khả thi?

Không phải yêu cầu nào cũng thực hiện được ngay. Hãy giải thích rõ lý do bằng dữ liệu cụ thể, đề xuất giải pháp thay thế và cùng khách hàng thảo luận để tìm phương án phù hợp hơn.

Q3: Nếu các bên liên quan có ý kiến trái ngược nhau?

Trường hợp này rất phổ biến. Hãy đóng vai trò trung gian, tổ chức các buổi họp để tất cả cùng thảo luận và tìm ra điểm chung. Nếu cần, có thể sử dụng MoSCoW Prioritization để xác định mức độ ưu tiên của yêu cầu.

Q4: Làm sao để tránh yêu cầu thay đổi liên tục?

Hãy xây dựng Scope Statement ngay từ đầu để giới hạn phạm vi dự án. Ngoài ra, có thể áp dụng Change Control Process, nơi mọi thay đổi phải được đánh giá và phê duyệt trước khi thực hiện.

Q5: Nếu khách hàng không hợp tác?

Một số khách hàng có thể ít quan tâm đến dự án hoặc không sẵn sàng dành thời gian làm việc với BA. Khi đó, hãy chủ động sắp xếp các buổi họp ngắn, tận dụng các kỹ thuật trực quan như prototyping để thu hút sự chú ý và giữ liên lạc thường xuyên.

Khơi gợi yêu cầu từ khách hàng không chỉ đơn giản là ghi chép thông tin, mà còn là một quá trình tương tác, phân tích và xử lý thông tin một cách thông minh. Một BA giỏi không chỉ giúp dự án đi đúng hướng mà còn tạo ra giá trị thực sự cho khách hàng. Hy vọng bài viết này giúp bạn hiểu rõ hơn về nghệ thuật thu thập yêu cầu và áp dụng hiệu quả trong công việc thực tế của mình!

Phân Tích UML và Tư Duy Thiết Kế trong Business Analysis

1. Giới Thiệu về UML và Tư Duy Thiết Kế trong BA

Trong lĩnh vực Phân Tích Kinh Doanh (Business Analysis - BA), mô hình hóa yêu cầu (Requirements Modeling) đóng vai trò cốt lõi giúp chuyển đổi nhu cầu nghiệp vụ thành các mô tả kỹ thuật dễ hiểu đối với đội ngũ phát triển. Một trong những công cụ hữu ích nhất hỗ trợ BA trong công việc này chính là UML (Unified Modeling Language). UML không chỉ giúp trực quan hóa hệ thống mà còn giúp tạo ra các tài liệu mang tính chuẩn hóa, hỗ trợ việc giao tiếp hiệu quả giữa các bên liên quan.

UML cung cấp một tập hợp các sơ đồ để biểu diễn nhiều khía cạnh khác nhau của hệ thống, từ hành vi đến cấu trúc. Đối với BA, việc hiểu rõ và áp dụng UML đúng cách giúp dễ dàng diễn đạt các yêu cầu, tối ưu hóa quy trình phân tích và thiết kế hệ thống.

2. Requirements Modeling và UML

Mô hình hóa yêu cầu (Requirements Modeling) là quá trình chuyển đổi các yêu cầu của khách hàng thành một dạng thức trực quan, dễ hiểu và dễ triển khai. UML cung cấp nhiều loại sơ đồ hữu ích để BA thực hiện nhiệm vụ này, trong đó có thể kể đến:

  • Use Case Diagram: Giúp mô tả các chức năng chính của hệ thống, các tác nhân (actors) và mối quan hệ giữa chúng.

  • Class Diagram: Biểu diễn cấu trúc dữ liệu của hệ thống thông qua các lớp (class), thuộc tính (attribute) và phương thức (method).

  • Sequence Diagram: Minh họa trình tự các bước tương tác giữa các thành phần trong hệ thống.

  • Activity Diagram: Thể hiện luồng công việc và các hoạt động diễn ra trong một quy trình nghiệp vụ.

Nhờ UML, các BA có thể xác định rõ ràng các chức năng chính, thiết kế quy trình làm việc và đảm bảo rằng hệ thống cuối cùng đáp ứng đúng mong đợi của doanh nghiệp.

3. Data Objects và IPO

Một hệ thống thông tin không thể tồn tại nếu không có dữ liệu. Trong quá trình phân tích, các Data Objects (đối tượng dữ liệu) đóng vai trò quan trọng giúp định nghĩa các thực thể trong hệ thống, chẳng hạn như khách hàng, đơn hàng, sản phẩm, nhân viên, v.v.

Khi phân tích quy trình làm việc và cách dữ liệu được xử lý, mô hình IPO (Input - Process - Output) giúp BA xác định luồng dữ liệu như sau:

  • Input (Dữ liệu đầu vào): Những thông tin hệ thống nhận được từ người dùng hoặc các nguồn bên ngoài.

  • Process (Xử lý dữ liệu): Các bước xử lý, tính toán hoặc biến đổi dữ liệu.

  • Output (Kết quả đầu ra): Dữ liệu được xử lý và hiển thị cho người dùng hoặc gửi đến các hệ thống khác.

Việc nắm vững cách thiết kế dữ liệu và cách dữ liệu luân chuyển trong hệ thống giúp BA tạo ra các mô hình hiệu quả hơn.

4. Các Sơ Đồ Quan Trọng trong BA

4.1. Context Diagram (Sơ Đồ Ngữ Cảnh)

Sơ đồ này giúp BA hình dung cách hệ thống tương tác với các tác nhân bên ngoài (external entities). Context Diagram đơn giản hóa hệ thống bằng cách chỉ tập trung vào luồng dữ liệu chính, giúp dễ dàng giao tiếp với các bên liên quan không có nền tảng kỹ thuật.

4.2. ORD (Object Relationship Diagram)

ORD giúp biểu diễn mối quan hệ giữa các đối tượng dữ liệu trong hệ thống. Đây là một dạng sơ đồ mở rộng từ Class Diagram, tập trung vào cách các thực thể liên kết với nhau thông qua các ràng buộc và quan hệ.

4.3. Swimlane Diagram

Swimlane Diagram được sử dụng để mô tả quy trình nghiệp vụ theo từng vai trò cụ thể. Mỗi "lane" đại diện cho một phòng ban, nhóm hoặc cá nhân, giúp BA xác định rõ ai chịu trách nhiệm cho từng bước trong quy trình.

4.4. State Diagram

State Diagram giúp theo dõi trạng thái của một thực thể hoặc đối tượng trong hệ thống từ lúc bắt đầu đến khi kết thúc. Đây là một công cụ quan trọng trong việc phân tích hành vi của hệ thống.

4.5. Activity Diagram

Activity Diagram giúp biểu diễn luồng công việc, luồng quyết định, các bước thực hiện trong một quy trình nghiệp vụ. Nó giúp mô tả chi tiết từng bước và quyết định trong quá trình thực hiện một tác vụ.

5. Cách Viết Tài Liệu Cho Một Dự Án

Khi một dự án phần mềm được triển khai, tài liệu đóng vai trò rất quan trọng để đảm bảo sự thống nhất trong hiểu biết giữa các bên. Một tài liệu BA chuẩn cần bao gồm các phần:

  1. Tổng quan dự án: Mô tả về mục tiêu, phạm vi và các bên liên quan.

  2. Mô tả nghiệp vụ (Business Requirements): Các yêu cầu từ phía doanh nghiệp.

  3. Yêu cầu chức năng (Functional Requirements): Các tính năng cụ thể mà hệ thống phải có.

  4. Yêu cầu phi chức năng (Non-functional Requirements): Hiệu suất, bảo mật, khả năng mở rộng, tính khả dụng.

  5. Mô hình UML và sơ đồ hệ thống: Bao gồm các sơ đồ như Use Case, Class, Activity, Sequence, v.v.

  6. Quy trình vận hành: Mô tả cách hệ thống hoạt động trong thực tế.

  7. Danh sách các bên liên quan (Stakeholders): Ai chịu trách nhiệm cho từng phần trong dự án.

Việc viết tài liệu rõ ràng, mạch lạc không chỉ giúp đội ngũ phát triển hiểu đúng yêu cầu mà còn giúp khách hàng dễ dàng theo dõi tiến độ và xác nhận tính chính xác của hệ thống.

ORD LÀ GÌ, TẠI SAO LẠI CẦN THIẾT VỚI BUSINESS ANALYST?

Viết tắt của cụm từ Object Relationship Diagram, ORD là mô hình mối quan hệ tĩnh giữa các đối tượng trong hệ thống. Một đối tượng có thể được mô tả như một thể hiện của một thực thể cụ thể trong hệ thống.

Vậy đối tượng (object) là gì?, là một thực thể cụ thể trong thế giới thực. Trong phần mềm những thông tin gì cần được quản lý thì đó gọi là một đối tượng (object) trong hệ thống.
Vậy một đối tượng trong hệ thống là gì?, là một thông tin gì đó mà ta muốn quản lý.

Tại sao ORD lại quan trọng trong tài liệu SRS?
- Thứ 1: ORD giúp Stakeholders hình dung về hệ thống dễ dàng, trực quan hơn.
- Thứ 2: ORD chỉ ra rằng hệ thống cần lưu trữ bao nhiêu đối tượng (object).
- Thứ 3: ORD giúp stakeholders hiểu được mối quan hệ giữa các đối tượng (object) trong hệ thống.
- Thứ 4: ORD chỉ ra sự tương tác giữa Actors với Objects trong hệ thống.
- Cuối cùng: ORD cũng thể hiện mối liên hệ của hệ thống với những hệ thống khác.

Để vẽ được ORD hoàn chỉnh bạn cần phải hiểu được hệ thống, biết hệ thống cần lưu trữ những thông tìn gì, mối quan hệ giữa các thông tin đó ra sao.
Ngoài ra bạn cần xác định được rõ các Actors và tương tác của Actors trong hệ thống.

Cách dễ dàng nhất để vẽ ORD chuẩn chỉnh, ta nên dùng Visio. Visio dễ dùng, tiện lợi và chỉnh sửa dễ dàng, đồng thời cũng thân thiện với các bạn hơn.

UML và tư duy thiết kế đóng vai trò quan trọng trong công việc của BA. Việc sử dụng UML một cách linh hoạt giúp BA mô tả yêu cầu một cách chính xác, trực quan, đồng thời hỗ trợ tốt cho việc phát triển phần mềm. Các sơ đồ như Context Diagram, ORD, Swimlane, State và Activity Diagram giúp minh họa rõ ràng quy trình và cấu trúc hệ thống. Cuối cùng, việc viết tài liệu chi tiết và đầy đủ giúp đảm bảo sự thành công của dự án. BA không chỉ là cầu nối giữa doanh nghiệp và đội ngũ kỹ thuật mà còn là người dẫn dắt tư duy thiết kế để tạo ra những hệ thống hiệu quả và phù hợp với nhu cầu thực tế.

Giảng viên

  • Nguyễn Bá Phú

    Chuyên gia IT Business Analyst

    Hơn 10 năm kinh nghiệm trong lĩnh vực IT BA

    Hơn 3 năm trong lĩnh vực giảng dạy/đào tạo IT BA

    Từng tham gia làm IT BA trong các tổ chức Vinfast, Fsoft, VNPay

    Hiện đang làm IT BA tại TP Bank

Đăng ký học

Học phí

499.000đ

2.000.000đ

-76%

Thanh toán