Hế lô anh em, ở phần trước anh em đã hiểu thế nào là Functional RequirementNon-Functional Requirement (NFR).

Tiếp tục bài này mình sẽ điểm qua các loại Non-Functional Requirement mà anh em BA mình hay gặp nhất. Cũng đơn giản, không có gì phức tạp lắm, tầm… 23 loại thôi anh em.

“23 loại…”

Đùa chứ 23 loại nhưng ngắn gọn, dễ hiểu lắm :3

BABOK v3.0 thì chia NFR làm 15 loại. Tuy nhiên, mình thấy có vài cái hơi khó hiểu, và đâu đó vẫn chưa cover được hết các trường hợp mình gặp, nên mình có làm lại danh sách dưới đây.

Danh sách 23 loại Non-Functional Requirement dưới đây là mình tổng hợp từ BABOK v3.0, từ trang Requirement Quest, từ template của một số công ty và từ kinh nghiệm thực tế mà mình từng trải.

Thứ tự quan trọng giảm dần nhé anh em.

Ô kê lét sờ gâuuuu 😎

 

1. Security

NFR 1: Security (Nguồn ảnh: SLANE Cartoons)

Security là các yêu cầu về bảo mật trong quá trình sử dụng hệ thống. Từ lúc truy cập, thực hiện thao tác, in ấn chứng từ, đến lúc đăng xuất khỏi hệ thống.

Ví dụ về Security:

  • Password của người dùng phải được hash bằng MD5.
  • Hệ thống sẽ deactivate 30 phút nếu người dùng nhập password sai 5 lần liên tiếp.
  • Tất cả những data “nhạy cảm” của người dùng như: password, SĐT, CMND, email phải được mã hóa bằng 1024bit SSL.
  • Khi user quên mật khẩu, link tạo mật khẩu mới phải được gửi về duy nhất địa chỉ email đăng ký đầu tiên.
  • Hoặc khi user thực hiện thanh toán online, hệ thống không được phép lưu trữ thông tin thẻ credit/ debit của user.

 

2. Performance

Phần này có lẽ quá rõ ràng với anh em rồi chứ hả 😎 Performance tức là hiệu suất hoạt động của hệ thống, và thường được đo lường bằng những tiêu chí sau:

  • Thời gian phản hồi cho một transaction
  • Số lượng transaction thực hiện được trong mỗi giây
  • Công suất (capacity), ví dụ số lượng transaction mà hệ thống có thể lưu trữ/ thực hiện cho mỗi đối tượng.
  • Hoặc các yếu tố về tài nguyên sử dụng như: RAM, dung lượng DB…

Một số ví dụ để anh em hình dung rõ hơn về Performance khi lấy yêu cầu từ khách hàng (ví dụ mình tham khảo từ công ty HN):

Tất cả những màn hình input và output dữ liệu cần phải được sẵn sàng để hiển thị cho người dùng trong vòng 3 giây, với điều kiện tải và connection giữa cilent/server là bình thường, cụ thể:

  • Đối với màn hình input: tối đa 30 trường dữ liệu, không tính toán dữ liệu phức tạp, không tương tác với hệ thống ngoài, có thể lưu trữ dữ liệu trực tiếp ngay xuống DB, và không lưu trữ các tệp nội dung lớn như: hình ảnh, video, tệp tin quá 3MB.
  • Đối với màn hình output: dữ liệu được query trực tiếp từ DB, hạn chế những query phức tạp, những query từ hệ thống ngoài.
    Hiển thị tối đa 50 dòng dữ liệu, mỗi dòng tối đa 10 cột, và mỗi dữ liệu có độ dài nhỏ hơn 100 ký tự
  • *Điều kiện tải bình thường: 30 CCU (concurrent user – người dùng đồng thời) khi không dùng cân bằng tải.
  • *Điều kiện server tối thiểu: Intel Core i5, 4GB RAM, 500GB hard disk.
  • *Client/ Server Connection: 500KB/s

Đối với những anh em làm software development, những điều trên là tối quan trọng. Nhưng đối với anh em làm triển khai, thì những điều trên có vẻ hơi… thừa.

Vì hãng đã lo những thứ này cho mình hết, mình chỉ giải thích cho khách hàng hiểu để tránh yêu cầu mở rộng sau này.

Tuy nhiên, cũng không nên lơ là mà bỏ nó ra khỏi document. Mình cũng đã từng như vậy. Hệ thống khi đó phải query tới rất nhiều những component bên ngoài cho từng transaction một.

Và dĩ nhiên, performance bị kéo tụt hẳn xuống dưới đáy và mình bị complain rất nhiều về vấn đề này. Lỗi do ai? Chính là do mình, do BA không làm rõ những vấn đề này ngay từ đầu. Don’t be like me!

 

3. Usability

Làm rõ các yêu cầu về Usability là sẽ giúp user happy hơn rất nhiều 🙂

Là một trong những NFR quan trọng bậc nhất, Usability chính là khả năng “dễ sử dụng” của hệ thống.

Nói về tính “dễ sử dụng” thì có 5 yếu tố sau, anh em có thể dựa vào đó để xác nhận yêu cầu với khách hàng.

(Xác nhận chứ không phải lấy yêu cầu, vì thường khách hàng họ cũng chả mấy khi để ý đến vấn đề này, trừ khi anh em đang làm product với end user cũng chính là end consumer).

 

a) Effectiveness

Là tính hiệu quả, làm được đúng những gì kỳ vọng.

Ví dụ user muốn xem hàng tồn kho thì thay vì user chọn menu On-hand >> rồi chọn kho để xem, thì hãy hiển thị số lượng tồn kho ngay bên cạnh tên kho để user có thể xem được ngay, mà không cần nhấp thêm phát nữa.

 

b) Efficiency

Cũng là tính hiệu quả, nhưng ngụ ý nhanh hơn, nguy hiểm hơn, thông minh hơn; nói chung là nhanh và chính xác hơn.

Ví dụ BA chúng ta phải thiết kế làm sao để: giảm thiểu tối đa thao tác của users trên màn hình để họ hoàn thành 1 task trên hệ thống nhanh nhất có thể.

Ví dụ từ 5 chạm, giảm xuống còn 3 chạm là có thể order xong ly trà sữa. Hoặc nút bấm có label rõ ràng để user hiểu ngay được hành động sau khi bấm nút.

Nguồn ảnh: uxmovement.com

c) Engagement

Là mức độ: UI của hệ thống “tương tác” với khách hàng như thế nào. Không chỉ đẹp, mà còn phải phù hợp với đối tượng end user và ngữ cảnh sử dụng.

Ví dụ hệ thống quản lý sản xuất thì không thể nào design trông như concưng.com được.

Nó tạo ra chút cảm xúc hơi hơi cu te chút xíu, mà những người làm planning trong sản xuất trên dưới 30 tuổi không hề mong đợi một hệ thống như vậy.

 

d) Error Tolerance

Tolerance là mức độ “dễ tha thứ” của hệ thống. Nghe thấy hài quá, để ví dụ cho anh em dễ hình dung.

Ví dụ khi tạo khách hàng, user nhập 20 trường thông tin, rồi nhấn nút Save. Khi đó, hệ thống tiến hành kiểm tra và phát hiện có 3/20 trường dữ liệu bị nhập sai kiểu dữ liệu.

Lúc này hệ thống thấy ghét quá, chơi xóa hết cha nó 20 dữ liệu mà user đã nhập, yêu cầu user nhập lại từ đầu, zậy mới ác chứ.

Đó là khi Error Toletance của hệ thống cực kỳ thấp.

Thay vào đó, hãy kiểm tra kiểu kiểu dữ liệu ngay trên từng field, và cảnh báo ngay nếu có lỗi, đừng bắt user nhập đi nhập lại nhiều lần.

 

e) Easy to learn

Là tính “dễ học” của hệ thống. Thường người ta sẽ nhìn vào độ consistent (độ nhất quán) của các form màn hình để đánh giá.

Ví dụ ở form màn hình Khách hàng, thanh Navigation ở vị trí A, thanh Command ở vị trí B, nút NEW ở vị trí C. Mà qua form màn hình Đơn hàng, thanh Navigation thì ở vị trí C, thanh Command ở vị trí A, nút New ở vị trí B, là coi như xong phim user luôn.

Họ không thể nhớ được, và cũng chả cần phải nhớ.

Phần nhiều các NFR thuộc nhóm Usability là mang kiến thức của UX, anh em có thể tham khảo thêm về Usability tại đây nhé.

 

4. Integrity

Mục này là nói về “độ chính trực” của dữ liệu. Tức độ chính xác, xác thực của dữ liệu.

Ví dụ từ dữ liệu A được input vào hệ thống, nó xử lý hầm bà lằng ra kết quả A’, A”, rồi sang B, C, D, D’, D” rồi ra E, cộng với F, chia cho G rồi tham chiếu với H để ra được một kết quả J cuối cùng.

Trong quá trình xử lý dữ liệu A để ra được dữ liệu “J” cuối cùng, hệ thống sẽ có các bộ batch jobs chạy ngầm bên dưới, chạy đồng bộ và cả bất đồng bộ.

Nói về integrity, khách hàng sẽ yêu cầu dữ liệu phải được tính toán chính xác tại-tất-cả-các-thời-điểm. Chứ không phải lúc này dữ liệu ra chính xác, lúc kia dữ liệu ra sai.

Nói thì nghe mắc cười quá, vì máy tính chứ có phải con người tính đâu mà lúc đúng lúc sai.

Nhưng thực tế đối vối những công thức phức tạp, đòi hỏi lấy dữ liệu từ nhiều nguồn thì chuyện này là có xảy ra chứ không phải không.

Như cá nhân mình đã từng gặp một trường hợp: để ra được con số thành tiền cuối cùng, hệ thống phải lấy toàn bộ thông tin đơn hàng, request đến dữ liệu khuyến mãi bên ngoài hệ thống để lấy giá, discount, hàng tặng các kiểu, rồi tính toán thêm 4-5 parameters gì nữa để ra được giá cuối cùng.

Trong quá trình tính toán này có các batch job chạy bất đồng bộ, đòi hỏi 1 đoạn thời gian khoảng 30s đến 1 phút mới chạy xong hoặc người dùng phải chịu khó bấm nút force các job đó thì nó mới chạy.

Khi những job này không chạy thì vô tình những batch job chạy đồng bộ khác nó overlap lên, thế là kết quả bị thiếu đi 1-2 phép tính gì đó, nên kết quả lúc ra sai, lúc ra đúng.

Ra kết quả sai là khi user refresh màn hình ngay, ra kết quả đúng là khi user chờ khoảng 30s rồi mới refresh màn hình hoặc chờ cho hệ thống tự refresh.

Lúc này thì thôi rồi, chỉ có đội quần chứ nói năng gì nữa. Hệ thống làm gì mà lúc ra sai, lúc ra đúng. Từ đó nó tạo ra tâm lý ngờ vực rất lớn của khách hàng về giải pháp mình mang lại.

Do đó, anh em cần phải thống nhất rõ với khách hàng về độ “integrity” – độ “chính trực” của dữ liệu trong những bối cảnh, những khoảng thời gian nhất định.

Nhớ nhé anh em, Integrity!

 

5. Availability

Availability là các yêu cầu về: mức độ hệ thống sẵn sàng để được sử dụng, gồm 2 yếu tố: 

  • Thời gian có thể sử dụng hệ thống
  • Các yếu tố phụ thuộc để vận hành hệ thống.

Ví dụ về thời gian nhé: Hệ thống phải đảm bảo vận hành 24/7, nâng cấp tối đa 1 lần trong vòng 3 tháng, downtime mỗi năm không quá 1 giờ đồng hồ.

Còn về các yếu tố phụ thuộc thì mình cũng bị nhiều trường hợp.

Ví dụ hệ thống của mình đang cài thêm một “Add-on” hoặc một ứng dụng nào được built bởi bên thứ ba, thì NFR ở đây có thể là: Hệ thống phải đảm bảo vận hành 24/7 và không phụ thuộc vào sự ngưng hoạt động của bất kỳ sản phẩm đến từ bên thứ 3 nào. 

 

6. Audit

Audit là các yêu cầu về khả năng ghi nhận lại các tác vụ đã thực hiện trên hệ thống, nhằm mục đích kiểm tra. Nhớ nhé anh em, chỉ nhằm mục đích kiểm tra, không phải để thống kê hay báo cáo.

Ví dụ về Audit:

  • Dữ liệu audit được sẽ lưu trữ tách biệt trong một database riêng, khác database chính của hệ thống.
  • Dữ liệu hệ thống phải được backup hằng ngày, và tồn tại trong vòng 30 ngày.
  • Các dữ liệu audit được phải ở chế độ Read Only và không được sửa từ giao diện người dùng.

 

7. External Interface

Phần này nôm na nghĩa là tích hợp.

Anh em sẽ elicit các yêu cầu cụ thể của khách hàng về vấn đề: tích hợp các components ở hệ thống đang build với các components ở các hệ thống khác như thế nào.

Vì chuyện tích hợp (integration) là cực kỳ quan trọng trong bất kỳ dự án nào, nên thường mình thấy phần mô tả requirement về tích hợp sẽ được tách riêng ra một phần riêng biệt trong document.

Phần này anh em sẽ mô tả một bức tranh tổng quan cho việc trao đổi dữ liệu giữa các system, bao gồm: những component nào được trao đổi, mục đích làm gì, tần suất thay đổi ra sao, số lượng người dùng tác động…

Anh em sẽ phối hợp với Tech Lead/ PM để mô hình hóa lại bức tranh tích hợp dữ liệu của khách hàng

Tuy nhiên ở phần External Interface, anh em cũng có thể thêm 1 vài yêu cầu chi tiết mà mình elicit được từ phía khách hàng như:

  • Toàn bộ dữ liệu phải được tích hợp qua API
  • Và các API phải trả kết quả ra dạng JSON hoặc XML
  • Hoặc toàn bộ quá trình nhận/ gửi dữ liệu giữa các hệ thống phải được mô tả chi tiết trong document.

 

8. User Interface

Có thể anh em sẽ dễ nhầm lẫn giữa NFR Usability và User Interface. Nó đều đa phần thể hiện ở giao diện người dùng. Nhưng:

  • Usability mang nghĩa rộng hơn về tính “dễ sử dụng”, nó có thể là cải thiện UI, thay đổi cấu trúc dữ liệu, hoặc thậm chí là thay đổi luồng data đi trong hệ thống.
  • Còn User Interface chỉ đơn thuần là những yêu cầu về giao diện người dùng mà Khách hàng mong muốn, bao gồm:
    • Cấu trúc UI
    • Cảnh báo và thông báo lỗi
    • Một số yêu cầu khác.

Một số ví dụ về User Interface như sau:

  • Các lưới dữ liệu xuất hiện trên hệ thống đều phải có chức năng filter và sort.
  • Hệ thống đều phải hỏi xác nhận (Y/N) cho các thao tác xóa dữ liệu.
  • Tất cả các thông báo lỗi đều phải đưa ra các hướng dẫn khắc phục cho người dùng.
  • Khuyến khích vertical scrolling, hạn chế tối đa horizontal scrolling.
  • Giao diện màn hình luôn có độ phân giải mặc định 1024×768 pixels.
  • Đối với các quy trình tuần tự qua nhiều bước, phải có progess bar kèm thông tin chi tiết.
  • Toàn bộ drop down list phải được sắp xếp theo thứ tự A to Z và số tăng dần.

Câu thần chú nổi tiếng khi làm bất kỳ UI mockup nào. (Nguồn từ: Hugh Macleod)

 

9. Migration

Migration là NFR quy định về việc migrate dữ liệu từ hệ thống cũ sang hệ thống mới.

Migrate dữ liệu tức là chuyển dữ liệu, đồng bộ dữ liệu từ hệ thống này, môi trường này, sang hệ thống khác, môi trường khác.

Ví dụ: Chuyển toàn bộ 250,000 dữ liệu khách hàng; 12,500 dữ liệu sản phẩm và 500 dữ liệu bảng giá từ hệ thống ABC cũ sang hệ thống ABC mới.

Cái này anh em phải, phải làm rõ ngay từ đầu. Vì chuyện migrate data không hề đơn giản tí nào. Mình đã từng rất tơi tả vì ôm đồm tới hơn 180,000 dòng dữ liệu sản phẩm đưa qua hệ thống mới bằng… excel.

 

10. Supportability

Supportability mô tả những yêu cầu về môi trường/ nền tảng mà hệ thống chạy tốt trên đó.

Ví dụ về supportability của sản phẩm Dynamics 365.

Các thiết bị, nền tảng mà giải pháp Dynamics 365 hỗ trợ (Nguồn ảnh: Microsoft).

 

11. Compliance

Compliance nghĩa là tuân thủ, làm đúng.

Tức compliance là các yêu cầu về việc hệ thống phải đảm bảo tuân thủ theo đúng những quy định của pháp luật, quy định của nhà nước, luật công ty, luật tài chính, luật đất đai, luật môi trường, luật bảo vệ trẻ em, động vật quý hiếm, abc, xyz…

Phần compliance này thường sẽ bao trùm luôn những quy định chung nhất, ví dụ quy định của các tổ chức thanh toán quốc tế, quy định hàng hải, vận tải đường biển, vâng vâng…

 

12. Flexibility

Là yêu cầu về khả năng linh hoạt của hệ thống, có thể thích ứng với bất kỳ “môi trường” nào.

Từ môi trường ở đây có thể là: ở các tổ chức khác nhau, phạm vi địa lý khác nhau, hoặc là những ngành nghề khác nhau.

Ví dụ sản phẩm Microsoft Dynamics 365 là giải pháp có thể đáp ứng flexibility requirement của bất kỳ khách hàng khó tính nào.

Vì đây là gói giải pháp áp dụng được ở rất nhiều ngành nghề khác nhau: từ manufacture, đến media, banking, hay kể cả healthcare. Chưa kể nó được áp dụng trên rất nhiều quốc gia, trải khắp thế giới.

Độ flexible của Dynamics 365, khi có tới hơn 120 quốc gia có thể áp dụng với mức độ hiệu quả hoạt động ngang nhau, ở Việt Nam cũng như ở Mỹ, không thua kém gì nhau. (Nguồn ảnh: Microsoft)

Ví dụ khách hàng có 5 location trên khắp thế giới: Việt Nam, Lào, Campuchia, Mông Cổ và Ả rập sau đi. Lúc này giải pháp của anh em phải mang tính flexible. Tức là triển khai ở Việt Nam được, thì triển khai ở Ả rập sau đi vẫn được.

Ví dụ giải pháp anh em build có hỗ trợ chữ Latin ==> Việt Nam, Mông Cổ ô kê.
Nhưng lại không hỗ trợ chữ tượng hình ==> Lào, Campuchia, Ả Rập tèo ngay. Ví dụ vậy.

Do đó, Dynamics 365 là một ví dụ điển hình cho việc đáp ứng flexibility requirement của khách hàng.

Ô kê, một vài phút quảng cáo trơ trẽn cho Dynamics 365 đã hết, chuyển qua phần tiếp theo nhé anh em :3

 

13. Scalability

Scalability là khả năng mở rộng của system.

Ví dụ với một trang e-commerce hiện tại, hệ thống có thể proceed được 500 orders cùng một lúc, thì anh em có thể có nhiều cách để thiết kế lớp back end phía sau.

Tuy nhiên, nếu khách hàng họ “tà loòng thêm” yêu cầu về khả năng: có thể scale up sau 2 năm hoạt động, thì lúc này lớp back end phải được thiết kế khác.

Ở Non-Functional Requirement này, anh em sẽ ghi nhận những yêu cầu chi tiết về độ scale up mà họ muốn trong tương lai (dĩ nhiên là nếu được :v).

Một số ví dụ cụ thể:

  • Server có khả năng upgrade cấu hình.
  • Có khả năng tách DB trên một server riêng và backend trên một server riêng.
  • Có khả năng áp dụng load balancer chạy bằng HA Proxy.
  • Có khả năng chia nhỏ DB master thành các DB con và đồng bộ ngược trở lại.

 

14. Extensibility

So với Scalability là mở rộng về tần suất hoạt động, thì Extensibility là mở rộng về phạm vi chức năng của giải pháp.

Tức khả năng phát triển thêm những tính năng mới mà không làm ảnh hưởng tiêu cực đến các tính năng cũ.

Ví dụ về Extensibility:

  • Có khả năng phát triển thêm module quản lý chi phí Marketing cho kênh bán lẻ mà không thay đổi cấu trúc dữ liệu cũ.
  • Có khả năng phát triển tính năng kiểm hàng tồn kho mà không thay đổi cấu trúc dữ liệu cũ.

 

15. Localization

Trong danh mục các NFR, Localization là cái mình nghĩ sẽ ít được quan tâm nhất, nhưng lại đóng yếu tố rất quan trọng. Nghe lạ lùng vậy đó.

Nó ít được quan tâm phần nào có lẽ vì nó đã khá… rõ ràng.

Localization nghĩa là các yêu cầu về “tính bản địa” của giải pháp mình đang làm. Cụ thể nó là các yếu tố liên quan đến:

  • Ngôn ngữ địa phương, phát âm
  • Luật pháp bản địa
  • Đơn vị tiền tệ bản địa
  • Văn hóa
  • Hoặc thậm chí là các đặc thù trong tính cách của end-users, người trực tiếp sử dụng hệ thống.

Ngôn ngữ địa phương thì có thể bỏ qua, vì thời buổi giờ thì hầu như system nào cũng hỗ trợ đa ngôn ngữ. Tiếng Anh là ngôn ngữ chung của IT – là thứ chắc chắn phải có. Còn lại sẽ là ngôn ngữ địa phương.

Nhưng cần chú ý là end-users là nhóm người sử dụng British English, hay American English. Cái này cũng đem lại trải nghiệm người dùng rất khác biệt.

Phát âm cũng vậy. Behaviour hay behavior cũng là vấn đề à nha. Mấy điểm này phải moi móc thông tin từ khách hàng hết, xem họ yêu cầu như thế nào.

Luật pháp là cái quan trọng nhất. Ví dụ anh em triển khai module kế toán cho 1 doanh nghiệp ở Việt Nam khác hẳn hoàn toàn triển khai cho 1 doanh nghiệp ở Venezuela. Vì sổ sách kế toán, các bộ luật, và chứng từ liên quan đến nghiệp vụ kế toán ở 2 location là hoàn toàn khác nhau.

Tương tự là văn hóa, hoặc tính cách của end-users. Cái này sẽ hơi thiên về UX, mình không rành lắm, nên mình sẽ để một cái link ở đây, anh em tự tìm hiểu nhóe.

Tuy nhiên, giờ thế giới đa phần lên mây hết. Các SaaS được thiết kế thành các package rất flexible, hỗ trợ yếu tố Localization rất nhiều. Nên hầu như NFR này không được quan tâm nhiều lắm ở thời điểm bấy giờ.

 

16. Purchased Component

Tiếp theo, Purchased Component các NFR mô tả các component có trong hệ thống mà khách hàng phải trả tiền để sử dụng, bao gồm việc mô tả tính nănghạn chế của các components này.

Ví dụ: Mình triển khai hệ thống Dynamics 365 Customer Engagement (CRM) cho khách hàng, thay vì việc khách hàng muốn mình build mới giải pháp Loyalty – Quản lý khách hàng thân thiết trên CRM, thì họ mong muốn mình mua một giải pháp Loyalty có sẵn và trả tiền theo subscription hàng tháng, để tiết kiệm thời gian triển khai và để họ đưa vào sử dụng càng nhanh càng tốt.

Khi đó, BA phải mô tả rất chi tiết về yêu cầu sử dụng giải pháp Loyalty có sẵn này như một “Purchased Component”. Tính năng nó ra sao, hạn chế của nó như thế nào, khả năng thích ứng của nó với các phiên bản Dynamics 365, rồi nâng cấp ra sao, vâng vâng và mây mây.

 

17. Maintainability

Maintainability là các yêu cầu về khả năng bảo trì hệ thống. Tức là hệ thống có: dễ dàng được phát hiện ra lỗisửa lỗi hay không.

“Dễ dàng được phát hiện ra lỗi và sửa lỗi” nghĩa là khi gặp bug, Admin có thể dễ dàng biết được nguyên nhân tại sao, và nắm được hướng khắc phục ngay.

Để làm được điều đó thì lớp behind the scenes bên dưới phải không được quá phức tạp, rối rắm. Coding phải có convention rõ ràng, gọn, sạch, đẹp. Document phải rõ ràng từng module, từng feature. Thì team maintain – support mới có thể làm tốt công việc sau này được.

Ví dụ một số yêu cầu về Maintainability:

  • Với mỗi lần nâng cấp hệ thống định kỳ hàng quý sẽ không kéo dài quá 30 phút.
  • Toàn bộ code Javascript và .NET phải được viết theo coding convention của ABC XYZ.
  • Document và code phải được review nội bộ qua 2 cấp.

 

18. Safety

Đây đây đây…

Đây là cái mình nghĩ sẽ ít ai nghĩ tới, vì nó quá độc lạ và đặc biệt là ít dùng.

Safety là một NFR mô tả các yêu cầu về việc: hệ thống không được làm hại đến môi trường hoặc sức khỏe của con người trong mục đích sử dụng.

Ví dụ: hệ thống quản lý khám chữa bệnh cho bênh viện ABC, các đơn thuốc trước khi được in ra và gửi cho bệnh nhân phải được bác sỹ tự tay nhấn nút Approve trên hệ thống.

Vì nếu đơn thuốc được y tá hoặc hệ thống phát hành hàng loạt, mà không có sự kiểm duyệt của bác sỹ thì rất nguy hại đến… bệnh nhân vì có thể sẽ có sai sót xảy ra (ảnh hưởng đến sức khỏe con người).

Đó là nội dung chính của mục NFR Safety này.

 

19. Legal and Copyright

Phần này cũng lại quan trọng mà thường mình thấy mọi người ít khi để ý, đặc biệt là mình hê hê.

Đó là chuyện legal và các mẫu copyright liên quan.

Legal & Copyright là một NFR quy định các thủ tục pháp lý cần thiết, quy định sử dụng wordmark, trademark hay quy định sử dụng logo của khách hàng như thế nào cho đúng.

Ví dụ về Legal & Copyright NFR (ví dụ mình tham khảo từ công ty HN):

Tất cả các quyền sở hữu trí tuệ (Intellectual Property Rights – IPR) tồn tại hoặc liên quan đến sản phẩm hoặc tài liệu đính kèm được tạo bởi HN, thì đều là kết quả của gói dịch vụ và được sở hữu bởi khách hàng.

 

20. Installability

Cái tên nói lên tất cả. Installability là các yêu cầu về cài đặt hệ thống. Cài đặt ở đây bao gồm: cài đặt mới, cài đặt lại, nâng cấp, và xóa cài đặt.

Non-Functional Requirement về Installability nói đến các yêu cầu về quá trình cài đặt, ví dụ: quy trình cài đặt không được quá mấy bước, ai là người cài đặt, họ cần có những kiến thức tối thiểu về ngôn ngữ gì, platform, công cụ gì? PHP, C#, JS…

Ví dụ NFR về Installability:

  • Việc cài đặt hệ thống cho người dùng phải được thực hiện bởi đối tác phát triển phần mềm hoặc Quản trị viên hệ thống của khách hàng có ít nhất 3 năm kinh nghiệm làm C# và các thư viện liên quan.
  • Hoặc việc nâng cấp plugin sẽ không làm thay đổi dữ liệu và cấu trúc dữ liệu của hệ thống.

 

21. Accessibility

Accessibility là các yêu cầu về khả năng hỗ trợ người dùng sử dụng hệ thống, đặc biệt là dành cho những người khiếm khuyết.

Ví dụ về Accessibility:

  • Hệ thống e-Learning hỗ trợ các khóa học phiên bản TEXT cạnh bản AUDIO dành cho người khiếm thính.
  • Với những người khiếm thị, hệ thống hỗ trợ điều khiển qua giọng nói.

Hệ thống có nhiều chức năng hỗ trợ người dùng (đặc biệt là người khiếm khuyết) sử dụng hệ thống hay không? (Nguồn ảnh: Leewilson)

 

22. Reusability

Reusability là các yêu cầu về khả năng có thể tái sử dụng của một hoặc nhiều phần trong hệ thống.

Ví dụ: với các trang e-commerce thì mục Frequently Asked Questions lúc nào cũng có. Đây là thứ khách hàng có thể yêu cầu để sau này họ có thể dùng source code đó để build các trang e-commerce khác cho các công ty con chẳng hạn.

 

23. Online Manual

Online Manual là các NFR quy định về các chức năng hỗ trợ người dùng trực tuyến ngay trên hệ thống.

Đa phần là các nút HELP ngay ở góc phải bên trên màn hình. Khi người dùng bấm vô thì mở ra một trang online documentation, lưu trữ toàn bộ tài liệu hướng dẫn để người dùng tham khảo ngay tức thì.

Hoặc khi người dùng thực hiện một thao tác lỗi, hệ thống hiển thị một popup message hướng dẫn cách khắc phục ngay.

.

.

.

KẾT BÀI

Vậy là tất tần tật mình đã giới thiệu qua về 23 loại Non-Functional Requirement. Hi vọng không ít thì nhiều, nó sẽ giúp ích được anh em trong công việc.

Nếu có gì thắc mắc hay muốn trao đổi gì thêm thì anh em cứ comment bên dưới, hoặc email trực tiếp cho mình nhé.

Hẹn gặp lại anh em ở những notes sau 😎

See yaaaaa!!!