Cá nhân mình thì nghĩ rằng tuỳ thuộc vào việc nó có là tính năng xuất phát từ stakeholder requirement hay không.
Ví dụ một phần mềm có quá nhiều tính năng phức tạp, hay một game có lối chơi phức tạp, thì có thể sẽ phát sinh stakeholder requirement rằng phải có một tính năng Help/Tutorial để giúp user/player làm quen với phần mềm/game dần dần, rồi sẽ đi sâu vào cách trình bày các hướng dẫn ra sao như là các functional requirements (ví dụ 1 số game chỉ làm cái popup có video minh hoạ và giải thích bằng chữ, một số game khác thì sẽ có các chỉ dẫn trên màn hình highlight các tính năng trong game và gamer tự bấm theo chỉ dẫn, một số phần mềm Windows xưa có cả một cửa sổ Help riêng có mục lục các tính năng và một nút liên hệ online trên cửa sổ đó, hay kiểu màn hình Tips hay hiện ra khi mới mở một chương trình). Stakeholder có thể là UI/UX designer.
Còn kiểu stakeholder requirement chỉ quay quanh những nghiệp vụ mà các stakeholder đang làm, thì tính năng Help lại xếp vào non-functional requirement vì chủ yếu nó giúp cho người dùng hiểu rõ hơn về tính năng đang thao tác, chứ nó không ảnh hưởng trực tiếp đến nghiệp vụ. Quay lại ví dụ của anh Thịnh thì functional requirement là ly chè và non-functional là khăn lau miệng, nếu không có khăn lau miệng thì khách vẫn ăn chè được (nhưng trải nghiệm không tốt). Với ví dụ tính năng Help thì thực ra ngoài việc dựng trên hệ thống cũng có thể làm user guide như một cách thay thế, trải nghiệm thì thua tính năng Help dựng sẵn nhưng sẽ hơn là không có gì.
Này là góc nhìn của mình thôi nha, mình cũng hóng thêm góc nhìn từ anh Thịnh giống bạn.

Ở chỗ cũ em làm có áp dụng một process chuyển khoản tự động với 1 functional requirement là phải thực hiện bước so sánh tên của khách hàng khai báo với tên chủ tài khoản để xem tài khoản có phải chính chủ hay không (ở đây đã chấp nhận bỏ qua yếu tố gian lận sử dụng tài khoản trùng tên, vì trường hợp này với quy trình thủ công trước đó cũng không có cách kiểm tra). Do tên của khách hàng khai báo sẽ là dạng tiếng Việt có dấu viết theo Title Case nên phải convert sang không dấu và ghi theo UPPER CASE rồi mới tiến hành so sánh. Trong quá trình test bước convert này trên môi trường preproduction với dữ liệu replicated từ production qua, thì phát sinh realization là một số khách hàng vẫn còn dùng Unicode tổ hợp thay vì Unicode dựng sẵn và phần tính năng convert chỉ mới hỗ trợ Unicode dựng sẵn, nên bên em phải bổ sung hỗ trợ thêm phần Unicode tổ hợp. Một lần em đi phỏng vấn gần đây thì em có đưa ra trường hợp này để ví dụ cho một non-functional requirement mà em từng đụng phải nhưng người phỏng vấn thì ko đồng tình với lý do là họ xem các yêu cầu về bảo mật, tính ổn định này kia (mà có vẻ họ đang nghiêng về tính ổn định hạ tầng/performance hệ thống)… mới là non-functional requirement. Góc độ em thì vẫn xem nó là non-functional requirement vì cover thêm case này cũng giúp cho tính ổn định của process này được tốt hơn và không phải xử lý fallback ở những case đúng ra vẫn có thể xử lý được chỉ là do encoding khác nhau. Nên em cũng muốn có một góc nhìn khác và nếu có thể, em cũng mong anh giải thích vì sao trường hợp này có thể/không thể xếp vào non-functional requirement.

cảm ơn em nhé

Mình thấy dùng Quality of Services mới đáp ứng độ Đủ của khía cạnh Non-functional rqm Thực tế thì các đầu mục triển khai sản phẩm, đào tạo user, documents,…. cũng nằm trong danh mục rqm mà nhỉ? còn User experience đúng nhưng chưa đủ

Cảm ơn Sơn nhé