Bạn có biết tại sao nhiều dự án phần mềm thất bại không? Theo Forbes, hai nguyên nhân chính là yêu cầu không rõ ràng và kế hoạch kém. Điều quan trọng để một dự án đạt được thành công là phải có các yêu cầu rõ ràng và chi tiết, bao gồm cả yêu cầu chức năng và phi chức năng.

Để tránh điều này, bạn hoặc nhóm dự án của bạn nên hiểu đầy đủ và phác thảo rõ ràng sự khác biệt giữa các yêu cầu chức năng và phi chức năng. Hiểu những khác biệt này là chìa khóa để thu thập thông tin phù hợp cho sự thành công của dự án.
 
Vì vậy, hãy cùng khám phá từng loại yêu cầu là gì và chúng khác nhau như thế nào.
 
1. Yêu cầu chức năng (Functional Requirements)
Yêu cầu chức năng mô tả các tính năng mà sản phẩm của bạn phải có để giúp người dùng đạt được mục tiêu của họ. Nó sẽ xác định cách hệ thống sẽ hoạt động trong các tình huống khác nhau.
 

1.1. Các loại yêu cầu chức năng:

Các yêu cầu chức năng có thể bao gồm: 
 
  • Hoạt động và quy trình làm việc: Những nhiệm vụ và quy trình nào mà sản phẩm nên thực hiện (chức năng chi tiết về các tính năng của sản phẩm).
  • Xử lý dữ liệu: Cách nhập và xuất dữ liệu cũng như đảm bảo dữ liệu ở đúng định dạng và hợp lệ.
  • Hành vi giao diện người dùng: Giao diện của sản phẩm sẽ hoạt động như thế nào khi người dùng tương tác với nó.
  • Tính toàn vẹn và bảo mật dữ liệu: Giữ dữ liệu chính xác, an toàn và bảo mật.
  • An toàn và tuân thủ: Đảm bảo sản phẩm đáp ứng các tiêu chuẩn an toàn và các quy định khác.
  • Quyền truy cập và ủy quyền của người dùng: Cách hệ thống kiểm tra và xác thực ai có thể sử dụng hoặc sửa đổi nó.

1.2. Các loại yêu cầu chức năng:

Yêu cầu chức năng phải rõ ràng, đơn giản và dễ hiểu. Dưới đây là một số ví dụ điển hình:

  • Hệ thống phải gửi email xác nhận bất cứ khi nào đơn hàng được đặt.
  • Hệ thống phải cho phép khách truy cập blog đăng ký nhận bản tin bằng email của họ.
  • Hệ thống phải cho phép người dùng xác minh tài khoản bằng số điện thoại của họ.
Trái ngược với suy nghĩ thường thấy, các yêu cầu chức năng không giống như User Stories , nhưng User Stories có thể giúp xác định yêu cầu nên là gì, tập trung vào nhu cầu của người dùng.
 
Một ví dụ về User Story:
  • Là người dùng hiện tại, tôi muốn đăng nhập vào tài khoản của mình.
Ví dụ tương tự về Functional Requirement:
  • Hệ thống phải cho phép người dùng đăng nhập bằng cách nhập email và mật khẩu của họ.
  • Hệ thống phải cho phép người dùng đăng nhập bằng tài khoản Google của họ.
  • Hệ thống phải cho phép người dùng đặt lại mật khẩu bằng cách nhấp vào "Tôi quên mật khẩu" và nhận email đến địa chỉ đã xác minh của họ.
2. Yêu cầu phi chức năng (Non-Functional Requirements)

Yêu cầu phi chức năng, hay NFR, là các thông số kỹ thuật mô tả cách hệ thống sẽ vận hành và các ràng buộc của nó. Họ tập trung vào các khía cạnh như tốc độ, bảo mật, độ tin cậy và tính toàn vẹn dữ liệu, nêu chi tiết hệ thống hoạt động tốt như thế nào hơn là chức năng của nó.

2.1. Các loại yêu cầu phi chức năng:

Các yêu cầu phi chức năng xác định hiệu suất tổng thể và các hạn chế của hệ thống. Những yêu cầu này đảm bảo rằng sản phẩm hoạt động hiệu quả, thân thiện với người dùng và dễ tiếp cận.
 
  • Hiệu suất: Hệ thống cung cấp kết quả nhanh như thế nào?
  • Khả năng mở rộng: Hệ thống xử lý khối lượng công việc ngày càng tăng tốt như thế nào?
  • Tính di động: Phần mềm, hệ điều hành và trình duyệt nào (bao gồm cả phiên bản của chúng) hoạt động với phần cứng nào?
  • Khả năng tương thích: Hệ thống có hoạt động tốt với các ứng dụng và quy trình khác không?
  • Độ tin cậy: Hệ thống có thường xuyên gặp lỗi nghiêm trọng không?
  • Khả năng bảo trì: Mất bao lâu để khắc phục sự cố và quản trị viên có thể quản lý hệ thống dễ dàng như thế nào?
  • Tính sẵn sàng: Hệ thống có thường xuyên hoạt động không?
  • Bảo mật: Sản phẩm có xử lý thông tin nhạy cảm một cách an toàn và có đáp ứng các tiêu chuẩn bảo mật CNTT không?
  • Tính khả dụng: Việc sử dụng hệ thống có dễ dàng không?

2.2. Ví dụ về yêu cầu phi chức năng:

Để hiểu rõ hơn về các yêu cầu phi chức năng, đây là một số ví dụ:

  • Mỗi trang sẽ tải trong vòng 3 giây
  • Quá trình này sẽ hoàn tất trong vòng 2 giờ để dữ liệu sẵn sàng trước 8 giờ sáng sau khi cập nhật qua đêm
  • Hệ thống phải tuân thủ các nguyên tắc tiếp cận nội dung web
  • Bảo mật cơ sở dữ liệu phải đáp ứng các yêu cầu của HIPAA
  • Người dùng phải được nhắc cung cấp chữ ký điện tử trước khi truy cập trang mới.
3. Sự khác biệt giữa Yêu cầu chức năng (Functional Requirement) và Yêu cầu phi chức năng (Non-Functional Requirement)
Cả yêu cầu chức năng và phi chức năng đều mô tả những gì sản phẩm phải có để đáp ứng nhu cầu của các bên liên quan và doanh nghiệp. Sự khác biệt chính là:
  • Yêu cầu chức năng phác thảo những gì phần mềm phải làm - các tính năng và chức năng của nó.
  • Yêu cầu phi chức năng mô tả cách hệ thống thực hiện các chức năng này.
Ví dụ: trong nền tảng nhắn tin, một yêu cầu chức năng có thể chỉ định rằng người dùng sẽ có thể gửi tin nhắn. Một yêu cầu phi chức năng sẽ chỉ định tốc độ hệ thống sẽ cho phép chỉnh sửa tin nhắn để đáp ứng mong đợi của người dùng.
 
Để biết thêm chi tiết về sự khác nhau giữa 2 loại yêu cầu này, hãy xem hình ảnh dưới đây:
 

4. Hướng dẫn chi tiết cách thiết lập Software Requirements (Yêu cầu phần mềm)

4.1. Tài liệu SRS:

Khi tạo phần mềm, việc ghi lại tất cả các yêu cầu trong tài liệu Đặc tả yêu cầu phần mềm (SRS) là rất quan trọng. Tài liệu này nêu chi tiết tất cả các tính năng và yêu cầu của hệ thống. Chất lượng SRS của bạn có thể ảnh hưởng đến chi phí phát triển và liệu sản phẩm cuối cùng có đáp ứng được mong đợi của khách hàng hay không.

 

Để viết tài liệu SRS, hãy làm theo các bước sau:
  • Biết mục đích, giá trị và các điều khoản chính của sản phẩm.
  • Liệt kê các tính năng chính, mô tả chúng, đặt tiêu chuẩn mã hóa, xác định quy tắc kinh doanh và lưu ý mọi hạn chế.
  • Mô tả cách hệ thống hoạt động, dữ liệu nào nó cần và mọi yêu cầu về cơ sở dữ liệu.
  • Giải quyết các nhu cầu về chất lượng, hiệu suất và bảo mật của phần mềm. 

4.2. Usecase:

Usecase mô tả cách hệ thống tương tác với người dùng. Usecase phác thảo mọi cách có thể mà người dùng có thể sử dụng một tính năng. Điều này bao gồm việc xác định vai trò của người dùng (ví dụ như các loại người dùng khác nhau) và nêu chi tiết các tính năng của hệ thống giúp người dùng đạt được mục tiêu của họ.

 

Ví dụ: trong một ứng dụng tập thể dục, trường hợp sử dụng có thể là: “Khi người dùng chọn 'Theo dõi bước đi' từ menu, ứng dụng sẽ hiển thị tiến trình hàng ngày của họ".
 

4.3. User Stories:

User Stories tập trung vào những gì người dùng muốn từ hệ thống và những gì hệ thống cần làm cho họ. Chúng là những mô tả ngắn gọn, đơn giản về nhu cầu của người dùng.

Tất cả các User Stories nên phù hợp với tiêu chí mô hình INVEST:

I – Independent  – Độc lập  
N – Negotiable  – Thỏa thuận  
V – Valuable  – Có giá trị  
E – Estimable  - Có thể ước tính  
S – Small  - Nhỏ  
T – Testable  - Có thể kiểm tra  
Một cấu trúc User Story điển hình bao gồm vai trò người dùng (ai), mục tiêu (họ muốn làm gì) và lý do (tại sao họ muốn làm điều đó).
 
Ví dụ: trong dịch vụ đặt phòng, người dùng có thể mong đợi tìm thấy thanh tìm kiếm để tìm nơi lưu trú và kiểm tra xem đặt phòng của họ đã được xác nhận hay đang chờ xử lý. Trong một ứng dụng thể dục, người dùng có thể nói, "Tôi muốn theo dõi các bước của mình hàng ngày để xem tôi hoạt động như thế nào."
 
5. Mẹo để tài liệu hóa Software Requirements
Tạo tài liệu tốt là rất quan trọng đối với bất kỳ dự án phần mềm nào. Các yêu cầu được viết tốt đảm bảo mọi người đều hiểu rõ và giúp xác định phạm vi và ngân sách của dự án. Dưới đây là một số mẹo để tạo một tài liệu tốt:
 

 

  • Giữ cho tài liệu rõ ràng: Đảm bảo các yêu cầu của bạn dễ hiểu và không có biệt ngữ. Sử dụng hình ảnh, sơ đồ và đồ thị để làm cho thông tin dễ tiếp thu hơn. Việc thêm bảng chú giải thuật ngữ và liên kết chéo cũng có thể hữu ích.
  • Cụ thể và đầy đủ: Viết các yêu cầu chính xác, chính xác bao gồm mọi tình huống mà không có mâu thuẫn. Tránh các thuật ngữ mơ hồ như "hệ thống phải nhanh" và thay vào đó sử dụng các thuật ngữ rõ ràng, có thể đo lường được.
  • Làm cho nó có thể kiểm tra được: Đảm bảo các yêu cầu của bạn được viết để bạn có thể kiểm tra xem chúng có được đáp ứng thành công hay không sau khi sản phẩm được xây dựng.
  • Giữ tính khả thi: Tập trung vào các tính năng và thuộc tính chất lượng mà người dùng cần. Đảm bảo rằng các yêu cầu của bạn phản ánh các mục tiêu kinh doanh cấp cao hơn.
6. Kết luận
Mọi dự án phần mềm đều bắt đầu với tầm nhìn, mục đích và đích đến rõ ràng. Để đạt được mục tiêu đó một cách suôn sẻ, bạn cần có các yêu cầu chức năng và phi chức năng. Những yêu cầu này đóng vai trò là lộ trình của bạn, đặt ra ranh giới rõ ràng và giúp bạn trả lời các câu hỏi chính để đảm bảo sự thành công của dự án.
 
Nguồn tham khảo:


Nhu cầu đào tạo doanh nghiệp

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.
 
 

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất

Ban biên tập nội dung - BAC