Full Bộ Câu Hỏi Phỏng Vấn IT BA Đầy Đủ & Toàn Diện

Business Analyst là người phân tích nhu cầu, vấn đề của doanh nghiệp, làm rõ yêu cầu và chuyển hóa nhu cầu đó thành đặc tả giải pháp mà đội ngũ kỹ thuật có thể hiểu và triển khai.

• Thu thập, khơi gợi và làm rõ yêu cầu nghiệp vụ.
• Phân tích quy trình kinh doanh (Business Process).
• Xác định yêu cầu chức năng (Functional) và phi chức năng (Non-functional).
• Soạn thảo tài liệu đặc tả: BRD, SRS, User Story, Use Case...
• Thiết kế workflow, mô hình hóa quy trình.
• Cầu nối trao đổi giữa Developer, Tester, UI/UX và Khách hàng.
• Hỗ trợ giải đáp nghiệp vụ trong suốt vòng đời phát triển và hỗ trợ UAT.

Bạn có thể xem các tài liệu mà Business Analyst cần làm trong một dự án tại bài viết: Các tài liệu BA cần làm trong một dự án

Requirement là yêu cầu mà hệ thống/sản phẩm cần đáp ứng để giải quyết nhu cầu hoặc đạt mục tiêu kinh doanh.

• Business Requirement: Mục tiêu cấp cao mà doanh nghiệp muốn đạt được và lý do tại sao cần làm. Ví dụ: Giảm thời gian xử lý đơn hàng từ 30 phút xuống còn 10 phút.
• Functional Requirement: Hệ thống phải làm gì để phục vụ mục tiêu đó. Ví dụ: Hệ thống cho phép tạo đơn hàng, tự động tính tổng tiền, cập nhật trạng thái kho.

• Functional Requirement: Mô tả chức năng và hành vi của hệ thống (Hệ thống làm được gì). Ví dụ: Đăng nhập tài khoản, tạo đơn hàng mới.
• Non-functional Requirement: Tiêu chuẩn chất lượng và ràng buộc vận hành (Hệ thống hoạt động tốt như thế nào). Ví dụ: Response time dưới 3 giây, chịu tải 10.000 concurrent users, mật khẩu mã hóa SHA-256.

Theo chuẩn BABOK có 4 loại chính:

• Business Requirements: Mục tiêu chiến lược cấp cao của doanh nghiệp.
• Stakeholder Requirements: Nhu cầu cụ thể của từng nhóm người dùng liên quan.
• Solution Requirements: Yêu cầu giải pháp, gồm Functional (chức năng) và Non-functional (chất lượng).
• Transition Requirements: Yêu cầu chuyển giao tạm thời (data migration, đào tạo sử dụng).

Stakeholder là cá nhân, nhóm hoặc tổ chức có quyền tác động đến dự án hoặc chịu ảnh hưởng trực tiếp từ kết quả dự án. BA xác định Stakeholder thông qua việc phân tích vai trò phòng ban, mức độ quyền lực (Power) và mức độ quan tâm (Interest) để có chiến lược quản lý phù hợp.

AS-IS là hiện trạng quy trình đang vận hành; TO-BE là quy trình mong muốn sau khi cải tiến. BA bắt buộc phải phân tích AS-IS để nhìn rõ những điểm nghẽn (pain points), từ đó mới có cơ sở thiết kế mô hình TO-BE giải quyết triệt để vấn đề mà không làm xáo trộn vận hành.

• Interview: Phỏng vấn 1-1 với Stakeholder để đào sâu vấn đề.
• Workshop: Hội thảo tập hợp nhiều phòng ban để cùng thảo luận và chốt yêu cầu nhanh.
• Observation: Quan sát trực tiếp người dùng làm việc thực tế.
• Survey/Questionnaire: Khảo sát thu thập ý kiến diện rộng từ số đông.
• Document Analysis: Đọc và phân tích tài liệu quy trình, luật định hoặc hệ thống cũ.
• Prototyping: Dựng khung giao diện mẫu để người dùng hình dung và xác nhận.

Business Rule là các quy tắc, chính sách nghiệp vụ do tổ chức đặt ra mà phần mềm bắt buộc phải tuân theo. Ví dụ: Đơn hàng trên 10 triệu đồng cần Quản lý duyệt; Chỉ được hủy đơn khi trạng thái là "Chờ xử lý".

Business Process là chuỗi hoạt động có liên kết logic được thực hiện theo trình tự để đạt mục tiêu kinh doanh. BA thường dùng sơ đồ: Flowchart (lưu đồ cơ bản), BPMN (chuẩn quy trình chuyên sâu có phân chia swimlane) hoặc Activity Diagram.

Actor là thực thể bên ngoài tương tác trực tiếp với hệ thống để thực hiện một mục đích hoặc nhận kết quả. Actor không nhất thiết là con người, có thể là hệ thống bên thứ ba (Cổng thanh toán, ERP), thiết bị phần cứng hoặc tiến trình tự động (Cron job).

Precondition là điều kiện bắt buộc trước khi Use Case bắt đầu; Postcondition là kết quả đạt được sau khi Use Case hoàn tất. Ví dụ: Use Case "Hủy đơn" - Precondition là Đã đăng nhập và đơn hàng chưa thanh toán; Postcondition là Đơn đổi sang "Đã hủy" và tồn kho được hoàn lại.

Gồm: ID & Tên Use Case, Actor chính/phụ, Precondition, Luồng chính (Normal Flow), Luồng nhánh/ngoại lệ (Alternative & Exception Flows), Postcondition và Business Rules liên quan.

Là sơ đồ UML thể hiện mối quan hệ giữa các Actor và các chức năng (Use Case). Cách vẽ: Vẽ khung System Boundary, đặt Actor (hình người) bên ngoài, đặt Use Case (hình oval) bên trong và nối đường tương tác kèm các quan hệ include, extend.

Tìm hiểu thêm: Sơ đồ UML là gì? Tại sao BA lại cần biết?

Cấu trúc: As a [Role], I want [Feature], So that [Benefit]. Ví dụ: "Là khách hàng, tôi muốn đăng nhập bằng email để truy cập đơn cá nhân." Kèm theo luôn có tiêu chí nghiệm thu (Acceptance Criteria).

Là tập hợp các điều kiện và tiêu chí nghiệm thu cụ thể mà một User Story phải đáp ứng để được PO chấp nhận nghiệm thu (thường viết theo format Given - When - Then).

BPMN là bộ ký hiệu chuẩn quốc tế mô hình hóa quy trình nghiệp vụ. Vai trò: Giúp nghiệp vụ và kỹ thuật có tiếng nói chung, làm rõ trách nhiệm giữa các phòng ban thông qua các Swimlane.

• Sketch: Bản vẽ phác tay nhanh trên giấy.
• Wireframe: Bản bố cục đen trắng tập trung vào luồng và cấu trúc.
• Mockup: Bản dựng giao diện tĩnh hoàn chỉnh màu sắc, font chữ (UI).
• Prototype: Bản mô phỏng tương tác bấm chuyển màn hình như app thật.

• Waterfall: Tuyến tính, làm tuần tự (Yêu cầu → Thiết kế → Code → Test); khó đổi phạm vi, sản phẩm bàn giao ở cuối.
• Agile: Linh hoạt, chia thành các chu kỳ ngắn (1-4 tuần); phát hành sản phẩm và nhận phản hồi liên tục.

• Scrum: Làm việc theo khung Sprint cố định, có vai trò bắt buộc (PO, SM, Dev Team) và các sự kiện nghiêm ngặt.
• Kanban: Tối ưu luồng công việc liên tục (Flow), dùng bảng trực quan và giới hạn việc đang làm (WIP limit).

Gồm: Sprint Planning (lập kế hoạch Sprint), Daily Scrum (họp đứng 15 phút), Sprint Review (demo sản phẩm cho bên liên quan) và Sprint Retrospective (họp rút kinh nghiệm nội bộ).

• Product Owner (PO): Quản trị backlog và tối đa hóa giá trị sản phẩm.
• Scrum Master: Hướng dẫn thực hành Scrum và loại bỏ rào cản cho nhóm.
• Developers/Team: Đội ngũ kỹ sư trực tiếp lập trình, test và hoàn thiện sản phẩm.

Là tập hợp các điều kiện và bước thực hiện để kiểm chứng tính năng. Cấu trúc gồm: ID, Tiêu đề, Precondition, Test Data, Các bước thao tác (Steps), Kết quả mong đợi (Expected Result) và Kết quả thực tế (Actual Result).

Là tài liệu chiến lược kiểm thử: xác định phạm vi, nhân sự, lịch trình, công cụ và tiêu chí nghiệm thu. Cần có Test Plan để đảm bảo việc kiểm thử toàn diện, đúng tiến độ và kiểm soát rủi ro chất lượng.

Gồm: Bug ID/Title, Mức độ nghiêm trọng (Severity), Độ ưu tiên (Priority), Môi trường test, Các bước tái hiện (Steps to reproduce), Kết quả thực tế (Actual), Kết quả mong muốn (Expected) và bằng chứng đính kèm (Log, ảnh chụp).

Test là quá trình xác thực phần mềm hoạt động đúng nghiệp vụ và ổn định. Trong Waterfall, test nằm ở giai đoạn kế cuối sau khi code xong; trong Agile, test diễn ra liên tục song song trong từng Sprint.

Thường có: Mục tiêu dự án, Thuật ngữ (Glossary), Phạm vi (In/Out-of-scope), Luồng quy trình (Process Flow), Đặc tả tính năng (Use Case/User Story/Rules), Wireframe, Yêu cầu phi chức năng và Lịch sử phiên bản.

Áp dụng chiến lược "Keep Satisfied": Xin ý kiến phê duyệt trước các quyết định lớn, gửi báo cáo định kỳ ở mức tổng quan (High-level) súc tích và tránh làm phiền bằng các vấn đề kỹ thuật tiểu tiết.

Chia theo ma trận Power/Interest thành 4 nhóm: Quản lý chặt chẽ, Giữ hài lòng, Cung cấp thông tin đầy đủ, và Theo dõi tối thiểu. Phải quản lý vì họ nắm giữ ngân sách, phạm vi và quyết định sự thành bại dự án.

Là kỹ thuật xác định khoảng cách giữa AS-IS và TO-BE. Ví dụ: AS-IS là gõ tay thông tin từ Excel vào CRM; TO-BE là tự import từ Excel; GAP là chưa có tính năng đọc file và validate dữ liệu. BA xác định gap để đề xuất giải pháp.

Scope xác định ranh giới việc gì làm (In-scope) và việc gì không làm (Out-of-scope). BA kiểm soát bằng cách: viết rõ tiêu chí nghiệm thu, lấy sign-off chính thức, quản lý chặt Change Request và đánh giá tác động trước khi nhận yêu cầu mới.

Kỹ thuật chia độ ưu tiên: Must have (bắt buộc), Should have (nên có), Could have (có thì tốt), Won't have (chưa làm). Dùng để chốt phạm vi MVP và quản lý tiến độ bàn giao theo giai đoạn.

• User Story: Ngắn gọn, tập trung vào góc nhìn người dùng và giá trị mong muốn (phù hợp Agile thảo luận nhanh).
• Use Case: Chi tiết, tập trung vào tương tác từng bước giữa người dùng và hệ thống, có luồng rẽ nhánh và ngoại lệ.

API là phương thức giao tiếp giữa các hệ thống. IT BA cần hiểu: Endpoint URL, HTTP Methods (GET, POST, PUT, DELETE), Request/Response Body (JSON), Header, Params, Status Code và cơ chế xác thực.

• Authentication: Xác thực "Bạn là ai?" (Đăng nhập bằng mật khẩu, OTP, FaceID).
• Authorization: Phân quyền "Bạn được phép làm gì?" sau khi đã đăng nhập (Admin được xóa bài, User chỉ được đọc).

200 (Thành công), 201 (Tạo mới thành công), 400 (Client gửi sai định dạng), 401 (Chưa đăng nhập), 403 (Không có quyền), 404 (Không tìm thấy tài nguyên), 500 (Lỗi máy chủ nội bộ).

Mô hình 3 lớp: Presentation (Frontend UI), Business Logic (Backend API xử lý nghiệp vụ) và Data Layer (Cơ sở dữ liệu lưu trữ).

Frontend là giao diện người dùng; Backend là logic và cơ sở dữ liệu. BA cung cấp Wireframe/Screen Flow cho Frontend, cung cấp quy tắc nghiệp vụ/mapping dữ liệu cho Backend và kết nối hai bên về luồng API.

ERD là sơ đồ thực thể mô tả cấu trúc cơ sở dữ liệu. Gồm 3 quan hệ cơ bản: 1 - 1 (1 User có 1 Profile), 1 - N (1 Khách có nhiều Đơn hàng) và N - N (Nhiều Học viên tham gia nhiều Khóa học).

Nắm vững các truy vấn SQL cơ bản (SELECT, WHERE, JOIN, GROUP BY). Áp dụng để tự trích xuất dữ liệu kiểm tra lỗi, đối chiếu dữ liệu báo cáo và làm rõ cấu trúc lưu trữ cùng Dev.

Đánh số theo vX.Y: Tăng số Y khi sửa đổi nhỏ, tăng số X khi thay đổi lớn về phạm vi. Luôn có bảng Version History ghi rõ Ngày, Người sửa, Nội dung thay đổi và Người duyệt.

Quy tắc Semantic Versioning (MAJOR.MINOR.PATCH): Major tăng khi đổi kiến trúc không tương thích cũ, Minor tăng khi thêm tính năng mới, Patch tăng khi vá lỗi.

Lưu tập trung trên Confluence/SharePoint, chia thư mục theo module dự án, gắn trạng thái rõ ràng (Draft, In Review, Approved) và liên kết trực tiếp với các ticket phát triển.

>>> Nâng cấp kỹ năng làm BA với Khóa học ITBA

Sử dụng Jira quản lý Sprint và task, Confluence quản lý tài liệu đặc tả, Miro vẽ sơ đồ quy trình và Slack/Teams để trao đổi nhanh hàng ngày.

Dùng Figma khi cần thiết kế chi tiết phối hợp cùng UI Designer; dùng Balsamiq hoặc Draw.io để vẽ nhanh wireframe phác thảo luồng nghiệp vụ.

Ưu điểm: Nét vẽ tay trực quan, dựng nhanh, giúp khách hàng tập trung vào luồng logic thay vì soi xét màu sắc font chữ. Nhược điểm: Không thể hiện được bản vẽ chi tiết độ nét cao (Hi-Fi).

Dùng Confluence. Ưu điểm: Làm việc nhóm đồng thời tốt, lưu lịch sử sửa đổi rõ ràng, liên kết mượt mà với Jira. Nhược điểm: Phụ thuộc mạng và chi phí bản quyền doanh nghiệp.

Bao gồm: BPMN quy trình, Use Case Diagram, Activity Diagram, State Machine (vòng đời trạng thái đơn hàng), Sequence Diagram (gọi API) và ERD.

Gồm Unit Test, Integration Test, System Test và UAT. BA tham gia chính vào Functional Test nghiệp vụ và điều phối giai đoạn Kiểm thử chấp nhận của người dùng (UAT).

Có. BA kiểm thử dưới góc nhìn nghiệp vụ người dùng cuối để đảm bảo phần mềm giải quyết đúng bài toán kinh doanh trước khi giao cho khách hàng nghiệm thu.

Đối chiếu với tài liệu yêu cầu: Nếu sai lệch đặc tả đã thống nhất thì xác nhận là Bug để Dev sửa; nếu hệ thống chạy đúng tài liệu nhưng phát sinh thêm nhu cầu mới thì xếp vào Change Request.

Gồm: 1. Phân tích & dựng Wireframe; 2. Viết tài liệu đặc tả & chốt Sign-off; 3. Grooming truyền đạt yêu cầu cho Dev/QC; 4. Giải đáp vướng mắc trong lúc code; 5. Kiểm thử nghiệp vụ nội bộ; 6. Hỗ trợ khách hàng UAT.

Họp Review chốt phạm vi với Stakeholder, tổ chức Grooming chuyển giao yêu cầu cho Dev/QC, tạo task trên Jira và theo dõi giải đáp phát sinh.

BA nghiệm thu nội bộ trước khi khách hàng UAT. Khi có lỗi, BA dẫn chứng tiêu chí nghiệm thu đã thống nhất, trao đổi hỗ trợ và ghi nhận log lên Jira để Dev nắm tiến độ.

Giao tiếp linh hoạt & lắng nghe chủ động, Tư duy phản biện (Critical Thinking) tìm nguyên nhân gốc, và Sự nhạy bén về giá trị kinh doanh của sản phẩm.

Đảm bảo giải pháp phần mềm mang lại giá trị kinh doanh đo lường được cho doanh nghiệp và giải quyết đúng vấn đề của người dùng với nguồn lực tối ưu nhất.

Nghiên cứu đối thủ đầu ngành, đọc thuật ngữ chuẩn ngành (Glossary), phỏng vấn chuyên gia nghiệp vụ (SMEs) và vẽ lại luồng hành trình người dùng cốt lõi.

Làm rõ giá trị yêu cầu, đánh giá tác động (Impact Analysis) đến tiến độ/chi phí, trao đổi với PM/PO đề xuất chuyển sang phase sau hoặc đổi chỗ phạm vi; kích hoạt Change Request nếu bắt buộc làm ngay.

Không vội đưa giải pháp mà đào sâu pain point: Đang quản lý bằng gì? Thất thoát số liệu ở đâu? Khó khăn lớn nhất là gì? Chỉ số cụ thể muốn cải thiện là gì?

Kiểm tra lại số liệu giao dịch giờ cao điểm thực tế, làm việc với Architect để nắm giới hạn kỹ thuật và chi phí hạ tầng, đề xuất phương án hàng đợi bất đồng bộ (Queue) tối ưu chi phí.

Đề xuất phân quyền theo trường dữ liệu (Field-level): Sales được sửa thông tin liên hệ phụ; khóa trường pháp nhân quan trọng (MST) kèm quy trình duyệt; bật Audit Log lưu toàn bộ lịch sử sửa đổi.

Tìm hiểu mục tiêu đằng sau từng bên, đối chiếu với mục tiêu chiến lược của dự án, phân tích ưu nhược điểm (Trade-off) và tổ chức họp chung để cấp có thẩm quyền quyết định.

Khảo sát dựa trên dữ liệu định lượng (thời gian làm, số lỗi nhập tay) để chỉ ra điểm nghẽn thực tế; giải thích hệ thống mới giúp giảm bớt việc thủ công cho chính họ.

Chuẩn bị sẵn phương án/wireframe mẫu để họ chọn nhanh A/B; rút ngắn họp xuống 15 phút tập trung điểm trọng yếu; gửi email xác nhận với điều khoản mặc định nếu sau X ngày không phản hồi.

Quan sát người dùng thao tác thực tế (Shadowing/Usability test), rà soát số bước thao tác, tối ưu lại UX/UI và thử nghiệm bản mẫu với nhóm nhỏ trước khi sửa code.

Kiểm tra nghiệp vụ dồn cục cuối tháng (chốt sổ, lương, batch job), phân tích traffic cao điểm và phối hợp Tech kiểm tra tải database để đề xuất chạy đêm hoặc auto-scaling.

BA Outsource: Bám sát scope hợp đồng, kiểm soát chặt Change Request, chịu áp lực deadline và chi phí. BA Product: Gắn bó dài hạn với sản phẩm, tối ưu trải nghiệm và đo lường chỉ số tăng trưởng người dùng (Retention, ROI).

PO: Chịu trách nhiệm về định hướng sản phẩm, giá trị ROI và quyết định thứ tự ưu tiên Backlog. BA: Phân tích chi tiết quy trình, viết User Story/AC và giải đáp nghiệp vụ cho Dev hàng ngày.

Dùng Ma trận truy vết yêu cầu (Traceability Matrix), quản lý tập trung từ điển Business Rules và luôn rà soát chéo các module liên quan trước khi chốt phiên bản.

Dựa trên 6 tiêu chuẩn: Đầy đủ (Complete), Rõ ràng không hiểu nước đôi (Unambiguous), Nhất quán (Consistent), Khả thi (Feasible), Kiểm thử được (Testable) và Truy vết được (Traceable).

Thu thập thông tin: Ai bị, tính năng nào, thời điểm xảy ra? Lấy các bước tái hiện và ảnh lỗi, tự tái hiện trên môi trường test rồi báo cho Tech ưu tiên xử lý.

Quy trình 4 bước: 1. Tìm hiểu mục tiêu tổng thể dự án; 2. Xác định danh sách Stakeholders chính; 3. Khảo sát hiện trạng (AS-IS) và xây dựng định hướng (TO-BE); 4. Thống nhất phương thức làm việc và phạm vi MVP ban đầu với toàn đội ngũ.

(Gợi ý mẫu): "Em từng tham gia vào 2 lĩnh vực chính là E-commerce và CRM. Trực tiếp phụ trách các module quan trọng như luồng Giỏ hàng & Thanh toán trực tuyến, quản lý Lead khách hàng và tự động xuất báo cáo doanh số."

(Gợi ý mẫu): "Dự án gần nhất của em gồm 8 người: 1 PM, 1 BA (là em), 4 Dev, 1 QC và 1 Designer. Em phụ trách độc lập việc khảo sát yêu cầu, viết toàn bộ SRS/User Story và đồng hành nghiệm thu sản phẩm từ đầu đến khi ra mắt."

Khó khăn lớn nhất là yêu cầu khách hàng thay đổi liên tục. Em tháo gỡ bằng cách họp chốt Scope hàng tuần và áp dụng quy trình Change Request rõ ràng, giúp dự án giữ vững tiến độ và bàn giao đúng cam kết.

• Khơi gợi yêu cầu (Elicitation): 8/10 điểm - Nhờ lắng nghe chủ động và đặt câu hỏi trúng đích.
• Phân tích & hệ thống hóa giải pháp: 7.5/10 điểm - Có tư duy logic mạch lạc.
• Viết tài liệu đặc tả (Documentation): 8/10 điểm - Trình bày chuẩn hóa, dễ hiểu cho cả Dev lẫn Khách hàng.

Áp dụng bộ câu hỏi 5W1H và dùng sơ đồ/wireframe trực quan để cùng xác nhận. Khi có bất đồng thuật ngữ, em chủ động diễn giải sang ngôn ngữ đời thường gần gũi đi kèm các ví dụ thực tế.

Khai thác khoảng 70% tính năng: quản lý Backlog, theo dõi Sprint Board, quản lý Release. Ấn tượng nhất là Jira Automation giúp tự động cập nhật trạng thái công việc và tiết kiệm thời gian cho cả team.

Rất ít khi phải hỏi lại, vì tài liệu luôn có sẵn Test Data mẫu, các bước thao tác cụ thể và kết quả mong đợi rõ ràng cho cả trường hợp thành công lẫn lỗi ngoại lệ.