Non-Functional Requirements và chuyện về cái xô bể
Non-Functional Requirements và chuyện về cái xô bể
Chuyện là nhà mình có cái xô bể, chắp vá cũng được 7-8 lớp. Về bản chất, nó vẫn đựng nước được. Nhưng ngoài điểm đó ra, nó trông như đồ bỏ.
Mẹ mình thì vẫn khoái dùng cái xô này, và không nỡ vứt nó đi :3
Nhưng mỗi lần về quê mình lại chẳng muốn dùng nó tí nào? Kỳ cục zậy đó? Cùng là một cái xô bể, nhưng có người muốn dùng, có người không.
Đó là vấn đề của Quality of Service. Ánh xạ qua thế giới phần mềm, nó chính là Non-Functional Requirement 
Nội dung [Hide]
- 1. Các loại requirement trong một dự án phần mềm
- 2. Functional Requirement là gì?
- 3. Non-Functional Requirement là gì?
- 3.1. Non-Functional Requirement quan trọng đến mức nào?
- 3.2. Non-Functional Requirement tạo ra GAP lớn giữa…
- 4. Các loại Non-Functional Requirement?
1. Các loại requirement trong một dự án phần mềm
Như anh em đã biết, hoặc chưa biết: một giải pháp, một sản phẩm, hay một phần mềm nào đó đều có các yêu cầu cụ thể (requirement) cho các giải pháp, sản phẩm hay phần mềm đó.
Là một người làm Business Analyst, chúng ta sẽ làm rất nhiều thứ xoay quanh các requirement này.
Requirement thì có 4 loại:
- Business Requirement
- Stakeholder Requirement
- Solution Requirement
- Transition Requirement.
Bất kỳ phần mềm nào cũng vậy? Sinh ra đều phải có mục đích. Tức mỗi phần mềm đều có các yêu cầu của riêng nó. Mà các yêu cầu này không phải là ít.
Một phần mềm có rất-rất-rất nhiều yêu cầu. Nào là phải làm được cái này, cái kia, nào là phải đẹp, phải nhanh, phải abc, xyz…
Chính vì có quá nhiều requirement, xuất phát từ nhiều đối tượng khác nhau. Lộn xộn quá, nên người ta mới gom nó lại, rồi chia thành 4 loại requirement như trên, để anh em BA chúng ta có thể dễ dàng moi móc và quản lý được nó.
Cụ thể 4 loại nó như thế nào thì mình sẽ để dành nói ở bài sau. Bài này mình sẽ tập trung nói về Solution Requirement.
Ô kê, Solution Requirement được chia nhỏ thành 2 loại sau:
- Functional requirement
- và Non-Functional requirement.
Có một số ví dụ cho anh em dễ hình dung hơn:
Ly nước:
- Functional Req: ly đựng được nước
- Non-Functional Req: ly rớt không bể.
Mũ bảo hiểm:
- Functonal Req: có đèn chiếu sáng, nhấp nháy lòe loẹt trong đêm
- Non-Functional Req: chịu được lực va đập lên tới 3000 Newton.
Ly chè đậu đen của bà Bảy đầu xóm:
- Functional Req: chóng đói, bổ sung vitamin đậu đen.
- Non-Functional Req: ăn xong có khăn giấy lau miệng, hoặc ăn xong không đau bụng.
Phần mềm ABCDXYZ:
- Functional Req: quản lý thông tin khách hàng
- Non-Functional Req: có nút Help – hướng dẫn người dùng online ngay trên hệ thống.
Đó là một vài ví dụ để anh em hình dung được thế nào là Functional Req và Non-Functional Req.
Vậy Functional Requirement là gì?
2. Functional Requirement là gì?
Functional Requirement là:
The capabilities that a solution must have in terms
of the behavior and information that the solution will manage
BABOK ver3.0
Trên là định nghĩa của BABOK, nhưng thôi, đọc nghe dài dòng tùm lum tùm la quá. Rút gọn lại anh em có thể hiểu Functional Requirement là những thứ mà giải pháp có thể làm được.
Hay cụ thể hơn, Functional Requirement là nói về: Behaviors và Functions (Hành vi và Chức năng) của giải pháp.
Ví dụ:
- Ly thì phải đựng được nước
- Mũ bảo hiểm phải có đèn phát sáng
- Ly chè ăn zô là đỡ đói
- Hệ thống ABCDXYZ quản lý được thông tin khách hàng.
Vậy còn lại.
3. Non-Functional Requirement là gì?
BABOK ver3.0 định nghĩa Non-Functional Requirement như sau:
Not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.
BABOK ver3.0
Lại dài loằng ngoằng, nhưng không sao, đọc cũng dễ hiểu. Càng về sau BABOK định nghĩa càng dễ hiểu mà, hehe.
Non-Functional Requirement là những thứ:
- Không liên quan trực tiếp tới hành vi – chức năng của giải pháp
- Nhưng lại là các điều kiện giúp hệ thống chạy tốt và đảm bảo được chất lượng như yêu cầu.
Rút gọn 2 dòng trên, mình có cách định nghĩa trực quan hơn như sau:
Non-Functional Requirement = Quality of Services
Tức Non-Functional Requirement là những thứ liên quan đến CHẤT LƯỢNG sản phẩm.
Sản phẩm đó đáp ứng được mục đích sử dụng là 1 chuyện, nhưng nó phải đảm bảo tốt về mặt trải nghiệm người dùng thì mới thật sự đẳng cấp
3.1. Non-Functional Requirement quan trọng đến mức nào?
Quay lại cái xô ở đầu bài. Xô, là giải pháp để đựng nước và được dùng cho các mục đích khác nhau.
- Functional Req của cái Xô là đựng được nước. Chỉ nhiêu đó thôi.
- Còn Non-Functional Req của cái Xô là: xô làm bằng nhựa không giòn, phơi nắng không bể, không mọc rêu, không trơn, kiểu dáng thon gọn, vừa tay cầm.
Rõ ràng, cái xô ở nhà mình chỉ đạt được mỗi Functional Requirement, còn Non-Functional Requirement thì.. thấy gớm.
Mẹ mình thích dùng vì mẹ mình chỉ quan tâm đến Functional Requirement, tức là chức năng của nó, chỉ cần đựng được nước là được.
Còn mình không thích dùng vì nó không đáp ứng được Non-Functional Requirement, những requirement mà đáng lý ra một cái xô phải có. Đã zậy, còn lủng lỗ, chấp vá tùm lum tùm la, thấy ớn.
Điều này nói lên được vấn đề gì?
Nó nói lên được: User họ quan tâm điều gì?
À há…
Mấu chốt là ở chỗ này.
Nếu user giống mẹ mình, không care nhiều đến Non-Functional, ok anh em trong vùng an toàn.
Cứ thoải mái, chỉ cần cho hệ thống chạy được là được. Tức là hệ thống chỉ cần làm được những thứ mà khách hàng yêu cầu là được.
Còn nếu user giống mình, rất rất quan tâm đến Non-Functional thì…, well, có vẻ hơi mệt với anh em. Đối với họ, không những hệ thống phải chạy được, mà hệ thống còn phải chạy nhanh, gọn, và đẹp nữa.
Và một khi mình nắm được mức độ kỳ vọng của users, mình sẽ biết cách làm họ hài lòng hơn.
Đã không ít lần mình và đồng bọn đang bon bon về đích, tưởng chừng sẽ Go-Live êm xuôi trót lọt. Mà phải khựng lại cả thảy 4-5 lần cũng chỉ vì cái chữ Non-Functional Requirement này.
Khách hàng liên tục complain về nhóm users sử dụng iPad nhập liệu quá lâu, và touch quá nhiều trên màn hình để có thể… hoàn thành được một giao dịch.
Hay việc tìm kiếm các keyword trên hệ thống cũng gặp trở ngại.
Ví dụ, có một dữ liệu mang tên: “Chú Bảy đẹp chai cute hột me tốt bụng”. Thì khi user nhập keyword: “đẹp chai me” thì hệ thống không tìm ra kết quả.
Nhưng nếu user nhập keyword: “đẹp chai cute hột me” thì kết quả mới nhả ra. Tức hiện tại hệ thống chỉ tìm được kết quả theo các keyword là một string theo đúng thứ tự từ trái sang phải.
Trong khi users họ lại muốn: chỉ cần nhập keyword “đẹp chai me”, thì hệ thống sẽ nhả ra tất cả các kết quả chứa 3 từ khóa “đẹp”, “chai”, và “me” riêng biệt, không cần care đến thứ tự. Ví dụ:
- Ông Sáu đẹp chai cute hột me khiêm tốn
- ABC đẹp cute chai me hột khiêm tốn
- XYZ đẹp me chai cute khiêm tốn hột…
Rõ ràng đó chính là các Non-Functional Requirement mà mình, một người BA không hề nắm được, cũng như không làm rõ ngay từ đầu, khiến cho anh em tốn khá nhiều effort để setup lại mọi thứ cho phù hợp với các “quality of services” này.
Đau thương, chỉ có thể chốt lại được bằng từ đau thương 
….
Do đó nếu có ai hỏi mình: Non-Functional Req quan trọng đến mức nào? Thì mình tự tin trả lời ngay: quan trọng như Functional Requirement vậy.
Nhiều lúc chưa cần quan tâm behind the scenes chạy như thế nào, lớp front end mà chuối là users cũng bỏ chạy rồi 
(Nguồn ảnh: Browserling.com)
Mình tự tin đặt 2 thằng này ngang hàng nhau. Và đây thường là điểm GAP rất lớn giữa…
3.2. Non-Functional Requirement tạo ra GAP lớn giữa…
…anh em làm outsource và làm product.
Thường những người làm triển khai/ outsource – như mình không quan tâm nhiều đến các Non-Functional Requirement. Vì end user của các giải pháp mình làm thường không phải là “end consumer”.
Mà end user thì không phải trả tiền để sử dụng hệ thống, end consumer mới là người trả tiền để sử dụng hệ thống.
Tức là end consumer mới là người sử dụng thông qua hệ thống.
Ví dụ anh em outsource làm hệ thống quản lý khách sạn Millennium, thì end user của hệ thống này là các Quản trị viên của hệ thống, các nhân viên phòng ban. Tức họ là ai? Là người của khách sạn. Không phải khách hàng.
Họ sẽ dụng hệ thống như một công-cụ-trung-gian giúp họ quản lý khách sạn tốt hơn mà thôi.
Còn đối với anh em làm product. Product ở đây có thể là ứng dụng đặt phòng trực tuyến của khách sạn Millennium. End user chính là end consumer. Họ vừa là người dùng ứng dụng, vừa là người trả tiền để sử dụng dịch vụ của Millennium.
Do đó, vấn đề “quality of service” của ứng dụng, hay các yếu tố non-functional của ứng dụng có làm họ vui hay không? Có làm họ thấy thoải mái khi sử dụng hay không? Ứng dụng chạy mượt không? vâng vâng… luôn được chú trọng hàng đầu.
Những yếu tố này góp phần KHÔNG-HỀ-NHỎ trong việc khách hàng ra quyết định: có tiếp tục sử dụng dịch vụ nữa hay không.
Chưa kể, làm product phục vụ end consumer, anh em phải phục vụ tới hơn cả triệu người dùng. Chứ không phải lẻ tẻ vài ba chục, hay chỉ vài trăm người dùng như những hệ thống quản lý back-end.
Chắc hẳn anh em còn nhớ vụ Momo lắc lì xì.
Chỉ trong vòng một ngày 24/1, Momo phải chịu tải lên đến hơn 2 triệu lượt đăng nhập và lắc cùng một lúc. Tức là hơn 2 triệu lượt CCU (concurrent users). Điều này có nghĩa đội ngũ anh em Momo phải liên tục xử lý tình trạng tắt nghẽn server. Kinh khủng!
Hoặc lâu lâu app có vấn đề gì thì phải lo cắm đầu fix ngay, kể cả có holiday hay weekend.
Vì giả dụ anh em down cái app được quảng cáo thiệt ngon về xài, mà mới chạm có 3-4 cái thấy lag banh chành, nút bấm gì mà tùm lum tùm la. Thì ngay lập tức: app bị delete cái một, và suốt đời nằm gọn trong blacklist.
Do đó, đây là GAP không hề nhỏ, liên quan đến “tư duy hành nghề” của những anh em làm outsource muốn chuyển qua làm product. Tuy nhiên, miễn là đừng ẩu và luôn chú ý cẩn thận thì mình nghĩ GAP cũng không quá lớn
.
.
.
Ô kê, hi vọng mình đã chém đủ mạnh để anh em hiểu về tầm quan trọng của Non-Functional Requirement (NFR). Biết nó quan trọng, chúng ta sẽ chú ý đến nó hơn.
Chú ý kể cả khi anh em đang làm triển khai những SaaS nhé. Những Software as a Service như Dynamics 365 của Microsoft. Có những thứ NFR mà mình chẳng thể can thiệp được, ví dụ như Security hay Accessibility của những SaaS này.
Những yếu tố NFR này được các hãng build sẵn thành một gói để chúng ta tiện triển khai và sử dụng.
Tuy nhiên, BA cũng cần nắm rõ những yếu tố NFR này ngay từ đầu dự án để tránh out of scope sau này, cũng như giải thích trước cho khách hàng để họ hiểu những điểm mạnh và hạn chế của giải pháp (tránh đòi thêm sau này).
Những NFR này thì các hãng đều có sẵn official document, anh em có thể dễ dàng tìm thấy bằng cụ Gồ
Câu hỏi cuối cùng, Non-Functional Requirement (NFR) gồm những loại nào?
Phần dưới đây mình sẽ nói sơ lược về các loại NFR hay gặp nhất, từ những gì mình lượm lặt được trong quá trình làm việc cũng như chia sẻ từ các bậc tiền bối
4. Các loại Non-Functional Requirement?
Sorry anh em, vì phần bốn này dài quá nên mình sẽ tách ra ở bài tiếp theo. Mình sẽ để link ở đây, vị trí này, anh em đón đọc nhé.
Phần này sẽ nói về các loại NFR, kèm các ví dụ cụ thể luôn cho anh em dễ hình dung
Tóm tắt
Bài này mình sẽ đúc kết bằng những dòng sau cho anh em dễ nhớ:
- Có 4 loại requirement: Business Req, Stakeholder Req, Solution Req và Transition Req (mình sẽ nói rõ hơn ở bài sau)
- Solution Requirement gồm: Functional và Non-Functional Req.
- Functional Requirement nói lên behaviors và functions của giải pháp (what the system do?)
- Non-Functional Requirement nói lên quality of services của giải pháp (how the system work?)
Phải luôn là Functional trước, rồi các yếu tố Non-Functional sẽ đi theo sau, đừng làm ngược lại (Nguồn ảnh: akfpartners.com)
That’s all! Hẹn gặp anh em ở bài sau nhé
Nguồn: thinhnotes.com
