Giả sử bạn viết xong mọi yêu cầu chức năng cho màn hình báo cáo tồn kho, chạy test ngon lành, ai cũng khen, rồi tới ngày go-live dữ liệu thật đổ vào mấy chục nghìn dòng, báo cáo mất hơn một phút mới load xong, khách đứng bên cạnh nhìn bạn. Đó là lúc bạn nhận ra mình đã quên một thứ tên là non-functional requirement, yêu cầu phi chức năng.
NFR là gì#
Yêu cầu chức năng trả lời hệ thống làm gì, tạo được đơn hàng, duyệt được đề nghị mua, xuất được báo cáo, còn yêu cầu phi chức năng trả lời hệ thống chạy tốt tới mức nào, nhanh bao nhiêu, bảo mật ra sao, ai được xem gì, ghi log thế nào. BABOK Guide v3 xếp NFR vào nhóm solution requirements, gọi là non-functional hay quality of service requirements, tức những điều kiện hoặc phẩm chất giải pháp phải có (IIBA, 4.4), kỹ thuật tương ứng là Non-Functional Requirements Analysis (10.30).
Ví dụ cho dễ nhớ, yêu cầu chức năng là hệ thống xuất báo cáo tồn kho, còn yêu cầu phi chức năng là báo cáo tồn kho trả kết quả trong vòng X giây với Y bản ghi, X và Y là con số bạn phải điền theo từng dự án.
NFR hay bị quên vì một lý do đơn giản, nó không hiện ra lúc demo chức năng, màn hình chạy đúng, bấm nút ra kết quả là tưởng xong, trong khi chạy đúng với chạy tốt khi có, ví dụ, 50.000 dòng và 200 người dùng cùng lúc là hai chuyện khác hẳn nhau.
viết sao cho đo được#
Lỗi phổ biến nhất là dùng từ mơ hồ, hệ thống phải nhanh thì nhanh là bao nhiêu, giao diện thân thiện thì đo bằng gì, bảo mật tốt thì tốt theo chuẩn nào. NFR tốt phải gắn được con số, điều kiện và cách kiểm, ví dụ với số minh họa, “Báo cáo tồn kho trả kết quả trong 5 giây với 100.000 bản ghi, đo trên máy chủ theo cấu hình chuẩn”, câu này test được, tester biết phải tạo bao nhiêu dữ liệu, bấm nút rồi bấm đồng hồ. Khách chưa xác định được con số thì đừng bỏ trống, ghi một con số tạm để mọi người có chỗ bàn, rồi đánh dấu cần khách xác nhận.
checklist NFR theo nhóm#
Đi khảo sát thì hỏi theo từng nhóm này để khỏi sót. Hiệu năng là báo cáo nào hay dùng cuối tháng mà dữ liệu lớn, bao nhiêu người dùng cùng lúc vào giờ cao điểm, và một câu mở rất đáng hỏi là thao tác nào anh chị thấy chậm nhất hiện tại. Bảo mật và phân quyền là ai được xem gì, ai được sửa gì, có dữ liệu nào chỉ một phòng được xem không, có cần phân quyền theo chi nhánh hay nhà máy không. Audit trail là thao tác nào cần lưu vết, ai làm, làm lúc nào, giá trị trước và sau, với ERP thì chuyện ai đổi giá, ai duyệt đơn thường là yêu cầu bắt buộc của kiểm toán.
Khả năng dùng là người dùng ở đâu, dùng thiết bị gì, công nhân dưới xưởng có dùng máy tính bảng hay máy quét mã vạch không, cần tiếng Việt, tiếng Anh hay thêm ngôn ngữ khác. Lưu trữ là dữ liệu giữ bao lâu, có cần lưu để đối chiếu nhiều năm không, khối lượng tăng thế nào theo năm. Tích hợp là hệ thống phải nói chuyện với phần mềm nào khác, qua API hay nhập xuất file, tần suất ra sao.
góc ERP, những NFR hay bị quên nhất#
Phân quyền theo vai trò và site là cái đầu tiên, một hệ thống ERP phục vụ nhiều nhà máy, nhiều chi nhánh, kế toán nhà máy A không được nhìn số nhà máy B, chuyện này không chốt từ đầu thì lúc chạy là một mớ bòng bong, bài Quản trị truy cập Cloud ERP: bài toán IAM mổ kỹ vấn đề này.
Đóng kỳ kế toán là cái thứ hai, cuối tháng phải đóng kỳ, không ai được sửa chứng từ kỳ đã đóng, ai được mở lại kỳ, quy trình mở lại thế nào, NFR này mà quên thì kế toán trưởng sẽ tìm bạn đầu tiên.
Batch đêm là cái thứ ba, nhiều tác vụ nặng của ERP chạy ban đêm như tính giá thành, chốt tồn kho, đồng bộ dữ liệu, cần chốt rõ tác vụ nào chạy lúc nào, chạy bao lâu, fail thì cảnh báo cho ai.
Khối lượng dữ liệu sau migration là cái cuối, chuyển dữ liệu từ hệ cũ sang xong thì bảng có thể phình to, báo cáo chạy nhanh với vài nghìn dòng chưa chắc còn nhanh với vài trăm nghìn dòng. Lưu ý là bản thân việc chuyển dữ liệu là transition requirement theo BABOK, còn NFR ở đây là hiệu năng sau khi dữ liệu đã vào.
đưa NFR vào đâu#
NFR không phải thứ để cuối cùng mới nghĩ tới. Trong tài liệu truyền thống nó nằm trong SRS, có mục riêng cho yêu cầu phi chức năng, còn trong Agile thì rải rác, trong acceptance criteria của từng story, trong Definition of Done của team, hoặc trong một trang yêu cầu chung mà story nào cũng phải tôn trọng.
Hiểu lầm hay gặp là NFR là việc của kiến trúc sư hay dev, BA chỉ lo chức năng. Kiến trúc sư quyết cách đáp ứng, nhưng con số bao nhiêu là đủ phải tới từ nghiệp vụ, kế toán chờ báo cáo cuối tháng được bao lâu, xưởng mất mạng thì có quét mã vạch tiếp được không, và người hỏi được mấy câu đó là BA. Đặt ở đâu cũng được, miễn là nó được ghi ở chỗ có người chịu trách nhiệm, chứ đừng để ai cũng nghĩ người khác lo.
hỏi NFR từ buổi khảo sát đầu tiên#
Phát hiện thiếu NFR muộn nhất là lúc go-live, khi dữ liệu thật đổ vào và người dùng thật bấm vào, lúc đó sửa là tốn nhất, nên ngay từ buổi khảo sát đầu hãy dành một phần câu hỏi cho hiệu năng, phân quyền và audit, đừng chỉ hỏi màn hình cần những gì. Muốn biết NFR nằm ở đâu trong bộ tài liệu thì đọc BRD, SRS, FS khác nhau thế nào, còn kiểm NFR bằng dữ liệu thật trước go-live thì có bài UAT cho dự án ERP.
NFR nào từng làm bạn bị vả lúc go-live? Kể mình nghe qua Facebook hoặc LinkedIn nhé.
