Từ điển thuật ngữ BA

Tiêu chí Chấp nhận

Điều kiện cụ thể mà một user story hoặc requirement phải đáp ứng để được chấp nhận.

Sơ đồ hoạt động

Sơ đồ UML mô tả luồng công việc theo thứ tự thời gian, mạnh ở chỗ có rẽ nhánh điều kiện, có bước chạy song song và có nhiều vai trò cùng tham gia một quy trình.

Cách làm phần mềm linh hoạt theo Tuyên ngôn Agile

Tập hợp giá trị và nguyên tắc trong Tuyên ngôn Agile 2001, ưu tiên phần mềm chạy được và phản hồi nhanh với thay đổi. Bản thân Agile là tư duy, còn Scrum hay Kanban là khung làm việc cụ thể.

Tác tử AI

Hệ thống dùng mô hình ngôn ngữ để tự chọn công cụ và chạy nhiều bước tới một mục tiêu, thay vì chỉ trả lời một câu hỏi. Đổi lại, nó cần hạn mức, log đầy đủ và điểm dừng cho người duyệt.

Quản trị AI

Bộ quy định nội bộ về việc ai được dùng AI vào việc gì, dữ liệu nào được đưa ra ngoài, và ai chịu trách nhiệm khi đầu ra sai. Ở Việt Nam nó gắn thẳng với luật bảo vệ dữ liệu cá nhân.

Giao diện lập trình ứng dụng

Cách hai phần mềm nói chuyện với nhau theo một hợp đồng đã thoả thuận: gửi gì, nhận gì, lỗi thì báo ra sao. BA không cần code nhưng phải đọc hiểu hợp đồng đó.

Trí tuệ nhân tạo

Tên gọi chung cho các hệ thống máy tính làm được những việc trước đây phải cần người: đọc hiểu, phân loại, dự đoán, tạo nội dung. Với BA, câu hỏi đáng tiền là nó chạy theo luật cứng hay theo xác suất.

Quy trình hiện tại

Bản mô tả quy trình đang chạy thật, kèm thời gian, số lượng và điểm tắc. Điểm mấu chốt là ghi đúng thực tế chứ không phải chép lại quy định nội bộ cho đẹp.

Giả định

Điều được coi là đúng để lập kế hoạch và viết yêu cầu, nhưng chưa được xác nhận. Ghi ra thì thành rủi ro có tên; không ghi thì thành cuộc cãi nhau ở tuần thứ mười.

Làm mịn backlog

Hoạt động liên tục làm rõ, chẻ nhỏ và ước lượng các hạng mục trong Product Backlog để chúng đủ sẵn sàng cho sprint tới. Tên cũ Grooming đã bị bỏ khỏi Scrum Guide.

Kiểm thử hộp đen

Cách kiểm thử chỉ dựa vào đầu vào và đầu ra theo yêu cầu, không cần biết bên trong code viết thế nào. Đây là kiểu test mà QC và người dùng nghiệp vụ làm hằng ngày.

Lỗi phần mềm

Cách gọi dân dã của một lỗi trong phần mềm khiến hệ thống chạy sai so với mong đợi. Trong tài liệu chuẩn thì từ chính xác là defect, còn bug là từ cả team dùng hằng ngày.

Biểu đồ đốt việc

Đồ thị cho thấy khối lượng công việc còn lại giảm dần theo thời gian trong sprint hoặc release. Công cụ để team tự soi mình, không phải bảng chấm điểm cho quản lý.

Phân tích nghiệp vụ

Hoạt động tìm ra nhu cầu thật của tổ chức và đề xuất giải pháp mang lại giá trị, theo định nghĩa của IIBA. Nó là một việc chứ không phải một chức danh, nên PO, PM hay trưởng phòng đều đang làm.

Cẩm nang kiến thức phân tích nghiệp vụ, phiên bản 3

Bộ chuẩn nghề do IIBA phát hành, gom công việc của BA thành 6 knowledge area, 30 task và khoảng 50 kỹ thuật. Đây là tài liệu gốc cho mọi kỳ thi ECBA, CCBA, CBAP.

Mô hình sáu khái niệm cốt lõi của phân tích nghiệp vụ

Sáu khái niệm Change, Need, Solution, Stakeholder, Value, Context tạo thành bộ khung tư duy của BABOK v3. Sáu cái gắn chặt nhau, đổi một cái là phải xem lại năm cái còn lại.

Lập kế hoạch và giám sát công việc phân tích

Knowledge area lo việc lập kế hoạch cho chính công việc của BA: làm theo cách nào, ai tham gia, ai duyệt, tài liệu lưu ở đâu. Nó điều phối năm vùng còn lại của BABOK v3.

Chuyên viên phân tích nghiệp vụ

Người đứng giữa bên có vấn đề và bên xây giải pháp: đào ra nhu cầu thật, mô tả lại thành thứ dev và QC làm được, rồi bám tới lúc hệ thống chạy thật. Ở Việt Nam chức danh này phủ rất rộng.

Luận chứng đầu tư dự án

Tài liệu lập luận vì sao nên chi tiền cho một dự án: vấn đề đang tốn bao nhiêu, các phương án, chi phí, lợi ích ước tính và rủi ro. Đây là thứ quyết định dự án có được duyệt hay không.

Ký hiệu và Mô hình Quy trình Nghiệp vụ

Tiêu chuẩn quốc tế để mô hình hóa quy trình nghiệp vụ bằng ký hiệu đồ họa.

Tái thiết kế quy trình nghiệp vụ

Thiết kế lại quy trình từ gốc để đạt bước nhảy về chi phí, tốc độ hoặc chất lượng, thay vì chỉnh sửa dần. Đụng tới cả cơ cấu tổ chức nên rủi ro cao và cần lãnh đạo đứng tên.

Yêu cầu nghiệp vụ

Tầng yêu cầu cao nhất, nói vì sao doanh nghiệp bỏ tiền làm dự án này — mục tiêu, lợi ích, con số phải đạt. Do lãnh đạo hoặc chủ đầu tư phát biểu, không phải người dùng cuối.

Tài liệu Yêu cầu Nghiệp vụ

Tài liệu mô tả chi tiết các yêu cầu nghiệp vụ của dự án, bao gồm mục tiêu, phạm vi, chức năng và ràng buộc.

Quy tắc nghiệp vụ

Chính sách hoặc quy định của doanh nghiệp quyết định điều gì được phép, điều gì bị cấm và tính toán ra sao — tồn tại độc lập với phần mềm, phần mềm chỉ là nơi thực thi nó.

Chứng chỉ năng lực phân tích nghiệp vụ bậc trung

Bậc giữa của IIBA, dành cho BA đã có khoảng 3.750 giờ làm nghề. Đây là chứng chỉ ít người chọn nhất trong ba bậc, và có lý do khá thực tế cho chuyện đó.

Chứng chỉ chuyên gia phân tích nghiệp vụ cấp cao

Chứng chỉ cấp cao nhất trong ba bậc nền của IIBA, đòi khoảng 7.500 giờ làm BA trong 10 năm gần nhất. Đề thi là các tình huống dài, đọc kỹ đề còn khó hơn nhớ lý thuyết.

Yêu cầu thay đổi

Đề nghị chính thức thay đổi phạm vi, chức năng hoặc tài liệu đã chốt, kèm phân tích tác động về thời gian, chi phí và rủi ro trước khi có người đủ thẩm quyền phê duyệt.

Trợ lý hội thoại

Giao diện hội thoại trả lời người dùng, từ cây nút bấm đơn giản tới hệ chạy trên mô hình ngôn ngữ. Phần khó nhất khi thiết kế không nằm ở câu trả lời, mà ở lúc phải chuyển sang người thật.

Sơ đồ lớp

Sơ đồ UML mô tả các lớp đối tượng trong thiết kế hướng đối tượng: thuộc tính, hành vi và quan hệ giữa chúng. Dev vẽ là chính, nhưng BA cần đọc được để soi quy tắc nghiệp vụ.

Ràng buộc

Giới hạn mà giải pháp buộc phải nằm trong: ngân sách, thời gian, công nghệ có sẵn, quy định pháp lý, chính sách công ty. Không phải thứ để thương lượng, mà là khung để thiết kế.

Sơ đồ ngữ cảnh

Sơ đồ một trang đặt hệ thống ở giữa và các bên trao đổi dữ liệu với nó xung quanh. Vẽ trong mười lăm phút, dùng để chốt ranh giới phạm vi và liệt kê danh sách tích hợp.

Cửa sổ ngữ cảnh

Lượng token tối đa mà mô hình đọc được trong một lượt, tính cả chỉ dẫn, tài liệu bạn dán vào, lịch sử hội thoại và cả câu trả lời. Vượt ngưỡng thì phần cũ bị cắt đi, và mô hình quên.

Khách hàng

Bên mua và trả tiền cho sản phẩm, người ký hợp đồng và nghiệm thu. Trong dự án phần mềm doanh nghiệp, khách hàng và người dùng cuối thường là hai nhóm khác nhau.

Bản đồ hành trình khách hàng

Sơ đồ trải các chặng mà một người đi qua khi tương tác với sản phẩm hay dịch vụ, kèm việc họ làm, cảm xúc và điểm đau ở từng chặng, để tìm ra chỗ đáng sửa trước.

Hệ thống quản lý quan hệ khách hàng

Nơi công ty giữ toàn bộ dữ liệu và lịch sử tương tác với khách hàng — từ lead lạ tới hợp đồng và hậu mãi — thay vì để nó nằm trong Zalo cá nhân của từng bạn sales.

Họp nhanh mỗi ngày

Buổi họp 15 phút mỗi ngày của Developers để soi tiến độ so với Sprint Goal và chỉnh lại kế hoạch cho 24 giờ tới. Không phải buổi báo cáo tiến độ cho quản lý.

Từ điển dữ liệu

Bảng liệt kê từng trường dữ liệu của hệ thống: tên, kiểu, độ dài, bắt buộc hay không, giá trị hợp lệ và ý nghĩa nghiệp vụ. Tài liệu ít hào nhoáng nhưng được mở ra nhiều nhất.

Sơ đồ luồng dữ liệu

Sơ đồ theo dõi đường đi của dữ liệu trong hệ thống: vào từ đâu, được xử lý ở đâu, lưu vào kho nào. Phân cấp theo tầng, bắt đầu từ context diagram rồi tách dần.

Chuyển đổi dữ liệu

Đưa dữ liệu từ hệ thống cũ sang hệ thống mới: ánh xạ trường, làm sạch, chạy thử, đối soát rồi cutover. Nghe là việc kỹ thuật, nhưng người phải giải thích số liệu lệch lại là BA.

Khiếm khuyết phần mềm

Chỗ sai nằm trong code, cấu hình hoặc tài liệu khiến hệ thống không đáp ứng đúng yêu cầu đã chốt. Đây là từ chuẩn dùng trong báo cáo và biên bản nghiệm thu, thay cho chữ bug nói miệng.

Vòng đời của lỗi

Chuỗi trạng thái mà một defect đi qua từ lúc được phát hiện tới lúc đóng: New, Assigned, Open, Fixed, Retest, Verified, Closed, cộng các nhánh rẽ như Reopen, Rejected hay Deferred.

Tiêu chuẩn hoàn thành

Danh sách điều kiện mà mọi hạng mục phải thỏa mãn thì mới được coi là xong. Áp dụng cho tất cả item trong sản phẩm, và là cam kết đi kèm artifact Increment trong Scrum.

Tiêu chuẩn sẵn sàng làm

Bộ điều kiện tối thiểu để một hạng mục backlog được đưa vào sprint: đủ rõ, đủ nhỏ, có acceptance criteria, không còn phụ thuộc chặn. Không nằm trong Scrum Guide.

Hệ thống thiết kế

Bộ quy tắc và thư viện thành phần giao diện dùng chung cho cả sản phẩm: màu, chữ, nút, biểu mẫu, thông báo, kèm hướng dẫn khi nào dùng cái nào.

Phân tích tài liệu

Khai thác yêu cầu bằng cách đọc thứ tổ chức đã có sẵn: quy định, biểu mẫu, hợp đồng, tài liệu hệ thống cũ, dữ liệu thật và ticket hỗ trợ. Rẻ, làm được ngay, và luôn cần đối chiếu lại với người thật.

Công cụ vẽ sơ đồ miễn phí, web app ở app.diagrams.net

Công cụ vẽ sơ đồ miễn phí chạy trên trình duyệt, có sẵn thư viện BPMN, UML, flowchart và wireframe. Là công cụ mặc định của phần lớn BA Việt Nam, kể cả nơi đã mua Visio.

Khai thác thông tin và phối hợp

Knowledge area về việc moi thông tin từ các bên liên quan và giữ họ đồng hành suốt dự án. Chữ elicitation cố tình không dịch là thu thập, vì thông tin thường phải đào chứ không nằm sẵn chờ nhặt.

Vector nhúng (biểu diễn ngữ nghĩa)

Cách biến một đoạn văn bản thành dãy số sao cho hai đoạn gần nghĩa nằm gần nhau. Nhờ vậy máy tìm được theo ý người hỏi chứ không cần trùng từ khoá — nền của tìm kiếm ngữ nghĩa và của RAG.

Người dùng cuối

Người trực tiếp ngồi thao tác trên hệ thống hằng ngày. Họ thường không phải người ký hợp đồng, không dự họp chốt yêu cầu, nhưng họ quyết định hệ thống sống hay chết.

Hệ thống hoạch định nguồn lực doanh nghiệp

Bộ phân hệ chạy phần lõi của doanh nghiệp trên một cơ sở dữ liệu chung: kế toán, mua hàng, kho, sản xuất, bán hàng, nhân sự. Sửa số liệu ở kho thì sổ sách kế toán đổi theo ngay.

Sơ đồ thực thể quan hệ

Sơ đồ mô tả dữ liệu hệ thống lưu trữ: các thực thể, thuộc tính và quan hệ giữa chúng kèm số lượng. Là bản chốt dữ liệu với khách trước khi dev tạo bảng đầu tiên.

Chứng chỉ nhập môn phân tích nghiệp vụ

Bậc nhập môn của IIBA, không đòi giờ kinh nghiệm nên sinh viên và người chuyển nghề thi được ngay. Nó chứng minh bạn nắm từ vựng BABOK, không chứng minh bạn làm được việc.

Môi trường hệ thống

Các bản cài đặt riêng biệt của cùng một hệ thống dùng cho từng mục đích: DEV để lập trình, SIT để ghép nối, UAT để khách nghiệm thu, PROD là hệ thống thật đang chạy.

Hạng mục lớn

Khối công việc lớn, thường mất nhiều sprint, được chẻ dần thành feature rồi user story. Là cách gom nhóm để nhìn tổng thể, không phải một cấu phần của Scrum Guide.

Tính năng

Một nhóm chức năng có thể mô tả bằng ngôn ngữ người dùng và mang lại giá trị đo được, nằm giữa epic và user story về kích cỡ. Đơn vị mà stakeholder thật sự nói chuyện hằng ngày.

Công cụ thiết kế giao diện chạy trên trình duyệt

Công cụ thiết kế giao diện chạy trực tiếp trên trình duyệt, nhiều người sửa cùng lúc trên một file. Là nơi BA nhận bản thiết kế, để lại comment và lấy thông số viết tài liệu.

Tinh chỉnh mô hình

Huấn luyện tiếp một mô hình có sẵn trên bộ dữ liệu riêng để nó bám giọng văn, định dạng hoặc lối làm việc của bạn. Dạy được phong cách và cấu trúc, không dạy được dữ liệu thay đổi hằng ngày.

Lưu đồ

Sơ đồ mô tả một luồng xử lý theo thứ tự, có rẽ nhánh điều kiện, dùng bộ ký hiệu quen thuộc ai cũng đọc được. Mạnh khi giải thích nhanh, yếu khi quy trình có nhiều vai trò.

Yêu cầu chức năng

Mô tả hành vi hệ thống phải thực hiện: nhận đầu vào gì, xử lý ra sao, trả kết quả nào. Đọc xong một FR tốt là QC nghĩ ra được test case ngay mà không cần hỏi lại.

Tài liệu Yêu cầu Chức năng

Tài liệu mô tả chi tiết các chức năng cụ thể mà hệ thống phần mềm cần thực hiện.

Đặc tả chức năng

Tài liệu mô tả chi tiết một tính năng hoạt động thế nào ở mức dev cầm là code được: từng màn hình, từng trường, luật kiểm tra dữ liệu, thông báo lỗi, luồng ngoại lệ.

Phân tích Khoảng cách

Kỹ thuật so sánh trạng thái hiện tại (as-is) với trạng thái mong muốn (to-be).

AI tạo sinh

Nhánh AI tạo ra nội dung mới — văn bản, ảnh, code, giọng nói — thay vì chỉ phân loại hay dự đoán. Đầu ra đổi theo từng lần chạy, nên cách viết yêu cầu và cách nghiệm thu cũng phải đổi theo.

Đưa hệ thống lên chạy thật và cắt chuyển

Giai đoạn chuyển từ hệ thống cũ sang hệ thống mới trong đời thật: kế hoạch cắt chuyển theo mốc giờ, tiêu chí go hoặc no-go, phương án quay đầu và những tuần chăm sóc đặc biệt sau đó.

Ảo giác của mô hình (bịa thông tin)

Hiện tượng mô hình trả lời trôi chảy nhưng sai sự thật, đôi khi kèm cả số điều khoản và nguồn tự bịa. Đây là rủi ro phải chặn bằng thiết kế và acceptance criteria, chứ không có bản vá nào sửa dứt điểm được.

Bản vá khẩn

Bản sửa gấp đưa thẳng lên môi trường thật để chặn một sự cố đang gây thiệt hại, bỏ qua phần lớn lịch phát hành thông thường nhưng vẫn phải test và ghi lại đầy đủ.

Hệ thống quản trị nhân sự

Phần mềm quản lý con người trong tổ chức: hồ sơ, hợp đồng, chấm công, tính lương, nghỉ phép, đánh giá. Đụng tới lương nên sai một dòng là cả phòng biết ngay hôm sau.

Phân tích tác động

Việc rà xem một thay đổi sẽ đụng tới những đâu trước khi ai đó gật đầu: chức năng liên quan, dữ liệu cũ, tích hợp, báo cáo, phạm vi test lại, tài liệu và cả người đang vận hành.

Kiến trúc thông tin

Cách tổ chức, đặt tên và sắp xếp thông tin cùng chức năng trong sản phẩm, sao cho người dùng đoán được thứ họ cần nằm ở đâu mà không phải mò.

Viện Phân tích Nghiệp vụ Quốc tế

Tổ chức phi lợi nhuận thành lập năm 2003, giữ bộ chuẩn BABOK và cấp các chứng chỉ ECBA, CCBA, CBAP. Việt Nam có chapter riêng, hoạt động theo tinh thần tình nguyện nên nhịp độ lên xuống theo từng giai đoạn.

Phỏng vấn khai thác yêu cầu

Kỹ thuật khai thác yêu cầu qua buổi trao đổi trực tiếp với một hoặc hai người, dùng khi cần chiều sâu, cần hiểu ngoại lệ, hoặc khi chủ đề nhạy cảm không tiện đưa ra phòng họp đông người.

Bộ tiêu chí đánh giá user story

Sáu tiêu chí kiểm tra chất lượng một user story: Independent, Negotiable, Valuable, Estimable, Small, Testable. Dùng như bộ soi nhanh trước khi đưa story vào sprint.

Chuyên viên phân tích nghiệp vụ mảng công nghệ thông tin

Nhánh BA gắn với phần mềm: đầu ra là tài liệu cho đội phát triển, đầu vào là nghiệp vụ của khách. Ở Việt Nam gần như mọi tin tuyển BA đều là tin tuyển IT BA, dù tiêu đề chỉ ghi hai chữ BA.

Công cụ quản lý công việc và issue của Atlassian

Công cụ theo dõi công việc phổ biến nhất ở các đội phần mềm: mọi yêu cầu, lỗi và đầu việc đều tồn tại dưới dạng issue có loại, trạng thái, người phụ trách và lịch sử thay đổi.

Phương pháp Kanban

Cách quản lý công việc bằng bảng trực quan và giới hạn số việc đang làm dở, kéo việc mới vào khi có chỗ trống thay vì đẩy theo lô. Không có sprint, không có vai trò bắt buộc.

Mô hình ngôn ngữ lớn

Mô hình đoán chữ tiếp theo, huấn luyện trên khối văn bản khổng lồ, đủ tốt để tóm tắt, viết nháp, phân loại và trích xuất thông tin. Nó không tra cứu sự thật, nó dự đoán chuỗi chữ hợp lý nhất.

Hệ thống cũ còn đang chạy

Hệ thống đời cũ nhưng vẫn giữ nghiệp vụ lõi và chưa ai dám tắt. Thường thiếu tài liệu, thiếu người hiểu, thiếu API — và mọi dự án mới đều phải sống chung với nó.

Dữ liệu chủ

Nhóm dữ liệu dùng chung và ít thay đổi của doanh nghiệp: khách hàng, sản phẩm, nhà cung cấp, nhân viên, tài khoản kế toán. Sai ở đây thì mọi báo cáo phía sau đều sai theo.

Biên bản họp

Bản ghi lại kết quả một cuộc họp: quyết định đã chốt, việc phải làm kèm người và hạn, những gì còn treo. Viết đúng thì nó là bằng chứng; viết sai thì nó là bốn trang không ai đọc.

Cú pháp vẽ sơ đồ bằng chữ, render sẵn trong nhiều công cụ tài liệu

Cú pháp viết sơ đồ bằng chữ, được GitHub, GitLab, Notion và nhiều wiki render thẳng trong tài liệu. Sơ đồ nằm cùng tài liệu, sửa bằng cách sửa chữ, diff được như code.

Sản phẩm khả dụng tối thiểu

Phiên bản sản phẩm nhỏ nhất đủ để kiểm chứng một giả định quan trọng bằng người dùng thật. Mục tiêu là học được điều gì đó, không phải giao một bản rút gọn cho kịp hạn.

Bản mô phỏng giao diện

Bản thiết kế tĩnh đầy đủ màu sắc, font, icon và nội dung thật của một màn hình. Đây là thứ dev nhìn vào để code và là thứ khách hàng ký duyệt về mặt hình ảnh.

Giao thức kết nối ngữ cảnh cho mô hình

Chuẩn mở quy định cách một ứng dụng AI kết nối tới công cụ và nguồn dữ liệu bên ngoài, để mỗi tích hợp không phải viết lại từ đầu. Nó là lớp cắm dây, không làm mô hình thông minh hơn.

Phương pháp ưu tiên MoSCoW

Phương pháp ưu tiên hóa yêu cầu: Must have, Should have, Could have, Won't have.

Xử lý ngôn ngữ tự nhiên

Nhóm kỹ thuật cho máy đọc và xử lý ngôn ngữ của người: phân loại, trích xuất thực thể, phân tích cảm xúc, tóm tắt. Với tiếng Việt, tách từ và chữ không dấu là hai chỗ hay vỡ nhất.

Yêu cầu phi chức năng

Yêu cầu về chất lượng vận hành của hệ thống: nhanh, an toàn, ổn định, dễ mở rộng, chạy được trên môi trường nào. Không viết ra thì dev tự quyết, và QC không biết đường nào mà test.

Quan sát người dùng làm việc

Đến tận nơi xem người dùng làm việc thật thay vì nghe họ kể lại. Kỹ thuật tốn công nhưng là cách gần như duy nhất để bắt được những bước không ai nghĩ tới việc kể ra.

Nhận dạng ký tự quang học

Kỹ thuật đọc chữ từ ảnh hoặc PDF scan thành văn bản máy xử lý được. Dùng đúng chỗ thì tiết kiệm hàng trăm giờ nhập liệu, dùng sai chỗ thì bạn đang OCR một file vốn đã có sẵn dữ liệu.

Chân dung người dùng

Nhân vật đại diện cho một nhóm người dùng, dựng từ dữ liệu phỏng vấn và quan sát thật, để cả team có chung một hình dung khi phải chọn làm tính năng nào trước.

Công cụ sinh sơ đồ UML từ mã văn bản

Công cụ sinh sơ đồ từ mã văn bản, phủ gần hết UML 2.x cùng C4 và nhiều loại khác. Mạnh hơn Mermaid về UML đầy đủ, đổi lại phải có chỗ render và đôi khi cần cài thêm Graphviz.

Chứng chỉ phân tích nghiệp vụ của Viện Quản lý Dự án

Chứng chỉ phân tích nghiệp vụ do PMI cấp, nhìn công việc BA từ góc quản lý dự án. Hợp với người đã ở trong hệ sinh thái PMI hoặc làm dự án có quy trình chặt.

Hệ thống bán hàng tại quầy

Phần mềm và thiết bị tại quầy thu ngân: quét hàng, tính tiền, nhận thanh toán, in bill, chốt ca. Mỗi giây chậm ở đây nhân lên với hàng nghìn lượt khách mỗi ngày.

Mức độ ưu tiên

Thứ tự cần xử lý một defect, quyết định bởi tác động kinh doanh và lịch phát hành chứ không chỉ bởi mức hỏng. Một lỗi nhỏ vẫn có thể ưu tiên cao nếu khách nhìn thấy mỗi ngày.

Backlog Sản phẩm

Danh sách được sắp xếp ưu tiên chứa tất cả công việc cần thiết cho sản phẩm.

Chủ sản phẩm

Người chịu trách nhiệm tối đa hoá giá trị sản phẩm bằng cách quyết định thứ tự Product Backlog. Một người cụ thể, có quyền nói không, chứ không phải một hội đồng ký duyệt.

Lộ trình sản phẩm

Bản trình bày hướng đi của sản phẩm trong vài tháng tới, theo mục tiêu cần đạt thay vì danh sách tính năng kèm ngày giao. Công cụ để thống nhất kỳ vọng, không phải bản cam kết.

Người bảo trợ dự án

Người cấp cao đứng sau dự án: duyệt ngân sách, gỡ vướng giữa các phòng ban, chịu trách nhiệm cuối cùng về kết quả kinh doanh mà dự án hứa mang lại.

Kỹ thuật viết prompt

Kỹ năng viết chỉ dẫn cho mô hình sao cho ra đúng thứ mình cần: rõ vai trò, đủ ngữ cảnh, chốt định dạng đầu ra, nêu ràng buộc. Về bản chất giống hệt việc viết một yêu cầu không mơ hồ.

Bản mẫu tương tác

Bản mẫu bấm được của sản phẩm: nối các màn lại theo luồng thật để người ta thao tác thử trước khi dev viết một dòng code nào. Dùng để demo, để test và để chốt luồng.

Đảm bảo chất lượng

Tập hợp hoạt động hướng vào quy trình để lỗi ít có cơ hội sinh ra: đặt chuẩn tài liệu, review, audit, cải tiến cách làm. QA nhìn vào cách làm việc chứ không nhìn từng build.

Kiểm soát chất lượng

Hoạt động soi sản phẩm đã làm ra để tìm chỗ sai so với yêu cầu: chạy test case, log bug, verify lại sau khi dev fix. Ở Việt Nam, QC còn là tên gọi của chính người làm việc đó.

Ma trận RACI

Công cụ phân công trách nhiệm: Responsible, Accountable, Consulted, Informed.

Kiểm thử hồi quy

Chạy lại các phần đã chạy đúng trước đây để chắc rằng thay đổi mới không làm hỏng cái cũ. Càng sửa nhiều, càng phải chạy, và đây là lý do chính khiến người ta đầu tư test tự động.

Ghi chú phát hành

Bản ghi ngắn đi kèm mỗi lần phát hành: phiên bản này có gì mới, sửa lỗi nào, còn hạn chế gì, cần làm gì trước và sau khi cập nhật. Người vận hành và khách đọc nó để khỏi bị bất ngờ sáng hôm sau.

Yêu cầu

Phát biểu về một nhu cầu, một năng lực hệ thống phải có, hoặc một điều kiện phải thoả mãn — viết ra để khách, BA, dev và QC hiểu giống nhau chứ không mỗi người một kiểu.

Phân tích yêu cầu và định nghĩa thiết kế

Knowledge area dày nhất của BABOK v3, gồm 6 task: mô hình hoá yêu cầu, kiểm tra chất lượng tài liệu, xác nhận giá trị, dựng cấu trúc yêu cầu, đưa phương án thiết kế và khuyến nghị giải pháp.

Khai thác yêu cầu

Quá trình moi ra yêu cầu từ người, tài liệu và hệ thống hiện có bằng các kỹ thuật cụ thể như phỏng vấn, workshop, quan sát, phân tích tài liệu, prototype và khảo sát.

Quản lý vòng đời yêu cầu

Knowledge area lo phần yêu cầu sau khi đã thu thập: truy vết, duy trì, ưu tiên, đánh giá thay đổi và phê duyệt. Đây là vùng hay bị bỏ lơ nhất và cũng gây đau nhất khi dự án chạy được nửa đường.

Sắp xếp ưu tiên yêu cầu

Việc quyết định làm gì trước, làm gì sau và không làm gì, dựa trên giá trị, chi phí, rủi ro và phụ thuộc — chứ không dựa trên ai nói to nhất trong cuộc họp.

Ma trận truy vết yêu cầu

Bảng nối yêu cầu với nơi nó được hiện thực và nơi nó được kiểm thử, để trả lời hai câu: yêu cầu này đã làm chưa, và nếu sửa chỗ này thì hỏng những gì.

Buổi làm việc nhóm để chốt yêu cầu

Buổi làm việc có cấu trúc, gom nhiều bên liên quan vào một phòng để cùng chốt yêu cầu trong thời gian ngắn. Kiểu cổ điển của nó là JAD, và thứ quyết định thành bại là người điều phối.

API theo kiến trúc REST

Kiểu API phổ biến nhất hiện nay: mỗi thứ trong hệ thống là một tài nguyên có địa chỉ riêng, thao tác bằng GET/POST/PUT/DELETE, dữ liệu đi về dưới dạng JSON.

Sinh nội dung có truy xuất dữ liệu

Cách ghép mô hình ngôn ngữ với kho tài liệu của công ty: tìm các đoạn liên quan trước, rồi mới để mô hình trả lời dựa đúng trên những đoạn đó, kèm trích dẫn nguồn cho người dùng kiểm lại.

Phân tích Nguyên nhân Gốc rễ

Phương pháp hệ thống để xác định nguyên nhân gốc rễ của vấn đề.

Kiểm thử xác minh nhanh

Kiểm tra nhanh và có trọng điểm vào đúng phần vừa được sửa hoặc vừa thêm, xem nó có hoạt động hợp lý không trước khi bỏ công test sâu và chạy hồi quy.

Phình phạm vi dự án

Phạm vi dự án lớn dần lên bằng những đề nghị nhỏ không ai duyệt chính thức, cho tới lúc timeline và ngân sách vỡ mà không chỉ ra được thời điểm nào đã sai.

Khung làm việc Scrum

Khung làm việc nhẹ gồm 3 accountability, 5 event và 3 artifact, giúp nhóm nhỏ chia việc thành chu kỳ ngắn, làm ra thứ dùng được rồi nhìn lại và điều chỉnh.

Người dẫn dắt nhóm Scrum

Người chịu trách nhiệm để Scrum chạy đúng và nhóm làm việc hiệu quả: huấn luyện, gỡ vướng, chắn nhiễu từ bên ngoài. Không giao việc, không chấm KPI, không quản lý ai cả.

Sơ đồ tuần tự

Sơ đồ UML mô tả thứ tự trao đổi thông điệp giữa các thành phần theo trục thời gian dọc. Là công cụ số một khi dự án có tích hợp nhiều hệ thống và cần chốt ai gọi ai trước.

Mức độ nghiêm trọng

Mức độ ảnh hưởng của một defect lên hệ thống và nghiệp vụ, do QC đánh giá dựa trên hậu quả kỹ thuật. Nó khác với priority, tức thứ tự cần sửa trước sau.

Đăng nhập một lần cho nhiều hệ thống

Người dùng đăng nhập một lần rồi vào được nhiều hệ thống khác nhau mà không phải nhập lại mật khẩu. Đằng sau là một nơi giữ danh tính chung cho cả tổ chức.

Kiểm thử sơ bộ

Bộ kiểm tra nhanh vài chức năng xương sống ngay sau khi nhận build, để quyết định build này có đáng test tiếp hay trả lại cho dev. Thường chạy trong 15 tới 60 phút.

Phần mềm dạng dịch vụ thuê bao

Phần mềm dùng qua trình duyệt, trả tiền theo tháng hoặc theo người dùng, nhà cung cấp lo hạ tầng và nâng cấp. Bạn thuê chỗ ngồi chứ không mua nhà.

Vòng đời phát triển phần mềm

Chuỗi các pha một phần mềm đi qua từ lúc có ý tưởng tới lúc ngừng dùng: lập kế hoạch, phân tích, thiết kế, lập trình, kiểm thử, triển khai, vận hành. BA có việc ở gần như mọi pha.

Đặc tả yêu cầu phần mềm

Tài liệu gom toàn bộ yêu cầu chức năng, phi chức năng, ràng buộc và giao diện của một phần mềm vào một chỗ, đủ chi tiết để đội phát triển xây và đội kiểm thử nghiệm thu.

Đánh giá giải pháp

Knowledge area đo xem giải pháp đã triển khai có thật sự tạo ra giá trị hay không, và đề xuất làm gì tiếp. Đây là vùng bị bỏ qua nhiều nhất ở các dự án Việt Nam vì team đã chuyển sang dự án khác.

Yêu cầu giải pháp

Tầng mô tả hệ thống phải làm được gì và làm tốt đến mức nào, chia thành yêu cầu chức năng và phi chức năng. Đây là tầng BA viết ra, không phải tầng khách đọc cho chép.

Sprint

Khoảng thời gian cố định (2-4 tuần) trong Scrum để hoàn thành một tập công việc đã cam kết.

Danh sách việc của một sprint

Kế hoạch của Developers cho một sprint, gồm Sprint Goal, các hạng mục lấy từ Product Backlog và cách làm chúng. Do chính đội phát triển sở hữu và cập nhật hằng ngày.

Buổi lập kế hoạch sprint

Sự kiện mở màn mỗi sprint, nơi cả Scrum Team thống nhất Sprint Goal, chọn hạng mục từ Product Backlog và phác kế hoạch làm. Timebox tối đa 8 giờ cho sprint một tháng.

Buổi nhìn lại cuối sprint

Sự kiện khép lại sprint, nơi Scrum Team nhìn lại cách mình làm việc rồi chọn ra vài cải tiến có tác động lớn nhất để xử lý ngay. Timebox tối đa 3 giờ cho sprint một tháng.

Buổi rà soát cuối sprint

Buổi cuối sprint, nơi Scrum Team và stakeholder cùng xem Increment thật rồi bàn xem nên điều chỉnh Product Backlog thế nào. Timebox tối đa 4 giờ cho sprint một tháng.

Bên liên quan

Bất kỳ cá nhân hay nhóm nào tác động đến dự án hoặc chịu tác động từ dự án: người trả tiền, người dùng, người vận hành, bộ phận tuân thủ, cả đối tác bên ngoài.

Phân tích Các bên Liên quan

Quá trình xác định các bên liên quan, phân tích mức độ ảnh hưởng và quan tâm của họ.

Yêu cầu của các bên liên quan

Tầng yêu cầu ở giữa: mô tả nhu cầu của từng nhóm người liên quan và cách họ tương tác với giải pháp. Do trưởng phòng, người dùng nghiệp vụ, đội vận hành phát biểu.

Sơ đồ máy trạng thái

Sơ đồ UML mô tả vòng đời của một đối tượng: nó có những trạng thái nào, sự kiện nào làm nó chuyển trạng thái, và chuyển nào bị cấm. Rất hợp với đơn hàng và hồ sơ nhiều bước duyệt.

Điểm ước lượng công việc

Đơn vị ước lượng tương đối cho một hạng mục backlog, gộp cả độ phức tạp, khối lượng và mức rủi ro. So sánh việc này với việc kia, chứ không quy ra giờ công.

Phân tích chiến lược

Knowledge area của BABOK v3 trả lời câu hỏi vì sao phải thay đổi và đi từ đâu tới đâu. Gồm phân tích hiện trạng, mô tả trạng thái tương lai, đánh giá rủi ro và chọn chiến lược thay đổi.

Chuyên gia nghiệp vụ

Người nắm sâu nhất một mảng nghiệp vụ và là nguồn để BA kiểm chứng quy tắc, ngoại lệ, số liệu. Thường rất bận và thường là điểm nghẽn của cả dự án.

Quản lý chuỗi cung ứng

Việc điều phối cả dòng hàng lẫn dòng thông tin từ nhà cung cấp tới tay khách: dự báo, mua, sản xuất, lưu kho, vận chuyển. Phần mềm SCM là chỗ mấy quyết định đó được số hoá.

Khảo sát bằng bảng hỏi

Thu thông tin từ nhiều người cùng lúc bằng bộ câu hỏi soạn sẵn. Rẻ và nhanh khi cần con số trên diện rộng, nhưng gần như vô dụng nếu dùng để khám phá thứ mình chưa hiểu.

Sơ đồ phân làn

Cách bố cục sơ đồ quy trình theo làn, mỗi làn là một vai trò và mỗi bước nằm trong làn của người chịu trách nhiệm. Nhìn ra ngay chỗ bàn giao và chỗ việc hay bị rơi.

Phân tích SWOT

Framework phân tích chiến lược: Strengths, Weaknesses, Opportunities, Threats.

Tích hợp hệ thống

Việc nối các hệ thống rời rạc lại để dữ liệu chảy qua nhau mà không cần người ngồi copy paste. Phần khó nằm ở thoả thuận nghiệp vụ giữa hai bên chứ không ở đoạn code.

Kiểm thử tích hợp hệ thống

Giai đoạn kiểm thử ghép các hệ thống hoặc module lại với nhau để xem dữ liệu chạy qua ranh giới giữa chúng có đúng không. Đây là nơi lộ ra phần lớn lỗi tích hợp trước khi tới tay người dùng.

Ca kiểm thử

Một ca kiểm thử cụ thể gồm tiền điều kiện, các bước thao tác, dữ liệu đầu vào và kết quả mong đợi, để hai người khác nhau chạy đều ra cùng một kết luận đúng hay sai.

Độ phủ kiểm thử

Tỉ lệ phần đã được kiểm thử so với phần cần kiểm thử, tính theo yêu cầu, theo chức năng hoặc theo dòng code. Con số này chỉ có nghĩa khi nói rõ đang phủ trên cái gì.

Kế hoạch kiểm thử

Tài liệu chốt phạm vi kiểm thử, cách test, ai làm, môi trường và dữ liệu nào, tiêu chí bắt đầu và kết thúc. Nó tồn tại để lúc gấp gáp không ai tự ý bỏ bớt phần quan trọng.

Kịch bản kiểm thử

Mô tả ngắn một tình huống cần kiểm thử ở mức nghiệp vụ, chưa đi vào từng bước bấm. Một scenario thường đẻ ra nhiều test case chi tiết bên dưới.

Quy trình mục tiêu

Quy trình đích sau dự án: đã xử lý điểm tắc của as-is, chạy được với hệ thống và con người có thật, và có người đủ thẩm quyền ký duyệt. Là gốc để bóc ra danh sách yêu cầu.

Yêu cầu chuyển đổi

Loại yêu cầu chỉ tồn tại trong giai đoạn chuyển từ hệ thống cũ sang hệ thống mới: chuyển dữ liệu, chạy song song, đào tạo, phương án quay lui. Hết chuyển đổi là hết vòng đời.

Nhóm năng lực nền của người phân tích nghiệp vụ

Chương riêng trong BABOK v3 liệt kê sáu nhóm năng lực cá nhân mà BA cần có, từ tư duy phân tích tới kỹ năng giao tiếp và công cụ. Đây là phần khó dạy nhất và cũng quyết định nhất khi phỏng vấn.

Ngôn ngữ mô hình hóa thống nhất

Bộ ký hiệu chuẩn do OMG duy trì để vẽ sơ đồ mô tả hệ thống phần mềm, gồm 14 loại sơ đồ. BA thường chỉ cần thạo bốn tới năm loại là đủ dùng cho hầu hết tài liệu.

Kiểm thử tính khả dụng

Giao cho người dùng thật một nhiệm vụ cụ thể rồi ngồi quan sát họ làm, để tìm chỗ khó dùng. Đo bằng việc họ có làm xong không, mất bao lâu và vướng ở đâu.

Trường hợp Sử dụng

Mô tả cách người dùng tương tác với hệ thống để đạt được một mục tiêu cụ thể.

Sơ đồ ca sử dụng

Sơ đồ UML cho thấy hệ thống cho ai làm được những việc gì và ranh giới hệ thống nằm ở đâu. Công cụ chốt phạm vi gọn nhất mà BA có, vẽ được cùng khách trong nửa giờ.

Kiểm thử Chấp nhận Người dùng

Giai đoạn kiểm thử cuối cùng do người dùng thực hiện để xác nhận hệ thống đáp ứng yêu cầu nghiệp vụ.

Trải nghiệm người dùng

Toàn bộ cảm nhận của một người khi dùng sản phẩm để đạt mục tiêu của họ: nhanh hay chậm, dễ hay rối, tin tưởng hay lo lắng. Rộng hơn phần giao diện rất nhiều.

Giao diện người dùng

Lớp mà người dùng nhìn thấy và chạm vào: màn hình, nút bấm, biểu mẫu, thông báo, màu sắc, chữ nghĩa. Là phần hữu hình của sản phẩm và cũng là phần khách hàng góp ý nhiều nhất.

Câu chuyện Người dùng

Mô tả tính năng từ góc nhìn người dùng: As a [user], I want [goal] so that [benefit].

Lập bản đồ câu chuyện người dùng

Cách sắp xếp user story thành bản đồ hai chiều: ngang là trình tự người dùng làm việc, dọc là mức ưu tiên. Giúp nhìn ra khoảng trống và cắt phạm vi phát hành gọn hơn danh sách phẳng.

Cơ sở dữ liệu vector

Kho lưu và tìm kiếm các vector embedding theo độ gần nghĩa, trả về những đoạn giống nhất trong mili giây. Nhiều dự án nội bộ chỉ cần extension pgvector trên Postgres sẵn có là đủ.

Tốc độ hoàn thành của nhóm

Số điểm mà một team hoàn thành trong một sprint, lấy trung bình vài sprint để dự báo dung lượng sắp tới. Chỉ có nghĩa trong nội bộ một team, không đem so giữa các team.

Hệ thống quản lý kho

Phần mềm điều hành mọi việc xảy ra bên trong kho: hàng về xếp ở đâu, ai đi lấy, lấy theo thứ tự nào, kiểm kê ra sao. Làm việc theo từng vị trí và từng lần quét mã.

Mô hình thác nước

Mô hình phát triển đi tuần tự qua từng pha, mỗi pha ký duyệt xong mới sang pha sau. Bị chê nhiều nhưng vẫn là cách chạy phổ biến ở dự án ngân hàng, nhà nước và các hợp đồng trọn gói tại Việt Nam.

Cơ chế gọi ngược khi có sự kiện

Thay vì bên cần dữ liệu hỏi liên tục, bên có dữ liệu tự gửi một gói tin sang ngay khi sự kiện xảy ra. Kiểu như thay vì gọi điện hỏi hàng về chưa, bạn để lại số và họ nhắn khi hàng về.

Khung sườn giao diện

Bản vẽ xám của một màn hình: chỗ nào đặt cái gì, bấm vào thì đi đâu, chưa quan tâm màu sắc hay font chữ. Dùng để chốt bố cục và luồng thao tác trước khi ai đó bỏ công tô vẽ.