top of page

Non-Functional Requirement (NFR)

Ảnh của tác giả: Tuan AnhTuan Anh
Non-functional requirement

Trong quá trình làm việc, hầu hết mọi người thường tập trung vào việc phân tích và ghi nhận các yêu cầu chức năng (functional requirements) của hệ thống, tức là những yêu cầu về chức năng, tính năng cụ thể mà phần mềm cần phải có. Tuy nhiên, có một yếu tố quan trọng khác, tuy không liên quan trực tiếp đến chức năng nhưng lại ảnh hưởng không nhỏ đến sự thành công của sản phẩm, đó chính là Non-functional Requirements (yêu cầu phi chức năng).

Trong bài viết này mình sẽ cùng các bạn làm rõ ràng NFR là gì và BA cần làm gì với các yêu cầu này.


1. Non-functional Requirements là gì?

Nói một cách đơn giản, Non-functional Requirements là những yêu cầu không liên quan đến chức năng cụ thể của hệ thống, mà tập trung vào các khía cạnh như:

  • Hiệu năng (Performance): Tốc độ xử lý, khả năng đáp ứng của hệ thống. Ví dụ: Hệ thống phải có khả năng xử lý 1000 yêu cầu cùng lúc.

  • Bảo mật (Security): Khả năng bảo vệ dữ liệu và hệ thống khỏi các truy cập trái phép. Ví dụ: Dữ liệu người dùng phải được mã hóa để bảo vệ thông tin cá nhân.

  • Độ tin cậy (Reliability): Khả năng hoạt động ổn định và liên tục của hệ thống. Ví dụ: Hệ thống phải hoạt động 24/7 với thời gian downtime tối thiểu không quá 10%.

  • Khả năng sử dụng (Usability): Mức độ dễ sử dụng và thân thiện của giao diện người dùng. Ví dụ: Giao diện phải trực quan, dễ hiểu và dễ điều hướng.

  • Khả năng bảo trì (Maintainability): Khả năng dễ dàng sửa chữa, nâng cấp và bảo trì hệ thống. Ví dụ: Code phải được viết rõ ràng, dễ hiểu và có cấu trúc tốt.

  • Khả năng mở rộng (Scalability): Khả năng mở rộng hệ thống để đáp ứng nhu cầu ngày càng tăng. Ví dụ: Hệ thống phải có khả năng xử lý lượng dữ liệu và người dùng ngày càng lớn.

  • Và các loại yêu cầu khác như kích cỡ màn hình, khả năng tương thích...


2. Tại sao Non-functional Requirements lại quan trọng?

Non-functional Requirements tuy không trực tiếp tạo ra các tính năng mới cho sản phẩm, nhưng chúng lại đóng vai trò then chốt trong việc đảm bảo chất lượng và sự thành công của sản phẩm.

Giả sử:

  • Một ứng dụng ngân hàng trực tuyến với tốc độ xử lý giao dịch chậm chạp, ì ạch sẽ dễ dàng khiến người dùng bực mình và chuyển sang sử dụng ứng dụng của ngân hàng khác.

  • Một website thương mại điện tử không bảo mật có thể bị tin tặc, hacker tấn công, dẫn đến mất mát dữ liệu của doanh nghiệp và người dùng. Giảm uy tín của doanh nghiệp.

  • Một ứng dụng có giao diện rối rắm và khó dùng có thể khiến người dùng gỡ ứng dụng chỉ sau vài thao tác sử dụng.


Vì vậy, bỏ qua Non-functional Requirements cũng giống như "xây nhà mà quên móng", sản phẩm có thể "sụp đổ" bất cứ lúc nào.


3. BA cần làm gì với Non-functional Requirements

Có rất nhiều loại NFRs khác nhau, các bạn có thể tham khảo từ file mẫu này của mình nhé. Với BA, không phải loại NFRs nào cũng cần các bạn xử lý. Bên dưới mình sẽ liệt kê các loại NFRs thường gặp, đồng thời cũng sẽ phân loại NFRs nào BA cần xử lý, follow và loại nào thì không cần.


3.1 Các loại NFRs cần BA xử lý:

  • NFRs liên quan trực tiếp đến nghiệp vụ: Ví dụ, yêu cầu về hiệu năng của hệ thống thanh toán, yêu cầu về bảo mật thông tin khách hàng, yêu cầu về khả năng sử dụng của giao diện người dùng.

  • NFRs ảnh hưởng đến trải nghiệm người dùng: Ví dụ, yêu cầu về tốc độ tải trang, yêu cầu về tính thẩm mỹ của giao diện, yêu cầu về khả năng truy cập trên các thiết bị khác nhau.

  • NFRs liên quan đến các tiêu chuẩn, quy định: Ví dụ, yêu cầu về bảo mật dữ liệu theo GDPR, yêu cầu về khả năng truy cập cho người khuyết tật theo WCAG.


Trong những trường hợp này, BA cần:

  • Chủ động thu thập và phân tích NFRs: Tìm kiếm NFRs trong các tài liệu, cuộc họp, hoặc từ những trao đổi với khách hàng, hoặc cácanh/chị BA đi trước.

  • Mô tả NFRs một cách rõ ràng và cụ thể: Sử dụng các tiêu chí đo lường được để định lượng NFRs. Ví dụ, "Hệ thống phải có thời gian phản hồi trung bình dưới 3 giây".

  • Trao đổi và thống nhất với các bên liên quan: Đảm bảo mọi người có chung sự hiểu biết về NFRs và cách thức thực hiện chúng.

  • Theo dõi và kiểm tra: Đảm bảo NFRs được đáp ứng trong suốt quá trình phát triển và sau khi sản phẩm được triển khai.

3.2 Các loại NFRs không cần BA xử lý:

  • NFRs mang tính kỹ thuật cao: Ví dụ, yêu cầu về cấu trúc database, yêu cầu về ngôn ngữ lập trình, yêu cầu về hiệu năng server. Những yêu cầu này thường do dev team hoặc kiến trúc sư phần mềm (Software Architect - SA) xử lý.

  • NFRs liên quan đến quy trình kiểm thử: Ví dụ, yêu cầu về độ bao phủ của test case, yêu cầu về công cụ kiểm thử. Những yêu cầu này thường do tester xử lý.

  • NFRs liên quan đến quản lý dự án: Ví dụ, yêu cầu về tiến độ, ngân sách, quản lý rủi ro. Những yêu cầu này thường do project manager xử lý.


Trong những trường hợp này, BA cần:

  • Hiểu rõ nội dung của NFRs: Đảm bảo bạn hiểu được ý nghĩa và tầm quan trọng của NFRs, mặc dù bạn không phải là người trực tiếp thực hiện.

  • Truyền đạt NFRs cho các bên liên quan: Đảm bảo dev team, tester, project manager hiểu rõ NFRs và có trách nhiệm thực hiện chúng.

  • Theo dõi và giám sát: Theo dõi việc thực hiện NFRs và báo cáo bất kỳ vấn đề nào cho các bên liên quan.


Non-functional requirement là một phần không thể thiếu trong quá trình phát triển một sản phẩm phần mềm. Một sản phẩm dù tính năng có tốt đến mấy mà các yêu cầu phi chức năng đều không đáp ứng được hoặc không được đáp ứng đầy đủ cũng sẽ dễ dàng làm user thất vọng và từ bỏ sản phẩm. Việc hiểu rõ, phân tích kỹ lưỡng và quản lý hiệu quả NFRs giúp BA tạo ra những sản phẩm chất lượng tốt hơn, góp phần mang lại thành công cho dự án. Hy vọng bài chia sẻ trên sẽ giúp bạn phần nào hiểu rõ hơn về NFRs cũng như tầm quan trọng của loại yêu cầu này.

 
 

Comentarios


  • Facebook
  • LinkedIn

TankClass

bottom of page