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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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