Yêu cầu phi chức năng là gì?
Một phần mềm quản lý đơn hàng có thể vượt qua buổi chạy thử khi chỉ vài người sử dụng, nhưng chậm hẳn lúc cả đội bán hàng vào làm. Nhân viên bấm gửi lại vì không thấy phản hồi, rồi phải kiểm tra đơn nào đã được ghi nhận. Các màn hình vẫn đủ, nhưng công việc không còn diễn ra như mong đợi.
Tình huống giả định này cho thấy danh sách tính năng chưa đủ để xác định một hệ thống có dùng được trong thực tế hay không. Doanh nghiệp còn phải làm rõ tải sử dụng, thời điểm cần hoạt động, cách giữ dữ liệu nhất quán và cách tiếp tục công việc khi có lỗi. Đó là những nội dung thường được xem xét trong yêu cầu phi chức năng.
1. Yêu cầu phi chức năng là gì?
Yêu cầu chức năng mô tả những việc phần mềm cần làm, như tạo đơn, giữ hàng hoặc xuất báo cáo. Yêu cầu phi chức năng mô tả chất lượng, điều kiện vận hành và các ràng buộc cần đáp ứng khi thực hiện những việc đó. “Có thể tra cứu đơn hàng” và “tra cứu vẫn đáp ứng khi nhiều người cùng làm việc” vì thế là hai nội dung cần trao đổi khác nhau.
Ranh giới giữa hai nhóm không phải lúc nào cũng tuyệt đối. Một yêu cầu bảo mật có thể dẫn đến chức năng phân quyền, còn yêu cầu truy vết có thể cần màn hình lịch sử thay đổi. Điều quan trọng là nhu cầu được chuyển thành nội dung thiết kế và kiểm tra được, không phải tranh luận xem một dòng thuộc nhóm nào rồi để nó không có người chịu trách nhiệm.
Các yêu cầu này nên xuất hiện từ lúc xác định phạm vi. Nếu đến gần nghiệm thu mới biết hệ thống phải phục vụ nhiều chi nhánh cùng lúc hoặc không được dừng trong giờ nhận đơn, nhóm phát triển có thể phải sửa cả cách tổ chức dữ liệu và triển khai. Một điều kiện sử dụng nghe rất đơn giản với người nghiệp vụ vẫn có thể tạo ảnh hưởng lớn đến giải pháp.
Đọc thêm: Phân tích yêu cầu là gì? Bước đầu để phát triển đúng hướng
2. Doanh nghiệp cần làm rõ những yêu cầu nào?
Trước khi điền một danh sách thuật ngữ kỹ thuật, hãy cùng người trực tiếp làm việc đi qua một tình huống từ đầu đến cuối. Với hệ thống đơn hàng giả định, nhân viên tìm khách, kiểm tra tồn kho, gửi đơn, chờ xác nhận và bàn giao cho kho. Ở mỗi bước, cần hỏi: nếu chậm, sai hoặc không thực hiện được, ai sẽ bị ảnh hưởng và công việc sẽ tiếp tục bằng cách nào?
Bảng dưới đây là cách phân tích tình huống, không phải bộ yêu cầu bắt buộc cho mọi hệ thống. Những câu trả lời có thể dẫn đến yêu cầu về hiệu năng, khả năng phục hồi, bảo mật hoặc cách vận hành; một số câu trả lời cũng cần được ghi vào quy tắc chức năng.
| Tình huống | Cần làm rõ | Nếu bỏ sót |
|---|---|---|
| Đầu giờ nhiều người cùng tra cứu | Thao tác quan trọng, tải đồng thời, lượng dữ liệu và thời gian phản hồi chấp nhận được | Chạy thử ít người thì tốt, dùng thật lại chậm |
| Nhân viên gửi lại vì chưa thấy xác nhận | Cách kiểm tra đơn đã được nhận và ngăn ghi nhận trùng | Một yêu cầu bị xử lý nhiều lần |
| Một dịch vụ liên quan bị gián đoạn | Trạng thái nào được giữ, phần nào được thử lại, ai được thông báo | Người dùng không biết nên chờ hay gửi lại |
| Dữ liệu bị sửa nhầm hoặc hệ thống dừng | Dữ liệu cần khôi phục, mức gián đoạn và người xác nhận có thể dùng lại | Có bản sao nhưng chưa thể tiếp tục nhận đơn |
| Xuất danh sách hoặc đổi người phụ trách | Ai được xem, xuất, sửa và cần lưu lại hành động nào | Thông tin ra ngoài phạm vi hoặc không rõ người thay đổi |
Khả năng sử dụng và vận hành cũng cần được nhìn từ công việc. Một thông báo lỗi chỉ ghi “thất bại” có thể khiến nhân viên không biết đơn đã được tạo chưa; một cảnh báo kỹ thuật không có người tiếp nhận cũng không giúp xử lý gián đoạn. Cần mô tả người dùng phải hiểu được điều gì và đội vận hành cần thấy thông tin nào để phản ứng.
Đặc biệt, cần phân biệt hệ thống đang hoạt động với hệ thống có thể phục hồi. Hệ thống có thể ít bị dừng nhưng vẫn chưa có phương án xử lý khi dữ liệu bị sửa sai. Ngược lại, có bản sao lưu không có nghĩa dịch vụ sẽ trở lại ngay. Đây là hai câu hỏi khác nhau và có thể cần những cách kiểm tra khác nhau.
3. Mô tả yêu cầu thế nào để kiểm tra được?
Có thể bắt đầu bằng cấu trúc: tình huống sử dụng, điều kiện đo, kết quả cần đạt, cách kiểm tra và người xác nhận. Cấu trúc này buộc hai bên làm rõ điều đang được đánh giá. “Hệ thống nhanh” chưa cho biết nhanh ở màn hình nào; “tải được nhiều người” chưa cho biết mọi người đang đọc dữ liệu hay cùng gửi giao dịch.
Ví dụ dưới đây dùng số liệu giả định chỉ để minh họa cách viết, không phải mức chuẩn của ngành hoặc cam kết của Fenix: “Với bộ dữ liệu thử gồm 200.000 đơn và kịch bản 50 người dùng đồng thời, ít nhất 95% lượt tra cứu thành công phải hiển thị kết quả trong 2 giây ở môi trường kiểm thử đã thống nhất.”
Để câu này thực sự dùng được, vẫn phải xác định bộ lọc nào được thử, thời điểm bắt đầu và kết thúc phép đo, thiết bị và mạng đại diện, cùng cách tạo tải. Các lượt lỗi và hết thời gian chờ phải được ghi nhận riêng và có tiêu chí chấp nhận; không được bỏ chúng ra rồi chỉ báo cáo tốc độ của những lượt đã thành công.
Điểm “95%” cũng có ý nghĩa khác với “trung bình”. Thời gian trung bình có thể thấp dù một nhóm người dùng chờ rất lâu. Nếu phần còn lại của lượt tra cứu ảnh hưởng đến công việc quan trọng, cần làm rõ cách xử lý và giới hạn tương ứng. Không nên thêm nhiều chỉ số chỉ để tài liệu trông chuyên nghiệp; mỗi chỉ số phải giúp trả lời một rủi ro đã xác định.
Nếu chưa có số liệu để chốt mục tiêu, đừng điền một con số tùy ý. Hãy dùng dữ liệu vận hành hiện có, quan sát giờ cao điểm hoặc chạy thử để ước lượng; ghi rõ phần còn giả định và thời điểm phải quyết định. Người nghiệp vụ nêu tác động có thể chấp nhận, nhóm kỹ thuật đánh giá khả năng và chi phí, rồi hai bên thống nhất mức cần đáp ứng.
4. Chọn mức yêu cầu phù hợp với nhu cầu và chi phí
Yêu cầu cao hơn thường đi cùng một cách tổ chức và chi phí khác. Nếu báo cáo nội bộ có thể hoàn tất trước đầu ngày làm việc tiếp theo, yêu cầu báo cáo luôn tức thời có thể không tạo thêm giá trị tương xứng. Trong khi đó, phần xác nhận đơn có thể cần được ưu tiên vì khách đang chờ và kho chuẩn bị giao hàng. Cần xếp ưu tiên theo luồng công việc, thay vì áp một mức cho toàn hệ thống.
Một cuộc trao đổi hữu ích nên có các phương án và hệ quả. Doanh nghiệp có chấp nhận bảo trì vào một khung giờ đã thông báo không? Báo cáo lớn có thể chuyển sang xử lý nền và báo khi hoàn tất không? Các lựa chọn này có thể giúp đáp ứng mục tiêu thực tế với mức đầu tư phù hợp hơn, nhưng phải được người dùng liên quan đồng ý và được mô tả rõ trong phạm vi.
Cũng cần phân biệt mục tiêu nghiệp vụ với giải pháp kỹ thuật. “Không mất đơn khi một thành phần gặp lỗi” là nhu cầu cần làm rõ; “phải dùng một loại kiến trúc cụ thể” đã là lựa chọn giải pháp. Trừ khi có ràng buộc được xác nhận, nên để đội kỹ thuật đề xuất và chứng minh phương án, thay vì khóa công nghệ trước khi hiểu yêu cầu.
5. Kiểm tra yêu cầu khi nghiệm thu và vận hành
Khi một yêu cầu đã được chấp thuận, cần đưa nó vào thiết kế và kế hoạch kiểm thử liên quan. Nhóm nghiệp vụ xác nhận tình huống và ảnh hưởng; nhóm kỹ thuật chuẩn bị cách đo và bằng chứng; người có thẩm quyền quyết định phần sai lệch có chấp nhận được không. Một dòng ghi trong tài liệu đầu dự án nhưng không có kế hoạch kiểm tra sẽ khó bảo vệ mong đợi của cả hai bên.
Điều kiện kiểm thử phải được giữ cùng kết quả. Một phép thử dùng rất ít dữ liệu hoặc môi trường khác đáng kể với dự kiến vận hành cần nêu giới hạn, không chỉ kết luận “đạt”. Với trường hợp gián đoạn, cần kiểm tra trạng thái giao dịch, cách khôi phục và khả năng tiếp tục công việc, chứ không chỉ xem máy chủ đã chạy trở lại.
Nghiệm thu phần mềm: Doanh nghiệp cần kiểm tra gì?
Sau khi đưa vào dùng, những giả định ban đầu cần được xem lại khi tăng người dùng, mở chi nhánh hoặc thêm kết nối. Nếu mục tiêu không còn đáp ứng, phải phân biệt thay đổi về quy mô với lỗi chưa đạt yêu cầu đã thống nhất. Lịch sử yêu cầu và kết quả kiểm tra sẽ giúp cuộc trao đổi dựa trên dữ kiện thay vì cảm giác phần mềm “bỗng nhiên chậm”.
Trước buổi trao đổi dự án, doanh nghiệp có thể chuẩn bị ba thông tin: những công việc không được gián đoạn, thời điểm hoặc quy mô sử dụng đáng chú ý và các sự cố từng gây mất công xử lý. Từ đó, hãy cùng Fenix làm rõ điều kiện cần đáp ứng, phần cần khảo sát thêm và cách kiểm tra. Giá trị của yêu cầu phi chức năng nằm ở việc biến mong đợi về chất lượng thành những quyết định mà cả nghiệp vụ và kỹ thuật đều có thể thực hiện.
