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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Đư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 đó.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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