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.

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.

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ó.

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.

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ế.

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.

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.

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.

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ạ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.

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ệ.

Ả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.

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ò.

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.

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.

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.

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.

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.

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.

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ồ.

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.

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.

Đă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.

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.

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.

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.

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

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.

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.

Độ 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ì.

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.

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ờ.

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.